PostHog o'z omboridan DuckDB texnologiyasidan voz kechdi

Besh oy oldin PostHog o'z ma'lumotlar omborini ClickHouse o'rniga DuckDB asosida qaytadan qurgan edi, biroq hozirda kompaniya ushbu yechimdan butunlay voz kechdi. O'tishning asosiy sabablari sifatida mijozlar yuklamalarining ortishi va bir tugunli bulutli tizimlarning cheklovlari ko'rsatildi.

• PostHog murakkab so'rovlarni bajarish uchun besh oy oldin DuckDB'ga o'tgan edi.
• Bulut muhitida bir tugunli mexanizmni masshtablash qiyinchiliklar tug'dirdi.
• DuckLake hajmi 2 petabayt, ya'ni 1 trillion qator va 15.3 million ta snapshotga yetdi.
• Kompaniya o'zining Trino va HogLake formatiga asoslangan yangi arxitekturasini yaratdi.

Bulut muhitidagi cheklovlar

DuckDB lokal kompyuterda ma'lumotlarni tahlil qilish uchun eng yaxshi vosita bo'lsa-da, bulutda u kutilmagan muammolarni keltirib chiqardi. Mijozlar kutilgandan ham murakkabroq so'rovlarni ishga tushirdilar, bu esa juda katta resurslarni talab qiluvchi instansiyalarni talab qildi. Har bir so'rov uchun zarur bo'lgan protsessor va xotirani oldindan taxmin qilish juda qiyin vazifa bo'lib chiqdi.

Foydalanuvchilar o'z ishlarini bajarishda bunday texnik tafsilotlarga e'tibor qaratmasligi kerak. Shuningdek, ma'lumotlarni asinxron tarzda yuklamasdan S3'dan o'qish jarayonida ham qo'shimcha to'siqlarga duch kelindi. Resurslarni so'rov kelishidan oldin taqsimlash zarurati tizimning moslashuvchanligini pasaytirdi.

DuckLake arxitekturasi va uning muammolari

Ombor sifatida DuckLake kengaytmasidan foydalanilganda, PostHog miqyosida standart katalog sxemasi yetarli bo'lmay qoldi. Format barcha SQL ma'lumotlar bazalari uchun moslashuvchan bo'lishi kerakligi sababli, muayyan dvigatel uchun optimizatsiyalar cheklangan edi. Natijada yagona jadvalga yozish jarayoni uch daqiqadan ko'proq vaqt olishi mumkin edi.

Katalogdagi statistika qatorlarining 99% dan ortig'i allaqachon mavjud bo'lmagan jabvallarga tegishli bo'lib chiqdi. Uni tozalash yozish tezligini vaqtincha oshirgan bo'lsa-da, muammo takrorlanaverdi. Rasmiy sxemaga 100% mos kelish majburiyati muhandislarni o'z fork versiyasida ishlashga majbur qildi.

Postgres protokoli bilan bog'liq qiyinchiliklar

Postgres protokoli orqali 5432-port bo'ylab to'g'ridan-to'g'ri ulanishlarni taqdim etish g'oya sifatida yaxshi ko'rinsa-da, amalda uni masshtablash juda qiyin kechdi. Ulanishlarning uzilishi, bo'sh turgan sessiyalarni boshqarish va uzoq davom etadigan ulanishlar qimmatga tushdi. HTTP bilan solishtirganda pgwire uchun yukni taqsimlash vositalari juda kam edi.

Turli xil Postgres mijozlari o'zlarining talablariga ega bo'lib, jamoa doimiy ravishda xatolarni to'g'rilash bilan shug'ullandi. PostHog mijozlarning cheksiz xohishlarini bajarishdan ko'ra, eng yaxshi ma'lumotlar omborini yaratishga e'tibor qaratishga qaror qildi.

Kelgusi rejalar va xulosalar

Olingan tajriba shuni ko'rsatdiki, asosiy e'tibor texnologiyaning o'ziga emas, balki foydalanuvchiga taqdim etiladigan qulaylikka qaratilishi kerak. Jamoa Trino asosida o'zining maxsus yechimini ishlab chiqdi va HogLake nomli yangi ochiq jadval formatini yaratdi. Ushbu yangi tizim birinchi hamkorlarga taqdim etilishidan oldin kompaniya ichida petabaytli hajmda sinovdan o'tkazildi.