Выбор БД для хранения данных

Смотрю в сторону MongoDB

По условию задачи тебе не надо искать по произвольным данным, поэтому их можно благополучно сериализовать, а в качеств бд использовать postgres/mysql.

P.S. Что-то вас прорвало, прям.

> Данных может быть очень много.

Это сколько?

Postgres

На кой тут вообще БД? Обычные файлы, по времени или при достижении размера — переключаешься на следующий. Текущие положения объектов и отрезки времени на каждый файл держать где-нить отдельно...

Порядка 50000 мобильных объектов с частотой отправки данных от 1 секунды до 5 минут.

Тоже конечно вариант, надо его обдумать

Postgres

Аргументируйте

> с частотой отправки данных от 1 секунды до 5 минут.

Ты, конечно, понимаешь, что это дает разницу в 300 раз? %) А от этого зависит решение.

Ты, конечно, понимаешь, что это дает разницу в 300 раз? %) А от этого зависит решение.

Это зависит от множества факторов. Можно принять среднюю частоту трека - раз в минуту

у него расширение для гео- данных?

У sqlite тоже есть: http://www.sqlite.org/rtree.html, правда я не знаю, насколько оно вообще тут уместно.

> Можно принять среднюю частоту трека - раз в минуту

Тогда 50000*(60*24*60) ~4.3млрд записей в 2 месяца. Думаю, Постгрес справится, но это вполне проверяется на среднем десктопе.

у него расширение для гео- данных?

Это не критично. Геоданные мы только сохраняем

Постгрес это хорошо, но вот в случае с файлами мы можем «прозрачно» детачить файлы. А как у постгреса. Т.е. пометить что данные есть, но они «по запросу»

> вот в случае с файлами мы можем «прозрачно» детачить файлы. А как у постгреса. Т.е. пометить что данные есть, но они «по запросу»

Что такое «детачить файлы»? %) Если речь идет об архиве (для данных, которые старше 2 месяцев), просто выгружай их в другую БД.

Уводить их совсем. К примеру на другой хост. В таком случае гонять их между разными бд не так быстро

> Уводить их совсем. К примеру на другой хост.

Может, я чего-то не понимаю, но кто мешает сделать архивную БД на другом хосте?

...или, если нужно обязательно хранить данные в единой БД, сделать для архивных данных отдельный tablespace, и хостить его где-нибудь в SAN.

> вот в случае с файлами мы можем «прозрачно» детачить файлы.

а какого рода файлы имеются ввиду? текстовые( как тут предлагали ), flat, просто локальные?

а какого рода файлы имеются ввиду? текстовые( как тут предлагали ), flat, просто локальные?

Я еще не продумывал этот вариант :)

Не нужна никакая специальная бд, просто бинарный лог в файл с добавлением каждой новой записи в конец.

> просто бинарный лог в файл с добавлением каждой новой записи в конец.

а как вы предполагаете: 50000 клиентов на запись и х/з сколько клиентов на поиск данных из этого файла - это рядовая задача для простого себе бинарного лога размером в 4.3млрд записей?

> 50000 клиентов на запись

Нет там 50000 клиентов %)

sqlite

> Нет там 50000 клиентов %)

«Порядка 50000 мобильных объектов» - а как вы их назовете?

а как вы предполагаете: 50000 клиентов на запись и х/з сколько клиентов на поиск данных из этого файла - это рядовая задача для простого себе бинарного лога размером в 4.3млрд записей?

Если вы считаете, что существуют на свете хранилища которые делают иначе, то наивно заблуждаетесь. От простой современной ФС и до громоздкой рСУБД все это делают именно так и никак иначе.

Да, для бинарного лога (в виде одного или нескольких файлов) это обычная нагрузка/задача.

> Если вы считаете, что существуют на свете хранилища которые делают иначе, то наивно заблуждаетесь. От простой современной ФС и до громоздкой рСУБД все это делают именно так и никак иначе.

Да, для бинарного лога (в виде одного или нескольких файлов) это обычная нагрузка/задача.

