Porovnanie MySQL a PostgreSQL. Vyberte si subd medzi mysql, postgresql, mariadb a mssql? Porovnanie výkonu servera ms sql a postgresql

Buďme úprimní, hoci 1C Enterprise je kompatibilný s mnohými DBMS, v skutočnosti 99 percent funguje buď v MS SQL alebo v bezplatnom PostgreSQL.

Inými slovami, tieto dve „subs“ dobyli trh klient-server 1C.

A môžeme pokojne predpokladať, že ak firma nepracuje v MS SQL, tak s najväčšou pravdepodobnosťou používa práve PostgreSQL.

Preto má zmysel porovnávať Postgres iba s MS SQL.

Dnes sa o MS SQL aj PostgreSQL veľa píše, no väčšinou ich objektívne neporovnávajú.

V tomto článku budeme analyzovať hlavné technické body bezplatného PostgreSQL a porovnáme ho s MS SQL.

To vám v budúcnosti umožní urobiť tú najlepšiu voľbu a pripraviť sa na rôzne „prekvapenia“ alebo, čo by bolo správnejšie, na „vlastnosti“ práce v tomto bezplatnom DBMS.

Vyhodnotíme všetko tak, ako to je, bez toho, aby sme Postgresu pridávali tie zásluhy, ktoré nemá a bez prikrášľovania platených MS.

Hneď odpoviem na otázku, ktorá trápi mnohých začiatočníkov!

ÁNO! MS SQL je rýchlejší ako PostgreSQL, to je fakt! A existuje na to niekoľko dôvodov!

Možno som hneď niekoho sklamal a možno s týmto tvrdením nesúhlasíte, ospravedlňujem sa, ale samotná fyzika tohto bezplatného DBMS mu neumožňuje predbehnúť MS SQL, najmä ak sa bavíme o takej bande ako je napr. "Monster 1C" a PostgreSQL.

S podobnými argumentmi sa neraz stretnete na rôznych konferenciách a seminároch venovaných tomuto DBMS. Nikto nič neskrýva ani nepopiera, fakt je fakt.

Napriek tomu je výkon PostgreSQL pre používateľov celkom dostatočný mohol pohodlne pracovať v 1C.

Či už je to tucet používateľov alebo dokonca niekoľko stoviek, ktorí súčasne pracujú v 1C Enterprise.

Prečo "Monster 1C"?

V skutočnosti takto 1C vidí PostgreSQL bez nainštalovaných špeciálnych „záplat“ a rozšírení.

Áno, to, čo sa volá po vybalení, stiahnutím distribučnej súpravy PostgreSQL v kancelárii. stránku nebudete môcť použiť na prácu v spojení s 1C. 1C-ka strašne spomalí a len zastaví, odmietne pracovať.

Prečo sa to deje a prečo „záplaty“?

Faktom je, že 1C Enterprise vytvára v priebehu svojej práce obrovské množstvo dočasných tabuliek, môžeme sa porozprávať asi tisíce tabuliek za sekundu, a ak si vezmeme napríklad register „Plátok posledného“ - „Zostatky a obraty“, tam môžu dobre a milión riadkov byť.

Faktom je, že štandardne (bez „záplat“) PostgreSQL nepočíta štatistiky o týchto veľkých dočasných tabuľkách, inými slovami, optimalizátor dotazov, ktorý sa riadi údajmi zo štatistík (a, ako si pamätáme, je prázdny, nie je čo počítať) zhruba povedané, robí výber pomocou VYBRAŤ *čo samozrejme bude fungovať veľmi, veľmi pomaly!

Preto tie grandiózne brzdy v 1C!

Samozrejme, toto nie sú všetky problémy, ktoré je potrebné vyriešiť, aby PostgreSQL normálne fungoval v tandeme s 1C. Ďalšie "záplaty" budú potrebné a špeciálne rozšírenia a po 15-20 užívateľoch aj ďalšie. nastavenia v konfigurácii

Áno, v skutočnosti všetko vyzerá oveľa komplikovanejšie, ako som opísal vyššie, ale ak to veľmi zjednodušíte, hlavný problém pomalej práce 1C s PostgreSQL bude vyzerať takto.

Druhá vec, ktorá sa mi na PostgreSQL veľmi nepáči, je žiadne multithreading v rámci jednej požiadavky v porovnaní s MS SQL.

(Od verzie 9.6 sme urobili prvý pokus o paralelizáciu dotazov, ale zatiaľ to funguje slabo, niekedy je efekt opačný). ale za vyskúšanie 5!)

Čo samozrejme ovplyvňuje výkon, aby ste to jednoducho pochopili -

PostgreSQL môže odstrániť váš 48-jadrový server jedným veľkým dotazom!

Je to jednoduché, nedochádza k paralelizácii vlákien v rámci jednej požiadavky a jedna veľká požiadavka „načíta“ len jedno jadro.

Áno, ak existuje veľa požiadaviek, načítajú sa všetky jadrá a všetko bude fungovať dobre.

A skoro som zabudol porovnávame PostgreSQL s MS SQL Standard nie Express!

Express, hoci môže byť použitý na komerčné účely, má množstvo obmedzení

napríklad 10 GB na základňu, využitie jedného procesora, 1 GB Náhodný vstup do pamäťe,

robí použitie takéhoto produktu takmer nereálnym pre prácu v 1C Enterprise.

Pokiaľ nemáte veľmi malú databázu a iba pár používateľov (a aj tak existuje len veľmi málo 1 GB bŕzd pre DBMS).

Porovnajme si teda PostgreSQL s populárnou verziou Standard.

SKRIPTY!!!

PostgreSQL sú primárne skripty v porovnaní s MS SQL, väčšina operácií sa musí robiť ručne, áno, samozrejme, niektoré základné veci môžete nainštalovať cez rozhranie, ale zdôrazňujem, že tie základné a krok doľava, krok doprava a musíte napísať skript alebo BASH v systéme Linux alebo cmd, powershell v systéme Windows.

Zobrazenie a analýza stôp pomocou nástroja SQL Server Profiler.

V PostgreSQL chýba známy SQL Server Profiler a slovom „chýba“ mám na mysli, že vstúpim úplne, žiaľ, nič podobné v PostgreSQL nie je.

Existujú samozrejme nástroje, ktoré umožňujú, ak máte čas zachytiť požiadavku alebo nastaviť bod prerušenia 1C v debuggeri a niečo získať a uvidíte, ale v porovnaní s Profiler, ako sa hovorí, to nebolo ani zďaleka.

Môžete si založiť denník a potom to všetko prejsť – ale na dlhú dobu!

Tu je príklad:

Programátor 1C sa snaží odladiť nejaký veľký dotaz, trvá to dlho, napríklad 30 minút, a tak v PostgreSQL, aby sa údaje dostali do logu, musí byť tento dotaz vykonaný! Viete si predstaviť, ako dlho trvá odladenie takejto požiadavky?

