Konferencia PyCon SK 2022, ktorá sa konala v Bratislave, je každoročné stretnutie komunity využívajúcej a vyvíjajúcej Python. Organizujú ju dobrovoľníci a dobrovoľníčky z občianskeho združenia SPy o.z. zameraného na šírenie jazyka Python a ďalších open sourcových technológií a myšlienok.

Aj tento rok bol nabitý zaujímavými prednáškami a workshopmi, ktoré pritiahli množstvo nadšencov Python-u. V tomto článku predstavíme tému, ktorá je asi večná ako programovanie a to je výber databázy.

Reč je o prednáške Choosing the right database for your next project - Looking at options beyond PostgreSQL and MySQL , ktorú prezentoval pán Marc-Andre Lemburg. Čo sme sa v nej dozvedeli?

V posledných rokoch vzniklo množstvo nových databáz. Väčšinou veľkými internetovými spoločnosťami, napr. spoločnosťami Google, Facebook, LinkedIn, Uber atď. alebo menšími startupmi, ktoré chcú vyplniť medzeru na trhu. Ich cieľom je lepší výkon, rýchlejší tok údajov, rýchlejšia analýza, škálovateľnosť, spoľahlivosť, použitie v klastroch, kontajnerizácia, používanie GPU, in-memory nastavenia, oddelenie výpočtovej a úložnej kapacity.

Prehľad databáz. Databáza databáz tu https://dbdb.io/.

Ako vybrať databázu ?

• Určite typické dátové zaťaženie
• Pozrite sa na zamýšľané prípady použitia, aby ste určili priority funkcií
• Zvážte ďalšie rozhodovacie faktory/obmedzenia
• Získajte prehľad o tom, čo je k dispozícii na trhu
• Vyberte si najvhodnejšiu !
• V prípade väčších projektov: Vytvorte POC, ktorý pomôže určiť správnu voľbu

Overenie konceptu (POC - proof of concept) je malá aplikácia, ktorá testuje kľúčové požiadavky navrhovaného riešenia. V prípade databázových aplikácií sa POC zvyčajne zameriava na niekoľko kritických transakcií a overuje, či databáza dokáže podporovať navrhovanú schému, dotazy a napokon aj očakávaný objem a priepustnosť.

Určenie typického pracovného zaťaženia údajov

OLTP (Online transaction processing) - online spracovanie transakcií

• Hlavný účel: operácie
• Optimalizované na rýchle CRUD, jednoduché spájanie
• Údaje sa často menia
• Príklady: Databázy na všeobecné účely

OLAP (Online analytical processing) - online analytické spracovanie

• Hlavný účel: analytika a reportovanie
• Optimalizované na čítanie, zložité dotazy, veľké spoje
• Údaje sú pomerne stabilné, niekedy dokonca len na čítanie alebo dopĺňanie
• Príklady: Riešenia dátových skladov

Prípady použitia

Pochopenie - definovanie problémov

• Známe: Prípad použitia vašej databázy bude často vyžadovať konkrétnu sadu funkcií

• Neznáme: Plánujte budúci vývoj

• Rozširovanie

• Frekvencia zmien vašich návrhov/schém

• Ďalšie požiadavky, ktoré ešte nemusíte poznať

Pozrime sa na niekoľko rozmerov zložitosti

• Zložitosť schémy
• Kardinálna zložitosť
• Časová zložitosť
• Zložitosť dopytu
• Zložitosť nasadenia
• Prevádzková zložitosť

(možno budete musieť pridať ďalšie dimenzie)

Zložitosť schémy

Jednoduché schémy

• Správa relácií a používateľov
• Vyhľadávacie tabuľky

Príklady: Webové servery, protokolovanie, ukladanie udalostí

Zložité schémy

• Prepojené schémy z rôznych systémov
• Široké tabuľky na implementáciu vnorených štruktúr

Príklady: Účtovné, obchodné alebo rezervačné systémy

Migrácie

Kardinálna a časová zložitosť

Kardinálna zložitosť

• Mnoho jednoduchých riadkov
• Menej riadkov s mnohými stĺpcami
• Mnoho riadkov s množstvom stĺpcov
• Faktory škálovateľnosti: Rýchlosť rastu údajov za mesiac

