Názory k článku Svět se strašlivě změnil, ale databáze jsou pořád stejné
-
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.
-
Jak se stále a stále více dat vejde do paměti, přestává být pro rychlost zpracování důležité I/O a umocňuje se rychlost vyhodnocení dotazu - hlavně podmínek v něm napsaných. Před dvaceti lety používaly všechny SQL databáze k vyhodnocování interpret. Myslím, že do budoucna bude nezbytné dotazy překládat (nejlépe dynamickým překladačem jako je v GraalVM).
-
to je skor chyba navrhu schemy ze sa domena namodeluje tak blbo ze sa tam potom joinuje 5 tabuliek dokopy.
spravne by to malo byt naopak. mam aplikaciu a navrhnem si dotazy a schemu tak aby bola ta query na jeden select v konstantnom case.
takze naopak - rozmyslim si co chcem a spravim schemu aby som to nemusel na sql urovni komplikovat.
toto samozrejme moze byt trochu neflexibilne "ako aplikacia rastie" no existuju postupy ako robitm v nosql svete (cassandra) sa hojne vyuziva duplikacia. sql je postavene na tom, aby som nikde neplytval miestom a mal to vsetko dobre denormalizovane.
v nonsql to nebyva casto problem. je mi jedno ze duplikujem. nemam potom ziadne joiny a query su na jeden select v konstantnom case.
-
Ne, struktura databáze nemůže vycházet z požadavků konkrétní query. Struktura musí vycházet z dat. To je mor, který vede k neudržovatelným schematům. Vždy to skončí buď smrtí aplikace (už to dál nejde udržet), nebo celým přepsáním.
Ten důvod proč je to tak špatně je v normalizaci. Pokud vám někdo řekl, že je to kvůli plýtvání místem, tak vám ten hlavní důvod tajil. Normalizace je matematický aparát jehož cílem je vyhnout se duplicitním údajům. A ty nejsou problém kvůli místu, které zabírají duplikáty, ale kvůli udržitelnosti dat - každá duplicita totiž komplikuje update a delete. Změna jediného údaje pak totiž obnáší celou sadu updatů duplicitních údajů. U insert only databází je to jedno, ale pokud má databáze podporovat i update, tak je duplicita dat obrovský problém. To vám pak změna jednoho údaje končí updatem několika tabulek. Což je ještě ten menší problém. Větší problém je pak to, když se k tomu dostane jiný programátor a neví, kde všude se to přepsat má a kde ne. Protože některé tabulky jsou "živé" a při změně hodnoty se musí přepsat i tady, zatímco jiné tabulky jsou "historie" a ty se naopak přepsat nesmí.
A hrozná legrace to začne být ve chvíli, kdy se vám do toho začnou motat "defaulty". To je kupříkladu když prodejní položka má název, který se dotáhne do řádku prodejní objednávky ve chvíli, kdy ho vytváříte. Ale v tom řádku prodejní objednávky pak jde přepsat. A vy pak musíte zamítnout code review a znovu opakovat: ano, při updatu popisu položky je potřeba si fulltextově dohledat jiné tabulky, kde jsou sloupce "part_no" s FK na item_master a "part_description" a tam data updatovat taky, ale prodejní a nákupní objednávky jsou výjimka! A ne, výrobní zakázka a pracovní příkaz výjimky nejsou, tam se to přepsat má (shop order a work order přepsat, sales order a purchase order nepřepisovat).
To jako vážně ne, tam se musí oprášit 3NF a dát to do latě. A navíc tam poměrně často bývá takový legrační efekt, že denormalizace se provede aby to bylo rychlejší, ale celé se to tím zpomalí. Ona denormalizace pomůže s OLAP. Jenže je to obrovská zátěž pro OLTP. Je fajn, že vám report skladových transakcí funguje rychleji, jenže vy jste díky denormalizaci přidal do některých OLTP transakcí update nad tou největší tabulkou, kterou v aplikaci máte. Takže update skladové položky rázem místo 10 milisekund trvá minutu. A jako bonus občas timeout na record lock.
Denormalizaci jsme vždy zastavili. Nikdy to nevedlo k ničemu dobrému. Opravdu zásadní problémy s dotazy přes X obrovských tabulek jsme řešili pomocí materialized view nebo pomocí tabulek, které pravidelně nebo na dotaz krmíme přes ETL.
-
zalezi od aplikacie, ked to je priamociara vec a la IoT kde skoro stale len zapisujem a obcas precitam a viem co robim a aky to ma usecase tak to nie je problem ale vyhoda - dostanem za to nieco ine (nechcem ist tym smerom, ze co, nechcem o tom tu pisat).
ked ale mam nejaku skladovu aplikaciu kde "ani boh" nevie ako sa tie data / schema bude casom menit tak normalne sql tam samozrejme ma vacsiu vyhodu.
osobne som zazil nosql projekt netrivialnej velkosti a po tom ako sa nastavila schema tak sa uz menila len minimalne - len sa pridavali fieldy a tabulky nad tym logika spravila vsetko. nehovorim ze to bolo lahke a ze sme vela krat lutovali ze to nema joiny ale je to proste iny svet a treba sa na to pozerat inak.
aby som bol uplne presny tak my sme velmi neduplikovali pretoze to so sebou prinasa tiez nevyhody - napr. Cassandra ma batch statements ktore simuluju lightweight transakcie a je to trosku narocnejsie na koordinatora ale ked sa to neznasilnuje, tak sa to da pouzit.
za tym nazorom "tabulku si navrhnem podla query" si stojim - stoji na tom cela filozofia Cassandry a ma to velmi silne vyhody ked clovek vie co robi. "schema na query" nie je moj vymysel, staci si o tom nieco precitat - vela ludi je toho zastancom.
-
No SQL databáze pořád považuju za relativně zlom. Například už dávno neplatí nutnost mít všechny data ve 3NF, jen proto, že tabulky neumí vícehodnotová pole a nebo že je neumí indexovat (po jednotlivých hodnotách).
Aktuálně pracuji v CouchDB a naprosto vyhovuje tomu, na čem pracuji. Naopak si nedokážu představit, že bych to dělal v SQL. Jedná se o kolekci různorodých dat a jejich zařazení dle formátu do indexů, něco jako duck typing v OOP, kdy místo toho, abych dopředu deklaroval třídy (a tabulky), tak sbírám data tak jak jsou a následně je indexuji podle toho, co obsahují za informace.
Co považuji za zůvěřilost je že se do NoSQL databází dostává query jazyk v podobě SQL. Přitom je to právě o tom, že NoSQL jsou tak odlišné, že klasické SQL dotazy se na to nehodí. Tato věc se bohužel dostala i do mé oblíbené CouchDB, přestože využitelnost tohoto nástroje (Mango Querues) je nulová. Degraduje NoSQL databázi na jednotabulkovou DB s jednoduchým indexem a ještě navíc neumí join. Ale ta tlačenka je neuvěřitelná.
-
Taktak, máte na mysli bezschématovost NoSQL jako vlastnost u RDB se nevyskytující a umožňující silně dynamické zpracování dat (částečně související s nedávno zde diskutovaným rozdílem mezi typovanými a netypovanými jazyky). Právě nepochopení rozdílné koncepce způsobuje, že po webu dnes lze najít knihovny pro práci se schématy v NoSQL.
-
Ano,
No SQL bylo prelomova technologie poprve pouzita v 60. letech minuleho stoleti a dodnes bezi trebav bankovnich systemech.
Prezentace z jopenspace 2014
https://www.slideshare.net/zmerta/gtm-in-no-sql-in-core-banking-systems -
Hezký článek
Podle mě se zase jen potvrzuje, jak se vše točí neustále v cyklech a opakují se historické věci. Např. web - dříve byly statické stránky, pak bych rozmach aktivních a teď je zase móda přecházet na statické, generované (např. za pomocí GitLab Pages).
Nebo třeba jen taková věc, jako je grafický design. Když vezmu Windows, tak od barev ve Windows 9x/XP to ve Vista přešlo přes skleněné efekty a průhlednost (a MS pořád říkal, že je to díky akceleraci rychlejší, jak předchozí, bez ttěch efektů), pak se postupně začal přes Windows 8.x a Windows 10 tlačit styl co nejméně barev a byla snaha mít dvě barvy a teď zase MS začal tlačit více barev a stínování (viz návrh nových ikon pro Visual Studio apod.).
Co se týká DB, tak já začínal na dBase 3, přešel jsem před dBase IV na FoxPro 2.6, pak na Visual FoxPro (zde náznak něčemu, co se dalo nazvat v rámci možností databáze - "ref. integrita" atd.). Pak jsem přešel na "pravé SQL" DB Oracle 7,8,9,10 až do současné 18. Paralelně s tím jsem pozoroval rozmach NoSQL a XML databází, ale to mě nikdy nějak nechytlo, v mém využití jsem na to nenašel místo a nejsem typ, co přejde na nějakou módní vlnu, aniž by mu to dávalo smysl (ale své místo NoSQL samozřejmě mají). Teď hype s NoSQL myslím opadl a SQL zase celkem jede a zatím nemám důvod měnit.
Že se doplňují myslím ukazuje např. Oracle, který má snad vše. Od klasické "velké" SQL, přes MySQL, NoSQL, In-memory DB, Cloud DB atd.
PS: Teď čekám, kdy zase začne být populární server side rendering a bude se ustupovat od front end zaměřených technologií typu Angular a React
-
L.Stříbrný podporovatel
Ohledně tech webů, to je nesmysl:
1) Generované statické stránky jsou naprostá minorita.
2) Server-side rendering populární je, ale v rámci těch "frontendových" (přesněji client-side) technologií, viz například Next.js. Odklon od client-side technologií moc neočekávám, to není otázka módy, ale toho, s nimi lze poskytnout mnohem lepší uživatelskou zkušenost.
Krásným příkladem je zdejší registrační formulář, který jsem musel vyplňovat asi nadesetkrát. Protože jsem ho vždycky vyplnil, odeslal a dozvěděl jsem se, že login je už zabraný. Ale odesláním se mi vymazalo heslo, takže jsem vyplnil nové jméno a znovu hesla, odeslal, mezitím se změnila kontrolní otázka, tak jsem to musel vyplnit zase znovu, nové jméno, hesla a novou kontrolní otázku. Kdyby to nebylo dělané jako čistě server-side formulář, tak tam může být indikátor obsazenosti uživatelského jména hned po jeho vyplnění a mnohonásobné vyplňování není třeba.
-
Re.: <b>Co bude za deset let</b>
S příchodem velkých SSD disků bych čekal, že se přístup k databázím posune na nižší úroveň, že tu budeme mít krabičky, které budou vypadat jako HDD, ale bude to sofistikované SŘBD, kde i indexace bude mít HW podporu.
Snad se podaří, vyhnout období, kdy to bude vendor lock black box a rovnou to někdo navrhne jako otevřené řešení..
ČLÁNKY DO MAILU