Ну, в общем, в сети много всего на эту тему. В общем, в реляционной базе данных схемы известны "заранее" - хотя со временем это может измениться, оно довольно статично.
Большая "выгода" большинства не только в Sql заключается в том, что они:
- не требуют фиксированной схемы и фиксированных отношений для обеспечения согласованности данных. Это означает, например, графическая база данных - вы можете связываться с другими объектами проще и гибче.
- по своей конструкции способны (лучше) масштабировать по горизонтали, что - в больших системах - является большим преимуществом в решении проблем, связанных с производительностью.
- данные не должны быть (очень) структурированы. Это опять-таки полезно, если вам нужно включить внешние источники данных или типичные неструктурированные данные в вашу базу данных.
примечание: существует несколько типов базы данных NoSql, каждый с другим подходом и своими собственными аргументами.
Итак:
Помимо моего конкретного случая использования, когда обычно предпочитать RDMBS вместо NoSQL для хранения временных рядов?
При использовании RDMBS вам необходимо - по крайней мере - знать свои схемы заранее, и не ожидается, что они будут меняться очень часто.
Вы предпочитаете RDMBS, если:
- этот вид структурированных данных и проверки согласованности являются внутренним свойством данных, которые вы храните. Например: вести инвентаризацию склада, отслеживать рабочие часы и т. Д.
- ваше хранилище данных можно рассматривать как изолированный орган. Например: индексатор файловой системы или хранилище результатов тестирования продукта.
Когда предпочитать NoSQL над RDBMS?
Вы предпочитаете NoSql, если:
- Вы не можете определить все отношения заранее и ожидать частого добавления данных, источников и отношений. Типичные случаи использования: хранилища больших данных, хранилища отношений; более конкретно: социальные сети, расширенные статистические корреляции или часто меняющиеся поставщики внешних данных.
- Вам нужна высокая масштабируемость, что более естественно в большинстве систем NoSql.
- Вы просто хотите поместить некоторые данные в облако более или менее структурированным образом
Что касается вашего варианта использования:
Кажется, что ваша структура данных хорошо известна и исправлена. Это оправдывает реляционную базу данных.
Что касается высокой нагрузки: структура данных также известна заранее. Тем не менее, есть несколько уловов, связанных с высокой нагрузкой. Реляционная база данных может быть настроена так, чтобы справляться с этой суммой и работать очень хорошо.
Итак, в остальном - это хороший опыт - я не вижу сильных аргументов в пользу NoSql (хотя я могу что-то упустить [например, производительность)).
С другой стороны, это ставит другой вопрос: так как вы контролируете 24/7; как часто вам нужны данные прошлого года или годом раньше? В прошлом месяце или неделе?
Я просто спрашиваю, потому что есть еще варианты, чтобы справиться с этими объемами данных. Исторические данные часто обрабатываются как журнал и запрашиваются только «сейчас и потом». В этом случае вы можете хранить фрагменты данных на разных серверах или даже в разных формах. Например, данные вибрации 10 кГц также могут храниться на выделенном сервере в виде большого двоичного объекта или потока хранимых данных.