Časová zložitosť

• Len na čítanie alebo len na pripojenie (napr. časové rady)
• Časté zmeny údajov
• Požiadavka na vykonávanie dopytov v čase

Zložitosť dopytov

Požiadavky na výkon

• Transakcie za sekundu (TPS) pre OLTP alebo
• Analytické časy pre OLAP

Spájanie

• Jednoduché spájania vedúce k malým súborom výsledkov
• Komplexné spájanie viacerých veľkých tabuliek

Normalizácia

• Plne normalizované tabuľky (DRY v databázach)
• Denormalizované tabuľky (aby sa zabránilo online spojeniam)

Potreba materializovaných pohľadov, (špeciálnych) indexov

Zložitosť nasadenia

• Výpočet
• Jeden server / cluster
• Miestny hardvér / cloud
• Vyhradený hardvér / virtuálne počítače / kontajnery / Kubernetes
• Úložisko
• Údaje v blízkosti uzlov (pamäť, NVM, NFS)
• Objektové úložisko (napr. S3)
• Odolnosť a zotavenie po havárii (DR)
• Nastavenia pre prípad zlyhania / vysokej dostupnosti
• Monitorovanie
• Automatizácia a samoobnovenie

Prevádzková zložitosť

• Spravované / samohostiteľné
• Komplexná konfigurácia
• Vlastná optimalizácia
• Potreba (pružného) škálovania
• Integrácia Devops
• VM a servery: Ansible / Salt / Terraform / atď.
• Kubernetes: Operátory / Helm Charts
• Manuálne zásahy: Prístup cez Shell, nástroje používateľského rozhrania
• Aktualizácie
• Nulové prestoje
• Zníženie výkonu

Ďalšie rozhodovacie faktory

• Je databáza dostatočne vyspelá pre moje potreby ?
• Je ekosystém dostatočne silný aby poskytoval dlhoročnú podporu ?
• Ako dôležitá je odolnosť /výkonnosť / škálovateľnosť ?
• Aké sú dôsledky na náklady ?
• Zmestili by sa údaje do pamäte / jedného servera / clusteru / S3?
• Má databáza dobré / podporované rozhrania Python ?
• Poskytuje databáza rozhrania pre nástroje používané vo vašej stacku ?

Napr. Django, SQLAlchemy, DBT, Pandas, Dask, fugue atď.

Samotná prednáška bola dosť strohá. V podstate len taký ľahký úvod do problematiky. Aj keď na webe inej podobnej konferencie sa dá nájsť aj obšírnejšia verzia tejto prednášky. Predpokladám, že autor nám predstavil skátenú verziu pre nedostatok prideleného času, čo je škoda. Teraz sa trošku detailnejšie pozrieme na niektoré typy databáz.

Tu sú niektoré z kľúčových typov databáz, z ktorých si musíte vybrať pre vývoj vášho projektu.

Databázy NoSQL a SQL

Výber medzi SQL (relačnou) a NoSQL (nerelačnou) štruktúrou údajov je najdôležitejším faktorom pri výbere databázy.

Je dôležité si uvedomiť, že hoci obe databázy sú realizovateľné riešenia, majú dôležité rozdiely.

NoSQL DB nemajú štandardnú organizovanú schému pre všetky záznamy, na rozdiel od relačných databáz, ktoré obsahujú riadky a stĺpce. Rôzne záznamy v databáze NoSQL založenej na JSON majú rôzne polia.

| Systém riadenia relačných databáz (RDBMS) | Nerelačný alebo distribuovaný databázový systém | | Databáza so statickou/fixnou/preddefinovanou schémou | Databáza s dynamickou schémou | | Nie je ideálna na hierarchické ukladanie údajov | Najlepšia možnosť na hierarchické ukladanie údajov | | Vhodný na vykonávanie zložitých dotazov | Nie je najlepšou možnosťou na vykonávanie zložitých dotazov | | Vertikálne škálovateľná databáza | Horizontálne škálovateľná databáza | | Ide s atomicitou, konzistentnosťou, izoláciou a trvanlivosťou (ACID) | Nasleduje konzistentnosť, dostupnosť, tolerancia rozdelenia(CAP) | | Príklady: PostgreSQL, Oracle, MySQL, Oracle, MS-SQL Server atď. | Príklady: Neo4j, GraphQL, HBase, MongoDB, Cassandra atď. |

