PostgreSQL или MySQL: истиот тест дава различен одговор од JSON-товарот

За нова апликација што ќе пребарува по различни атрибути во JSON, PostgreSQL е посилен почетен избор поради начинот на кој може да го индексира документот. Ако филтрите користат мал број однапред познати патеки, MySQL останува разумен избор, особено за тим што веќе го одржува. Одлучувачко е кои прашања ќе ги извршува апликацијата, а не кој производ има повисока бројка во општ тест.

Едно објавено мерење му дава предност на PostgreSQL при читање ред по идентификатор. За апликација со JSON-филтри, истата бројка има поинаква тежина: таа го опишува едноставното читање, додека разликата во индексирањето кажува повеќе за товарот што тимот навистина го очекува. Затоа резултатот од тестот треба да стои покрај видот на прашањето и условите во кои е добиен.

Што измерил тестот, а што останало надвор од него

Во тестот на BinaryIgor, базата и генераторот на товар работеле на одделни DigitalOcean машини од класата c-8-intel, секоја со 8 процесорски јадра и 16 GB меморија; читањето еден ред по идентификатор достигнало 34.674 прашања во секунда кај PostgreSQL и 22.782 кај MySQL, додека читањето по идентификатор со две спојувања достигнало 17.167, односно 17.214 прашања во секунда. Во првиот случај разликата е јасна, а во вториот пропусноста е речиси иста. Ниту едно од тие мерења не е мерење на пребарување низ JSON-документ.

Условите го ограничуваат значењето на резултатот. Споредени се конкретни шеми, прашања, индекси, клиентски драјвери и серверски подесувања; промената на која било од тие ставки може да го смени односот. Авторот објавил и латентност за побавните одговори, па пропусноста сама не ја опишува целата работа на апликацијата. Кога корисникот чека сложен филтер, време за одговор на тој филтер е поважно од бројот едноставни читања што серверот може да ги заврши во секунда.

За верно повторување на споредбата, кратката матрица на услови е поважна од рангирањето: читање по идентификатор, одделна машина за товарот, Docker за базите, подесена меморија и различни пулови на конекции. Тоа објаснува зошто бројката е корисна како резултат за конкретна конфигурација, но не и како општа процена за каталог со филтри, аналитичко прашање или апликација што често запишува податоци.

Каде PostgreSQL добива простор кај JSON-филтрите

Документацијата за PostgreSQL jsonb опишува разложен бинарен формат и директно индексирање на колоната; GIN-индексот може да поддржи соодветни проверки за постоење клуч, содржина и JSON-патека. За апликација во која нови филтри може да се појавуваат по различни атрибути, тоа е важна архитектонска предност: широкиот индекс може да опфати многу клучеви и вредности без за секој од нив однапред да се издвојува посебна колона. Тоа е можност за пристап до податоците, не објавен резултат дека секое такво прашање ќе биде побрзо од MySQL.

Широкиот GIN-индекс има и цена. Тој чува записи за многу содржини на документот, додека насочен индекс на израз чува само податоци од патеката што навистина се пребарува. Ако филтрите се стабилни, насочениот индекс може да биде помал и побрз за пребарување. Начинот на пишување на SQL-прашањето исто така е важен: оператор применет врз извлечен дел од документот нема автоматски да го користи индексот поставен врз целата колона.

Затоа „имаме JSON“ не е доволен опис на товарот. Разликата е меѓу прашање што бара една позната вредност и прашања што редовно бараат различни вгнездени атрибути. Во вториот случај можноста за индексирање на поширок сет пребарувања е посилен аргумент за PostgreSQL отколку неговата предност при читање по идентификатор во објавениот тест.

Што бара индексирањето во MySQL

Според прирачникот за MySQL 8.4, JSON-колона не се индексира директно: конкретна скаларна вредност може да се извлече во генерирана колона и таа да се индексира, а опишан е и индекс врз соодветен израз со JSON_VALUE(). Така прашање по позната патека може да добие насочен индекс. Ако производот подоцна воведе филтер по друго поле во документот, тимот треба да одлучи дали и за него е потребен индекс.

Овој пристап има смисла кога шемата на пребарувањето е стабилна. На пример, во условен каталог што секогаш филтрира по иста скаларна карактеристика, индекс за таа вредност може да биде сосема доволен. Ако филтрите се менуваат со секоја нова група производи, расте бројот на патеки за кои треба да се размислува одделно. Секој дополнителен индекс зафаќа простор и додава работа при запис, па одлуката влијае и врз одржувањето на шемата.

Споредбата тука е меѓу две стратегии за индексирање, а не меѓу „JSON поддржан“ и „JSON неподдржан“. И двете бази можат да чуваат и да пребаруваат JSON. Прашањето за мал тим е дали вообичаените филтри може однапред да се именуваат или апликацијата ќе бара флексибилност за нови патеки.

Зошто пулот и спојувањата го менуваат читањето на резултатот

Во кодот за извршување на тестот, стандардниот пул е поставен на 128 конекции за MySQL и 64 за PostgreSQL. Тоа се различни клиентски услови, иако класата на машините е иста. Бројката за пропусност затоа ја опишува целата поставка, вклучувајќи го начинот на кој клиентот ги испраќа прашањата, а не изолираната брзина на серверот.

Спојувањата додаваат друг слој. Читање по идентификатор обично има краток и предвидлив пат до редот; прашање со повеќе поврзани табели зависи од селективноста на условите, статистиката и избраниот план за извршување. Речиси еднаквата пропусност при спојувањата во објавениот тест покажува колку може да се промени практичниот впечаток кога ќе се смени само видот на прашањето. За апликација што комбинира релациски податоци со JSON-филтри, треба да се разгледува целото прашање, а не секој негов дел одделно.

Матрица за избор на база

• Променливи JSON-филтри: PostgreSQL jsonb е посилен почетен избор кога нови клучеви често стануваат услови за пребарување. Вклучете ја големината на GIN-индексот и товарот при запис во процената.
• Неколку стабилни JSON-патеки: MySQL е сериозен кандидат со индекс на генерирана колона или на соодветен израз. Истата патека може да се индексира насочено и во PostgreSQL, па самото присуство на JSON не го решава изборот.
• Претежно читање по клуч: објавениот тест покажува предност за PostgreSQL во наведената конфигурација. Таа вредност е релевантна само колку што вашата шема, податоци, индекси и пул наликуваат на измерените услови.
• Повеќе спојувања или мешан товар: споредувајте ги вистинските прашања, плановите за извршување и латентноста. Резултат од едноставно читање не ја претставува работата на целата апликација.
• Слични технички резултати: оперативното искуство на тимот станува значајно. Познатите алатки за резервни копии, дијагностика и одржување имаат вредност што синтетичката пропусност не ја мери.

За конечна одлука, доволна е мала проба со реалистична шема, репрезентативни податоци и прашањата што апликацијата навистина ќе ги поставува: читање по клуч, типично спојување и очекуван JSON-филтер. Запишете ги индексите, ресурсите и големината на пулот заедно со пропусноста и латентноста. Ако одговорот се смени по додавање индекс за патека или по промена на пулот, токму таа зависност покажува што тимот ќе треба да одржува во продукција.

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

• Строг JSON од AI: точната структура сè уште може да содржи погрешни вредности
• Укинете пристап на поврзани апликации: Google и Microsoft имаат различни граници
• Clockify или Toggl Track: бесплатниот тим губи на различно место