ну что ж, этот вопрос за сегодня мне приходится задать уже не в первый раз, покажите - как вы будете решать поставленные задачи:

а) получить все треки устройства за период с ... по ...
б) вытеснять старые данные в бэкап

П.С. чуть подправил

А про различные структуры для работы с данными на внешних носителях (B-деревья, например) тебе в школе не рассказывали?

Вопросы достаточно глупые.

а) локализуем кусок (или диапазон кусков) бинлога по временам чекпоинтов (даты создания новых кусков) + последовательное чтение куска бинлога или бинарный поиск.

б) см. пункт а.

а) локализуем кусок (или диапазон кусков) бинлога по временам чекпоинтов (даты создания новых кусков) + последовательное чтение куска бинлога или бинарный поиск.

Как минимум если у нас один бинлог на всех нам прийдется просканить весь кусок бинлога

> Вопросы достаточно глупые.

просто это ты кретин

а) локализуем кусок (или диапазон кусков) бинлога по временам чекпоинтов (даты создания новых кусков) + последовательное чтение куска бинлога или бинарный поиск.

хочу посмотреть за два месяца - 4.3млрд записей, каким х%ем ты там прикрутишь бинарный поиск для поиска расположения определенного устройства?

б) см. пункт а.

да - это несомненно очень связанные задачи

Как минимум если у нас один бинлог на всех нам прийдется просканить весь кусок бинлога

Смотря как его писать. Если просто по факту прибытия данных, то в худшем случае такой же точно бинарный поиск по времени + немного сканов. В лучшем, т.е. если применять нужные хитрости в структуре, будет почти тоже самое.

хочу посмотреть за два месяца - 4.3млрд записей, каким х%ем ты там прикрутишь бинарный поиск

если у тебя совсем туго с сообразительностью, то я тебе помочь ничем не могу. Могу только дать подсказку на пальцах: подели свои 4.3 млрд записей частей эдак на 1000 - 10000 кусков и попробуй найти нужный кусок по mtime.

> если у тебя совсем туго с сообразительностью, то я тебе помочь ничем не могу. Могу только дать подсказку на пальцах: подели свои 4.3 млрд записей частей эдак на 1000 - 10000 кусков и попробуй найти нужный кусок по mtime.

предлагаешь выделить место под файл заранее и потом шерстить рукам его куски? замечательное решение, ведь оно заодно решает проблемы:

а) масштабирования - можно легко удвоить кол-во клиентов, или пережить их пиковую активность
б) вытеснять данные в бэкап - все так же просто и удобно

> «Порядка 50000 мобильных объектов» - а как вы их назовете?

Так и назову. А клиент (записывающий) там будет, вероятно, один - программа для сбора информации с этих «объектов».

> Так и назову. А клиент (записывающий) там будет, вероятно, один - программа для сбора информации с этих «объектов».

по такой логике любой прокси-сервер - это клиент, а все что за ним - «объекты»

предлагаешь выделить место под файл заранее и потом шерстить рукам его куски?

Вы где-нибудь видели такие бинлоги? Если да, назовите где. Каждый кусок это отдельный файл с определённым кол-вом записей и/или размером + общая система именования файлов.

> Каждый кусок это отдельный файл с определённым кол-вом записей и/или размером + общая система именования файлов.

файлы бьются по дате или клиентам?

> по такой логике любой прокси-сервер - это клиент, а все что за ним - «объекты»

Просто ты не понимаешь, о чем речь. «Объекты» - это объекты, за положением которых ведется наблюдение. Это наблюдение ведет одна или несколько программ, но никак не 50000.

> Просто ты не понимаешь, о чем речь. «Объекты» - это объекты, за положением которых ведется наблюдение. Это наблюдение ведет одна или несколько программ, но никак не 50000.

конечно - всегда проще обвинить собеседника в непонимании :) вы просто подменяете понятия, «объект» в данном случае - это и есть клиент, который шлет данные на сервер, да - между СУБД(?) и ним есть прослойка, которая подправляет данные и «шлет» их дальше, и это кстати рядовая операция для СУБД - вы должны это знать

файлы бьются по дате или клиентам?

