SQL часто має проблеми, коли справа доходить до керування величезними обсягами даних часових рядів, але це не через саму мову.
Головним винуватцем є архітектура, у якій зазвичай працює SQL, а саме реляційні бази даних, що швидко стають неефективними, оскільки вони не призначені для аналітичних запитів великих обсягів даних часових рядів. Про це йдеться в матеріалі InfoWorld.
Традиційно SQL використовується з системами управління реляційними базами даних (RDBMS), які за своєю суттю є транзакційними. Вони структуровані навколо концепції підтримки й оновлення записів на основі жорсткої заздалегідь визначеної схеми.
Тривалий час найпоширенішим типом бази даних був реляційний, з невіддільним супутником – SQL, тому зрозуміло, що багатьом розробникам та аналітикам даних це зручно.
Однак надходження даних часових рядів приносить нові виклики й ускладнює сферу реляційних баз даних. Програми, датчики та низка пристроїв створюють невпинний потік даних часових рядів, які не вписуються у фіксовану схему, як це роблять реляційні дані.
Цей безперервний потік даних створює колосальні набори даних, що призводить до аналітичного навантаження, яке потребує особливого типу бази даних. Саме в таких ситуаціях розробники, як правило, переходять до баз даних NoSQL і часових рядів для обробки величезної кількості напівструктурованих або неструктурованих даних, створених периферійними пристроями.
Хоча дизайн традиційних баз даних SQL погано підходить для обробки часових рядів, використання спеціально створеної бази даних часових рядів, яка підтримує SQL, виглядає як порятунок.
Тепер користувачі SQL можуть використовувати цю звичну мову для розробки застосунків у реальному часі й ефективного збору, зберігання, управління й аналізу обсягів даних часових рядів, що постійно зростають.
Однак попри цю нову можливість користувачі SQL повинні враховувати певні характеристики даних часових рядів, щоб уникнути потенційних проблем або викликів у майбутньому.
Дані часових рядів за своєю суттю не є реляційними
Це означає, що може виникнути потреба переорієнтувати сприйняття про використання даних часових рядів. Наприклад, окрема точка даних часового ряду сама по собі не дуже корисна. Ця послідовність даних у ряді надає важливий контекст для будь-якого окремого датуму.
Таким чином, користувачі дивляться на спостереження часових рядів у групах, але окремі спостереження є дискретними. Щоб швидко отримати інформацію з цих даних, користувачі повинні думати в контексті часу й обов’язково визначити вікно часу для своїх запитів.
Оскільки значення кожної точки даних безпосередньо впливає на інші точки даних у послідовності, дані часових рядів все частіше використовуються для виконання аналітики в реальному часі для виявлення тенденцій і закономірностей, що дає змогу розробникам і технічним керівникам дуже швидко ухвалювати обґрунтовані рішення. Це набагато складніше з реляційними даними через час і ресурси, які можуть знадобитися для запиту пов’язаних даних із кількох таблиць.
Масштабованість має першочергове значення
Оскільки ми підключаємо все більше обладнання до Інтернету, кількість створених даних зростає експоненційно. Щойно ці навантаження на дані перевищать тривіальні (іншими словами, коли вони потраплять у виробниче середовище), транзакційна база даних не зможе масштабуватися. У цей момент прийом даних стає вузьким місцем, і розробники не можуть ефективно запитувати дані. Це все не може відбуватися в реальному часі через затримки читання та запису бази даних.
База даних часових рядів, яка підтримує SQL, може забезпечити достатню масштабованість і швидкість для великих баз даних. Висока продуктивність завантаження дає змогу базі даних часових рядів безперервно завантажувати, перетворювати й аналізувати мільярди точок даних часових рядів за секунду без обмежень.
Оскільки обсяги даних продовжують зростати з експоненційною швидкістю, база даних, яка може масштабуватися, має вирішальне значення для розробників, що керують даними часових рядів. Для програм, пристроїв і систем, які створюють величезні обсяги даних, зберігання даних може бути дуже дорогим.
Використання високого рівня стиснення знижує витрати на зберігання даних і дає змогу зберігати до 10 разів більше даних без втрати продуктивності.
SQL можна використовувати для запиту часових рядів
Спеціально створена база даних часових рядів дає змогу користувачам використовувати SQL для запиту даних часових рядів. База даних, яка використовує Apache DataFusion – систему розподілених запитів SQL, буде ще ефективнішою.
DataFusion – це проєкт із відкритим вихідним кодом, який дає змогу користувачам ефективно запитувати дані протягом певних проміжків часу за допомогою операторів SQL.
Apache DataFusion є частиною екосистеми Apache Arrow, яка також включає систему запитів Flight SQL, створену на основі Apache Arrow Flight, і Apache Parquet, формат файлів для зберігання даних у стовпцях.
Flight SQL забезпечує високопродуктивний інтерфейс SQL для роботи з базами даних за допомогою фреймворку Arrow Flight RPC, що забезпечує швидший доступ до даних і меншу затримку без необхідності конвертувати дані у формат Arrow.
Залучення клієнта Flight SQL необхідно перед тим, як дані стануть доступними для запитів або аналітики. Щоб забезпечити легкий доступ між Flight SQL і клієнтами, співтовариство з відкритим кодом створило драйвер FlightSQL – легку оболонку для клієнта Flight SQL, написану на Go.
Крім того, екосистема Apache Arrow базується на колонкових форматах як для пам’яті (Apache Arrow), так і для стійкого файлового формату (Apache Parquet). Зберігання в колонках ідеально підходить для даних часових рядів, оскільки дані часових рядів зазвичай містять кілька ідентичних значень за час. Наприклад, якщо користувач щохвилини збирає дані про погоду, значення температури не будуть коливатися щохвилини.
Ці самі значення надають можливість для дешевого стиснення, що дає змогу використовувати випадки з високою потужністю. Також це дозволяє швидше сканувати за допомогою інструкцій SIMD, наявних у всіх сучасних CPU. Залежно від способу сортування даних користувачам може знадобитися лише переглянути першу колонку даних, щоб знайти максимальне значення певного поля.
Порівняйте це з орієнтованим на рядки сховищем, яке вимагає від користувачів переглядати кожне поле, набір тегів і позначку часу, щоб знайти максимальне значення поля. Іншими словами, користувачі повинні прочитати перший рядок, розібрати запис на колонки, включити значення полів у свій результат і повторити. Apache Arrow забезпечує набагато швидший та ефективніший процес для запитів і запису даних часових рядів.
Фреймворк програмного забезпечення, що не залежить від мови, пропонує багато переваг
Чим більше розробники можуть працювати над даними у своїх програмах, тим ефективнішими можуть бути ці програми. Застосування мовно-незалежної системи, такої як Apache Arrow, дає змогу користувачам працювати з даними ближче до джерела.
Фреймворк, який не залежить від мови, не тільки усуває або зменшує потребу у процесах вилучення, перетворення та завантаження (ETL), але й полегшує роботу з великими наборами даних.
Зокрема, Apache Arrow працює з Apache Parquet, Apache Flight SQL, Apache Spark, NumPy, PySpark, Pandas та іншими бібліотеками обробки даних. Також він містить природні бібліотеки на C, C++, C#, Go, Java, JavaScript, Julia, MATLAB, Python, R, Ruby та Rust. Це означає, що всі системи використовують один і той самий формат пам’яті, немає накладних витрат при комунікації між системами, а сумісний обмін даними є стандартним.
Настав час для часових рядів
Дані часових рядів включають усе: від подій, кліків і даних датчиків до журналів, метрик і трас. Дані часових рядів дають змогу докладно зрозуміти закономірності в часі та відкривають нові шляхи для аналітики в реальному часі, прогнозного аналізу, моніторингу IoT, моніторингу застосунків і DevOps, що робить часові ряди незамінним інструментом для ухвалення рішень на основі даних.
Наявність можливості використовувати SQL для запиту цих даних усуває суттєву перешкоду для входу і впровадження для розробників із досвідом RDBMS. База даних часових рядів, яка підтримує SQL, допомагає усунути розрив між транзакційними й аналітичними робочими навантаженнями, надаючи зрозумілі інструменти, щоб отримати максимум від даних часових рядів.
MySQL 5.7: оновити чи перенести? Читайте в матеріалі ProIT.
