ClickHouse или PostgreSQL: аналитика убрзава, али стиже и друга база

Задржите аналитику у PostgreSQL-у док контролне табле испуњавају договорени циљ за кашњење и број истовремених упита, а извештавање не омета трансакциони рад. Ако ти циљеви остају недостижни и после подешавања, ClickHouse може да преузме аналитичке упите, док PostgreSQL остаје место уписа. ClickHouse-ов архитектонски водич препоручује постепено издвајање изабраних података у аналитичку копију, уз мерење кашњења, истовремености и свежине.

Не постоји универзалан праг у броју редова после којег треба додати базу. Одлука зависи од стварних упита, броја корисника који их покрећу у исто време и тога колико свежи резултати морају да буду. Бржи аналитички одзив вреди само ако оправда трошак преноса, провере и одржавања друге копије.

Када PostgreSQL достиже границу

За повремене извештаје, ограничене временске опсеге и селективне упите PostgreSQL често остаје једноставнији избор. Индекси, статистике планера, унапред израчунати прегледи и реплика за читање могу да побољшају одзив или склоне аналитичко оптерећење са примарне базе. Њихов ефекат треба мерити на упитима које контролне табле заиста покрећу, јер додатни индекси и освежавање прегледа такође троше ресурсе.

Потреба за посебном аналитичком базом расте када истовремени упити агрегирају велики део историје, а PostgreSQL више не испуњава циљ за одзив или свежину без све скупљег одржавања. Реплика за читање одваја упите од примарне инстанце, али задржава складиште организовано по редовима. ClickHouse складишти вредности колона одвојено, па упит који чита неколико поља кроз много редова може да избегне читање непотребних колона. Та разлика је разлог за пробу на сопственом оптерећењу, а не обећање да ће сваки упит бити бржи.

Праг изразите кроз одзив, истовременост и свежину

Поставите циљ за p95 кашњење целе контролне табле и њених важних упита: то је време у ком се заврши 95 одсто посматраних извршавања. Мерите га током уобичајеног и вршног броја истовремених отварања, уз бележење оптерећења примарне базе. Брз појединачни упит не решава проблем ако се одзив нагло погорша када више корисника отвори исту таблу.

Условни пример: тим захтева да p95 важног упита остане испод две секунде при двадесет истовремених захтева, а приказани подаци касне највише један минут. То су примерени циљеви за поређење, не опште границе PostgreSQL-а или ClickHouse-а. Ако их подешен PostgreSQL стабилно испуњава, друга база још нема доказану корист. Ако их пробија, пилот мора да покаже да ClickHouse поправља одзив без кршења услова за свежину.

Код PostgreSQL реплике за читање пратите и кашњење примене промена. PostgreSQL документација о надзору објашњава да replay_lag на асинхроној реплици приближно показује када недавне трансакције постају видљиве упитима, али може да буде NULL када је реплика сустигла извор и нема нових промена. То није мера свежине ClickHouse копије: њу треба мерити од уписа у извор до појаве исправног резултата у аналитичком упиту.

Зашто јавни бенчмарк није праг за прелазак

Јавни тестови показују шта вреди испробати, али не мере понашање ваше контролне табле. Правила ClickBench-а описују резултате за више од 60 система и 43 упита над једном равном табелом; упити се извршавају редом, без провере истовременог оптерећења. Тест разликује хладна и загрејана извршавања, а сам наводи да избор података, облик табеле и различите конфигурације ограничавају директно поређење. Зато из његовог ранга не може да се прочита ваш p95 при вршном броју корисника.

Сложенији упити имају друга ограничења. Рад објављен у PVLDB-у приказује TPC-H мерења на једном AWS чвору и наводи да неки упити са корелисаним потупитима нису били подржани у тестираној верзији ClickHouse 24.6, док су други изостављени због тадашњих ограничења оптимизације спајања табела. То је граница тог мерења, а не тврдња о подршци у верзији коју бисте данас изабрали. За архитектонску одлуку меродавни су упити, модели података и верзије које би ваша примена користила.

Шта кошта ClickHouse копија преко CDC-а

Код репликације промена, односно CDC-а, PostgreSQL остаје трансакциони извор, а ClickHouse добија копију изабраних података за читање. PostgreSQL документација о логичкој репликацији описује почетно копирање стања табеле и потом слање нових промена претплатнику. Тај опис се односи на PostgreSQL репликацију; за ClickHouse одредиште потребан је одговарајући CDC механизам који чита промене и примењује их по правилима изабраног модела.

Почетно учитавање мора да буде усклађено са позицијом од које CDC наставља да чита промене. У супротном, копија може да прескочи или понови записе. Поред простора за другу базу и ресурса за пренос, у рачуницу улазе надзор кашњења, измене шема, обрада грешака и поступак поновног учитавања после прекида. Посебно треба знати колико дуго ток може да стоји пре него што наставак постане тежи од обнове копије.

И тачност резултата тражи рад. Трансакциона табела са изменама и брисањима не постаје сама од себе исправна аналитичка табела тренутног стања. Тим мора да одреди кључ записа, начин примене новијих верзија и брисања, као и понашање при промени шеме. Ако извештај спаја више табела, кашњење сваке копије може бити различито; резултат зато треба проверити на упоредивом пресеку података.

Пилот са једном табелом показује да ли се друга база исплати

За пилот изаберите табелу из које може да се израчуна један спор, пословно важан приказ. Измерите полазни p95 у PostgreSQL-у при истим упитима и истој истовремености које сте задали као циљ. Затим учитајте почетно стање, укључите CDC и поновите оптерећење над ClickHouse копијом. У поређење укључите и време почетног учитавања, потрошене ресурсе и рад потребан да ток промена остане стабилан.

Свежину измерите контролисаном изменом чије време уписа знате, па забележите када се њен исправан резултат појављује у ClickHouse упиту. Тачност проверите за исти пресек података у обе базе: упоредите број активних записа и агрегате које табла стварно приказује. Обухватите нови унос, измену и брисање. Ако упоредите извор и копију у различитим тренуцима, нормално CDC кашњење може изгледати као грешка у подацима.

Издвајање има основа када пилот истовремено испуни циљ за p95 под потребним оптерећењем, границу свежине и проверу пословних резултата, а укупни трошак рада остане прихватљив. Ако PostgreSQL већ постиже те услове уз мање одржавања, задржите аналитику у њему. Ако ClickHouse решава измерен проблем, најпре пребаците испробани приказ и задржите могућност повратка док се копија не покаже поузданом.

Прочитајте и:

• vidIQ или TubeBuddy: аналитика кошта више од масовних измена
• PostgreSQL или MySQL: бржи benchmark не доноси одлуку без истог нивоа изолације
• YouTube чланства у Србији: дугме Join стиже тек после провере