Какую выбрать СУБД и структуру БД для хранения ~160 млрд записей?

Question

[Сергей]

Суть проекта

Бурятся скважины около 100 штук, с них каждую секунду высылаются данные на центральный сервер.

Скважины бурятся в среднем 2 месяца.

Данные такого типа:

• Время
  
• Глубина
  
• около 300 параметров
  

Параметр имеет такой вид:

• ID параметра: string(3)
  
• Значение: float
  

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

Требуется организовать систему на этом сервере, чтобы она принимала и хранила эти параметры.

А также выводила кривые изменения параметров в реальном времени. Плюс кривые за прошлое время с изменением масштаба и диапазона просмотра.

Текущая программа использует MySQL, с отдельными таблицами на каждую скважину. Самая большая таблица занимает 30GB и 160 млн строк (текущая программа сохраняет меньшее кол-во параметров).

Теперь вопросы:

• Достаточно-ли PostgresQL для этих целей с 2-мя табличками?
  
• Либо имеет смысл для каждой скважины заводить отдельные таблицы?
  
• Может стоит использовать NoSQL?
  
• Может это относится к Big Data и нужны соответствующие решения?
  

Answer 1

[Иван Шумов]

Для хранения - key-value, для OLAP - column database. Для графиков - а зависимости от реалтайма. Или тупо стриминг из ingest'a или же регулярные агрегаты в другую базу.

Answer 2

[tester12]

Мускуль вполне справится.

160 млрд записей по 10 байт это ~ 1,6 ТБ, не так уж и много.

Графики выводятся не из основной базы, а из slave реплики (для уменьшения нагрузки на основную базу).

Скорее всего, графики можно выводить с меньшей точностью: брать цифры не раз в секунду, а раз в 10 минут. Потому что цифры "раз в секунду" всё равно не будут видны. Т.е. для графиков можно сделать отдельную, значительно меньшую по объёму базу.

Ещё можно подумать, насколько часто меняются параметры? Если параметр почти не меняется, может быть, записывать его с увеличенными интервалами? Например, раз в минуту? А в случае каких-то резких (катастрофических?) изменений возобновить запись раз в секунду.

Answer 3

[Сергей Еремин]

Для хранения справятся log-файлы... Ровно как и MySql, mariadb или postgresql ... или KV ../ да как угодно хранить можно.

Вопрос: что после с этими сохраненными данными делать и как их обрабатывать. И в зависимости от хателок будет вырисовываться архитектура и можно выбирать подходящую под задачу базу.