Лучшая база данных для удаленной регистрации данных датчиков

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

Указанные данные необходимо запрашивать различными способами: от подсчета данных с определенными характеристиками для статистики до простого вывода для построения графика.

Я ищу подходящий инструмент, я начал с MySQL, но мне кажется, что ему не хватает масштабируемости, необходимой для этого проекта, и это привело меня к базам данных noSQL, о которых я мало что знаю.

Какая база данных, реляционная или нет, будет хорошим выбором?

Спасибо.


person Mike    schedule 29.06.2012    source источник
comment
Средний веб-сайт на основе MySQL постоянно имеет 10 000 пользователей онлайн, генерируя данные (сообщения, клики...) каждую секунду. Так почему бы этому не покрыть датчики 10K, которые генерируют несколько байтов каждую минуту?   -  person Damir Sudarevic    schedule 29.06.2012
comment
Вы хотите получить доступ к данным в реальном времени / почти в реальном времени? Или будет нормально, если данные будут доступны для запроса через некоторое время после их сбора (например, на следующий день)?   -  person Frank Schmitt    schedule 29.06.2012
comment
Данные должны быть доступны в режиме реального времени, если это возможно, задержка в минуту допустима для проекта, но точно не в один день.   -  person Mike    schedule 30.06.2012


Ответы (3)


Обычно не существует «лучшей» базы данных, поскольку все они предполагают компромиссы того или иного рода. Ваш вопрос также очень расплывчатый, потому что вы ничего не говорите о своих потребностях в производительности, кроме количества вставок в минуту (сколько данных за вставку?) И что вам нужна «масштабируемость».

Это также похоже на случай преждевременной оптимизации, потому что вы говорите, что «чувствуете, что [MySQL] не хватает масштабируемости, необходимой для этого проекта», но это не похоже на то, что вы запускали какие-либо тесты, чтобы подтвердить действительно ли это проблема. Всегда лучше получить реальные данные, чем основывать важное архитектурное решение на «чувствах».

Вот предложение:

  1. Напишите простую тестовую программу, которая вставляет 10 000 строк выборочных данных в минуту.
  2. Запустите программу в течение приличного промежутка времени (несколько дней или более), чтобы сгенерировать значительный кусок тестовых данных.
  3. Запустите свои запросы, чтобы увидеть, соответствуют ли они вашим потребностям в производительности (которые вы не указали — насколько быстрыми они должны быть? как часто они будут выполняться? насколько они сложны?)

Здесь вы проверяете как минимум две вещи: может ли ваша база данных обрабатывать 10 000 вставок в минуту и ​​будут ли ваши запросы выполняться достаточно быстро, когда у вас будет огромный объем данных. С большими наборами данных они станут конкурирующими приоритетами, поскольку вам нужны индексы для быстрых запросов, но индексы со временем начнут замедлять ваши вставки. В какой-то момент вам также нужно будет подумать об архивации данных (или очистке, если исторические данные не нужны) как для производительности, так и по практическим причинам (ограниченное пространство для хранения).

Это будет проблемой независимо от того, какую базу данных вы выберете. Судя по тому немногому, что вы рассказали нам о своих потребностях в поиске («подсчет данных с определенными характеристиками» и «простой вывод для построения графика»), похоже, что подойдет любой тип базы данных. Возможно, важнее другие проблемы, такие как простота разработки (какие языки и инструменты вы используете?), развертывание, управление, ремонтопригодность кода и т. д.

Поскольку речь идет о данных датчиков, вы также можете просмотреть базу данных циклического перебора (RRD), такую ​​как RRDTool, чтобы увидеть, подходит ли этот подход для ваших нужд.

person John Landahl    schedule 29.06.2012
comment
Еще одно соображение: как данные с этих 10 000+ устройств попадут в вашу базу данных? Планировали ли вы, чтобы все они подключались напрямую к серверу (вероятно, очень плохая идея по ряду причин) или есть центральный сборщик, который выполняет все вставки? Думали ли вы об использовании очереди сообщений (например, ActiveMQ, HornetQ, RabbitMQ) для управления входящими данными? - person John Landahl; 29.06.2012
comment
Большое спасибо за предложение, мне как дилетанту точно не хватало правильного подхода к проблеме. Я попробую запустить предложенные вами тесты и посмотреть, как они пойдут. Чтобы ответить на ваши вопросы о запросах, они будут гораздо реже, чем вкладыши. Также я никогда не слышал об очередях сообщений, и спасибо за подсказку. Я обязательно проверю их. Кроме того, как вы думаете, есть ли какие-либо существенные минусы при выборе между базой данных SQL или базой данных noSQL для этого типа проекта? Простота масштабируемости, рекламируемая некоторыми из них, заинтриговала меня, но я никогда не использовал ни одну из них. - person Mike; 30.06.2012
comment
Индексы не будут замедлять вставку с течением времени. Вставка данных в дерево — это O(logN). Сначала это может быть медленно, но со временем не становится хуже. - person jva; 17.07.2012

Нашел этот вопрос при поиске в Google «базы данных для данных датчиков». Одним из очень полезных результатов поиска (наряду с этим вопросом SO) был этот блог:

На самом деле я начал аналогичный проект (http://reatha.de), но слишком поздно понял, что использую не самые лучшие технологии. Мой подход был похож на MySQL + PHP. В конце концов я понял, что это не масштабируется, и остановил проект.

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

Надеюсь, это поможет.

person Community    schedule 31.01.2014

вы можете попробовать использовать базу данных Redis noSQL

person Saurny    schedule 29.06.2012
comment
Это бесполезный ответ, потому что он не решает никаких проблем исходного плаката (какими бы расплывчатыми они ни были) и не дает никакого обоснования того, почему Redis является подходящим инструментом для работы. Любой может погуглить nosql и увидеть, что Redis является одним из (многих) вариантов. - person John Landahl; 29.06.2012