V MS SQL môžete prerušiť vykonávanie dotazu a analyzovať ho v Profileri, pretože tam už bude, ale so stavom „zlyhalo“.

Postgres nemá obdobu, pokiaľ ide o vytváranie „záloh“!

Tu máte ako prírastkovú „zálohu“, tak aj kompletnú zálohovanie a nepretržitá archivácia WAL.

V skutočnosti existuje čiastočná záloha a čiastočná obnova dát.

Môžete nakonfigurovať nepretržitú archiváciu a obnovu v určitom čase (Obnova v bode v čase (PITR)).

Tiež replikácie, je k dispozícii natívne v PostgreSQl bez akýchkoľvek „záplat“ utilít a doplnkov!

• Kaskádová replikácia
• Streamovacia replikácia
• Synchrónna replikácia
• Priebežná archivácia na pohotovostnom serveri

Toto všetko je už spočiatku v PostgreSQl a samozrejme nie v "expreske" a nie je dostupné vo verzii MS SQL Standard.

Ak chcete získať všetko uvedené vyššie v MS SQL, musíte si kúpiť veľmi drahý MS SQL Enterprise, teraz niečo okolo 15 000 $.

Čo nie je v porovnaní s MS SQL?

ŽIADNA diferenciálna "záloha"

Áno, v PostgreSQl neexistuje rozdielová „záloha“, ale existujú rôzne analógy prírastkových „záloh“.

Napríklad prírastkové „zálohovanie“ na úrovni bloku.

EXISTUJE rozdelenie TABLESPACEs, ktoré už štandardne podporuje 1C!

Čo mimochodom nie je v MS SQL!

Môžete napríklad nakonfigurovať, na ktorom disku budete mať „indexy“ a na ktorom disku bude umiestnená „tabuľka“, je to veľmi výhodné pri plánovaní IT infraštruktúry, pokiaľ ide o veľké databázy 1C. ONLINE_ANALYZE na prepočítanie štatistík. To isté platí pre súbor *dt.

S PostgreSQL len zriedka potrebujete REINDEX!

V skutočnosti by sa mal používať iba vtedy, keď existuje podozrenie, že bola narušená integrita databázy.

Môžete robiť "zálohy" s výnimkou tabuliek!

Napríklad vo vašej spoločnosti pracuje niekoľko 1C programátorov, ktorí to zaručene urobia zálohy vytvárať „zálohy“ pre ďalší rozvoj.

Používatelia tým trpia, databáza sa pri vytváraní veľkej „zálohy“ spomaľuje, najmä ak táto databáza obsahuje také veci, ako sú rôzne priložené súbory, archívy, dokumenty z listov. Takéto tabuľky súborov môžu ľahko obsahovať stovky gigabajtov. A môžu byť tiež vylúčené v PostgreSQl vytvorením „zálohy“, teda malej veľkosti a so všetkými funkciami súčasne.

Takže opäť nenačítavame sieťové zariadenia, neupchávame kanál, trávime oveľa menej času vytváraním takejto „zálohy“

Nakoniec vyhráva každý! A používatelia, programátori a správcovia pokojne spia.

V tomto článku sme analyzovali iba základné rozdiely medzi PostgreSQl a MS SQL (existujú aj iné), ale ak sa rozhodnete pre ten či onen DBMS, článok by vám mal pomôcť!

Veľa šťastia kolega!

P.S. Teraz pracujem na novom kurze „1C a PostgreSQL“ (už v štádiu nahrávania, počkajte, čoskoro!)

S pozdravom Bogdan.

V očakávaní mojej prezentácie na konferencii PGCONF.RUSSIA 2015 sa podelím o niekoľko postrehov o dôležitých rozdieloch medzi DBMS MySQL a PostgreSQL. Tento materiál bude užitočný pre všetkých, ktorí už nie sú spokojní s možnosťami a Funkcie MySQL, ako aj tí, ktorí robia prvé kroky v Postgrese. Samozrejme, tento príspevok by sa nemal považovať za vyčerpávajúci zoznam rozdielov, ale bude to stačiť na rozhodnutie v prospech jedného alebo druhého DBMS.

replikácie

Problém je v tom, že mnohé systémy správy úložného priestoru... často robia svoje vlastné WAL a PITR. Niektoré z nich robia vlastnú správu vyrovnávacej pamäte, zamykanie a správu replikácie/načítania. Takže, ako hovoríte, je ťažké povedať, kde by malo byť rozhranie
abstrahovaný.

Prešlo viac ako 10 rokov a čo vidíme? MySQL má nepríjemné problémy s transakciami medzi tabuľkami rôznych úložných strojov a MySQL má problémy s replikáciou. Počas týchto desiatich rokov pridal PostgreSQL pripojiteľné dátové typy a indexy a má tiež replikáciu - to znamená, že výhoda MySQL bola vyrovnaná, zatiaľ čo architektonické problémy MySQL zostali a zasahovali do života. MySQL 5.7 sa pokúsil vyriešiť problém s výkonom replikácie jeho paralelizáciou. Keďže projekt v práci je vzhľadom na svoj rozsah veľmi citlivý na výkon replikácie, skúsil som otestovať, či sa zlepšil. Zistil som, že paralelná replikácia v 5.7 je pomalšia ako jednovláknová replikácia v 5.5 a iba v niektorých prípadoch - približne rovnaká. Ak momentálne používate MySQL 5.5 a chcete inovovať na novšiu verziu, upozorňujeme, že migrácia nie je možná pre projekty s vysokou záťažou, pretože replikácia sa jednoducho zastaví.

Po správe o vysokom zaťažení Oracle vzal na vedomie test, ktorý som vyvinul, a povedal, že sa pokúsi problém vyriešiť; Nedávno mi dokonca napísali, že v testoch videli paralelnosť a poslali nastavenia. Ak sa nemýlim, pri 16 vláknach došlo k miernemu zrýchleniu oproti jednovláknovej verzii. Bohužiaľ som ešte nezopakoval svoje testy na poskytnutých nastaveniach - najmä preto, že s takýmito výsledkami sú naše problémy stále relevantné.

Presné dôvody tejto regresie výkonnosti nie sú známe. Návrhov bolo viacero – napríklad Christian Nelsen, jeden z vývojárov MariaDB, vo svojom blogu napísal, že môžu nastať problémy so schémou výkonu, so synchronizáciou vlákien. Z tohto dôvodu existuje regresia 40%, čo je viditeľné na konvenčných testoch. Vývojári Oracle to popierajú a dokonca ma presvedčili, že to neexistuje, zjavne vidím nejaký iný problém (a koľko ich je?).

