Обычно не существует «лучшей» базы данных, поскольку все они предполагают компромиссы того или иного рода. Ваш вопрос также очень расплывчатый, потому что вы ничего не говорите о своих потребностях в производительности, кроме количества вставок в минуту (сколько данных за вставку?) И что вам нужна «масштабируемость».
Это также похоже на случай преждевременной оптимизации, потому что вы говорите, что «чувствуете, что [MySQL] не хватает масштабируемости, необходимой для этого проекта», но это не похоже на то, что вы запускали какие-либо тесты, чтобы подтвердить действительно ли это проблема. Всегда лучше получить реальные данные, чем основывать важное архитектурное решение на «чувствах».
Вот предложение:
- Напишите простую тестовую программу, которая вставляет 10 000 строк выборочных данных в минуту.
- Запустите программу в течение приличного промежутка времени (несколько дней или более), чтобы сгенерировать значительный кусок тестовых данных.
- Запустите свои запросы, чтобы увидеть, соответствуют ли они вашим потребностям в производительности (которые вы не указали — насколько быстрыми они должны быть? как часто они будут выполняться? насколько они сложны?)
Здесь вы проверяете как минимум две вещи: может ли ваша база данных обрабатывать 10 000 вставок в минуту и будут ли ваши запросы выполняться достаточно быстро, когда у вас будет огромный объем данных. С большими наборами данных они станут конкурирующими приоритетами, поскольку вам нужны индексы для быстрых запросов, но индексы со временем начнут замедлять ваши вставки. В какой-то момент вам также нужно будет подумать об архивации данных (или очистке, если исторические данные не нужны) как для производительности, так и по практическим причинам (ограниченное пространство для хранения).
Это будет проблемой независимо от того, какую базу данных вы выберете. Судя по тому немногому, что вы рассказали нам о своих потребностях в поиске («подсчет данных с определенными характеристиками» и «простой вывод для построения графика»), похоже, что подойдет любой тип базы данных. Возможно, важнее другие проблемы, такие как простота разработки (какие языки и инструменты вы используете?), развертывание, управление, ремонтопригодность кода и т. д.
Поскольку речь идет о данных датчиков, вы также можете просмотреть базу данных циклического перебора (RRD), такую как RRDTool, чтобы увидеть, подходит ли этот подход для ваших нужд.
person
John Landahl
schedule
29.06.2012