Stĺpcové DB

Atomickou jednotkou tejto DB je stĺpec tabuľky, čo znamená, že údaje sa uchovávajú v mnohých stĺpcoch. Vďaka tomu je vyhľadávanie v stĺpcoch rýchlejšie, a keďže údaje v každom stĺpci sú relatívne konzistentné, zabezpečuje kompresiu údajov.

DB s kľúčovými hodnotami

Dotazy typu kľúč-hodnota DB sú jedným z jednotlivých dotazov, ktoré je možné vykonať. Napríklad dotaz typu “select all records where city = Philadelphia” nemusí byť podporovaný, pretože prechádza cez niekoľko hodnôt záznamov. Pri používaní tejto databázy použite pole TTL (time to live), ktoré vám umožňuje vybrať, kedy sa má konkrétny záznam v databáze odstrániť.

DB orientovaná na dokumenty

Dokumenty sú súbory JSON a schéma každého dokumentu sa môže líšiť. Indexovanie určitých polí v dokumente umožňuje rýchlejšie vyhľadávanie na základe týchto polí v databáze dokumentov (DB). Týmto spôsobom sa vynúti, aby všetky dokumenty obsahovali dané pole.

Grafové DB

Grafové DB majú uzly, ktoré znamenajú entity, a hrany, ktoré ukazujú, ako sú rôzne záznamy v databáze prepojené.

Faktory, ktoré treba zvážiť pri výbere správnej databázy

DBMS je zodpovedný za to, ako vaše aplikácie a databáza spolupracujú. Zabezpečuje, aby boli správne údaje k dispozícii vtedy, keď ich skupina používateľov, ktorá o nich žiada, potrebuje. Pred výberom systému správy databáz pre váš IT projekt by ste mali zvážiť niekoľko kľúčových aspektov.

Konzistentnosť údajov

Získanie potrebných informácií by nemalo byť veľkým problémom. Potreba udržiavať konzistentné údaje sa však zvyšuje, keď sa do databázy pridávajú ďalšie zdroje. Preto by sa pri výbere nového systému na správu databáz (DBMS) mala zvážiť možnosť nastavenia pravidiel konzistencie.

Konzistencia sa vzťahuje na to, ako sú databázové transakcie obmedzené len na zmenu údajov, ktoré sú nimi priamo ovplyvnené, podľa vopred stanovených obmedzení. Databázy SQL majú povesť spoľahlivejších databáz ako databázy NoSQL, pokiaľ ide o konzistenciu údajov. Z toho vyplýva, že ak vaša aplikácia vyžaduje čítanie najnovších údajov, je vhodnejšia prvá z nich.

Ochrana a zabezpečenie údajov

Ochrana prístupu a šifrovanie osobných údajov sú nevyhnutné. Tu sa mechanizmy šifrovania, ktoré poskytujú jednotlivé DBMS, líšia v závislosti od toho, ako môžu byť nastavené postupy a prístupové oprávnenia. Pri hodnotení systému správy databáz a metódy zabezpečenia údajov je potrebné pri rozhodovaní o metóde zabezpečenia údajov zohľadniť štruktúru databázy. Vždy skúmajte bezpečnostné mechanizmy databázy pre prípad poruchy alebo zlyhania systému. Pri používaní synchronizácie a decentralizovaného ukladania existujú ďalšie bezpečnostné obavy. Takisto je potrebné riešiť obavy, ako sú údaje v pohybe, údaje v pokoji, čítanie a zápis údajov atď. Môžete tiež začleniť prispôsobené alebo štandardné overovanie.

Ak to zhrnieme, databáza by mala mať najlepšie ochranné opatrenia na ochranu pred stratou dôvernosti, integrity a prístupnosti údajov.

Riešenie konfliktov údajov

