PostgreSQL vai MySQL: viens ātruma tests uzvarētāju neizvēlas

PostgreSQL un MySQL veiktspējai nav universāla uzvarētāja: izvēli nosaka lietotnes vaicājumi, indeksi un konfigurācija. Īsiem darījumiem salīdziniet caurlaidspēju un latentumu pie gaidāmā savienojumu skaita; ja būtiska ir meklēšana JSON dokumentos, vērtējiet tieši šo vaicājumu indeksēšanas iespējas.

Publicēts OLTP tests parāda, kā vienā vidē atšķiras lasīšana, rakstīšana un tabulu savienojumi. Tas var sašaurināt izvēli, taču pārsvaru konkrētā vaicājumā nevar automātiski pārcelt uz citu datu kopu, savienojumu skaitu vai JSON slodzi.

Ko patiesībā mēra OLTP salīdzinājums

Publicētajā 17 scenāriju OLTP testā PostgreSQL uzvarēja 14 scenārijos, MySQL — divos, bet vienā rezultāts bija neizšķirts. Tika salīdzinātas PostgreSQL 18.1 un MySQL 9.5 datubāzes Docker konteineros; katrai bija astoņu procesoru un 16 GB atmiņas ierobežojums. Savienojumu pūli atšķīrās: PostgreSQL izmantoja 64, MySQL — 128 savienojumus. Tādēļ skaitļi raksturo šīs konfigurācijas kopā ar testa vaicājumiem, nevis atsevišķu datubāzes īpašību.

MySQL pārsvars bija divos lasīšanas scenārijos ar saistītām tabulām. Vienā pasūtījums tika savienots ar lietotāju, otrā — ar pasūtījuma pozīcijām un precēm. Savukārt scenārijā, kur lietotāju pasūtījumiem aprēķināja apkopojumu, pārsvars bija PostgreSQL. Pat vienas kategorijas ietvaros rezultāts mainījās līdz ar vaicājuma formu.

Tests uzrāda gan izpildīto vaicājumu skaitu sekundē, gan latentumu. Caurlaidspēja raksturo paveiktā darba apjomu, bet 99. procentiles latentums rāda, cik ilgi jāgaida lēnākajai pieprasījumu daļai. Lietotnei ar stingru atbildes laika prasību lielāka caurlaidspēja viena pati vēl nav pietiekams izvēles pamats.

JSON glabāšana un indeksēšana ir cits salīdzinājums

PostgreSQL 18 JSON dokumentācija nošķir json, kas saglabā ievadītā teksta kopiju, un jsonb, kas dokumentu glabā apstrādātā binārā formā un atbalsta indeksēšanu. GIN indekss var palīdzēt meklēt datus daudzos jsonb dokumentos, taču indeksa operatoru klasei jāatbilst izmantotajam nosacījumam. Piemēram, klase jsonb_path_ops var būt efektīvāka ietveršanas meklējumiem, bet neatbalsta atslēgas esamības operatorus.

Jsonb pārveidošana ievades laikā prasa papildu darbu. Tā arī nesaglabā sākotnējo atslēgu secību un dublētas atslēgas. Ja lietotnei vajadzīga precīza ievadītā JSON teksta forma, šī atšķirība ir tikpat svarīga kā meklēšanas ātrums.

MySQL 8.4 JSON datu tipa apraksts paredz automātisku dokumentu derīguma pārbaudi un bināru glabāšanas formātu. Visu JSON kolonnu tieši indeksēt nevar: bieži meklētu skalāru vērtību var izvilkt ģenerētā kolonnā un indeksēt to, bet InnoDB atbalsta arī daudzvērtību indeksus JSON masīvu elementiem. Tās ir konkrētu meklējumu iespējas, nevis pierādījums, ka viena sistēma visus JSON vaicājumus izpildīs ātrāk.

OLTP testā izmantotas relāciju tabulas un to vaicājumi, tāpēc tā uzvaru skaits neatbild uz jautājumu par JSON indeksu ātrumu. Šajā izvēlē nozīme ir dokumentu struktūrai, meklētajām atslēgām, filtriem un tam, cik bieži dokumenti tiek mainīti.

Izvēle piecām darba slodzēm

Turpmākie secinājumi ir sākumpunkti izvēlei. Katram scenārijam svarīgs ir gan publicētā testa tvērums, gan apstāklis, kurā rezultātu vajag pārbaudīt ar saviem datiem.

