Стоит задача хранить большое количество сообщений приходящих постоянно с транспортных средств. Сообщения содержат параметры в весьма разнообразной форме (имеется несколько типов сообщений, в будущем не исключена возможность динамической, а не фиксированной структуры). Эти параметры в последствии используются для построения разнообразных отчетов.
Конкретно по объему приходящих сообщений: в рабочее время держится уровень 15-20 сообщений в секунду, ночью значительно меньше, но сообщения идут круглосуточно. Хотелось бы обеспечить хранение для средней скорости поступления 100 сообщений в секунду.
1. Первая попытка была для реляционной базы данных.
Так как структура сообщений разнится, то я решил выделить параметры сообщения в отдельную таблицу (связывая строки-параметры с сообщением через foreign key). На каждое сообщение приходится примерно 10-15 параметров в среднем. Но тогда получается, что в секунду у меня в среднем будет создаваться 100 * 15 = 1500 строк-параметров. Сколько это в месяц? 1500 * 3600 * 24 * 30 = ...3888000000 . Кхе-кхе-кхе. Я разделю пробелами: 3 888 000 000. Почти 4 миллиарда! Такой объем просто неподъемен для операций джойна (мне надо будет выбирать сообщения для одного транспортного средства и к ним джойнить все соответствующие параметры). Кроме того - сколько это займет на жестком диске? Возможные варианты оптимизации в таком случае - разбиение таблицы (поддерживается постгресом).
2. Альтернативный вариант для реляционной БД - не выделять параметры в отдельную таблицу. Но тогда придется создать пригодную для всех структур сообщений схему. Скорее всего это будет большое число колонок, которые будут заполняться частично в зависимости от сообщения. Решение такое не гибкое и не позволяет детально описывать значения параметров, однако избавляет нас от джойна и излишне большого числа строк. В таком сценарии мы будем ограничены 200-300 миллионами записей в месяц. Неприятно но, думаю, возможно.
Данные, имеющие возраст более месяца можно будет архивировать, так что значения для одного месяца примерно и будут представлять собой среднюю загруженность базы данных.
3. Кардинальная альтернатива - использование дивных зверей из лагеря NoSQL. По крайней мере среди них есть два кандидата, предлагающие решение проблемы разнящейся структуры сообщений. Это MongoDB и CouchDB, так называемые schema-less базы данных. Записи в них грубо говоря имеют JSON вид и ничто не мешает нам добавлять произвольные аттрибуты в произвольную запись. Запросы по атрибутам имеются, что выгодно отличает эти две базы данных от простых key/value баз данных. Однако, произвольность аттрибутов, говорят, ведет к обильному пожиранию дискового пространства. Вобщем тут тоже не без проблем.
На данный момент склоняюсь ко второму варианту. Он хоть архитектурно и не красив, но по крайней мере выглядит наиболее жизнеспособным для реальных боевых условий.
Конкретно по объему приходящих сообщений: в рабочее время держится уровень 15-20 сообщений в секунду, ночью значительно меньше, но сообщения идут круглосуточно. Хотелось бы обеспечить хранение для средней скорости поступления 100 сообщений в секунду.
1. Первая попытка была для реляционной базы данных.
Так как структура сообщений разнится, то я решил выделить параметры сообщения в отдельную таблицу (связывая строки-параметры с сообщением через foreign key). На каждое сообщение приходится примерно 10-15 параметров в среднем. Но тогда получается, что в секунду у меня в среднем будет создаваться 100 * 15 = 1500 строк-параметров. Сколько это в месяц? 1500 * 3600 * 24 * 30 = ...3888000000 . Кхе-кхе-кхе. Я разделю пробелами: 3 888 000 000. Почти 4 миллиарда! Такой объем просто неподъемен для операций джойна (мне надо будет выбирать сообщения для одного транспортного средства и к ним джойнить все соответствующие параметры). Кроме того - сколько это займет на жестком диске? Возможные варианты оптимизации в таком случае - разбиение таблицы (поддерживается постгресом).
2. Альтернативный вариант для реляционной БД - не выделять параметры в отдельную таблицу. Но тогда придется создать пригодную для всех структур сообщений схему. Скорее всего это будет большое число колонок, которые будут заполняться частично в зависимости от сообщения. Решение такое не гибкое и не позволяет детально описывать значения параметров, однако избавляет нас от джойна и излишне большого числа строк. В таком сценарии мы будем ограничены 200-300 миллионами записей в месяц. Неприятно но, думаю, возможно.
Данные, имеющие возраст более месяца можно будет архивировать, так что значения для одного месяца примерно и будут представлять собой среднюю загруженность базы данных.
3. Кардинальная альтернатива - использование дивных зверей из лагеря NoSQL. По крайней мере среди них есть два кандидата, предлагающие решение проблемы разнящейся структуры сообщений. Это MongoDB и CouchDB, так называемые schema-less базы данных. Записи в них грубо говоря имеют JSON вид и ничто не мешает нам добавлять произвольные аттрибуты в произвольную запись. Запросы по атрибутам имеются, что выгодно отличает эти две базы данных от простых key/value баз данных. Однако, произвольность аттрибутов, говорят, ведет к обильному пожиранию дискового пространства. Вобщем тут тоже не без проблем.
На данный момент склоняюсь ко второму варианту. Он хоть архитектурно и не красив, но по крайней мере выглядит наиболее жизнеспособным для реальных боевых условий.
Комментариев нет:
Отправить комментарий