TL;DR​

ScopeDB — це база даних, побудована безпосередньо поверх S3, яка розкриває потужність еластичності хмари та ізоляції робочих навантажень. Сервери ScopeDB запускаються за допомогою одного безстатевого бінарного файлу на Rust, тому не потрібно управляти локальними дисками, шардінгом даних або складними виборами лідера. ScopeDB досягає в десять разів більшої ефективності з точки зору вартості та продуктивності порівняно з базами даних, побудованими за архітектурою "без спільних ресурсів", делегуючи реплікацію даних на S3 та динамічно налаштовуючи кількість серверів в залежності від робочого навантаження.

Якщо ви хочете одразу зануритись, спробуйте наш playground з посиланням:

git clone https://github.com/scopedb/community.git  
docker compose -f ./community/playground/docker-compose.yml up -d  
docker run -it --rm --entrypoint /bin/scopeql --network host scopedb/scopedb

Інакше почнемо з історії!

Коли ваші дані спостережуваності виростають до петабайт​

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

Спостережуваність — це життєва сила сучасної розробки програмного забезпечення. Вона надає інформацію про здоров’я та продуктивність додатків, інфраструктури та сервісів. Оскільки масштаб сучасних систем зростає, зростає і обсяг генерованих даних спостережуваності.

Дані спостережуваності зазвичай генеруються різними джерелами, такими як логи (logs), метрики (metrics) та трасування (traces). Коли обсяг даних невеликий, їх можна зберігати в окремій базі даних. Однак платформа спостережуваності повинна буде управляти даними в масштабі, який може вирости до петабайт.

Наприклад, одна запис логів додатка зазвичай займає від 5 до 20 кілобайт. Одна область платформи спостережуваності, яка обслуговує тисячі орендарів, може генерувати десять мільярдів записів логів на день. Це близько 100 ТБ даних на день. Отже, швидко платформа повинна буде управляти петабайтами даних. Коли обсяг даних зростає, платформа повинна масштабуватися горизонтально, щоб справлятися з підвищеним навантаженням.

Оскільки ELK Stack є популярним рішенням для логів і трасувань, команда спочатку вибрала Elasticsearch як сховище для даних спостережуваності.

Команда успішно зберігала логи та трасування з Elasticsearch. Elasticsearch надає можливість пошуку для підтримки багатьох часто використовуваних запитів. Однак обсяг даних продовжує зростати, а сценарії використання стають усе більш різноманітними. Незабаром команда зіткнулася з кількома проблемами:

• Вартість: Elasticsearch вимагає великої кількості процесорів, пам'яті та локальних дисків для зберігання та запиту даних у масштабах. Вартість запуску кластерів Elasticsearch може бути високою.
• Складність: Керувати кластерами Elasticsearch складно. Особливо важко реалізувати рівні даних для перенесення холодних даних в реальному світі.
• Обмежений аналіз: Пошук — не єдина вимога для запитів до даних. Команда отримала вимоги для агрегацій та багатовимірного аналізу. Elasticsearch не призначений для цих складних аналітичних запитів: погана підтримка індексації, відсутність стовпцевого формату даних і відсутність векторизованого механізму запитів.

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

Останніми роками інженери платформ досліджують рішення data warehouse для даних спостережуваності. Відомий стовпцевий сховище даних набуває популярності як рішення для даних спостережуваності, щоб знизити витрати та підтримувати агрегації.

Команда створила прототип для цього рішення на основі data warehouse.
It showed promising results that the storage cost was reduced by 70% thanks to the compact columnar data format. Meanwhile, running aggregations on single big tables was fast by fine-tuning the configuration.

However, before the team could roll out the data warehouse solution to production, they encountered new challenges:

