Временные ряды: SQL или NoSQL?

Меня не волнуют общие различия между SQL и NoSQL (или их традиционные различия).

В настоящее время я смотрю на изменение хранения наших внутренних временных рядов. Все они содержат финансовые данные из разных источников. В настоящее время мы храним наши данные в частной базе данных. Это очень NoSQL, который имеет свой собственный язык запросов.

Меня интересует вклад сообщества: как бы вы хранили данные в базе данных SQL? Каковы преимущества использования SQL поверх NoSQL, особенно для временных рядов? Я безумен для рассмотрения хранения этого в SQL?

Наш набор данных состоит из миллионов временных рядов, причем около 10% из них содержат миллионы записей в каждом. Временные ряды организованы иерархически: / Рынок / Инструмент / Стоимость / Частота, где:

• Рынок - это биржа ценных бумаг и т. Д., В основном набор инструментов, обычно аналогичных инструментов.
• Инструмент это инструмент. Это может быть индикатор (Brent Crude), собственный капитал (GOOG) и т. Д.
• Значение - это один из нескольких типов данных для инструмента. Это может быть близко, высоко, низко и т. Д.
• Частота - это частота значений определенного временного ряда. Еженедельно, ежедневно, ежемесячно, тик, произвольно и т. Д.

Как данные будут храниться в базе данных SQL? Одна большая таблица (может быть чем-то разделена), одна таблица на рынок или инструмент, одна таблица на временной ряд.

Заранее спасибо.

В целом, для такого структурированного набора данных я подозреваю, что вы могли бы написать собственный формат данных, который был бы более быстрым для большинства ежедневных операций (т. Е. Небольшие данные извлекаются из произвольного времени). Преимущество перехода к стандартному инструменту БД вероятно в некоторых дополнительных функциях, например, специальные запросы, множественный доступ, репликация, доступность и т. Д. Также проще нанять помощь для поддержки хранилища данных на основе стандартов.

Если бы меня попросили настроить базу данных для хранения этих данных, я бы сделал следующее:

Предлагаемая схема

(1) Основные данные помещаются в многочисленные (1000-е) отдельных таблиц, каждая из которых содержит два столбца:

1. время: либо тип данных SQL DATETIME, либо числовой тип какой-то эпохи (это первичный ключ)
2. значение: вводится в соответствии с вашими данными. Я бы по умолчанию установил плавающую одинарную точность, однако тип данных с фиксированной запятой может быть более подходящим для финансовых транзакций. Это, вероятно, неиндексировано.

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

Эти таблицы требуют уникальных имен, и есть несколько вариантов. Они могут быть удобочитаемыми (например, nyse_goog_dailyhighs_2010) или случайными (моими предпочтениями). В любом случае требуется набор таблиц метаданных, а случайные имена таблиц не позволяют разработчикам вводить в имя что-либо, что не должно быть выведено.

(2) Метаданные хранятся в отдельных таблицах, как того требует приложение :

Для отслеживания метаданных требуется дополнительная таблица или набор таблиц. Эти таблицы будут содержать данные об обмене, инструменте, стоимости, частоте, диапазонах дат, происхождении (откуда поступили данные), а также все остальное, что вам нужно. Они сопоставлены с именами таблиц данных.

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

Затем на прикладном уровне я запрашивал таблицы метаданных, чтобы определить местонахождение моих данных, а затем выполнял относительно простые запросы к таблицам больших данных, чтобы получить мои данные.

Преимущества:

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

• Эта концепция тощих таблиц должна также обеспечивать быстрый доступ к диску для того, что, как я подозреваю, является наиболее распространенным запросом - непрерывным диапазоном данных из одной сущности. Большинство приложений данных ограничено дисковым вводом / выводом, поэтому это стоит рассмотреть. Как уже отмечал комментатор, это может быть идеальным приложением для базирующейся на столбцах базы данных, но мне еще предстоит найти ориентированный на столбцы продукт, который был бы достаточно распространенным, чтобы я мог сделать ставку на свою карьеру. Эта схема становится довольно близкой.

Недостатки:

• Около половины вашего дискового пространства отводится для хранения меток времени, когда, откровенно говоря, 100 или 1000 таблиц будут иметь точно такие же данные в столбце меток времени. (На самом деле это требование, если вы хотите выполнять простые объединения таблиц).

• Хранение имен таблиц и выполнение динамического поиска требует много сложностей приложения и строковых операций, что заставляет меня съеживаться. Но это все еще кажется лучше, чем альтернативы (обсуждаемые ниже).

Соображения:

• Будьте осторожны с округлением в вашем поле времени. Вы хотите, чтобы ваши значения были достаточно круглыми, чтобы включить объединения (если это необходимо), но достаточно точными, чтобы быть однозначными.

• Будьте осторожны с часовыми поясами и летним временем. Это трудно проверить. Я бы применял UTC к хранилищу данных (что может сделать меня непопулярным) и обрабатывал преобразования в приложении.

Варианты:

Некоторые варианты, которые я рассмотрел:

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

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

Мега-таблица: доведите концепцию «мультиплексирования» до крайности и поместите все данные в одну таблицу, один раз по временным рядам на столбец. Это требует больших объемов доступа к диску для непрерывного диапазона, запросов одного объекта и является кошмаром обслуживания. Например, для добавления нового объекта теперь требуется команда MODIFY TABLE для таблицы с множеством ТБ.

Для дополнительного обсуждения этого формата см. Различные ответы в: Слишком много столбцов в MySQL.

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

Приблизительно 2/3 хранилища теперь занято нормализующими столбцами, поэтому для этого потребуется много места на диске.

Вы можете использовать порядок первичных ключей (dataid, timestamp) для быстрых непрерывных запросов с одной сущностью. Или вы можете использовать порядок первичных ключей (timestamp. Dataid) для более быстрой вставки.

Тем не менее, даже после рассмотрения этих вариантов, я планирую следующую разработку: много таблиц, каждая из которых состоит из двух столбцов. Это или метод, который скоро будет опубликован кем-то более мудрым, чем я :).

Используйте MongoDB, вы можете создавать коллекции на лету очень быстро. Посмотрите на размещение ваших данных в отдельных базах данных и коллекциях в этих базах данных. Подумайте, сколько памяти вам нужно, чтобы попытаться сохранить каждый фрагмент в системной памяти - если вам нужен быстрый поиск. Глупо придерживаться внутреннего решения, если есть что-то более свежее, которое будет развиваться в соответствии с вашими потребностями. Звучит как хорошая инициатива.