Názory k článku Do hlubin tlačítka Líbí se: výběr databáze, API a backend

Cassandra / Scylla – mají náročnější instalaci a údržbu, vyžadují pravidelnou údržbu. >>> Toto řešení je vhodné spíš pro sekvenční čtení, my vyžadujeme náhodný přístup ... <<<

zalezi od toho aky sa nastavi patritioner, jasne ze Murmur3 tie data rozplacne skrz nody aby bol load rovnomerne a potom to je "nesekvencne" ked to je defakto random. Inak nechapen naco to treba prave "sekvencne" citat?

Na to by sa mohol pouzit samozrejme byte array partitioner ale ma to tiez svoje muchy (ako vsetko) no to je to co by vyriesilo ten problem, aj ked nechapem, preco nim je ...

https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/architecture/archPartitionerBOP.html

Beriem spat co som napisal lebo som si to blbo precital.

Je nespravne si mysliet ze Cassandra je robena na sekvencny pristup. Prave naopak. Murmur3 partitioner je default a ten repliky hadze random na nody. Takze ta autorova potreba citat random je ukojena out of the box. Nespravil autor v tomto vyroku chybu?

Sekvencne sa da pouzit ten byte array ordering ale to je nieco co sa musi dodatocne nastavit, takze som si skoro isty ze to je od zakladu robene na random namiestk sekvencneho, inak nechapem co tym chce autor povedat.

2i indexy su znakom blbeho modelu kde k tomu pristupuje clovek s hlavou z sql sveta. Tu riesi denormalizacia - modelujem tabulku tak aby som mal dobru query, netrapi ma kolko to zozere miesta na disku a ze sa to duplikuje.

Ďakujeme za podnet, na správanie Murmur3 sa pozrieme, možno sa nám bude hodiť na nejaký budúci projekt.

Je pravda že sme na začiaku mali hlavu v SQL svete, keďže pôvodná implementácia určená iba pre stránku seznam.cz bola postavená nad MariaDB, asi nás to pri návrhu ovplyvnilo.

Nechci vám kazit radost z mikroslužeb :-) ale mám pocit, že vám to funguje naopak - asi nějaký programátor spletl znaménko nebo tak něco.

Otevřel jsem si dva prohlížeče, v jednom jsem byl přihlášený a střídavě dával a odebíral hlas pod článkem. V druhém prohlížeči jsem kontroloval výsledek. Když v prvním bylo zakliknuto (červeně vyplněné srdíčko), tak byl počet hlasů v druhém prohlížeči vyšší. A když jsem vzal hlas zpátky, tak číslo zase kleslo. Zkoušel jsem to asi desetkrát, abych odfiltroval interferenci s případnými dalšími hlasujícími, takže náhoda to asi nebude.

Chápu, že tohle je v podstatě zbytečná služba a je vlastně úplně jedno, jaká čísla se tam budou zobrazovat, ale když už o tom píšete článek na Root, tak by to mohlo fungovat - aspoň trochu.

> Když v prvním bylo zakliknuto (červeně vyplněné srdíčko), tak byl počet hlasů v druhém prohlížeči vyšší. A když jsem vzal hlas zpátky, tak číslo zase kleslo.

No vždyť jo, tím, že jsi zahlasoval (srdíčko zčervenalo) se počítadlo zvýšilo a když se na to kliknul znova, tak se hlas odebral. Ale možná jen funguješ naopak :)

Oprava:

tak byl počet hlasů v druhém prohlížeči nižší. A když jsem vzal hlas zpátky, tak číslo zase stouplo.

jinak bych to sem nepsal

Když si přečteš odstaven Datový model pro databázi, tak se dozvíš, že data nemusí být hned konzistentní, pokud ti odpověď na každý z prohlížečů přijde z jiného datacentra

Když jsem článek otevřel, chtěl jsem ho zavřít, že to bude zase plné nesmyslů. Klobouk dolu, pěkně a rozumně postavená služba, dobře odůvodněné a vybrané technologie.

Velké plus je hlavně za couchbase, tu v čechách moc nepotkávám a je to škoda, moc pěkná technologie.

Jenom poznámka k mongu to co píšete je sice pravda, ale jenom pokud se bavíme o replikaci a ne o škálování. Pokud chcete škálovat, tak mongo má na tohle sharding. Navíc mi tohle přijde jako typický případ, kdy zápis můžete dělat do primary a číst z repliky. Ono i kdyby ta primary odešla, tak si nemyslím, že přijít o oplog by zrovna u tohohle případu byla nějaká tragédie.
Tím ale nechci říct, že zvolená DB je špatná.
Ale zajímalo by mě proč jste měli ve výběru NoSQL databáze a MySQL? Síla zvyku, protože jinak si to neumím vysvětlit?

My potrebujeme škálovanie aj s replikáciou zároveň, aby výpadok ľubovoľného stroja neohrozil dostupnosť či konzistenciu dát :). Aspoň u tejto služby to tak preferujeme.

Zápis do primary nám nevyhovuje, pretože to nie je robustné voči výpadku data centra v ktorom sa primary replika nachádza, a tiež je to potenciálne úzke hrdlo. V Sezname chceme mať služby postavené tak aby fungovali nezávisle na výpadku jednoho či viacerých datacentier.

Toto samozrejme nie je vždy zásadný problém, záleží od služby. Napríklad Seznam Zprávy používajú ako databázu MongoDB.

Vo výberu sme mali databázy, s ktorými v Seznamu máme skúsenosti s prevádzkou pod vysokou záťažou. Máme skúsenosti aj s ďalšími databázami, ale nie každá služba a každá databáza je pod vysokou záťažou.

Ako vysvetľuje následujúci odstavec, problém sú race conditions v celom systéme, nie vrámci komponenty backendu - tam race conditions nemáme :).

Jazyk či iné technológie, ktoré používame na projekte, vždy vyberáme podľa preferencií tímu, ktorý projekt realizuje, a vhodnosti na daný problém. Nie podľa toho čo je cool.

Cockroach, TiDB, TiKV, Badger ani Pebble sme nezvažovali keďže s nimi nemáme skúsenosti s väčšou záťažou, a medzi databázami s ktorými máme skúsenosti s väčšou záťažou bol vhodný kandidát.

Přemýšlel jsem dlouho nad tím vaším řešením a výběrem Couchbase a došel jsem k závěru, že bych spíš použil FoundationDB, přijde mi na ten váš usecase mnohem vhodnější, ve zkratce je to ACID key/value storage, možná znáte: https://www.foundationdb.org/ Přijde mi, že byste tam nemuseli řešit ty "kravinky" s konzistencí. Nevím, třeba se mýlím, ale mýlit se je lidské že? :-)

To vyzerá zaujímavo, ďakujeme za tip a zvážime použitie v nejakom ďalšom projekte :).

Vidím že nasazování na všechny možné služby postupuje. Na Kupi (taky služba Seznamu, už) jsou kromě lajků dokonce i komentáře https://www.seznam.cz/komentare/8791845-vinari-placou-zrusene-svatomartinske-kosty-i-vanocni-vecirky-je-nuti-snizovat-ceny

O těch se tu dokonce zatím ani nepsalo.

Je to někde popsáno, případně k použití i pro ostatní jak se psalo v prvním článku?

Použitie komentárov od Seznam.cz na službách partnerov je plánované, ale v súčastnosti sa zatiaľ sústredime na nasadenie na naše služby.