Pri replikácii MySQL sú problémy s ukladacím jadrom umocnené zvolenou úrovňou replikácie – sú logické, zatiaľ čo v PostgreSQL sú fyzické. Logická replikácia má v princípe svoje výhody, umožňuje robiť zaujímavejšie veci, spomeniem to aj v reportáži. Ale PostgreSQL, dokonca aj ako súčasť svojej fyzickej replikácie, už neguje všetky tieto výhody. Inými slovami, takmer všetko, čo je v MySQL, sa už dá urobiť v PostgreSQL (alebo bude možné v blízkej budúcnosti).

Nemôžete dúfať, že implementujete nízkoúrovňovú fyzickú replikáciu v MySQL. Problém je, že namiesto jedného logu (ako v PostgreSQL) sú tam dva alebo štyri – podľa toho, ako počítate. PostgreSQL jednoducho odovzdá dotazy, tie sa dostanú do protokolu a tento protokol sa použije pri replikácii. Replikácia PostgreSQL je super stabilná, pretože používa rovnaký protokol ako operácie zlyhania. Tento mechanizmus bol dlho napísaný, dobre otestovaný a optimalizovaný.

V MySQL je situácia iná. Máme samostatný protokol InnoDB a protokol replikácie a musíme vykonať potvrdenie tam aj tam. A toto je dvojfázové odovzdanie medzi protokolmi, ktoré je podľa definície pomalé. To znamená, že nemôžeme len vziať a povedať, že opakujeme transakciu z denníka InnoDB – musíme zistiť, o akú požiadavku ide a spustiť ju znova. Aj keď ide o logickú replikáciu, na úrovni riadkov je potrebné tieto riadky vyhľadať v indexe. A nielenže musíte urobiť veľa práce na vykonanie dotazu - zároveň sa opäť zapíše do jeho InnoDB logu už na replike, čo zjavne nie je dobré pre výkon.

V PostgreSQL je v tomto zmysle architektúra rádovo premyslenejšia a lepšie implementovaná. Nedávno oznámila funkciu s názvom Logické dekódovanie – ktorá vám umožňuje robiť rôzne zaujímavé veci, ktoré sa v rámci fyzického žurnálu robia len veľmi ťažko. V PostgreSQL ide o doplnok zhora, logické dekódovanie umožňuje pracovať s fyzickým protokolom, ako keby bol logický. Práve táto funkcionalita čoskoro odoberie všetky výhody replikácie MySQL, snáď okrem veľkosti denníka - vyhrá replikácia MySQL založená na príkazoch - ale replikácia MySQL založená na príkazoch má absolútne divoké problémy na tých najneočakávanejších miestach a vy nemal by to počítať dobré rozhodnutie(Aj o tom všetkom budem hovoriť v správe).

Okrem toho existuje spustená replikácia pre PostgreSQL - to je Tungsten, ktorá vám umožňuje urobiť to isté. Spúšťaná replikácia funguje nasledovne: nastavia sa spúšťače, vypĺňajú tabuľky alebo zapisujú súbory, výsledok sa odošle do repliky a tam sa aplikuje. Pokiaľ viem, cez Tungsten migrujú z MySQL na PostgreSQL a naopak. V MySQL funguje logická replikácia priamo na úrovni enginu a inak to už nie je možné.

Dokumentácia

Napríklad takto strieľala Percona: viedli MySQL Performance Blog a na tomto blogu bolo množstvo článkov, ktoré sa zaoberali určitými aspektmi fungovania MySQL. To prinieslo divokú popularitu, priviedlo klientov k poradenstvu, umožnilo prilákať zdroje na spustenie vývoja vlastného forku Percona-Servera. Existencia a relevantnosť MySQL Performance Blogu dokazuje, že oficiálna dokumentácia jednoducho nestačí.

PostgreSQL má prakticky všetky odpovede v dokumentácii. Na druhej strane, pri porovnávaní dokumentácie PostgreSQL s „dospelým“ Oracle som počul veľa kritiky. Ale v skutočnosti je to veľmi dôležitý ukazovateľ. Vôbec nikto sa nepokúša porovnávať MySQL so starším Oracle - bolo by to smiešne a smiešne - ale PostgreSQL sa už začína porovnávať celkom vážne, komunita PostgreSQL počúva túto kritiku a pracuje na zlepšení produktu. To naznačuje, že svojimi schopnosťami a výkonom začína konkurovať takým výkonný systém ako Oracle, na ktorom pracujú mobilných operátorov a banky, zatiaľ čo MySQL zostáva vo výklenku webových stránok. A obrovské projekty, ktoré sa rozrástli na veľké množstvo údajov a používatelia smútia smútok s MySQL veľkou lyžicou, neustále spočívajú na jej obmedzeniach a architektonických problémoch, ktoré nemožno vyriešiť vynaložením primeraného množstva času a úsilia.

Príkladom takýchto veľkých projektov na PostgreSQL je 1C: PostgreSQL prichádza ako možnosť namiesto Microsoft SQL a Microsoft SQL je skutočne fantastický DBMS, jeden z najvýkonnejších. PostgreSQL môže nahradiť MS SQL a pokus o nahradenie MySQL... poľutujeme túto scénu, ako napísal Mark Twain.

Normy

Zložitosť výkonu a správy

MySQL má problém so zložitými dopytmi. Napríklad MySQL nevie, ako znížiť zoskupenie do samostatných častí Union all. Rozdiel medzi týmito dvoma dotazmi je v tom, že v našom príklade zoskupovanie podľa samostatných tabuliek a zjednotenie všetkých zhora fungovalo 15-krát rýchlejšie ako zjednotenie všetkých a následné zoskupenie, hoci optimalizátor by mal oba dotazy priviesť do rovnakého efektívneho plánu vykonávania dotazov. Generovanie takýchto požiadaviek budeme musieť robiť ručne – teda venovať čas vývojárom tomu, čo má databáza robiť.

"Jednoduchosť" MySQL pramení, ako je vidieť vyššie, z extrémne slabých funkcií - MySQL jednoducho funguje horšie a vyžaduje viac času a úsilia počas vývoja. Naproti tomu PostrgreSQL má histogramy a normálny optimalizátor a bude takéto dotazy vykonávať efektívne. Ale ak existujú histogramy, potom sú tu ich nastavenia - aspoň veľkosť vedra. Musíte vedieť o nastaveniach a v niektorých prípadoch ich zmeniť - preto musíte pochopiť, o aký druh nastavenia ide, za čo je zodpovedný, vedieť takéto situácie rozpoznať, vidieť a zvoliť optimálne parametre.

Občas sa stane, že zručnosť PostrgreSQL môže skôr prekážať ako pomáhať. 95% času všetko funguje dobre - lepšie ako MySQL - a jeden hlúpy dotaz je oveľa pomalší. Alebo všetko funguje dobre a potom zrazu (z pohľadu používateľa), ako projekt rástol, začali niektoré dotazy fungovať zle (údajov bolo viac, začal sa vyberať iný plán vykonávania dotazov). Na opravu s najväčšou pravdepodobnosťou stačí spustiť analýzu alebo trochu upraviť nastavenia. Ale musíte vedieť, čo robiť a ako to urobiť. Minimálne si musíte prečítať dokumentáciu PostgreSQL na túto tému, ale z nejakého dôvodu neradi čítajú dokumentáciu. Možno preto, že v MySQL je z toho malá pomoc? :)