В самом простом разумном случае бьются по объектам, т.е. для каждого объекта свой поток бинлогов, и по мере заполнения (не по дате). Т.е. будет набор логов типа «%06x:%016x», где первое это номер объекта в hex форме, а второе серийный номер лога.

Чтобы был при этом быстый поиск, нужно к каждому объекту сделать ещё один циклический бинлог с записями (timestamp, seqnum, crcXX, прочая тех ерунда), примерно будет 32 байта каждая запись. Если взять конечный целевой размер циклического лога около 64-128 кб, будет порядка 2 - 4к записей, т.е. для поиска за последние несколько месяцев должно хватить. Чтение и анализ циклического лога занятие копеечное.

Любая промышленная СУБД (postgres, firebird, mysql). Просто пишите данные. В момент X (как правило, когда объём БД вырастет до критической точки) - sql скриптом удаляете старые месяцы (дни etc). Делаете бекапы (все нормальные СУБД делают налету), архивируете, складируете. Надо будет - развернёте старый бекап нужного периода на другом сервере. Не ведитесь на советы про бинарный файл, лог. Главное - не берите коммерческую СУБД, разоритесь на лицензиях :) (50000 кл.).

PS Работал с GPS-GSM мониторингом, со cвоими датчиками на автотранспорте (коммерческое решение для автопредприятий). Ничего интересного - координаты, скорость, топливо, спецсигналы. Писались с разными таймаутами, кому что надо. Над СУБД вообще не заморачивались. Были и такие, и такие. Из коробки - mysql. Сказали: «нет своего админа mysql», - взяли другую СУБД и т.д..

> конечно - всегда проще обвинить собеседника в непонимании :)

Еще проще пропустить объяснение.

>Каждый пакет имеет набор обязательных полей (координаты, ид объекта и т.д.) и имеет набор произвольных (к примеру состояние кнопок, уровень батареи, датчиков и т.д.)

А ты уверен что произвольные данные действительно произвольные? Ведь если определиться точно с этими данными, то можно без вопросов использовать РСУБД, без всякие nosql решений.

> Еще проще пропустить объяснение.

да, я так и поступил, вы правы - в данном случае роль клиента/сервера выполняет именно «буферная» программа, которая работает с БД, а «объекты» выполняют роль серверов - и отвечают на запросы

Любая промышленная СУБД (postgres, firebird, mysql). Просто пишите данные.

Нужно так же пояснить, что любая такая СУБД будет генерировать как минимум двойной дисковый трафик по отношению к оригинальномому потоку. Если всё это добро обмазано индексами (как же без них в рСУБД делать выборки? Можно, конечно, но будет отдельный гемор...), то поток возрастёт более чем в два раза. Ещё будет достаточно много random read/write, что совсем убъёт производительность СУБД.

Веб-прокси-сервер обязан обслужить всех клиентов одновременно.

Данные же можно поставить в очередь.

Нормально всё сделать - всё будет работать. В идею бинарника я даже не вчитывался. Увидел задачу - назвал инструменты, тем более исходил из опыта. Может быть в каких-то случаях бинарник выход (не встречал ещё, кроме игрушек :) ). Но в любом случае классический клиент-сервер с СУБД проще, быстрее, надёжней сделать (для этого СУБД собственно и существуют). Нормально поддерживать, чем смотреть на какой-то хак с бинарником, написанным уволившимся 3 года назад Васей Пупкиным. Подробностей задачи я не знаю. Как я понял - данные простые, можно спокойно набросать тестовые скрипты и проверить разные варианты (заодно посмотреть на производительность). Но это уже дело TC.

> Как я понял - данные простые, можно спокойно набросать тестовые скрипты и проверить разные варианты (заодно посмотреть на производительность)

+1

> любая такая СУБД будет генерировать как минимум двойной дисковый трафик по отношению к оригинальномому потоку.

Во-первых, не факт; во-вторых, даже при опросе каждую секунду и размере записи в 100Б имеем 50000*100 == 5МБайт/с; даже удвоенный трафик будет 10МБайт/с - просто не о чем говорить.