• Data Ingestion: The data warehouse solution was not designed for real-time data ingestion. The team had to build a custom ETL pipeline to ingest data into the warehouse.
• Stateful Scaling: The data warehouse solution employs a shared-nothing architecture, meaning the team had to manage data replication, data sharding, and leader election. You can hardly temporarily add new nodes to the cluster to handle peak workloads.
• Rigid Schema: The data warehouse solution requires a prior schema definition for each table. While the schema of observability data often evolves quickly and unpredictably with new fields and dimensions, it’s impossible to define a fixed schema in advance.

Instead of jumping into solving these challenges from the platform side, the team decided to look around for other solutions that could better fit the observability data use case.

Хмарні сервіси змінюють ситуацію​

Перед створенням ScopeDB ми розробляли бази даних більше десяти років. Ми створювали розподілені бази даних з архітектурою "без спільних ресурсів" (shared-nothing architecture). Вони добре працюють при розгортанні на bare-metal серверах. Однак при розгортанні в хмарі багато суттєвих припущень виявляються порушеними.

Локальні диски необхідні для баз даних з архітектурою "без спільних ресурсів". Однак єдиним доступним товарним блочним пристроєм у хмарі є EBS, що є надзвичайно дорогим при зберіганні петабайтів даних. Навіть один петабайт зберігання на EBS коштує від 80 000 до 125 000 доларів США на місяць.

На відміну від цього, об'єктне зберігання може запропонувати значно більш вигідне рішення. Для порівняння, зберігання одного петабайта даних на S3 коштує 21 550 доларів США на місяць. Враховуючи різницю в ціні IOPS та пропускної здатності, вартість EBS може бути в десять разів вищою за S3. Тим часом, S3 все ще забезпечує конкурентоспроможну надійність, масштабованість та еластичність.

Отже, бази даних у хмарі повинні перейти від локальних дисків до об'єктного зберігання, що означатиме зміщення парадигми від "без спільних ресурсів" до "з спільним диском".

Існуючі бази даних з архітектурою "без спільних ресурсів" можуть розвивати багаторівневе зберігання для перенесення холодних даних в об'єктне зберігання. Однак локальні диски все ще необхідні для основного зберігання даних. Реплікація даних, шардінг і вибір лідера також залишаються необхідними для виконання основних операцій і запитів.

Крім того, у хмарі ви можете динамічно масштабувати кількість вузлів в залежності від робочого навантаження. Кожен вузол може мати різні розміри та типи екземплярів; AWS EC2 пропонує широкий вибір типів екземплярів. Можна спроектувати базу даних, яка обробляє інгестію за допомогою малих універсальних екземплярів і обробляє запити за допомогою великих, оптимізованих за пам'яттю екземплярів. Більше того, щоб обробляти важкі запити, відокремлені від загальних запитів, ви можете тимчасово додавати нові вузли і, можливо, використовувати spot-екземпляри для кращої вартості.

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

Ми зустрілися з командою платформи спостережуваності та обговорили проблеми, з якими вони зіткнулися. Ми погодились, що виправлення бази даних з архітектурою "без спільних ресурсів" у хмарі — це марна трата часу. Натомість база даних, спроектована з самого початку з урахуванням об'єктного зберігання, могла б природно усунути проблеми загальних витрат та стейтфул масштабу (stateful scaling). З додатковими функціями для підтримки даних спостережуваності з гнучкою схемою ми могли б запропонувати краще рішення для платформи.

ScopeDB — це наш продукт, що реалізує цю ідею.
Currently, it serves all the workload of the observability platform.

Представляємо ScopeDB​

ScopeDB — це стовпцева база даних, яка працює безпосередньо поверх будь-якого товарного об'єктного зберігання. Вона спеціально спроектована для обробки даних з великими записами, запитами будь-якого масштабу та гнучкою схемою. Це основні характеристики даних спостережуваності.

Почнемо з огляду архітектури ScopeDB:

Інжестія в реальному часі​

Позбувшись від стейтфул вузлів (stateful nodes), розгортання ScopeDB може мати різні групи вузлів (nodegroups) для різних робочих навантажень. Кожна група вузлів може мати різну кількість безстатевих вузлів (stateless nodes) з різними типами екземплярів, що розкриває потужність ізоляції робочих навантажень.

