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

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

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

В общем зависит от объёма потока, нужно тестировать, с этим не поспоришь.

даже удвоенный трафик будет 10МБайт/с - просто не о чем говорить.

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

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

Тогда либо nosql-решение (couchdb, mongodb, xml-базы итд), либо настраивать костыль поверх РСУБД (EAV). Первый вариант таки лучше, не надо насиловать инструменты.

> 10 Мб/сек это ничто по сравнению с линейной скоростью современных дисков, но для смешанной нагрузки предел может быть ниже десятки.

Откуда там смешанная нагрузка? СУБД тоже умеет оптимизировать дисковый трафик.

Индексы дают большую фрагментацию, сами по себе файлы данных будут фрагментироваться со временем и на уровне блоков бд, и на уровне кластеров фс. Последнее будет сказываться после нескольких циклов перезаписи данных в таблице, особенно если поток будет неравномерным по времени. Bulk upload это не конёк рСУБД.

> Последнее будет сказываться после нескольких циклов перезаписи данных в таблице, особенно если поток будет неравномерным по времени

10МБайт/с - это максимум %)

Bulk upload это не конёк рСУБД.

Я не вижу здесь ничего, даже отдаленно напоминающего bulk

Ничего не пойму - что сложного то в БД? Ну много типов объектов (сколько? не бесконечно же), делайте по отдельной табличке на объект :) (шучу конечно, хотя тоже выход). Всё что вы описали в загаловке - реализуется sql, репликацией и бекапами. Классика.

А с чего все взяли, что будет большая нагрузка на БД? Ну 50к объектов. Ну write раз в 1 с. И что? Никто наверное не понимает, о чём речь.. Если я правильно понимаю:

Есть прибор с датчиками. Пишет инфу, пусть раз в 1 с. Её нужно скидывать на сервер. По GSM. Таких датчиков 50к... Улавливаете? Проблема раз - коннект датчика с сервером. Тем более их 50к. Как это обычно делается - n-ое количество многоканальных GSM-шлюзов, на которые звонят приборы. Естественно будет занято или обрыв etc. То-есть прибор, для сохранения непрерывности данных - пишет всё в свою память. При дозвоне - разом скидывает накопившееся. Какие буду задержки при всём этом хозяйстве - только считать, тестировать, эксплуатировать, тюнить GSM-каналы. БД тут - детский лепет.

Да ничего сложного, в общем-то. Просто не нравится (ну, лично мне вот не нравится) стиль — а возьмём-ка агромаднейшую, сложную штуку, и она за нас всё сделает. Ты всмотрись в постановку задачи: ну где там СУБД? Сложноструктурированные данные на полсотни взаимосвязанных таблиц? Непредсказуемые, широко разнообразные запросы? Ну да, я старой школы, начинал на М-222, может, где-то и устарел. Но вот смотрю я на современную суперпрограмму отслеживания UPS — она периодически пишет в com-порт «ATI2», получает пять чисел и выводит в виде графика — дык! Ява! 50 мегов инсталляция! Таки да, с меня и с компа не убудет... Тошнит просто почему-то...

Повторюсь на всякий случай: бинарный единый лог. При достижении предельного размера — закрываем и открываем следующий. Последнее местоположение каждого объекта храним в отдельном файле с прямым доступом. Возможен, например, такой вот вариант: писать туда только время и место, так что записи фиксированной длины. К нему нужен какой-то простенький индекс в памяти, hash либо дерево. Кстати, хоть и не спрашивал: поступившую информацию можно не писать в лог, если географически объект не ушёл далеко — сильно экономишь, если, например, объект спит себе на одном месте 8 часов... Ещё один простенький файлик — время начала и окончания, местоположение (локально, архив, ещё чего-нить) каждого частичного файла лога... Для поставленной задачи — таки всё.

Есть, конечно, смысл сесть и подумать, может, есть ещё какие требования — это может всё изменить. Но даже и так, в качестве прототипа — достаточно полезная штука, на которой можно получить немало опыта и понимание, куда двигаться дальше. И перекрутить во что угодно несложно, и выбросить не жалко...

> Сложноструктурированные данные на полсотни взаимосвязанных таблиц?

