ЗмістНатисність на посилання, щоб перейти до потрібного місця
Time-series база даних - це тип сховища, оптимізований для даних, прив’язаних до часу. Кожен запис у такій системі має часову мітку, і саме час є головною ознакою, за якою ці дані зберігаються, читаються та аналізуються. Подібні БД створені для великих потоків подій, які постійно надходять і переважно не змінюються після запису.
Такі бази застосовують у моніторингу серверів, фінансових системах, аналітиці вебтрафіку, IoT-пристроях або будь-яких процесах, де важливо бачити динаміку показників. Наприклад, зміни завантаження процесора за останні години, температуру сенсора щосекунди чи коливання біржового індексу протягом дня.
Time-series БД забезпечують швидке зчитування великих діапазонів часу, ефективні агрегації, компресію та можливість швидкого видалення старих даних без шкоди для продуктивності.
Серед популярних реалізацій - InfluxDB, TimescaleDB, Prometheus, VictoriaMetrics та навіть Elasticsearch, який часто використовують для time-series аналітики завдяки його можливості швидко індексувати події й виконувати агреговані запити. Це робить такі бази незамінними для систем моніторингу, аналітики та роботи з високочастотними даними, де час є ключовим фактором.
MySQL і PostgreSQL можна використовувати для time-series, але вони погано масштабуються під такі навантаження. Причина не в тому, що вони "погані", а в тому, що їхня архітектура не розрахована на дуже часті вставки й величезні обсяги даних, організованих саме за часом.
Чому MySQL і PostgreSQL не підходять для time-series
У класичних реляційних баз даних записи зберігаються в таблицях, а індекси - у B-деревах (B-tree). Коли дані постійно додаються за часом (щосекунди або навіть щомілісекунди), індекс починає швидко "роздуватися", сегменти пам’яті фрагментуються, а часті INSERT-и створюють навантаження на блокування сторінок і журнал транзакцій. У результаті база починає сповільнюватися, особливо коли дані вимірюються вже не мільйонами, а сотнями мільйонів або мільярдами рядків.
Другий недолік - агрегації по великих діапазонах часу. Наприклад, отримати "середню температуру за три місяці" у MySQL чи PostgreSQL - це повільний скан по величезній таблиці. В time-series БД ці операції виконуються миттєво, бо вони одразу оптимізовані під діапазонні запити та зберігають дані у форматі, що легко агрегується.
Ще одна проблема - видалення старих даних. У PostgreSQL це спричиняє масивний bloat і потребує VACUUM, який постійно перевантажує систему. У MySQL ситуація не краща: коли видаляється велика кількість старих записів, таблиці та індекси стають фрагментованими, і продуктивність падає. У time-series базах це вирішено архітектурно: старі дані зберігаються окремими "шматками" і просто відкидаються цілими блоками без навантаження.
Також у звичайних SQL-баз немає ефективного стиснення даних, оптимізованого саме для послідовностей значень у часі. У time-series сховищах (InfluxDB, VictoriaMetrics, Prometheus) компресія дозволяє зберігати ті самі дані у 5–20 разів компактніше.
Підсумовуючи: MySQL/PostgreSQL чудово працюють із класичними транзакційними даними, але при великих потоках телеметрії, логів або сенсорних показників їх продуктивність швидко падає. Time-series БД створені спеціально для такого навантаження: вони оптимізують запис, зберігання, читання і видалення даних, прив’язаних до часу.
Цей допис поки що не має жодних доповнень від автора/ки.