Група вузлів ingest демонструє типову налаштування для інжестії в реальному часі, з двома вузлами малих універсальних екземплярів.

API інжестії настільки просте, як один HTTP POST запит:

curl -X POST -H 'Content-Type: application/json' http://ingest-node:6543/v1/ingest -d @- <"  
 },  
 "statement": "INSERT INTO scopedb.tenant.logs"  
}  
EOF

Оскільки це одноразовий безстатевий запит, вузли інжестії можуть незалежно обробляти масивні запити на інжестію. Дані будуть декодовані у внутрішній формат таблиць і записані безпосередньо в S3. Локальні диски або реплікація даних не потрібні.

Компресія даних відбувається у фоновому режимі. Тому навіть якщо ви часто додаєте дані в невеликих наборах, фонове завдання збирає їх у більші файли, щоб зменшити вартість зберігання на S3 і покращити продуктивність запитів.

Аналіз будь-якого масштабу​

Ось кілька прикладів запитів, які ScopeDB може обробляти:

FROM scopedb.tenant.logs  
WHERE regexp_like(http_url, ".*webhooks.*")  
 AND host = "cratesland"  
 AND time >= now() - "PT24h"::interval  
 AND time < now()  
GROUP BY source  
AGGREGATE max(time) as time, count(true);

FROM scopedb.tenant.logs  
WHERE time >= now() - "PT15m"::interval  
 AND time < now()  
 AND search(message, "media")  
 AND search(message, "external")  
ORDER BY time DESC  
LIMIT 100;

ScopeDB має запитувальну мову, схожу на SQL, яку називають ScopeQL. Вона підтримує широкий спектр аналітичних запитів і спеціально розроблена для аналізу даних спостережуваності.

Наприклад, команда платформи спочатку використовувала Elasticsearch як сховище даних, яке надає потужні можливості пошуку. ScopeDB підтримує подібні складні фільтри, щоб покрити всі існуючі сценарії користувачів. Користувачі можуть фільтрувати за часовими діапазонами, збігами тексту, регулярними виразами, збігами міток, умовами з функціями та іншими параметрами. Агрегація — ще одна потужна функція для отримання інсайтів із даних спостережуваності, а підтримка Elasticsearch обмежена. Окрім базових функцій, таких як count, sum, min та max, ScopeDB підтримує розширені функції агрегації, як-от top-k, percentile та стандартне відхилення.

Продуктивність є важливою для виконання запитів з даними будь-якого масштабу. Основним фактором продуктивності є мінімізація обсягу оброблених даних. Особливо коли дані зберігаються в S3, ви хочете читати якомога менше об'єктів. ScopeDB може створювати різні індекси на стовпцях. У поєднанні з фільтрами для зменшення обсягу даних та розподілом даних в реальному часі, ScopeDB може значно зменшити кількість оброблених даних.

Крім того, ScopeDB зберігає дані в стовпцевому форматі, що означає, що він читає лише необхідні для запиту стовпці. Це бажано для більшості аналітичних запитів, оскільки зазвичай вони потребують лише кількох стовпців.
ScopeDB’s query engine is a vectorized query engine that processes multiple rows in a batch, further unleashing the benefit of columnar data format.

When performing aggregation on high-cardinality fields, one single node may not be able to handle the entire workload. Thanks to ScopeDB’s distributed query engine, we can scale out the query to multiple nodes. The query engine will distribute the workload to multiple nodes and merge the results in parallel. This not only makes running heavy queries possible but also accelerates queries in general.

Back to the architecture diagram, there are both default and heavy nodegroups. The default nodegroup is a long-running nodegroup for general queries. When a heavy query comes in (often an ad-hoc query), the deployment can temporarily scale out a new nodegroup (heavy) to handle the query, and then scale in after the query is done. In this way, heavy queries won't affect the performance of general queries.

Гнучка схема даних​

