PostgreSQL – це не просто проста реляційна база даних; це фреймворк для управління даними з потенціалом охопити всю сферу баз даних. Тенденція “Використання Postgres для всього” вже не обмежується кількома елітними командами, а стає загальноприйнятою передовою практикою.
Новий виклик для OLAP
На зустрічі 2016 року, присвяченій базам даних, я стверджував, що значною прогалиною в екосистемі PostgreSQL є відсутність достатньо хорошого механізму стовпчастого зберігання для робочих навантажень OLAP. Хоча PostgreSQL сама по собі пропонує багато можливостей для аналізу, її продуктивність при повномасштабному аналізі великих наборів даних не зовсім відповідає спеціалізованим сховищам даних в режимі реального часу.
Розглянемо ClickBench, аналітичний бенчмарк продуктивності, де ми задокументували продуктивність PostgreSQL, розширень його екосистеми та похідних баз даних. Неналаштований PostgreSQL працює погано (x1050), але з оптимізацією він може досягти (x47). Крім того, є три розширення, пов’язані з аналізом: стовпчикове сховище Hydra (x42), сховище часових рядів TimescaleDB (x103) і розподілений Citus (x262).
Цю продуктивність не можна вважати поганою, особливо в порівнянні з чистими OLTP-базами даних, такими як MySQL і MariaDB (x3065, x19700); однак, продуктивність третього рівня не є “достатньо хорошою”, відстаючи від OLAP-компонентів першого рівня, таких як Umbra, ClickHouse, Databend, SelectDB (x3~x4), на порядок. Це складне становище – недостатньо задовільне, щоб використовувати, але занадто хороше, щоб від нього відмовитись.
Однак, поява ParadeDB і DuckDB змінила правила гри!
Власне PG розширення ParadeDB pg_analytics досягає продуктивності другого рівня (x10), скорочуючи розрив з верхнім рівнем лише до 3-4 разів. З огляду на додаткові переваги, такий рівень розбіжності в продуктивності часто є прийнятним – ACID, свіжість і дані в реальному часі без ETL, без додаткового навчання, без підтримки окремих сервісів, не кажучи вже про можливості повнотекстового пошуку на рівні ElasticSearch.
DuckDB фокусується на чистому OLAP, доводячи продуктивність аналізу до крайності (x3.2) – за винятком академічно орієнтованої бази даних з закритим вихідним кодом Umbra, DuckDB, мабуть, є найшвидшою для практичної продуктивності OLAP. Це не розширення PG, але PostgreSQL може повністю використовувати приріст продуктивності аналізу DuckDB як вбудованої файлової бази даних за допомогою таких проектів, як DuckDB FDW і pg_quack.
Поява ParadeDB і DuckDB виводить аналітичні можливості PostgreSQL на найвищий рівень OLAP, заповнюючи останню критичну прогалину в аналітичній продуктивності.
Маятник у світі баз даних
Різниці між OLTP та OLAP не існувало на початку створення баз даних. Відокремлення сховищ даних OLAP від баз даних виникло в 1990-х роках через те, що традиційні OLTP-бази даних намагалися підтримувати шаблони запитів аналітичних сценаріїв і вимоги до продуктивності.
Довгий час найкраща практика обробки даних полягала у використанні MySQL/PostgreSQL для робочих навантажень OLTP і синхронізації даних зі спеціалізованими OLAP-системами, такими як Greenplum, ClickHouse, Doris, Snowflake тощо, за допомогою ETL-процесів.
Як і багато інших “спеціалізованих баз даних”, сильна сторона спеціалізованих OLAP-систем часто полягає в продуктивності – досягнення 1-3 порядків покращення порівняно з рідними PostgreSQL або MySQL. Однак ціною цього є надлишкові дані, надмірний рух даних, відсутність узгодження значень даних між розподіленими компонентами, додаткові трудовитрати на спеціалізовані навички, додаткові витрати на ліцензування, обмежена потужність мови запитів, програмованість і розширюваність, обмежена інтеграція інструментів, низька цілісність і доступність даних порівняно з повноцінною DMBS.
Однак, як то кажуть, “Що робиться, те робиться”. Завдяки вдосконаленню апаратного забезпечення за тридцять років, що минули після закону Мура, продуктивність зросла в геометричній прогресії, а витрати різко знизилися. У 2024 році один сервер x86 може мати сотні ядер (512 vCPU, EPYC 9754 x2), кілька ТБ оперативної пам’яті, один твердотільний накопичувач SSD може вмістити до 64 ТБ / 3M 4K rand IOPS / 14 ГБ / с, а одна повністю флеш-стійка може досягати декількох PB; об’єктне сховище, таке як S3, пропонує практично необмежену пам’ять.
Удосконалення апаратного забезпечення вирішило проблему обсягу та продуктивності даних, а розробки програмного забезпечення для баз даних (PostgreSQL, ParadeDB, DuckDB) – проблеми методів доступу до них. Це ставить під сумнів фундаментальні припущення аналітичного сектору – так званої індустрії “великих даних”.
Як свідчить маніфест DuckDB “Великі дані мертві“, ера великих даних закінчилася. Більшість людей не мають стільки даних, і більшість даних рідко запитуються. Межа великих даних відступає в міру розвитку апаратного та програмного забезпечення, що робить “великі дані” непотрібними для 99% сценаріїв.
Якщо 99% сценаріїв використання тепер можна обробити на одній машині за допомогою автономного PostgreSQL / DuckDB (і його реплік), то який сенс у використанні спеціалізованих аналітичних компонентів? Якщо кожен смартфон може вільно надсилати та отримувати текст, який сенс у пейджерах? (Із застереженням, що північноамериканські лікарні все ще використовують пейджери, що свідчить про те, що, можливо, менше 1% сценаріїв справді потребують “великих даних”).
Зміна фундаментальних припущень веде світ баз даних від фази диверсифікації назад до конвергенції, від великого вибуху до масового вимирання. У цьому процесі настане нова ера уніфікованих, багатомодельних, суперконвергентних баз даних, що возз’єднають OLTP і OLAP. Але хто очолить цю монументальну задачу реконсолідації поля баз даних?
PostgreSQL: Пожирач світу баз даних
Існує безліч ніш у сфері баз даних: бази даних часових рядів, геопросторові, документи, пошукові, графічні, векторні бази даних, черги повідомлень та об’єктні бази даних. PostgreSQL дає відчути свою присутність у всіх цих областях.
Прикладом може слугувати розширення PostGIS, яке встановлює фактичний стандарт для геопросторових баз даних; розширення TimescaleDB незручно позиціонує “загальні” бази даних часових рядів; а векторне розширення PGVector перетворює нішу спеціалізованих векторних баз даних на справжній фурор.
Це не вперше; ми знову спостерігаємо це в найстарішому і найбільшому субдомені: OLAP-аналітика. Але амбіції PostgreSQL не зупиняються на OLAP; вона дивиться на весь світ баз даних!
Що робить PostgreSQL такою потужною? Звичайно, вона вдосконалена, як і Oracle; вона з відкритим вихідним кодом, як і MySQL. Перевага PostgreSQL полягає в тому, що вона є одночасно вдосконаленою і з відкритим вихідним кодом, що дозволяє їй конкурувати з Oracle/MySQL. Але її справжня унікальність полягає в надзвичайній розширюваності та процвітаючій екосистемі розширень.
Магія надзвичайної розширюваності
PostgreSQL – це не просто реляційна база даних; це фреймворк для управління даними, здатний охопити всю галактику баз даних. Окрім відкритого вихідного коду та передових технологій, її основна конкурентна перевага полягає в розширюваності, тобто можливості багаторазового використання бази даних та компонування розширень.
PostgreSQL дозволяє користувачам розробляти розширення, використовуючи загальну інфраструктуру бази даних для надання функцій з мінімальними витратами. Наприклад, розширення векторної бази даних pgvector, що містить лише кілька тисяч рядків коду, є незначним за складністю порівняно з мільйонами рядків PostgreSQL. Проте, це “незначне” розширення забезпечує повноцінні векторні типи даних та можливості індексування, перевершуючи багато спеціалізованих векторних баз даних.
Чому? Тому що творцям pgvector не потрібно було турбуватися про загальні додаткові складнощі бази даних: ACID, відновлення, резервне копіювання та PITR, висока доступність, контроль доступу, моніторинг, розгортання, сторонні екосистемні інструменти, клієнтські драйвери тощо, які потребують мільйони рядків коду для якісного вирішення. Вони зосередилися лише на основній складності своєї проблеми.
Наприклад, ElasticSearch був розроблений на основі пошукової бібліотеки Lucene, в той час як екосистема Rust має покращену бібліотеку повнотекстового пошуку наступного покоління Tantivy як альтернативу Lucene. ParadeDB потрібно лише обернути і підключити до інтерфейсу PostgreSQL, щоб запропонувати пошукові сервіси, які можна порівняти з ElasticSearch. Що ще важливіше, вона може стояти на плечах PostgreSQL, використовуючи об’єднану силу всієї екосистеми PG (наприклад, гібридний пошук з pgvector), щоб “нечесно” конкурувати з іншою спеціалізованою базою даних.
Розширюваність дає ще одну величезну перевагу: сумісність розширень, що дозволяє різним розширенням працювати разом, створюючи синергетичний ефект, де 1+1 ” 2. Наприклад, TimescaleDB можна комбінувати з PostGIS для підтримки просторово-часових даних; розширення BM25 для повнотекстового пошуку можна комбінувати з розширенням PGVector, забезпечуючи можливості гібридного пошуку.
Крім того, дистрибутивне розширення Citus може прозоро трансформувати автономний кластер у кластер розподіленої бази даних з горизонтальним поділом. Цю можливість можна ортогонально комбінувати з іншими функціями, перетворюючи PostGIS на розподілену геопросторову базу даних, PGVector на розподілену векторну базу даних, ParadeDB на розподілену повнотекстову пошукову базу даних і так далі.
Ще більш важливим є те, що розширення розвиваються незалежно, без обтяжливої необхідності злиття та координації основних гілок. Це забезпечує масштабування – розширюваність PG дозволяє численним командам паралельно досліджувати можливості бази даних, причому всі розширення є необов’язковими і не впливають на надійність основної функціональності. Ті функції, які є зрілими та надійними, мають шанс бути стабільно інтегрованими в основну гілку.
PostgreSQL досягає як фундаментальної надійності, так і гнучкої функціональності завдяки магії надзвичайної розширюваності, що робить її особливим явищем у світі баз даних і змінює правила гри в ландшафті баз даних.
Game Changer на DB Arena
Поява PostgreSQL змінила парадигми в галузі баз даних: Команди, які намагаються створити “нове ядро бази даних”, тепер стикаються з серйозним випробуванням – як виділитися на фоні багатофункціонального Postgres з відкритим вихідним кодом. У чому їхня унікальна пропозиція?
Доки не відбудеться революційного прориву в апаратному забезпеченні, поява практичних, нових, універсальних ядер баз даних здається малоймовірною. Жодна окремо взята база даних не може зрівнятися із загальною доблестю PG, підкріпленою всіма її розширеннями – навіть Oracle, враховуючи козир PG – відкритість і безкоштовність 😉
Нішевий продукт для баз даних може зайняти своє місце, якщо він зможе на порядок перевершити PostgreSQL у певних аспектах (як правило, у продуктивності). Однак, зазвичай не проходить багато часу, перш ніж екосистема PostgreSQL породжує альтернативні розширення з відкритим вихідним кодом. Вибір на користь розробки розширення PG, а не цілої нової бази даних, дає командам величезну перевагу в швидкості, щоб наздогнати суперників!
Дотримуючись цієї логіки, екосистема PostgreSQL буде розвиватися як сніжний ком, накопичуючи переваги і неминуче наближаючись до монополії, відображаючи статус ядра Linux в серверних ОС протягом декількох років. Опитування розробників та звіти про тенденції розвитку баз даних підтверджують цю траєкторію.
PostgreSQL вже давно стала улюбленою базою даних в HackerNews та StackOverflow. Багато нових проектів з відкритим вихідним кодом за замовчуванням обирають PostgreSQL як основну, якщо не єдину, базу даних. І багато компаній нового покоління переходять на PostgreSQL.
Як сказано в статті “Радикальна простота: Просто використовуйте Postgres“, спрощення технологічних стеків, зменшення кількості компонентів, прискорення розробки, зниження ризиків і додавання нових можливостей можна досягти за допомогою “простого використання Postgres“. Postgres може замінити багато бекенд-технологій, включаючи MySQL, Kafka, RabbitMQ, ElasticSearch, Mongo та Redis, без особливих зусиль обслуговуючи мільйони користувачів. Just Use Postgres більше не обмежується кількома елітними командами, а стає загальноприйнятою передовою практикою.
Що ще можна зробити?
Кінець гри для домену баз даних здається передбачуваним. Але що ми можемо і що повинні робити?
PostgreSQL вже є майже досконалим ядром бази даних для переважної більшості сценаріїв, що робить ідею про “вузьке місце” ядра абсурдною. Форки PostgreSQL і MySQL, які рекламують модифікації ядра як переваги, по суті, йдуть в нікуди.
Це схоже на ситуацію з ядром операційної системи Linux: незважаючи на велику кількість дистрибутивів Linux, всі обирають одне і те ж ядро. Форкінг ядра Linux розглядається як створення непотрібних труднощів, і індустрія не схвалює його.
Відповідно, основним конфліктом є вже не саме ядро бази даних, а два напрямки – розширення та сервіси бази даних! Перше стосується внутрішньої розширюваності, а друге – зовнішньої сумісності. Подібно до екосистеми ОС, конкурентний ландшафт буде зосереджений на дистрибутивах баз даних. У сфері баз даних лише ті дистрибутиви, що зосереджені на розширеннях та сервісах, мають шанс на остаточний успіх.
Ядро залишається прохолодним, а MariaDB, форк батьківської MySQL, наближається до делістингу, в той час як AWS процвітає, пропонуючи послуги та розширення на додаток до безкоштовного ядра. Інвестиції вливаються в численні розширення екосистеми PG і дистрибутиви сервісів: Citus, TimescaleDB, Hydra, PostgresML, ParadeDB, FerretDB, StackGres, Aiven, Neon, Supabase, Tembo, PostgresAI та наш власний дистрибутив PG – Pigsty.
Дилемою в екосистемі PostgreSQL є незалежна еволюція багатьох розширень та інструментів, за відсутності уніфікатора для їхньої синергії. Наприклад, Hydra випускає свій власний пакет і Docker-образ, так само як і PostgresML, кожен з яких поширює образи PostgreSQL з власними розширеннями і тільки з власними. Ці образи та пакети далекі від комплексних сервісів баз даних, таких як AWS RDS.
Навіть постачальники послуг та інтегратори екосистем, такі як AWS, не в змозі включити багато розширень з різних причин (ліцензія AGPLv3, проблеми з безпекою при багатокористувацькій оренді), таким чином, не використовуючи потенціал синергетичного підсилення розширень екосистеми PostgreSQL.
Розширення – це душа PostgreSQL. Postgres без свободи використання розширень – це все одно, що готувати їжу без солі, гігантський обмежений.
Вирішення цієї проблеми є однією з наших першочергових цілей.
Наша резолюція: Свинарник
Незважаючи на попередній досвід роботи з MySQL та MSSQL, коли я вперше використав PostgreSQL у 2015 році, я був переконаний у її майбутньому домінуванні у сфері баз даних. Майже десять років потому я перетворився з користувача та адміністратора на учасника та розробника, спостерігаючи за тим, як PG рухається до цієї мети.
Взаємодія з різними користувачами показала, що недоліком у сфері баз даних більше не є ядро – PostgreSQL вже є достатнім. Справжньою проблемою є використання можливостей ядра, що є причиною бурхливого успіху RDS.
Однак я вважаю, що ці можливості повинні бути настільки ж доступними, як і вільне програмне забезпечення, як і саме ядро PostgreSQL – доступними кожному користувачеві, а не тільки орендованими у кіберфеодалів.
Таким чином, я створив Pigsty, перший локальний дистрибутив PostgreSQL з батарейками, як альтернативу RDS з відкритим вихідним кодом, що має на меті використати колективну силу розширень екосистеми PostgreSQL та демократизувати доступ до сервісів баз даних виробничого рівня.
Ми визначили шість основних пропозицій, що стосуються центральних питань у сервісах баз даних PostgreSQL: Розширюваний Postgres, Надійна інфра-структура, Наочна графіка, Доступні сервіси, Інструментарій, що підтримується, та Компоновані модулі.
Ініціали цих ціннісних пропозицій утворюють ще одну абревіатуру – Pigsty:
Postgres, Infras, Графіка, Сервіс, Інструментарій, Ваш.
Ваш графічний інструментарій для обслуговування інфраструктури Postgres.
Розширювана PostgreSQL є основою цього дистрибутива. У нещодавно випущеному Pigsty v2.6 ми інтегрували розширення DuckDB FDW і ParadeDB, значно розширивши аналітичні можливості PostgreSQL і гарантуючи, що кожен користувач зможе легко використовувати цю потужність.
Наша мета – об’єднати сильні сторони екосистеми PostgreSQL, створивши синергетичну силу, подібну до Ubuntu у світі баз даних. Я вважаю, що дебати про ядро вирішені, і реальна конкурентна межа лежить тут.
Розробники, ваш вибір визначатиме майбутнє світу баз даних. Я сподіваюся, що моя робота допоможе вам краще використовувати найдосконаліше у світі ядро баз даних з відкритим вихідним кодом: PostgreSQL.
ОРИГІНАЛ СТАТТІ:Postgres is eating the database world
АВТОР СТАТІ:Vonng
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
