Vlákno názorů k článku Svět se strašlivě změnil, ale databáze jsou pořád stejné od Miroslav Šilhavý - Také nepředpokládám ústup SQL databází. Vnímám určitý dočasný...
-
Také nepředpokládám ústup SQL databází. Vnímám určitý dočasný odklon od SQL jako etapu vývoje. MySQL zničilo vnímání lidí, k čemu vlastně SQL slouží (diskuse o ACID etc.). Celá jedna generace byla zasažena tím, že nepochopila, že SQL není o tom vytáhnout si jednu tabulku a vymlasknout ji ve smyčce ven. Tato generace, aniž by pochopila význam SQL, zcela přirozeně začala preferovat "něco jiného". Když už (My)SQL není ACID, tak proč vlastně používat tak nepohodlný jazyk, svázanost konvencemi, ... Stejně "blbého" výsledku se dalo dosáhnout i jednoduššími prostředky (m. j. no-SQL databázemi).
Dnes si všímám, že se další generace dostává zpět ke kořenům. No SQL databáze jsou jednoduché, už z nich člověk nemá pocit svázaností konvencemi a v podstatě není co na nich kritizovat. Jednoduše a účelně plní to, pro co byly navrženy. Tím byli programátoři dovedeni zpět k úvahám, jesli by se nedalo od databází očekávat víc, tedy zpět k SQL.
Přijde mi to taková generační, databázová schola ludus. Dogmata musela být zbořena, abychom zase viděli i to dobré v tradičních technologiích.
Dlouho jsem považoval MySQL za jedenáctou biblickou ránu. Dnes ho vnímám jako průvodce k zajímavějším technologiím.
-
Zatím jsem potkal jen opravdu mizivé množství případů, kde by bylo nutné snadné horizontální škálování. Většinou to byla spíš lenost programátora, někdy neznalost jak tvořit dynamickou vazbu. Nejčastěji to byla kombinace obojího, dělat dvojitý join na MySQL značně ubírá na výkonu (např. oproti PostgreSQL).
NoSQL databáze mají i své nevýhody, na programátory jsou kladeny zase jiné nároky, co musí ošetřit zejména na vrstvě aplikace. Výhodou (ať je to správně zamotané) je to, že juniornímu programátorovi přijde srozumitelnější číst ošetření v aplikaci, než chápat SQL, locky, transakce, práci s časem v SQL atd. atd.
-
Myslím, že ono nejde jen o juniorní programátory. Z hlediska správy celého projektu a jeho kódu je jednoduše mnohem snažší a čitelnější mít codebase pokud možno v jednom jazyku a na jedné platformě s jednou sadou paradigmat. Když tedy NoSQL funkčně víceméně stačí, je už tohle docela podstatný tradeoff.
-
Je to zobecnění, podepřené jednak a) tím jak vidím do databází (vždy tam musí být daň za obecnější datový model i způsob uložení), b) netem občas problesknou články - úspěšně jsme migrovali z Monga na Postgres, případně migrovali jsme z Postgresu na MySQL (případně opačně), ale téměř nikdo se nechlubí, že by z SQL db migrovali do NoSQL. To samozřejmě může být zkreslené tím jaké zdroje sleduji.
V každém případě je celá řada faktorů, které hrají velkou roli v tom, jestli někde bude NoSQL nebo SQL databáze rychlejší - počínaje velikostí db, poměrem velikosti db vůči RAM, komplexností protokolu, složitostí operací, rychlostí zápisu na disk, rychlostí sítě, koneckonců i rychlostí CPU. Další otázkou je reálnost benchmarků a reálného provozu, případně zkušenosti s dlouhodobou údržbou.
-
Pan Stehule, bez urazky (ked uz mame tie moderovane diskusie, tak len slusne) ale verte tomu (a naozaj viem co hovorim, kedze to je moj kazdodenny chleba), ze to tom, ze o sql -> nosql casto nepocujete, ako ste podotkli, to len vas problem.
V sucasnosti migruju na nosql databazy firmy ako Epic Games, Adobe, Atlassian ... robim s kolegami ktori to u nich nasadzuju, a nemozem povedat, ze by tych "prechodov" medzi firmamy bolo malo. Prave naopak. Je ich cim dalej tym viac.
-
Pokud ty projekty nejsou veřejné, tak se k nim nemohu dostat. Jinak, jádro pudla je v tom, jak data chcete uchovávat, jakým způsobem, a co s nimi chcete dělat. Zrovna tak, jak kritizuji a zmiňuji nepovedené nasazení NoSQL, tak obdobně existují projekty nad SQL db, kde bych relační databázi nenasadil, a kde se NoSQL databáze osvědčují.
Zkratkovitě, pokud píši něco, co se podobá účetnictví, evidenci majetku, skladové hospodářství, tak tam si myslím, že SQL relační ACID databáze jsou to pravé ořechové. Čím se aplikace méně podobá zmiňovaným aplikacím, tím je pravděpodobnější vhodné nasazení NoSQL - zpracování logů, práce s krátkodobými daty, práce s daty z IoT.
-
Problémy existujících SQL je samozřejmě škálovatelnost a taky spolehlivost, znovu připomínám tu první, bo jde ruku v ruce v komplexních systémech s tou druhou.
Abych zajistil spolehlivost řešení (jakžtakž), tak musím celou operaci nacpat do jedné SQL transakce, což znamená mít všechna relevantní data v jedné databázi (bez distribuovaných transakcí, viz níže) a stejně tak jeden komplexní aplikační service, který řeší danou logiku. Zároveň musím zajistit naprostou spolehlivost HW, což je prakticky nemožné. Pak se zhroutí teoreticky 100% spolehlivé pole a business má přinejmenším mnohahodinový výpadek, o tom, zda má skutečně kompletní poslední data, lze jen polemizovat.
Distribuované transakce zdánlivě problém vyřeší, pokud se jim dá důvěřovat - pořád tam hrozí riziko výpadku HW či SW v době druhého commit a nekonsistence přijde tak jako tak. Takže jde jen o falešný pocit bezpečí.
NoSQL (nebo i staré MySql či zcela jiné technologie) jsou otevřené v tom, co skutečně dokážou, může to znamenat víc práce na aplikační úrovni, ale mám úplně jinou škálovatelnost a hlavně spolehlivost implementovanou na základě business logiky, která ví, jak například zajistit idempotentnost operací. Většina operací totiž zdaleka nevyžaduje ACID, ale jen nějakou souslednost aktivit, včetně případného potvrzení jejich provedení na zcela jiný service, který je typicky mimo (distribuovanou) transakci.
-
Jak jednofázový commit, i dvoufázový commit skončí teprve tehdy, když jsou změny bezpečně uložené na disku. Tudíž riziko nekonzistence je prakticky nulové. Můžete mít problém s filesystémem, ale to je obecný problém pro všechny aplikace. Tohle mi nepřijde jako validní argumentace.
Obecně - gro diskuze je, kde implementovat logiku a) v databázi, a pak používat rychlé SQL, a většinou je to pekelně rychlé - bo lokální přístup, optimalizované příkazy, hromadné operace, atd - ale aplikace není monolit, což ne všem vyhovuje, b) v aplikaci, pak je aplikace monolit, nicméně operace s db jsou o řád pomalejší, bo Java není C, což se nahrazuje cache, což zase vyžaduje hromadu paměti, a horizontální škálování.
-
Muze byt i problem s backend storagi. Kdy cely storage retezec nekde lze o tom ze data byla fyzicky propsana na medium, ale ve skutecnosti jsou nekde v cache. Pak cloveku nekde neco chcipne na infrastrukture a je ohen na strese - a databazista na telefonu. Aby byla data skutecne propsana a signalizace mluvila pravdu a nic nez pravdu, je treba jeden z certifikacnich predpokladu komponent pro storage.
Na druhou stranu vim ze vyvojari DB dost casto naduzivaji vyplach cache/bufferu/sync a nekdy neni zbyti nez prenastavit storage nebo wrapper aby lhala o propsani samozrejme s trizikem ztraty dat. Delame to jen velmi vyjimecne s emailem na vsechny sloupy a databazistum zvlast.
-
Jako vývojář DB můžu říct, že každý fsync se kalkuluje a rozhodně se nenadužívá. Naopak je tam snaha fsync redukovat - v Postgresu např. asynchronním commitem nebo commit delayem. Je otázkou jestli to aplikační vývojáři vědí. U všech relačních db je write cache (a s ní nutné synchronizace) dost dobře optimalizovaná.
Samozřejmě celá technologie spočívá v důvěryhodnosti operace fsync. Pokud se vyblokuje, tak pak to může dopadnout všelijak - spíš špatně. Maily jdou možná zrekonstruovat, tam se používají jednoduché formáty. Moderní relační databáze díky MVCC používají relativně komplikované formáty a nekonzistentní filesystém rozhodně nerozdýchají.
Vypínání fsyncu, to mi ani neříkejte - doufal jsem, že se taková zvěrstva už nedělají :). To je jako ruská ruleta s 3 náboji :)
-
Bejvavalo.
Postgres je ve verzi 11 uz setsakra navysi a naopak Oracle si s sebou historicky taha peknych par WTF kousku typu select * from dual a nvl()/nvl2() nebo merge.
Momentalne povazuju Postgres a Oracle na priblizne stejne urovni, pricemz Oracle ma navrch v oblasti hrubeho vykonu a napr replikaci nebo dblinku, postgres se snaze pouziva a ma logictejsi syntaxi.
Oracle je navic nachylnejsi na neumetely, kdyz postavim bezneho joudu v pripade projektu max miliony radku pred postgres a oracle, dopadne to vicemene stejne.
A s cenovou politikou Oracle to znamena jedine -> bic a pryc.
-
To bude tím, že na NoSQL vznikají především nové projekty, které by teoreticky taky mohly být na RDBMS, ale za chvíli by se to brutálně plazilo.
Takže já mám běžící Postgres, MariaDB, ORACLE, Scylla DB, SQLite a obecně můžu říct, že ORACLE mizí, MariaDB je stále silná obzvlášť v Gallera Clusteru. SQLite je pro mě skokan, protože umožňuje používat síťovou analýzu ve Spatialite. SQLite je vůbec specifická věc, s velkou užitnou hodnotou.
Vlastně ve všech RDBMS mám Spatial Extenze.
ScyllaDB je úžasný stroj, jednoznačně - je to ale natolik odlišná logika, že to používám jen s integrací dohromady. Ovšem ta nechutná rychlost a škálovatelnost je nepřekonatelná.Za mě gigařešení je malá RDBMS pro navigaci nad obří NoSQL.
-
Hmm niekde sa to zapatrosilo. Ale tu Martin nieco spomina : https://www.youtube.com/watch?v=Bqh09LG_QDE
O tej migracii kvoli postgresu nam osobne prisiel na meetup porozpravat ich CTO a bolo to fakt dobre.
Mali nejaky velky PostgreSQL cluster s kaskadovou replikaciou a jedneho dna sa komplet zosypal a zostala iba jedna funkcna noda. Velmi rychlo zistili ze postgre nie je vhodne na vsetky use-case. Aj ked ma kde tu pekne reporty a statistiky o tom ako je rychlejsi v nosql operaciach ako mongo a podobne... -
Myslím si, že nikdo netvrdí, že Postgres, případně jiná relační databáze je vhodná na všechno.
Když občas vidím, co třeba firmy, u kterých jsem konzultantem, vymýšlí nad relační databází, tak jim Postgres rozmlouvám. Programátor by měl mít taky trochu technického citu, aby vnímal, jestli nějakou technologii už moc neznásilňuje. Navíc dneska je mraky paměti - docela jednoduše se dá napsat inmemory databáze nad strukturou optimalizovanou pro konkrétní situaci.
-
> ale téměř nikdo se nechlubí, že by z SQL db migrovali do NoSQL
Bodejť:-). Řekl bych, že obecný přístup je:
1) If it don't fix it (když to funguje, tak se v tom nehrab).
2) Cena za nový betelný hw zůstává stejná, ale raketově roste to, co si za to pořídíte. Je mnohem jednodušší - a levnější(!) - nedostatečně optimalizovanou aplikaci přesunout na nový hw než platit pár lidem optimalizace.
2) Optimalizacemi (hinty, partitioning,...) se dá v SQL dosáhnout ohromných věcí. Když SQL pro současné řešení naráží na své limity, optimalizace je pořád ještě levnější než to přepsat.
4) Pokud už někdo udělal chybu v analýze a nevhodně zvolil SQL místo NoSQL, pak migrace nepomůže - lepší je to vyhodit a začít znovu.Proto si myslím, že migrací SQL-->NoSQL bude jako bílých vran.
-
Jsou situace, kdy se horizontální škálování hodí, a pokud vám stačí občasná konzistence, pak je vyhráno. Jedná se ale o situace, kdy se počet aktivních klientů počítá na vyšší desítky tisíc - v podstatě kdekoliv, kde používám databází ve smyslu chytřejší cache, která nezačíná úplně od nuly, .. ale pořád je to více méně cache a o data mohu přijít a nic vážného se nestane.
Vlastně by se předchozí odstavec dal přeformulovat, že potřebujete horizontální škálování cache. Pokud se relační databáze používá, tak jak má, a neznásilňuje se přespříliš, tak se tady u nás vůbec nesetkávám s problémy s výkonem. Většina problémů s výkonem jsou naprosté banality - typu programátor neví, co je transakce, fsync, connection pool, atd.
-
Většina problémů s výkonem jsou naprosté banality - typu programátor neví, co je transakce, fsync, connection pool, atd.
Tohle bohužel neví většina programátorů. Stejně jako u Oracle, tak i u PostgreSQL je potřeba poměrně úzká spolupráce admina a programátora. Programátor nemá šanci pochopit (pojmout) problematiku databáze a jejího výkonu. Správce zase vidí jen IOPSY, CPU, zaplnění WAL, případně dlouhé query. Do nich zase zpravidla nevidí programátor. Když už vidí, je těžké programátorovi vysvětlit, že dotaz nemůže trvat 100 ms, protože pod zátěží by celá DB stála.
To všechno dalo kdysi výhodu jak MySQL, tak NoSQL databázím, protože žádný z těchto "problémů" tam není tématem. MySQL se v podstatě nainstaluje a správce neřeší o moc víc, než kolik dá paměti na cache.
Ze zkušenosti vím, jak je těžké nastartovat v programátorech správné návyky a jak jim vysvětlit, proč je výhodou přenést co nejvíce logiky, výkonu na co nejnižší vrstvu. Setkávám se s názory viz @martinpoljak, že nastavit checky, triggery nebo pravidla na SQL je málo čitelné. Dává mi hodně práce ukázat programátorům, že se to vyplatí. Když si konzistenci dat (tím myslím konzistenci vyšší úrovně, interpretaci dat) hlídá databáze, má aplikace a programátor ušetřenou práci. Nezřídka se v aplikaci řeší totéž na různých místech. Je pak výhodnější, když aplikace a její programátor nemusí na všechno myslet, a mohou se spolehnout, že hraniční stavy ohlídá databáze sama. Na programátorovi pak už je jen interpretovat předané chyby.
-
Adam KaliszStříbrný podporovatelProblém je, že na odbornou práci tedy nejenom "rubání" kódu, co může zastat programátor, potřebujete někoho s inženýrským myšlením a tedy poměrně hlubokým a rozsáhlým porozuměním problematiky. Taková osoba nebo tým osob ten systém vymyslí a načrtnou nejdůležitější části. Programátoři potom dodělají detaily, které ale asi nebudou tak kritické a nebo budou poměrně svázáni nějakou specifikací. Administrátoři mají načrtnuté určité postupy, taky nemusí teprve vymýšlet, co a jak musí dělat, aby dosáhli kýženého výsledku.
Od obou tří kategorií ale najít opravdu kompetentní osoby je těžké a ani jeden z těch úkolů není jednoduchý.Myslím, že hodně problémů s výkonem spočívá v tom, že hodně softwarových inženýrů a programátorů uvažují povětšinou o aplikaci, ale již mnohem méně o operačním systému, hardwaru a síťovém spoji. Často se vytváří zbytečné závislosti a vzniká neudržovatelný a neupdatovatelný monolit. Nebo naopak (hlavně u menších projektů) se funkcionalita přemrštěně dělí do komponent a přidává se tak zcela zbytečně režie/ latence/ údržba atp.
Asi je to hlavně o té míře a tu se profesionál naučí jen praxí - není na to žádná užitečná nebo jednoduchá rovnice. -
vadi mi na ludoch ktory o nosql hovoria ako o nastroji s "obcasnou konzistenciou". to absolutne nie je pravda. akokeby " obcasne" znamenalo, ze to je konzistentne kazdy druhy piatok poobede.
bavime sa tu o milisekundach. ked mate cluster o 5 nodoch a replikacny faktor 3 a idete nieco zapisat, tak sa to zapise na primarnu repliku a dva dalsie nody v pozadi.
ked by to isiel niekto precitat tak moze precitat staru hodnotu len vtedy ak nema consistency levely nastavene tak, aby mal strong consistency. ( v skratke musi byt read + write consistency > replikacny faktor)
toto sa deje minimalne a je to chyba architekta / admina. inak je cassandra konzistentna tak ako si ju konzistentnou spravite a vyrovna sa sql. to nie je chyba samotnej databazy. to je o tom co chcete a aky mate usecase. niekedy vas strong consistency nezaujima ale radsej chcete redundanciu a odolnost voci vypadkom.
je to velmi siroka tema no poprosim nezhadzovat nosql databazy. ma to castokrat iny usecase ako sql.
-
vadi mi na ludoch ktory o nosql hovoria ako o nastroji s "obcasnou konzistenciou".
...
bavime sa tu o milisekundach. ked mate cluster o 5 nodoch a replikacny faktor 3 a idete nieco zapisat, tak sa to zapise na primarnu repliku a dva dalsie nody v pozadiPokud nekonzistence může nastat, musíte počítat s tím, že nastane. Tedy musíte brát nekonzistentní stav za základ dalšího projektování aplikace, a naopak konzistentní stav za příjemnou výjimku (kterou se pochopitelně snažíte maximalizovat).
To vyžaduje úplně jiný směr přemýšlení nad daty - proto se nad SQL databázemi přemýšlí jako nad databázemi zajišťující konzistenci (i když ani to nemusí být pravda, ale umí to), zatímco NoSQL jako o databázi bez konzistence (ačkoliv může být konzistentní prakticky neustále).
V takovém označení nehledejte nic pejorativního, jedná se jen o hyperbolu na určením toho či onoho druhu databáze.
je to velmi siroka tema no poprosim nezhadzovat nosql databazy. ma to castokrat iny usecase ako sql
Přesně tak. Dokonce bych řekl, že use case pro SQL vs. NoSQL je úplně jiný.
-
Jakub Valenta (neregistrovaný)
Mě se hodně líbí tohle video. Ukazuje, že NoSQL datábáze by se neměli používat jako hloupé úložiště s "SQL databází" emulovanou v aplikaci. Spíš se má použít ve chvíli kdy máš omezený počet způsobů použití, které jsou jasně definované. Potom můžeš celou databázi denormalizovat tak, aby data pro každý případ byly připravené bez spojování tabulek a dalších výpočtů. Takže oproti SQL získáš větší rychlost za cenu vyšších paměťových nároků a neflexibility databáze, protože změna nebo přidaní nového způsobu používání dat znamená změnu struktury databáze a může být o dost složitější udržovat celou databázi konzistentní.
-
Možná by bylo dobré definovat, co jsou to ty SQL databáze. Je to chyba i autora článku (kterého si jinak nesmírně vážím), že používá tento pojem, ačkoliv má na mysli zjevně relační databáze. SQL je dotazovací jazyk, který kvůli jeho všeobecné známosti používá dnes (případně jeho deriváty) mnoho databází, které s relačními db nemají nic společného (nebo emulují relační db třeba pomocí KV db -tedy vlastně NoSQL dle článku).
Offtopic: Problém diskusí na Rootu není v tom, že se tady diskutuje mimo téma, ale že se zde vyjadřuje velké množství lidí, kteří nemají co říct. Viz příspěvek, na který reaguji. Tolik slov a žádná myšlenka.
-
Možná by bylo dobré definovat, co jsou to ty SQL databáze. Je to chyba i autora článku (kterého si jinak nesmírně vážím), že používá tento pojem, ačkoliv má na mysli zjevně relační databáze.
1. Autor v textu zmiňuje, že hovoří o relačních databázích.
2. SQL je jazyk, který vznikl pro relační databáze; jiné databáze si syntaxi přivlastnily (z pochopitelných důvodů). Standardy SQL (stačí si projít ANSI standardy od SQL-86) jsou stavěny na ovládání relačních databází. Je tedy tradiční zjednodušení SQL = relační databáze. (Podobně pojmem "benzínový motor" rozumíme zážehové motory. Přitom i vznětový motor může používat benzín jako palivo, a běžný zážehový motor může jezdit jak na etanol, tak na různé plyny (CNG, LPG)).
https://cs.wikipedia.org/wiki/SQL
https://en.wikipedia.org/wiki/SQLMožná by bylo opravdu lepší novým generacím v článcích připomínat i kontext a základní pojmy. Já patřím ještě ke generaci, kde se aspoň částečná znalost historie oboru považovala za nutnou. Přemýšlím také, proč zjevně chybný příspěvek dostal jen samé palce nahoru.
