Як ефективно зберігати дані великих часових рядів?

27

Мені потрібно зберігати та мати можливість запитувати деякі дуже великі обсяги даних часових рядів.

Властивості даних такі:

  • кількість серій: близько 12 000 (дванадцять тисяч)
  • кількість точок даних у всьому світі: близько 500 000 000 на місяць (п'ятсот мільйонів)
  • змішані типи значень: більшість точок даних - це знаки з плаваючою точкою, решта - це рядки
  • Період вибірки: змінна між серіями, а також у межах серії
  • мітки часу: мілісекундна точність
  • Період збереження даних: кілька років, без занепаду чи зниження часу
  • архіви даних потрібно вбудовувати майже в режимі реального часу, але прийнятна розумна затримка (~ 1 година)
  • минулі дані можна відновити за потреби, але з високою вартістю
  • іноді, але досить рідко, деякі попередні дані потребують оновлення

Властивості передбачених запитів:

  • більшість запитів щодо даних будуть запитами на основі часових позначок; від одного дня до декількох місяців / років. 90% + будуть запити за останніми даними

Інші вимоги:

  • розчин повинен бути вільним, як у вільному пиві та бажано з відкритим кодом

Первісною моєю думкою було використання PyTables / Pandas з файлами HDF5 як зберігання бекенда замість бази даних SQL.

Запитання:

  1. Якщо припустити, що PyTables / Pandas - це "найкращий" маршрут, то краще було б розділити дані на кілька файлів HDF, кожен з яких триває певний проміжок часу, або помістити все в один файл, який потім стане величезним?

  2. Чи варто віддати перевагу фіксованому чи формату таблиці? Для мене фіксований формат виглядає нормально, якщо я зберігаю один файл HDF щомісяця, оскільки таким чином ціла серія, ймовірно, вміщується в оперативній пам'яті, і я можу нарізати пам'ять, не потребуючи індексу формату таблиці. Я прав?

І якщо це не найкращий підхід, як я повинен структурувати цей сховище даних або які технології я повинен розглянути? Я не перший, хто займається зберіганням великих наборів даних часових рядів, який загальний підхід до вирішення цієї проблеми?

Інші підходи, які я розглядав:

  • бази даних масиву: вони чудово підходять для тимчасових рядів з постійним періодом вибірки, тому що вам потрібно лише зберігати час початку і кінця та період вибірки масиву, а потім лише значення у самому масиві та індексація є легкою. Але при змінних періодах вибірки в самих серіях мені потрібно дотримуватися більш близького співвідношення часових позначок -> значення, яке, на мій погляд, не є таким корисним для СУБД масиву.
  • стандартна база даних SQL з позначкою часу, paramID, значенням як стовпці, але за своєю природою вони вимагають багато вводу-виводу диска для будь-якого запиту
database  python  performance 
— літаючийміг
джерело
Ви повинні врахувати бази даних масиву - en.wikipedia.org/wiki/Array_DBMS#List_of_Array_DBMS . Я не кажу, що хтось із них був би правильним, або навіть найкращим або навіть досить хорошим, відповідь, просто щоб вони ввійшли у ваші думки. Крім записів у цьому списку є система kdb ( kx.com ), хоча вона далеко не безкоштовна.
— Марка високої продуктивності
Дякую за ваш внесок Я розглянув бази даних масиву, але проблема, яку я знаходжу в них, полягає в тому, що вони чудово підходять для часових рядів з постійним періодом вибірки, оскільки вам потрібно лише зберігати час початку і кінця та період вибірки масиву, а потім лише значення в сам масив та індексація прості. Але при змінних періодах вибірки в самих серіях мені потрібно дотримуватися більш близького співвідношення часових позначок -> значення, яке, на мій погляд, не є таким корисним для СУБД масиву. З урахуванням сказаного, я би радий, що я підтвердив свою помилку.
— flyingmig
питання редагування, щоб додати те, що я вважав до цього часу
— flyingmig
Питання: чи потрібно зберігати всі дані? Чи можуть дані занепадати з часом та / або є певний прийнятний рівень точності для плаваючих серій?
— J Trana
1
@ moinuddin-quadri Я в кінцевому підсумку використовував панда об’єктів DataFrame, що підтримуються місячними файлами HDF5 у форматі таблиці. Система працює вже більше року і демонструє дуже стабільну та швидку, навіть не використовуючи SSD-диски. Я спробую списати все це як відповідь, коли матиму час. Ще не соромтеся вести мене.
— літаючийміг

Відповіді:

5

Можливо, ви захочете поглянути на вуглець і пошепки , частина графітового проекту. Карбон може обробляти дуже велику кількість даних часових рядів. Хоча зараз, коли я читаю документи (минуло кілька років, як я його використав), це лише для числових даних. Ви сказали, що у вас є також рядкові дані, тому ви можете не вважати це корисним. Хоча, можливо, ви зможете отримати деяку думку про те, як вони здатні швидко обробляти велику кількість даних.

Щоб дати вам уявлення про те, наскільки добре він масштабується, коли графіт був вперше випущений у виробництво на Orbitz, він обробляв 160 000 метрик на хвилину .

— Брайан Оуклі
джерело
Дякую за пропозицію, але з мого розуміння шепіт не підходить, тому що його точність є другою, коли мені потрібна мілісекундна точність, і, як ви справедливо зазначали, у мене є також рядкові дані, які там не можна зберігати.
— flyingmig
1
@flyingmig Не пишіть шепіт так швидко. Його часові позначки є значеннями Unix-epoch. І описані вами "рядкові дані" у запитанні більше нагадують перерахунки, і вони, як правило, зберігаються у вигляді малих цілих значень.
— Росс Паттерсон
Sears використовує Carbon / Graphite / Ceres для зберігання 4M + унікальних точок даних в хвилину. Це не ідеально, і для цього потрібні графітові кластеризації та SSD, але це працює. Всі інші рішення там не є масштабними до цього рівня, що ми знайшли, але якщо у вас є ідеї, сміливо звучайте.
— Кевін Дж. Райс
3

InfluxDB - це база даних з відкритим кодом, написана на Go. Це було написано спеціально для обробки даних часових рядів, і вони опублікували показники, що показують набагато кращі показники порівняно з Кассандрою :

InfluxDB перевершив Кассандру в усіх трьох тестах, на 4,5 рази більша пропускна здатність, використовуючи при цьому 10,8-кратну кількість дискового простору та забезпечуючи швидкість відповіді на 168 разів для перевірених запитів.

— Дан Даскалеску
джерело
2

ви можете перевірити бази даних, орієнтовані на стовпці. Я не впевнений, що ви маєте на увазі під базами даних масиву, але за допомогою мого запропонованого підходу ви можете мати динамічну кількість значень за часовий період. Ви також можете мати кілька значень для однієї часової позначки. Цікава частина полягає в тому, що якщо у вас є значення, виміряні в одну і ту ж часову марку, ви можете зберігати їх як додаткові стовпці (наприклад, датчик, який вимірює температуру і вологість, ціна торгівлі на акціях і розмір торгівлі, ...). Через характер, орієнтований на стовпці, ви можете мати таблиці зі 100 стовпцями, але якщо ваш запит має доступ лише до п'яти стовпців, база даних читає лише дані п'яти стовпців.

Я написав серію про створення власної бази даних часових рядів, можливо, ви захочете ознайомитися з нею:

— hellomichibye
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.