Не на полсотни, но несколько таблиц будет.

Непредсказуемые, широко разнообразные запросы?

А вот это наверняка.

>Ты всмотрись в постановку задачи: ну где там СУБД

Это я говорю - брать СУБД без вариантов (вариант - только при testfail, ТЗ ж никто не видел). Бинарник при кучи разных типов данных, от 50к источников? Мда.. Вы подумайте, для чего данные пишутся то. Мы например - делали разные GUI, с прокрутками времени, посроениями маршрутов, графиков расхода топлива, спецсигналом в риалтайме от девайса и т.д.. Хачить свою выборку с активно пишущегося лога с разностороними данными? Я даже не представляю, как это будет «работать» и на каком железе.

mnesia?

Ну, таки во-первых — я ж не на ваш вопрос отвечаю. Вы, собственно, и не спрашивали ни о чём. В исходном вопросе — три требования.

Разные GUI, прокрутки времени — это вообще параллельные вопросы. Они от способа хранения, по-хорошему, никак не зависят.

Построения маршрутов — если имеется кая-нить ГИС, предъявляющая требования к представлению маршрута — это вообще отдельная тема.

Выборка с активно пишущегося лога — ви таки усматриваете здесь некую проблему? Я не знаком с тонкостями процесса GPS/GSM мониторинга, но, надеюсь, не предусматривается постоянное поддержание 50000 TCP-сессий или установка оных раз в от секунды до 5 мин? Полагаю, что-то типа UDP хотя бы. То бишь, один активно пишущий процесс и сколько угодно читающих — вполне себе несложная задача, бинарник там ли не бинарник. Процесс чтения — по временному интервалу определили файлы и читаем подряд с отбором нужных записей. Всяко быстрее, чем человек успеет устать. Или вы думаете, что текстовое файло со строками переменной длины читать, например, в редактор сильно проще?

Графики расхода топлива — вообще не представляю. Да, это, возможно, потребует СУБД, не спорю.

Спецсигнал в риалтайме от девайса — это что? Реакция на появление объекта в определённом месте? Это просто. Или что-то другое?

Сколько? Пока вижу одну. Из-за дополнительных, неизвестных заранее столбцов при укладке в SQL-сервер появится ещё несколько, но мы ж как раз и обсуждаем, стоит ли укладывать в оный сервер.

Наверняка будет ещё одна — с информацией об объекте, ну, хотя бы название или чего ещё.

Две — это, конечно, несколько, но не настолько уж много, чтобы непременно городить СУБД. Имхо, конечно.

Насчёт разнообразных запросов — ну, как я сказал, в исходном сообщении про это ничего не говорится. Например?

>А с чего все взяли, что будет большая нагрузка на БД? Ну 50к объектов.

ALTER TABLE с добавление столбца на базе форума с 2млн. сообщений в mysql на Q9440 с 16Гб оперативки длится около 40 минут для myisam и раза в 2-3 дольше для innodb. Всё это время таблица недоступна, сотни клиентов сидят и ждут...

Добавление «столбца» в копию этой БД в mongodb ничего не стоит, так как отсутствует понятие столбца, а индекс добавляется за считанные минуты в фоновом режиме, без прекращения доступа.

Я только ради этого подумываю о переходе на mongodb :) А так - пока приходится модификации откладывать неделями на ночь на выходные и потом добавлять на всякий случай сразу штук по пять полей int'ов и varchar'ов с глубокомысленными именами `field3`, `field4`... На всякий случай, если понадобится новое поле, чтобы ещё неделю-другую не ждать :)

Ужас, так жить нельзя. Но для этого я и посоветовал написать тестовые скрипты.

А что за схема базы? Что-то из open source форумов или самописанное?

>А что за схема базы? Что-то из open source форумов или самописанное?

В общем случае - не принципиально. Модификация больших таблиц под MySQL - это адъ. А в частном случае - да, свой форум. Регулярно какой-нибудь функционал вводишь - приходится модифицировать. Я итак уже все вычисляемые данные, типа места по IP, или браузера/ОС по user-agent храню в параллельной таблице. При модификациях в ней проще, можно тупо грохнуть всё, оно потом понемногу пересоздастся...