Zdôrazňujem, že PostgreSQL nie je v tomto zmysle o nič horší, akurát vám umožní odložiť problémy a MySQL ich okamžite vyhodí a vy musíte míňať čas a peniaze na ich riešenie. V tomto zmysle MySQL vždy funguje trvalo zle a dokonca aj vo fáze vývoja ľudia berú do úvahy tieto funkcie: robia všetko na maximum jednoduchým spôsobom. Týka sa to len výkonu, presnejšie spôsobov jeho dosiahnutia a jeho predvídateľnosti. Pokiaľ ide o správnosť a pohodlie, PostgreSQL je hlavou a ramenami nad MySQL.

Čo si teda vybrať?

Po prvé, aké skúsenosti má tím? Ak má celý tím 10 rokov skúseností s MySQL a potrebuje čo najrýchlejšie naštartovať, potom nie je pravda, že sa oplatí vymeniť známy nástroj za neznámy. Ak však načasovanie nie je kritické, mali by ste vyskúšať PostgreSQL.

Po druhé, nesmieme zabúdať na problémy s prevádzkou. Ak nemáte vysoko zaťažený projekt, potom z hľadiska výkonu nie je medzi týmito dvoma DBMS žiadny rozdiel. PostgreSQL má ale ešte jednu dôležitú výhodu: je prísnejší, robí za vás viac kontrol, dáva vám menší priestor na chyby, a to je z dlhodobého hľadiska obrovská výhoda. Napríklad MySQL musí napísať svoje vlastné nástroje na overenie normálnej referenčnej integrity databázy. A aj to môže byť problém. V tomto zmysle je nástroj PostgreSQL výkonnejší, flexibilnejší a príjemnejší na vývoj. Ale to do značnej miery závisí od skúseností vývojára.

Zhrnutie: ak máte jednoduchý internetový obchod, nemáte peniaze na správcu, nemáte vážne ambície vyrásť do veľkého projektu a máte skúsenosti s MySQL, vezmite si MySQL. Ak očakávate, že projekt bude populárny, ak je veľký, bude ťažké ho prepísať, ak má zložitú logiku a vzťahy medzi tabuľkami - vezmite si PostgreSQL. Aj po vybalení vám bude fungovať, pomôže vo vývoji, ušetrí čas a bude sa vám ľahšie rásť.

Je ťažké nájsť organizáciu, ktorá nepoužíva účtovné systémy od 1C - dokonca aj v mega-holdingoch, kde sa už dlho implementuje SAP alebo OEBS, sa takmer vždy používajú v jednej alebo druhej oblasti. Je potešujúce, že ruský aplikačný softvér sa stal de facto štandardom pre naše spoločnosti, ale je tu jedna jemnosť: rovnaký de facto štandard pre 1C: Enterprise sa stal Použitie Microsoft SQL Server ako DBMS.

Medzi praktizujúcimi 1C prezývkami je najčastejší názor, že bez komerčných DBMS od amerických výrobcov nič dobré nepríde, niekoľko stoviek používateľov si v tomto prípade nevyhnutne vyžaduje inštaláciu databázy na MS SQL, Oracle Database alebo IBM DB2. Na prácu pod kontrolou slobody PostgreSQL DBMS sa názory nám známych odborníkov rozchádzali, ale v rozmedzí od „vôbec nefunguje“ po „vhodné pre niekoľko desiatok používateľov, viac nie“.

Pre takéto skromné ​​odhady existovalo niekoľko hodnoverných vysvetlení: aktívne používanie dočasných tabuľkových mechanizmov platformami 1C (ktoré sú v Postgrese implementované príliš „čestne“ - s transakčným DDL, všetkými možnosťami obnovy), ako aj zvláštnosti práce s textom. dáta (zatiaľ čo v oblasti viacjazyčných textov je Vanilla Postgres opäť príliš konzervatívny, nevyužíva najvýkonnejšie systémové knižnice) a množstvo ďalších menej významných aspektov.

Tajne sme však verili v Postgres, najmä preto, že zhromaždenie tvrdilo, že vyrieši všetky tie problémy, ktoré skeptici používali na ospravedlnenie výberu komerčného DBMS. Okrem toho bolo pre nás dôležité získať cieľové ukazovatele pre hardvérový a softvérový komplex – databázový stroj pre DBMS postavený na báze sankčne bezpečného hardvéru a softvéru, ktorý vyvinula IBS spolu s Postgres Professional.

Z replikovaných aplikácií by najzrejmejšou aplikáciou pre takýto stroj boli, samozrejme, systémy 1C. A výsledky vykonaných benchmarkov nás úplne preniesli z kategórie „tajných veriacich“ (a dokonca aj pochybujúcich) do kategórie „presvedčených“: teraz môžeme bezpečne povedať, že 1C: Enterprise verzia 8.3 na zostave Postgres Pro EE 1.5 pre Skala-SR / Postgres Pro funguje lepšie ako na MS SQL 2012 na rovnakom hardvéri so všetkými možnými optimalizáciami.

Takže nejaké podrobnosti o experimentoch. Pokiaľ ide o testovanie výkonu, 1C má všetko systematicky a vedecky - existuje typická konfigurácia„Štandardný záťažový test“, na ktorom sa spúšťa benchmark, postupným pridávaním nových používateľov do záťaže, až kým aplikácia dostatočne nezareaguje na pohodlnú prácu. (Presnejšie, používatelia sa pridávajú, kým skóre výkonu štandardnej aplikácie Apdex neklesne pod hranicu 0,85 a maximálny počet takýchto efektívnych používateľov sa považuje za výsledok benchmarku.)

Použili sme verziu 8.3.9.1850 1C:Enterprise, štandardný záťažový test vo verzii 2.0.17.36. Pôvodne bolo rozhodnuté, že Postgresu neposkytneme žiadne zľavy: robíme maximálne optimalizácie na MS SQL na uzle z komplexu Skala-SR / Postgres Pro (Windows sme dali na holý kov, nastavili sme ho podľa všetkých kánonov, pre rýchlosť urobíme ramdisk pre dočasné tabuľky) a potom - vrátime ten istý uzol do komplexu Skala-SR, rolujeme Linux a Postgres Pro EE a na ňom samostatne (bez klastrových čipov dostupných v komplexe) - spustíme rovnaký test.

Test jedna: začíname so 100 úlohami, záťaž je 50/50 – polovica generuje dokumenty, polovica generuje správy. Druhý test: začnite so 400, zaťaženie 70/30. MS SQL "skončil" v prvom teste na 360 užívateľoch, na druhom - na 540, navyše limitom pri oboch spustení bola práca s lokálnymi I/O, napriek tomu, že procesor bol v priemere zaťažený len na 30%. Postgres Pro v prvom teste dosiahol 440 úloh a v druhom až 660 a všetko na databázovom serveri spočívalo na procesore, ktorý na „maximálnych používateľoch“ načítava viac ako 90%.

