Взагалі, для такого структурованого набору даних я підозрюю, що ви могли написати спеціальний формат даних, який був більш швидким для більшості щоденних операцій (тобто малі дані збираються з довільного часу). Перевага від переходу до стандартного інструменту БД, ймовірно, в деяких додатках, наприклад, спеціальні запити, багаторазовий доступ, реплікація, наявність тощо. Також легше найняти допомогу для підтримання сховища даних на основі стандартів.
Якби мене попросили створити базу даних для зберігання цих даних, я б зробив наступне:
Запропонована схема
(1) Основні дані розміщуються у численних (1000-х) окремих таблицях, кожна з яких містить два стовпці:
- час: або тип даних SQL DATETIME, або числовий тип з якоїсь епохи (це первинний ключ)
- значення: вводиться відповідно до ваших даних. Я б за замовчуванням поплавком одноточної точності, однак тип даних фіксованої точки може бути більш підходящим для фінансових операцій. Це, мабуть, нерозроблено.
Ці таблиці вийдуть досить великими, і ви, можливо, захочете вручну розділити їх (наприклад) року. Але вам доведеться перевірити працездатність системи та налаштувати її відповідно.
Ці таблиці потребують унікальних імен, і є пара варіантів. Вони можуть бути зрозумілими для людини (наприклад, nyse_goog_dailyhighs_2010) або (на мою перевагу) випадковими. У будь-якому випадку необхідний набір таблиць метаданих, і довільні назви таблиць не дозволяють розробникам вводити що-небудь у ім’я, яке не передбачалося робити.
(2) Метадані зберігаються в окремих таблицях, як того вимагає додаток :
Для відстеження метаданих необхідна додаткова таблиця або набір таблиць. Ці таблиці містять дані про обмін, інструмент, величину, частоту, діапазони дат, походження (звідки вони беруться), а також все, що вам потрібно. Вони відображаються у назвах таблиць даних.
Якщо є достатньо даних, цей пошук фактично може надати ім’я таблиці та ім'я бази даних, що дозволяє своєрідно реалізувати різкісні дані (якщо це правильне використання терміна). Але я б тримав це в запасі.
Тоді на рівні програми я б запитав таблиці метаданих, щоб визначити, де розміщуються мої дані, а потім виконувати відносно прості запити у великих таблицях даних, щоб отримати мої дані.
Переваги:
Мій (відносно обмежений) досвід полягає в тому, що бази даних можуть, як правило, обробляти велику кількість маленьких таблиць простіше, ніж меншу кількість великих таблиць. Цей підхід також дозволяє простіше у обслуговуванні (наприклад, очищення старих даних, відновлення пошкодженої таблиці, створення / перезавантаження з резервних копій, додавання нової сутності). Це повністю відокремлює різні типи даних, якщо (наприклад) у вас є дані з різною швидкістю або потрібні різні типи даних.
Ця концепція вузької таблиці також повинна забезпечувати швидкий доступ до диска, тому що я підозрюю, що це найпоширеніший запит - суцільний діапазон даних від одного об'єкта. Більшість додатків даних обмежені введенням / виводуми диска, тому це варто врахувати. Як уже писав коментатор, це мій ідеальний додаток для баз даних, орієнтованих на стовпці, але мені ще належить знайти продукт, орієнтований на стовпці, який є основним для мене, щоб зробити ставку на кар'єру. Ця схема дуже близька.
Недоліки:
Близько половини вашого дискового простору відведено для зберігання часових позначок, коли цілком відверто 100 або 1000 таблиць будуть мати такі самі дані в стовпці часових позначок. (Насправді це вимога, якщо ви хочете виконати легке приєднання таблиці).
Зберігання назв таблиць та виконання динамічного пошуку вимагає великої складності програми та операцій з рядком, що змушує мене дурити. Але це все ще здається кращим, ніж альтернативи (обговорено нижче).
Міркування:
Будьте уважні до округлення у своєму часовому полі. Ви хочете, щоб ваші значення були досить круглими, щоб вони могли приєднуватися (якщо потрібно), але досить точними, щоб бути однозначними.
Будьте уважні до часових поясів та літнього часу. Це важко перевірити. Я б застосував вимогу UTC у сховищі даних (що може зробити мене непопулярним) і обробляти перетворення в додатку.
Варіації:
Я розглянув кілька варіантів:
Складання даних: Якщо часові записи однаково розташовані, використовуйте один стовпчик часових позначок і (наприклад) 10 стовпців даних. Тепер часова марка посилається на час першого стовпця даних, а інші стовпці даних вважаються однаково розташованими між цією міткою часу та наступною. Це економить велику кількість пам’яті, яке раніше використовувалося для зберігання часових позначок, вартістю значних запитів та / або складності додатків. Безперервний діапазон, запити для однієї сутності потребують меншого доступу до диска.
Мультиплексирование: Якщо відомо, що для декількох часових рядів використовується один і той же часовий ряд, використовуйте одну часову позначку і (наприклад) 10 стовпців даних, як описано вище. Але тепер кожен стовпець представляє різний часовий ряд. Для цього потрібно оновити таблицю метаданих, яка не є пошуком назви таблиці та стовпців. Зменшується місце для зберігання. Запити залишаються простими. Однак безперервний діапазон запитів для однієї сутності вимагає значно більшого доступу до диска.
Мега-таблиця: До кінця підведіть концепцію "мультиплексингу" і введіть усі дані в одну таблицю, один раз часовий ряд на стовпець. Для цього потрібні великі обсяги доступу до диска для суміжного діапазону, запитів однієї сутності та є кошмаром технічного обслуговування. Наприклад, для додавання нового об'єкта зараз потрібна команда MODIFY TABLE у багатьох таблицях TB.
Для додаткової дискусії щодо цього формату дивіться різні відповіді у розділі:
Забагато стовпців у MySQL
Повністю нормалізована таблиця:
Замість використання багатьох таблиць з двома стовпцями ви можете використовувати одну, три стовпчикові таблиці, де стовпці - час, дані та значення. Тепер ваші таблиці метаданих потребують пошуку лише значень ідентифікаторів, а не імен таблиць або імен стовпців, що дозволяє вводити більше логіки в SQL запити, а не на додаток.
Приблизно 2/3 пам’яті зараз споживається з нормалізуючими стовпцями, тому для цього буде використано багато дискового простору.
Ви можете використовувати порядок первинного ключа (dataid, часова мітка) для швидких одночасних запитів з одною сутністю. Або ви можете використовувати порядок первинного ключа (timetamp. Dataid) для швидших вставок.
Однак навіть після розгляду цих варіантів мій план моєї наступної розробки - це багато таблиць, дві колонки кожна. Це, або метод, який незабаром повинен розмістити хтось розумніший за мене :).