Môžete sa stretnúť s konfliktmi údajov, keď používateľ na jednom zariadení zmení údaje, ktoré už vykonal iný používateľ na inom zariadení. Údaje sa môžu stať nekonzistentnými v rôznych verziách v rámci tej istej databázy. V dôsledku toho si riešenie týchto problémov vyžaduje výber najlepšieho databázového systému pre vývoj produktu. Databázový systém na riešenie konfliktov musí byť prispôsobiteľný na riešenie konfliktov medzi používateľmi, cloudovými systémami, zariadeniami a integráciami tretích strán.

Tvar údajov

Silne typizované údaje sú v databázach SQL často uložené v obdĺžnikových tabuľkách s riadkami a stĺpcami. Indexy urýchľujú niektoré vyhľadávania, zatiaľ čo spojenia JOINS umožňujú vyhľadávať v mnohých tabuľkách súčasne. Tieto techniky sú založené na dobre definovaných vzťahoch medzi tabuľkami databázy. V prípade potreby sa slabo typizovaný JSON vrátane polí a vnorených dokumentov často ukladá v dokumentových databázach. Uzly, hrany, trojice a štvorice sa ukladajú v grafovej databáze. K dispozícii sú aj databázy typu kľúč-hodnota a stĺpcové databázy NoSQL. V niektorých prípadoch môžete získať údaje vo forme, ktorú možno použiť na analýzu; v iných prípadoch je potrebná transformácia (do iných foriem). Databáza môže byť vytvorená nad inou databázou. Napríklad úložiská kľúč-hodnota môžu byť použité na podporu prakticky akejkoľvek databázy.

Zohľadnenie nákladov na služby a implementáciu

Pri výbere správy databáz v rámci implementácie a celkových nákladov na vlastníctvo (TCO) je dôležité preskúmať modifikovateľnosť a dostupnosť podpory a dokumentácie. Počas vývoja je potrebné neustále zvažovať špecifické požiadavky vašej firmy na systém správy databáz. Výber správnej sady nástrojov pre databázu je jednoduchší, ak presne pochopíte svoje požiadavky a nákladovú efektívnosť.

Modelovanie údajov pre viaceré databázy

Vykonanie dátového modelovania pred tým, ako sa rozhodnete pre databázu, je dobrý nápad. Využite tento model, aby ste videli, ako bude databáza štruktúrovaná a ako spĺňa vaše obchodné potreby. Dátové modelovanie je potrebné, ak vaša aplikácia obsahuje užitočné funkcie, ako sú napríklad reportovanie, vyhľadávanie alebo funkcie založené na polohe. Na spracovanie rôznych druhov údajov týchto programov je potrebných viacero databáz. Tu zvážte niekoľko databáz, ako napríklad Uber, ktorý využívajú MySQL, MongoDB a ďalšie. Ich sieť CDN (Content Delivery Network) využíva MongoDB, zatiaľ čo MySQL poháňa ich obchodnú logiku. Vďaka MongoDB mohli rýchlo a jednoducho ukladať veľké množstvo údajov.

Právne aspekty výberu DB

Existuje niekoľko zákonov na ochranu osobných údajov zákazníkov, ktorí dôverujú vášmu softvéru a aplikáciám. Ochrana súkromia, ochrana a umiestňovanie údajov spadá v Európskej únii pod nariadenie GDPR. Pokiaľ ide o zdravotnú starostlivosť, HIPAA a GLBA upravujú, ako finančné spoločnosti v USA zaobchádzajú s údajmi spotrebiteľov. Nový kalifornský zákon o ochrane súkromia spotrebiteľov (CCPA) chráni spotrebiteľov a podporuje práva na ochranu súkromia.

S údajmi môžete zaobchádzať v rámci zákonných hraníc, ak pri výbere databázy zabezpečíte dodržiavanie niektorého alebo všetkých týchto pravidiel ako súčasť osvedčených postupov. Niektoré databázy môžu mať často bezpečnostné nedostatky alebo nedostatky v ochrane osobných údajov, ktoré môžu mať negatívne dôsledky, pretože v takýchto databázach je ťažké manuálne identifikovať nedostatky.