Pre 1C, kde je počet súbežných používateľov najproblematickejším limitujúcim faktorom, je to pozoruhodný výsledok, a čo je najdôležitejšie, ukazuje to, že tieto najdôležitejšie ruské aplikačné systémy môžu nielen fungovať bez západných komerčných DBMS, ale dokonca to robia výrazne lepšie. .

Obsahová séria:

1. História vývoja MySQL a PostgreSQL

História MySQL sa začína v roku 1979 malou spoločnosťou vedenou Montym Wideniusom. V roku 1996 sa prvé vydanie 3.11 objavilo pod Solaris s verejnou licenciou. Potom bol MySQL portovaný na iné Operačné systémy, objavila sa špeciálna obchodná licencia. V roku 2000, po pridaní rozhrania podobného Berkeley DB, sa databáza stala transakčnou. Približne v rovnakom čase bola pridaná replikácia. V roku 2001 pridala verzia 4.0 k už existujúcemu MyISAM engine InnoDB, čo viedlo k ukladaniu do vyrovnávacej pamäte a zvýšeniu výkonu. V roku 2004 vyšla verzia 4.1, ktorá zaviedla poddotazy, čiastočné indexovanie pre MyISAM, Unicode. Verzia 5.0 v roku 2005 zaviedla uložené procedúry, kurzory, spúšťače a zobrazenia. MySQL rozvíja komerčné trendy: v roku 2009 sa MySQL stalo ochrannou známkou spoločnosti Oracle.

História postgresu sa začala v roku 1977 databázou Ingress.

V roku 1986 na University of Berkeley v Kalifornii bola premenovaná na PostgreSQL.

V roku 1995 sa postgres stal open source databázou. Objavil sa interaktívny psql.

V roku 1996 bol Postgres95 premenovaný na PostgreSQL verziu 6.0.

Postgres má niekoľko stoviek vývojárov po celom svete.

2. Architektúra MySQL a PostgreSQL

PostgreSQL- jednotný databázový server s jediným motorom - ukladacím strojom. Postgres používa model klient-server.

Pre každého klienta server vytvorí nový proces(nie stream!). Na prácu s takýmito klientskymi procesmi server používa semafory.

Žiadosť klienta prechádza nasledujúcimi fázami.

1. Pripojte sa.
2. Analýza: skontroluje sa správnosť požiadavky a vytvorí sa strom dotazov. Analyzátor je založený na základných unixových nástrojoch yacc a lex.
3. Prepísať: vezme sa strom dotazov a skontroluje sa v ňom prítomnosť pravidiel (pravidiel), ktoré ležia v systémových adresároch. Zakaždým, keď sa užívateľský dotaz prepíše na dotaz, ktorý pristupuje k databázovým tabuľkám.
4. Optimalizátor: pre každý dotaz sa vytvorí plán dotazov - plán dotazov, ktorý sa odovzdá vykonávateľovi - vykonávateľovi. Zmyslom plánu je, aby sa ním každý pohyboval možné možnosti získanie výsledku (či použiť indexy, spojenia atď.) a vyberie sa najrýchlejšia možnosť.
5. Spustenie dotazu: Vykonávateľ prechádza stromom rekurzívne a získa výsledok pomocou triedenia, spájania atď. a vracia riadky. Postgres je objektovo-relačná databáza, každá tabuľka v nej predstavuje triedu, medzi tabuľkami je implementovaná dedičnosť. Implementované štandardy SQL92 a SQL99.

Transakčný model je založený na takzvanom multi-version concurrency control (MVCC), ktorý dáva maximálny výkon. Referenčná integrita je zabezpečená prítomnosťou primárneho a sekundárneho kľúča.

MySQL má dve vrstvy – externú sql vrstvu a internú sadu enginov, z ktorých je najčastejšie využívaný InnoDb engine, keďže najviac podporuje ACID.

Implementovaný štandard SQL92.

Z modulárneho hľadiska možno kód MySQL rozdeliť do nasledujúcich modulov.

1. Inicializácia servera.
2. Správca pripojenia.
3. Správca streamu.
4. Ovládač príkazov.
5. Overenie.
6. Analyzátor.
7. Optimalizátor.
8. Správca tabuľky.
9. Motory (MyISAM, InnoDB, MEMORY, Berkeley DB).
10. Ťažba dreva.
11. Replikácia.
12. sieťové API.
13. kernel API.

Poradie modulov je nasledovné: najprv sa načíta prvý modul, ktorý načíta možnosti príkazový riadok, konfiguračné súbory, alokuje pamäť, inicializuje globálne štruktúry, načíta systémové tabuľky a odovzdá riadenie správcovi pripojení.

Keď sa klient pripojí k databáze, riadenie sa odovzdá správcovi vlákien, ktorý vytvorí vlákno (nie proces!) pre klienta a skontroluje jeho autentifikáciu.

Požiadavky klientov v závislosti od ich typu špičková úroveň spracováva štvrtý modul (dispečer). Žiadosti budú zaznamenávať 11. modul. Príkaz sa odovzdá analyzátoru, skontroluje sa vyrovnávacia pamäť. Ďalej sa dotaz môže dostať do optimalizátora, tabuľkového modulu, replikačného modulu atď. V dôsledku toho sa údaje vrátia klientovi prostredníctvom správcu toku.

Najdôležitejší kód je v súbore sql/mysqld.cc. Obsahuje základné funkcie, ktoré sa od verzie 3.22 nezmenili: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_options)_new handle_connect) handle_one_connection() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() // sql/sql_compatchparse. ::store_query() // sql/sql_cache.cc JOIN::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mysql_check_table() sql/sql_table.cc

Hlavička sql/sql_class.h definuje základné triedy: Query_arena, Statement, Security_context, Open_tables_state class, THD. Objekt triedy THD je deskriptor vlákna a je argumentom pre veľké množstvo funkcií.

3. Porovnanie MySQL a PostgreSQL: podobnosti a rozdiely

ACID štandard

Štandard ACID je založený na atomicite, integrite, izolácii a spoľahlivosti. Tento model sa používa na zabezpečenie integrity údajov. Realizuje sa na základe transakcií. PostgreSQL je plne v súlade so štandardom ACID. Pre plná podpora ACID v MySQL v konfigurácii musíte nastaviť default-storage-engine=innodb.

Výkon

Databázy sú často optimalizované pre prostredie, v ktorom fungujú. Obe základne majú rôzne technológie na zlepšenie výkonu. Historicky bol MySQL vyvíjaný s ohľadom na rýchlosť, zatiaľ čo PostgreSQL bol vyvinutý od samého začiatku ako vysoko prispôsobiteľná a štandardne vyhovujúca databáza. PostgreSQL má množstvo nastavení, ktoré zlepšujú rýchlosť prístupu:

