NoSQL и метеорологические данные

Question

Итак, появилась новая классная вещь, эти базы данных NoSQL. И вот мои данные: ряды строк рядов метеорологических данных: значения, представляющие определенные измерения на определенной станции (идентифицируемые номером ВМО, а не координатами) в определенный момент времени.

Не каждая станция измеряет каждый параметр, не каждый параметр измеряется постоянно.

Я храню эти данные (почасовые значения за 30 лет, что составляет ~ 1 млрд. Значений) в настоящее время в MySQL. Непрерывный рост и заметное добавление еще большего количества данных вызывают у меня небольшую головную боль.

Читая о системах NoSQL на основе документов, которые, кажется, достаточно легко масштабируются, мне стало интересно, является ли NoSQL жизнеспособной концепцией хранения данных для метеорологических данных. Есть ли у вас опыт с этим?

Обновление: забыли о типичных запросах: большинству запросов нужны данные по временной оси: т.е. дайте мне температуру станции 066310 с 01.01.2010 00:00 до 01.03.2010 00:00.

Или: дайте мне самые последние значения всех параметров конкретной станции.

Answer 1

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

Что вы выиграете в легкой масштабируемости, вы можете потерять в гибкости и согласованности.

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

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

Answer 2

Мне трудно сейчас создать согласованный ответ, но здесь все идет.

1. Ваши данные без проблем поместятся в хранилище данных "nosql", такое как Cassandra (и многие другие, вероятно)
2. Вы бы выиграли от схемы без схемы многих решений "nosql" (видя, что не все столбцы (для использования термина MySQL) присутствуют постоянно)
3. Запросы на основе времени будутне испытывайте проблем в Cassandra (ознакомьтесь с ключами на основе TimeUUID)
4. Похоже, вы не пользуетесь реляционной частью MySQL, поэтому вы не сильно пострадаете, потеряв ее
5. Несмотря на то, что с MySQL у вас может быть все в порядке, поскольку вы на самом деле не описываете проблемы, есть ли у вас проблемы?(Просто быть заинтересованным - это круто)
6. Такие вещи, как индексы и поиск - это вещи, которые вам придется реализовать вручную во многих хранилищах данных nosql, если это пугает вас, возможно, придерживаться sql.

Спасибо за внимание;)

Answer 3

Я думаю, вы должны попробовать полнофункциональную и зрелую СУБД, прежде чем отказаться от SQL.

См. Например:

http://www.yafla.com/dforbes/Getting_Real_about_NoSQL_and_the_SQL_Performance_Lie/

http://www.yafla.com/dforbes/The_Impact_of_SSDs_on_Database_Performance_and_the_Performance_Paradox_of_Data_Explodification/