Дані спостережуваності часто мають гнучку схему. Візьмемо логи як приклад. Незалежно від того, чи це структуровані логи (логи додатків), чи звичайні текстові логи (логи доступу), платформа може нормалізувати їх у напівструктурований формат, наприклад, JSON:

{  
 "timestamp": "2025-01-22T03:20:15.506432Z",  
 "severity": "INFO",  
 "message": "User login successful",  
 "user_id": 108848,  
 "ip_address": "192.168.1.100",  
 "application": "WebApp",  
 "log_type": "authentication",  
 "location": "LoginController",  
 "server": "WebServer-01"  
}

Хоча логи доступу можуть змінювати формат лише час від часу, логи додатків можуть кожного дня отримувати нові поля. Неможливо визначити фіксовану схему для всіх логів заздалегідь.

Натомість, бази даних для даних спостережуваності повинні підтримувати змінні типи даних. ScopeDB може парсити JSON рядки в змінне значення (variant value):

VALUES  
 (1, 'null'),  
 (2, NULL),  
 (3, 'true'),  
 (4, '-17'),  
 (5, '123.12'),  
 (6, '1.912e2'),  
 (7, '"Om ara pa ca na dhih" '),  
 (8, '[-1, 12, 289, 2188, false]'),  
 (9, '{ "x" : "abc", "y" : false, "z": 10} '),  
SELECT $0 AS n, PARSE_JSON($1) AS v,  
SELECT n, v, TYPEOF(v),  
ORDER BY n

Виведе:

+---+------------------------------+-----------+  
| n | v | TYPEOF(v) |  
+---+------------------------------+-----------+  
| 1 | null | null |  
| 2 | NULL | NULL |  
| 3 | true | bool |  
| 4 | -17 | int |  
| 5 | 123.12 | float |  
| 6 | 191.2 | float |  
| 7 | 'Om ara pa ca na dhih' | string |  
| 8 | [-1,12,289,2188,false] | array |  
| 9 | {"x":'abc',"y":false,"z":10} | object |  
+---+------------------------------+-----------+

Якщо деякі поля логу є фіксованими і часто запитуваними, платформа спостережуваності може визначити таблицю з фіксованими та змінними полями. Фіксовані поля зберігаються в окремих стовпцях, і користувачі можуть створювати індекси на них для прискорення запитів. Ось приклад для таблиці логів:

CREATE TABLE scopedb.tenant.logs (  
 time TIMESTAMP,  
 container_id STRING,  
 container_name STRING,  
 container_runtime_name STRING,  
 container_type STRING,  
 filename STRING,  
 filepath STRING,  
 host STRING,  
 message STRING,  
 message_length INT,  
 name STRING,  
 source STRING,  
 status STRING,  
 var VARIANT,  
);

Стовпець time в основному використовується для фільтрації та сортування. Стовпець var зберігає оригінальне повідомлення логу як змінне значення. Інші стовпці — це мітки, що видобуваються з повідомлення логу.
Users can then create index on time and tags to accelerate the query.

For querying over variant data, ScopeDB provides a set of functions to extract, cast, and compare variant values:

FROM scopedb.tenant.logs  
WHERE var["meta"]["peer.hostname"]::string = "192.128.10.75"  
 AND time >= now() - "PT6h"::interval  
 AND time < now()  
GROUP BY source  
AGGREGATE max(time) as time, count(true);

Вперед до майбутнього​

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

Ми розповімо про це в майбутніх публікаціях; слідкуйте за новинами!

Якщо ви хочете негайно спробувати, можете використати наш playground:

git clone https://github.com/scopedb/community.git  
docker compose -f ./community/playground/docker-compose.yml up -d  
docker run -it --rm --entrypoint /bin/scopeql --network host scopedb/scopedb




Перекладено з: [Introducing ScopeDB: Manage Data in Petabytes for An Observability Platform](https://flex-ninja.medium.com/introducing-scopedb-manage-data-in-petabytes-for-an-observability-platform-ae2e6ee809a2)