• čiastkové indexy;
• kompresia dát;
• alokácia pamäte;
• vylepšená vyrovnávacia pamäť.

MySQL má čiastočnú podporu pre čiastočné indexy v InnoDB. Ak vezmeme motor MySQL ISAM, ukáže sa, že je rýchlejší na ploché dopyty, zatiaľ čo na vložkách nie sú žiadne zámky, neexistuje podpora transakcií, cudzí kľúč.

Kompresia

PostgreSQL je lepší v kompresii a dekompresii údajov, čo umožňuje uložiť viac údajov na diskový priestor. V tomto prípade sa údaje o kompresii načítajú z disku rýchlejšie.

Kompresia MySQL pre rôzne motory je čiastočne podporovaná, čiastočne nie a závisí od konkrétnej verzie konkrétneho motora.

Na viacprocesorovom má PostgreSQL výhodu oproti MySQL. Aj samotní vývojári MySQL priznávajú, že ich engine na tom v tomto smere nie je až tak dobre.

Typy údajov

MySQL: na ukladanie binárnych dát používa typy TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, ktoré sa líšia veľkosťou (do 4 GB).

Charakter: štyri typy - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: podporuje užívateľské dátové jadro s príkazom CREATE TYPE, typ BOOLEAN, typy geometrie.

Znak: TEXT (limit - max. veľkosť riadku).

Na ukladanie binárnych údajov existuje typ BLOB, ktorý je uložený v systém súborov. Stĺpce tabuľky možno definovať ako viacrozmerné pole s premenlivou dĺžkou. Objektové relačné rozšírenie: Štruktúru tabuľky možno zdediť z inej tabuľky.

Uložené procedúry

PostgreSQL aj MySQL podporujú uložené procedúry. PostgreSQL sa riadi štandardom Oracle PL/SQL, MySQL štandardom IBM DB2. MySQL podporuje rozšírenie SQL na písanie funkcií C/C++ od verzie 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C pre písanie uložených procedúr.

Keys

PostgreSQL aj MySQL podporujú jedinečnosť primárneho kľúča a cudzieho kľúča. MySQL nepodporuje kontrolné obmedzenie a sekundárne kľúče sú čiastočne implementované. PostgreSQL: úplná implementácia plus podpora pre ON DELETE CASCADE a ON UPDATE CASCADE.

spúšťače

MySQL: základná podpora. PostgreSQL: deklaratívne spúšťače: SELECT, INSERT, DELETE, UPDATE, INSTEAD OF; procedurálne spúšťače: CONSTRAINT TRIGGER. Udalosti: BEFORE alebo AFTER na INSERT, DELETE, UPDATE.

Automatický prírastok

MySQL: V tabuľke môže byť iba jeden takýto stĺpec, ktorý je potrebné indexovať. PostgreSQL: dátový typ SERIAL.

Replikácie

Podporuje MySQL aj PostgreSQL. PostgreSQL má modulárnu architektúru a replikácia sa dodáva v samostatných moduloch:

• Slony-I - hlavný replikačný mechanizmus v postgrese, výkon klesá v kvadratickej závislosti od počtu serverov;

Replikácia v PostgreSQL je založená na spúšťačoch a je pomalšia ako v MySQL. Replikácia sa plánuje pridať do jadra od verzie 8.4.

V MySQL je replikácia súčasťou jadra a od verzie 5.1 má dve varianty:

• SBR - replikácia založená na príkazoch;
• RBR - riadková replikácia.

Prvý typ je založený na protokolovaní záznamov do binárneho protokolu, druhý typ je založený na protokolovaní zmien. Počnúc verziou 5.5 MySQL podporuje takzvanú semi-synchrónnu replikáciu, pri ktorej hlavný server (master) pri každom potvrdení vyprázdni dáta na iný server (slave). Motor NDB vykonáva úplnú synchrónnu dvojfázovú replikáciu.

Transakcie

MySQL: Len pre InnoDB. SAVEPOINT, podpora ROLLBACK TO SAVEPOINT. Úrovne uzamknutia: úroveň tabuľky (MyISAM). PostgreSQL: podporované plus úroveň potvrdenia čítania a úrovne izolácie. ROLLBACK, podpora ROLLBACK TO SAVEPOINT. Úrovne uzamknutia: úroveň riadkov, úroveň tabuľky.

Úrovne privilégií

PostgreSQL: Privilégiá môžu byť priradené používateľovi alebo skupine používateľov.

Export-import dát

MySQL: sada exportných nástrojov: mysqldump, mysqlhotcopy, mysqlsnapshot. Importovať z textové súbory, html, dbf. PostgreSQL: export - pomôcka pg_dump. Import medzi databázami a súborovým systémom.

Poddotazy

Existuje MySQL aj PostgreSQL, ale MySQL môže byť neproduktívne.

Indexovanie

Hašovanie indexu: čiastočné v MySQL, úplné v PostgreSQL. Fulltextové vyhľadávanie: v MySQL - čiastočné, v PostgreSQL - úplné. Čiastočné indexy: nie sú podporované v MySQL, podporované v PostgreSQL. Viacstĺpcové indexy: v MySQL je limit 16 stĺpcov, v PostgreSQL - 32. Indexy výrazov: v MySQL - emulácia, v PostgreSQL - plné. Neblokovaný index vytvorenia: čiastočný v MySQL, úplný v PostgreSQL.

Rozdelenie

MySQL podporuje horizontálne rozdelenie: rozsah, zoznam, hash, kľúč, kompozitné rozdelenie. PostgreSQL podporuje RANGE a LIST. Automatické rozdelenie tabuliek a indexov.

Automatické prepnutie pri zlyhaní

MySQL: čiastočné pre InnoDB - musíte manuálne vytvoriť zálohu. PostgreSQL: zapisovať vopred protokolovanie (WAL).

Data Storage Engines

PostgreSQL podporuje jeden engine - Postgres Storage System. V MySQL 5.1 je ich niekoľko:

• MyISAM - slúži na ukladanie systémových tabuliek;
• InnoDB – maximálna zhoda ACID, ukladá dáta s primárnymi kľúčmi, cache inserty, podporuje kompresiu od verzie 5.1 – pozri atribút ROW_FORMAT=COMPRESSED;
• NDB Cluster je pamäťovo orientovaný engine, klastrová architektúra využívajúca synchrónnu replikáciu;
• ARCHÍV - podporuje kompresiu, nepoužíva indexy;
• a tiež: MERGE, MEMORY (HEAP), CSV.

InnoDB je vyvinutý InnoBase, dcérskou spoločnosťou Oracle. V 6. verzii by sa mali objaviť dva motory – Maria a Falcon. Falcon je motor založený na transakciách ACID.

Licencovanie