• Īsi meklējumi pēc ID. Publicētajā konfigurācijā PostgreSQL bija spēcīgāks viena ieraksta lasījumos. Tas ir noderīgs signāls lietotnei, kurā šādi vaicājumi dominē. Ja reālajā sistēmā dati vairs neietilpst atmiņā, pieprasījumi izmanto citus indeksus vai ir citāds vienlaicīgo savienojumu skaits, izmēriet abas datubāzes ar attiecīgo datu apjomu.
• Bieži ievietošanas, labošanas un dzēšanas darījumi. Testa rakstīšanas scenāriji dod pamatu PostgreSQL uzskatīt par spēcīgu sākotnējo kandidātu. Paša izmēģinājumā saglabājiet izvietojumam vajadzīgo datu noturību un žurnalēšanu, kā arī tādu pašu darījumu lielumu. Citādi ātruma starpība var atspoguļot atšķirīgu datu saglabāšanas režīmu, nevis lietotnei pieejamu ieguvumu.
• Lasīšana ar tabulu savienojumiem. MySQL uzvaras pasūtījumu savienošanas vaicājumos padara to par nopietnu kandidātu šādai slodzei. Taču rezultāts neattiecas uz visiem savienojumiem: testā cits vaicājums ar pasūtījumu apkopojumu deva pretēju iznākumu. Pārbaudiet savas tabulu attiecības, filtrus, kārtošanu un atgriezto rindu skaitu.
• Meklēšana mainīgas struktūras JSON dokumentos. PostgreSQL jsonb ar piemērotu GIN indeksu ir saprotams sākumpunkts, ja filtri skar dažādas atslēgas. Ja lietotne pārsvarā meklē dažus zināmus laukus vai masīvu elementus, salīdzinājumā iekļaujiet arī MySQL ģenerēto kolonnu vai daudzvērtību indeksu risinājumu. Abos gadījumos izmantojiet savus dokumentus un faktiskos filtrus.
• Jaukta lasīšanas un rakstīšanas slodze. Atsevišķu vaicājumu maksimumi neatspoguļo situāciju, kad darbības notiek reizē. Publicētajā testā jaukta slodze bija viens konkrēts pieprasījumu sadalījums; lietotnē tas var būt citāds. Salīdziniet kopējo caurlaidspēju un latentumu pie paredzētās proporcijas, savienojumu skaita un datu apjoma.

Kāpēc konfigurācija var apgriezt rezultātu

Diskusijā par testu tika izvirzīts jautājums, vai MySQL rakstīšanas rezultātus ietekmēja binārais žurnāls; autors atbildēja, ka šo ietekmi nebija padziļināti izpētījis. Tas ir pamatots iemesls papildu mērījumam, taču diskusija nenosaka, cik lielu daļu no novērotās starpības žurnāls izskaidro.

MySQL 8.4 binārā žurnāla dokumentācija norāda, ka žurnāls parasti ir ieslēgts un tiek izmantots dublēšanai un replikācijai. Ja paredzētajam izvietojumam tas ir vajadzīgs, salīdzinājumā jāsaglabā šī prasība. Mērījums ar izslēgtu žurnālu var palīdzēt novērtēt tā ietekmi, bet tas ir atsevišķs konfigurācijas scenārijs.

Arī savienojumu pūla lielums, piešķirtā atmiņa, izolācijas līmenis un indeksi ietekmē to, kādu darbu datubāze spēj apkalpot. Testā MySQL un PostgreSQL bija vienādi konteineru resursu ierobežojumi, tomēr atšķirīgi savienojumu pūli un katrai sistēmai pielāgoti iestatījumi. Tāpēc vienāds procesoru skaits vēl nenozīmē identiskus mērījuma apstākļus.

Ko nosaka paša datu kopas izmēģinājums

Galīgai izvēlei vajadzīgs neliels, reprezentatīvs izmēģinājums ar lietotnes shēmu, dokumentiem un biežākajiem vaicājumiem. Abām sistēmām piešķiriet salīdzināmus resursus, bet katrā izveidojiet tieši tās vaicājumiem piemērotus indeksus. Palaidiet lasīšanu un rakstīšanu paredzētajā proporcijā un pakāpeniski palieliniet vienlaicīgo savienojumu skaitu līdz gaidāmajai slodzei.

Fiksējiet caurlaidspēju, vidējo un 99. procentiles latentumu kopā ar konfigurāciju, pie kuras tie iegūti. Ja viena sistēma uzvar ID meklējumos, bet otra — svarīgākajos savienojumos vai JSON filtros, izšķirošs ir šo vaicājumu īpatsvars lietotnē un pieļaujamais gaidīšanas laiks. Tas ir konkrētāks izvēles pamats nekā viena testa kopējais uzvaru skaits.

Lasiet arī:

• Metricool vai Buffer: kontu skaits apgriež cenas salīdzinājumu
• Basecamp vai Asana: liela komanda var apgriezt cenas salīdzinājumu
• Kraken vai Coinbase: Pro režīms var apgriezt komisiju salīdzinājumu