PostgreSQL: BSD (Berkeley Software Distribution) open source. MySQL: GPL (Gnu General Public License) alebo Commercial. MySQL je produkt s otvoreným zdrojovým kódom. Postgres je projekt s otvoreným zdrojom.

Záver

Keď to zhrnieme, môžeme povedať nasledovné: MySQL a PostgreSQL sú dve najpopulárnejšie open-source databázy na svete. Každá základňa má svoje vlastné charakteristiky a rozdiely. Ak potrebujete rýchle úložisko pre jednoduché dotazy s minimálnym nastavením, odporučil by som MySQL. Ak potrebuješ spoľahlivé skladovanie pre veľké množstvo dát so schopnosťou expandovať, replikovať, plne vyhovovať moderným štandardom jazyka SQL, by som navrhoval použiť PostgreSQL.

Budeme diskutovať o problémoch s konfiguráciou MySQL a PostgreSQL.

Stiahnite si zdroje

static.content.url=http://www.website/developerworks/js/artrating/

Zone=Open source, Linux

ID článku=779830

ArticleTitle=MySQL & PostgreSQL: Časť 1 Benchmarking

Relačné databázy existujú už dlho. Stali sa populárnymi vďaka riadiacim systémom, ktoré implementujú relačný model tak dobre, že je najlepším možným spôsobom prácu s údajmi, najmä pre kritické aplikácie a služby.

MySQL existuje už dlho a ukázalo sa, že je to skvelé riešenie, Postgresql prišiel na trh približne v rovnakom čase, ale poskytuje pomerne veľa zaujímavé funkcie a príležitosti, vďaka ktorým si rýchlo získava na obľube. V tomto článku sa pokúsime porovnať MySQL vs Postgresql, porovnáme hlavné rozdiely medzi týmito systémami, zistíme, ako fungujú a pokúsime sa pochopiť, ktorý systém bude pre váš projekt najlepší.

Databázy sú určené na štruktúrované ukladanie a rýchly prístup k rôznym údajom. Každá databáza, okrem samotných údajov, musí mať určitý model práce, podľa ktorého sa bude spracovanie údajov vykonávať. Na správu databáz sa používajú DBMS alebo systémy na správu databáz, medzi takéto programy patria MySQL a Postgresql.

Systémy správy relačných databáz umožňujú umiestňovanie údajov do tabuliek prepojením riadkov z rôznych tabuliek a tým prepojením rôznych, logicky skombinovaných údajov. Pred ukladaním údajov musíte vytvoriť tabuľky určitej veľkosti a zadať typ údajov pre každý stĺpec. Stĺpce predstavujú dátové polia a samotné dáta sú umiestnené v riadkoch. Systémy správy databáz a MySQL vs Postgresql sú relačné. Ďalej podrobnejšie zvážime, ako sa tieto dva programy líšia. A teraz prejdime k podrobnejšej úvahe.

Krátky príbeh

MySQL

Vývoj MySQL začal už v 90-tych rokoch. Prvé interné vydanie databázy sa uskutočnilo v roku 1995. Počas tohto obdobia sa na vývoji programu podieľalo niekoľko spoločností. Vývoj odštartovala švédska spoločnosť MySQL AB, ktorú kúpila spoločnosť Sun Microsystems, ktorá sa v skutočnosti stala majetkom spoločnosti Oracle. V súčasnosti, od roku 2010, Oracle vyvíja.

postgresql

Vývoj Postgresql sa začal v roku 1986 na Kalifornskej univerzite v Berkeley. Vývoj trval takmer osem rokov, potom sa projekt rozdelil na dve časti, komerčnú databázu IIlustra a úplne bezplatný projekt Postrgesql, ktorý vyvíjajú nadšenci.

Úložisko dát

MySQL

MySQL je relačná databáza, na ukladanie údajov do tabuliek sa používajú rôzne enginy, no práca s enginmi je ukrytá v samotnom systéme. Motor neovplyvňuje syntax dotazov a ich vykonávanie. Hlavné podporované motory sú MyISAM, InnoDB, MEMORY, Berkeley DB. Líšia sa od seba spôsobom zápisu dát na disk, ako aj metódami čítania.

postgresql

Postgresql je objektová relačná databáza, ktorá beží iba na jednom motore – ukladacom mechanizme. Všetky tabuľky sú reprezentované ako objekty, možno ich dediť a všetky akcie s tabuľkami sa vykonávajú pomocou objektívne orientovaných funkcií. Rovnako ako v MySQL sú všetky dáta uložené na disku v špeciálne triedených súboroch, no štruktúra týchto súborov a záznamov v nich je veľmi odlišná.

štandard SQL

Bez ohľadu na použitý systém správy databáz je SQL štandardizovaným jazykom vykonávania dotazov. A podporujú ho všetky riešenia, dokonca aj MySQL alebo Postgresql. Štandard SQL bol vyvinutý v roku 1986 a odvtedy bolo vydaných niekoľko verzií.

MySQL

MySQL nepodporuje všetky nové funkcie štandardu SQL. Vývojári zvolili túto cestu vývoja, aby udržali MySQL jednoduché na používanie. Spoločnosť sa snaží spĺňať normy, no nie na úkor jednoduchosti. Ak funkcia môže zlepšiť použiteľnosť, vývojári ju môžu implementovať ako svoje vlastné rozšírenie bez toho, aby venovali pozornosť štandardu.

postgresql

Postgresql je open source projekt, vyvíja ho tím nadšencov a vývojári sa snažia čo najviac dodržiavať štandard SQL a implementovať všetky najnovšie štandardy. To všetko však ide na úkor jednoduchosti. Postgresql je veľmi zložitý a preto nie je taký populárny ako MySQL.

Spracovateľské schopnosti

Ďalšie rozdiely medzi postgresql a mysql vyplývajú z predchádzajúceho odseku, ide o možnosti a obmedzenia spracovania údajov. Prirodzene, súlad s novšími normami poskytuje novšie príležitosti.

MySQL

Pri vykonávaní dotazu MySQL načíta celú odpoveď servera do pamäte klienta, pre veľké množstvo dát to nemusí byť veľmi pohodlné. Vo všeobecnosti je Postgresql z hľadiska funkcií nadradený Mysql, ďalej zvážime, v ktorých.

postgresql

Postgresql podporuje používanie kurzorov na pohyb po prijatých dátach. Dostanete iba ukazovateľ, celá odpoveď je uložená v pamäti databázového servera. Tento ukazovateľ je možné uložiť medzi reláciami. Podporuje vytváranie indexov pre niekoľko stĺpcov tabuľky naraz. Okrem toho môžu byť indexy rôzne druhy, okrem hash a b-tree sú k dispozícii GiST a SP-GiST pre prácu s mestami, GIN pre textové vyhľadávanie, BRIN a Bloom.

Postgresql podporuje regulárne výrazy v dotazoch, rekurzívnych dotazoch a dedičnosti tabuliek. Existuje tu však niekoľko obmedzení, napríklad nové pole môžete pridať iba na koniec tabuľky.

Výkon

Databázy musia byť optimalizované pre prostredie, v ktorom budete pracovať. Historicky bol MySQL navrhnutý pre maximálny výkon, zatiaľ čo Postgresql bol navrhnutý tak, aby bol vysoko prispôsobiteľný a maximálne vyhovoval štandardom. Postupom času však Postgresql získal mnoho vylepšení a optimalizácií.

MySQL

Vo väčšine prípadov sa na organizáciu práce s databázou v MySQL používa tabuľka InnoDB, táto tabuľka je B-strom s indexmi. Indexy vám umožňujú získať údaje z disku veľmi rýchlo, čo si vyžiada menej operácií s diskom. Ale skenovanie stromu vyžaduje nájdenie dvoch indexov, čo je už pomalé. To všetko znamená, že MySQL bude rýchlejší ako Postgresql iba pri použití primárneho kľúča.

postgresql

Všetky informácie o hlavičke tabuľky Postgresql sa nachádzajú v pamäti RAM. Nemôžete vytvoriť tabuľku, ktorá nemá dostatok pamäte. Záznamy tabuľky sú zoradené podľa indexu, takže ich môžete získať veľmi rýchlo. Pre väčšie pohodlie môžete použiť viacero indexov na rovnakú tabuľku.

Vo všeobecnosti je PostgreSQL rýchlejší, s výnimkou použitia primárnych kľúčov. Pozrime sa na niektoré testy s rôznymi operáciami:

Typy údajov

Jedným z vrcholov oboch databáz sú podporované typy údajov, ktoré môžete použiť. Keďže sa obe riešenia snažia zhodovať so syntaxou SQL, majú podobné sady, no stále sa v niektorých smeroch líšia.

MySQL

MySQL podporuje nasledujúce typy údajov:

• TINYINT: veľmi malé celé číslo.;
• SMALLINT: malý celok;
• STREDNÁ: stredne veľké celé číslo;
• INT: celé číslo normálnej veľkosti;
• BIGINT: veľký celok;
• PLAVÁK:číslo s plávajúcou desatinnou čiarkou so znamienkom s jednou presnosťou;
• DVOJNÁSOBNÁ, DVOJNÁSOBNÁ PRESNOSŤ, SKUTOČNÁ:číslo s pohyblivou rádovou čiarkou so znamienkom s dvojitou presnosťou
• DECIMALNY, NUMERICKY: podpísané číslo s pohyblivou rádovou čiarkou;
• DÁTUM: dátum;
  DÁTUM ČAS: kombinácia dátumu a času;
• ČASOVÁ ZNAČKA:časová značka;
• ČAS:čas;
  ROK: rok vo formáte YY alebo YYYY;
• CHAR: šnúrka pevnej veľkosti, vpravo vyplnená medzerami na maximálnu dĺžku;
• VARCHAR: reťazec s premenlivou dĺžkou;
• TINYBLOB, TINYTEXT: binárne alebo textové dáta s maximálnou dĺžkou 255 znakov;
• BLOB, TEXT: binárne alebo textové dáta s maximálnou dĺžkou 65535 znakov;
• MEDIUMBLOB, MEDIUMTEXT: textové alebo binárne dáta;
• LONGBLOB, LONGTEXT: textové alebo binárne dáta s maximálnou dĺžkou 4294967295 znakov;
• ENUM: enumerácia;
• SET: súpravy.

postgresql

Podporované typy polí v Postgresql sú úplne odlišné, ale umožňujú vám zapisovať presne tie isté údaje:

• bigint: 8-bajtové celé číslo so znamienkom;
• veľký seriál: automaticky inkrementované 8-bajtové celé číslo;
• trocha: binárny reťazec pevnej dĺžky;
• trochu sa mení: binárny reťazec premennej dĺžky;
• boolean: vlajka;
• box: obdĺžnik v rovine;
• byte: binárne dáta;
• rôzny charakter: reťazec znakov s pevnou dĺžkou;
• postava:
• cidr: IPv4 alebo IPv6 sieťová adresa;
• kruh: kruh na rovine;
• dátum: kalendárny dátum;
• dvojitá presnosť:číslo s pohyblivou rádovou čiarkou s dvojitou presnosťou;
• inet: Internetová adresa IPv4 alebo IPv6;
• celé číslo: 4-bajtové celé číslo so znamienkom;
• interval: obdobie;
• riadok: nekonečná priamka na rovine;
• lseg: segment na rovine;
• macaddr: Mac adresa;
• peniaze: peňažná hodnota;
• cesta: geometrická dráha v rovine;
• bod: geometrický bod v rovine;
• mnohouholník: mnohouholník na rovine;
• reálny: jednoduché číslo s pohyblivou rádovou čiarkou;
• smallint: dvojbajtové celé číslo;
• seriál: automatické inkrementovanie štvorbitové celé číslo;
• text: reťazec znakov s premenlivou dĺžkou;
• čas: Denná doba;
• časová značka: dátum a čas;
• tsquery: textový vyhľadávací dopyt;
• tsvector: textový vyhľadávací dokument;
• uid: jedinečný identifikátor;
• xml: XML dáta.

Ako vidíte, v Postgresql je viac typov údajov a sú rozmanitejšie, existujú typy polí pre určité typy údajov, ktoré MySQL nemá. Rozdiel medzi MySQL a Postgresql je zrejmý.

rozvoj

Oba projekty sú open source, ale vyvíjajú sa rôznymi spôsobmi. Nie každý má rád vývoj MySQL. A v tomto porovnaní mysql a postgresql dáva veľa rozdielov.

MySQL

Databázu MySQL vyvíja Oracle a povráva sa, že spoločnosť mieni spomaliť vývoj motora. Bolo vytvorených veľa forkov projektu, vrátane forku MariaDB od vývojára pôvodného MySQL. Vývoj však zostáva pomalý.

postgresql

Ako už bolo spomenuté na začiatku článku, vývoj začal na univerzite v Berkeley. Potom prešla do obchodnej spoločnosti. Teraz program vyvíja nezávislá skupina programátorov a predstavenstvo niekoľkých spoločností. Nové verzie sa vydávajú pomerne aktívne a získavajú stále viac nových funkcií.

závery

V tomto článku sme porovnali mysql a postgresql, pozreli sme sa na hlavné rozdiely medzi oboma systémami správy databáz a pokúsili sme sa pochopiť, čo je lepšie ako postgresql alebo mysql. Vo všeobecnosti je Postgresql najlepší z hľadiska schopností, ale je zložitý a nie všade použiteľný. MySQL je jednoduchší, ale chýba mu niekoľko skvelých funkcií. A akú databázu si vyberiete pre svoj projekt? Prečo práve ona? Napíšte do komentárov!

Na konci videa popisujúceho funkcie a vyhliadky Postgresql: