Teorie a praxe použití HBase

Dobré odpoledne Jmenuji se Danil Lipovoy, náš tým ve společnosti Sbertech začal používat HBase jako úložiště provozních dat. V průběhu jeho studia se nashromáždily zkušenosti, které jsem chtěl systematizovat a popsat (doufáme, že budou pro mnohé užitečné). Všechny níže uvedené experimenty byly provedeny s HBase verzemi 1.2.0-cdh5.14.2 a 2.0.0-cdh6.0.0-beta1.

1. Obecná architektura
2. Zápis dat do HBASE
3. Čtení dat z HBASE
4. Ukládání dat do mezipaměti
5. Dávkové zpracování dat MultiGet/MultiPut
6. Strategie pro rozdělení tabulek na regiony (rozdělení)
7. Odolnost proti chybám, zhutnění a umístění dat
8. Nastavení a výkon
9. Zátěžové testování
10. Závěry

1. Obecná architektura

Záložní Master poslouchá tlukot srdce aktivního na uzlu ZooKeeper a v případě zmizení přebírá funkce mastera.

2. Zapište data do HBASE

Nejprve se podívejme na nejjednodušší případ – zápis objektu klíč–hodnota do tabulky pomocí put(rowkey). Klient musí nejprve zjistit, kde se nachází server Root Region Server (RRS), který ukládá tabulku hbase:meta. Tyto informace obdrží od ZooKeeper. Poté přistupuje k RRS a čte tabulku hbase:meta, ze které získává informace o tom, který RegionServer (RS) je zodpovědný za ukládání dat pro daný klíč řádku v tabulce zájmu. Pro budoucí použití je meta tabulka ukládána klientem do mezipaměti, a proto následná volání jdou rychleji, přímo do RS.

Poté RS po obdržení požadavku jej nejprve zapíše do WriteAheadLog (WAL), který je nezbytný pro obnovu v případě havárie. Poté data uloží do MemStore. Toto je vyrovnávací paměť v paměti, která obsahuje seřazenou sadu klíčů pro danou oblast. Tabulku lze rozdělit na oblasti (oddíly), z nichž každá obsahuje nesouvislou sadu klíčů. To vám umožní umístit oblasti na různé servery, abyste dosáhli vyššího výkonu. Přes samozřejmost tohoto tvrzení však později uvidíme, že to nefunguje ve všech případech.

Po umístění položky do MemStore se klientovi vrátí odpověď, že položka byla úspěšně uložena. Ve skutečnosti je však uložen pouze ve vyrovnávací paměti a na disk se dostane až po uplynutí určité doby nebo při jeho zaplnění novými daty.

Při provádění operace „Smazat“ se data fyzicky nevymažou. Jednoduše se označí jako smazané a k samotnému zničení dojde v okamžiku volání hlavní kompaktní funkce, která je podrobněji popsána v odstavci 7.

Soubory ve formátu HFile se shromažďují v HDFS a čas od času se spustí menší kompaktní proces, který jednoduše spojí malé soubory do větších, aniž by se cokoli smazalo. Postupem času se z toho stává problém, který se objevuje pouze při čtení dat (k tomu se vrátíme trochu později).

Kromě výše popsaného procesu načítání existuje mnohem efektivnější postup, který je snad nejsilnější stránkou této databáze – BulkLoad. Spočívá v tom, že nezávisle tvoříme HFiles a ukládáme je na disk, což nám umožňuje dokonalé škálování a dosahování velmi slušných rychlostí. Ve skutečnosti zde omezení není HBase, ale možnosti hardwaru. Níže jsou uvedeny výsledky spouštění na clusteru sestávajícím z 16 RegionServerů a 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vláken), HBase verze 1.2.0-cdh5.14.2.

Zde můžete vidět, že zvýšením počtu oddílů (regionů) v tabulce, stejně jako spouštěcích programů Spark, získáme zvýšení rychlosti stahování. Rychlost také závisí na hlasitosti záznamu. Velké bloky dávají nárůst v MB/s, malé bloky v počtu vložených záznamů za jednotku času, přičemž všechny ostatní věci jsou stejné.

Můžete také začít načítat do dvou stolů současně a získat dvojnásobnou rychlost. Níže vidíte, že zápis 10 KB bloků do dvou tabulek najednou probíhá rychlostí cca 600 MB/s v každé (celkem 1275 MB/s), což se shoduje s rychlostí zápisu do jedné tabulky 623 MB/s (viz. č. 11 výše)

Druhý běh se záznamy 50 KB ale ukazuje, že rychlost stahování mírně roste, což naznačuje, že se blíží limitním hodnotám. Zároveň je třeba mít na paměti, že na samotném HBASE se prakticky nevytváří žádný náklad, vše, co je od něj požadováno, je nejprve dát data z hbase:meta a po nalinkování HFiles resetovat data BlockCache a uložit Vyrovnávací paměť MemStore na disk, pokud není prázdná.

3. Čtení dat z HBASE

Pokud předpokládáme, že klient již má všechny informace z hbase:meta (viz bod 2), jde požadavek přímo do RS, kde je uložen požadovaný klíč. Nejprve se vyhledávání provádí v MemCache. Bez ohledu na to, zda tam jsou data nebo ne, vyhledávání se provádí také ve vyrovnávací paměti BlockCache a v případě potřeby v HFiles. Pokud byla v souboru nalezena data, jsou umístěna do BlockCache a při příštím požadavku budou vrácena rychleji. Vyhledávání v HFile je díky použití Bloom filtru poměrně rychlé, tzn. po přečtení malého množství dat okamžitě zjistí, zda tento soubor obsahuje požadovaný klíč, a pokud ne, přejde na další.

Po obdržení dat z těchto tří zdrojů RS vygeneruje odpověď. Zejména může přenést několik nalezených verzí objektu najednou, pokud klient požadoval verzování.

4. Ukládání dat do mezipaměti

Vyrovnávací paměti MemStore a BlockCache zabírají až 80 % alokované paměti RS na haldě (zbytek je vyhrazen pro úlohy služby RS). Pokud je typický režim použití takový, že procesy zapisují a okamžitě čtou stejná data, pak má smysl omezit BlockCache a zvýšit MemStore, protože Když se zápis dat nedostane do mezipaměti pro čtení, BlockCache se bude používat méně často. Vyrovnávací paměť BlockCache se skládá ze dvou částí: LruBlockCache (vždy na hromadě) a BucketCache (obvykle mimo hromadu nebo na SSD). BucketCache by se měl používat, když je mnoho požadavků na čtení a nevejdou se do LruBlockCache, což vede k aktivní práci Garbage Collector. Radikální nárůst výkonu přitom od používání čtecí cache nečekejte, ale k tomu se vrátíme v odstavci 8

Pro celou RS je jedna BlockCache a pro každou tabulku je jeden MemStore (jeden pro každou rodinu sloupců).

Jak popsáno teoreticky při zápisu data nejdou do mezipaměti a skutečně, takové parametry CACHE_DATA_ON_WRITE pro tabulku a „Cache DATA on Write“ pro RS jsou nastaveny na false. V praxi však platí, že pokud zapíšeme data do MemStore, poté je vyprázdníme na disk (čímž je vyčistíme), následně smažeme výsledný soubor, pak provedením get requestu data úspěšně obdržíme. Navíc, i když úplně zakážete BlockCache a naplníte tabulku novými daty, pak resetujete MemStore na disk, smažete je a vyžádáte si je z jiné relace, stále se odněkud získávají. HBase tedy ukládá nejen data, ale také tajemné záhady.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

Parametr "Cache DATA on Read" je nastaven na hodnotu false. Pokud máte nějaké nápady, vítáme je v komentářích.

5. Dávkové zpracování dat MultiGet/MultiPut

Zpracování jednotlivých požadavků (Get/Put/Delete) je poměrně nákladná operace, takže pokud je to možné, měli byste je spojit do seznamu nebo seznamu, což vám umožní dosáhnout výrazného zvýšení výkonu. To platí zejména pro operaci zápisu, ale při čtení existuje následující úskalí. Níže uvedený graf ukazuje čas na přečtení 50 000 záznamů z MemStore. Čtení bylo provedeno v jednom vlákně a na vodorovné ose je uveden počet klíčů v požadavku. Zde vidíte, že při zvýšení na tisíc klíčů v jednom požadavku klesá doba provedení, tzn. rychlost se zvyšuje. Pokud je však ve výchozím nastavení povolen režim MSLAB, po tomto prahu začíná radikální pokles výkonu a čím větší je množství dat v záznamu, tím delší je provozní doba.

Testy byly provedeny na virtuálním stroji, 8 jader, verze HBase 2.0.0-cdh6.0.0-beta1.

Režim MSLAB je navržen tak, aby omezil fragmentaci haldy, ke které dochází v důsledku míchání dat nové a staré generace. Jako řešení, když je povolen MSLAB, jsou data umístěna do relativně malých buněk (kusů) a zpracována po částech. V důsledku toho, když objem v požadovaném datovém paketu překročí přidělenou velikost, výkon prudce klesne. Na druhou stranu, vypínání tohoto režimu také není vhodné, protože to povede k zastavením kvůli GC ve chvílích intenzivního zpracování dat. Dobrým řešením je zvýšení objemu buňky v případě aktivního zápisu přes put současně se čtením. Za zmínku stojí, že problém nenastane, pokud po nahrávání spustíte příkaz flush, který resetuje MemStore na disk, nebo pokud načtete pomocí BulkLoad. Níže uvedená tabulka ukazuje, že dotazy z MemStore na větší (a stejné množství) dat vedou ke zpomalení. Zvětšením velikosti chunksize však vrátíme dobu zpracování do normálu.

Kromě zvětšení velikosti chunksize pomáhá rozdělení dat podle regionů, tzn. rozdělení stolu. To má za následek méně požadavků přicházejících do každé oblasti a pokud se vejdou do buňky, odpověď zůstává dobrá.

6. Strategie rozdělení tabulek na regiony (rozdělení)

Vzhledem k tomu, že HBase je úložiště klíč-hodnota a rozdělení se provádí podle klíče, je nesmírně důležité rozdělit data rovnoměrně do všech oblastí. Například rozdělení takové tabulky na tři části povede k rozdělení dat do tří oblastí:

Stává se, že to vede k prudkému zpomalení, pokud později načtená data vypadají například jako dlouhé hodnoty, většina z nich začíná stejnou číslicí, například:

1000001
1000002
...
1100003

Protože jsou klíče uloženy jako bajtové pole, všechny budou začínat stejně a budou patřit do stejné oblasti #1, kde je uložen tento rozsah klíčů. Existuje několik strategií rozdělení:

HexStringSplit – Změní klíč na hexadecimálně zakódovaný řetězec v rozsahu "00000000" => "FFFFFFFF" a odsazení vlevo nulami.

UniformSplit – Změní klíč na bajtové pole s hexadecimálním kódováním v rozsahu "00" => "FF" a vyložením vpravo nulami.

Kromě toho můžete určit libovolný rozsah nebo sadu klíčů pro rozdělení a nakonfigurovat automatické rozdělení. Jedním z nejjednodušších a nejúčinnějších přístupů je však UniformSplit a použití zřetězení hash, například nejvýznamnější pár bajtů z běhu klíče přes funkci CRC32(rowkey) a samotný rowkey:

hash + rowkey

Poté budou všechna data distribuována rovnoměrně mezi regiony. Při čtení se první dva bajty jednoduše zahodí a zůstane původní klíč. RS také kontroluje množství dat a klíčů v regionu a v případě překročení limitů jej automaticky rozděluje na části.

7. Odolnost proti poruchám a datová lokalita

Vzhledem k tomu, že za každou sadu klíčů je zodpovědná pouze jedna oblast, řešením problémů spojených s pády nebo vyřazením RS z provozu je uložení všech potřebných dat do HDFS. Když RS klesne, master to detekuje prostřednictvím absence srdečního tepu na uzlu ZooKeeper. Poté přiřadí obsluhovanou oblast jinému RS a protože jsou HFiles uloženy v distribuovaném souborovém systému, nový vlastník je přečte a pokračuje v poskytování dat. Protože však některá data mohou být v MemStore a nestihla se dostat do HFiles, slouží k obnově historie operací WAL, která je také uložena v HDFS. Po aplikaci změn je RS schopen reagovat na požadavky, ale přesun vede k tomu, že některá data a procesy, které je obsluhují, skončí na jiných uzlech, tzn. lokalita se zmenšuje.

Řešením problému je velké zhutnění - tento postup přesouvá soubory do těch uzlů, které jsou za ně odpovědné (kde se nacházejí jejich regiony), v důsledku čehož se během tohoto postupu prudce zvyšuje zatížení sítě a disků. V budoucnu se však přístup k datům znatelně zrychlí. Kromě toho major_compaction provádí sloučení všech HFiles do jednoho souboru v rámci regionu a také vyčistí data v závislosti na nastavení tabulky. Můžete například zadat počet verzí objektu, které musí být zachovány, nebo dobu životnosti, po které je objekt fyzicky odstraněn.

Tento postup může mít velmi pozitivní vliv na fungování HBase. Obrázek níže ukazuje, jak se výkon snížil v důsledku aktivního záznamu dat. Zde můžete vidět, jak 40 vláken zapisovalo do jedné tabulky a 40 vláken současně četlo data. Zápis vláken generuje stále více souborů HFiles, které čtou jiná vlákna. V důsledku toho je potřeba z paměti odstraňovat stále více dat a nakonec začne fungovat GC, což prakticky paralyzuje veškerou práci. Zahájení velkého zhutňování vedlo k vyčištění výsledných úlomků a obnovení produktivity.

Test byl proveden na 3 DataNode a 4 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vláken). HBase verze 1.2.0-cdh5.14.2

Stojí za zmínku, že hlavní komprimace byla zahájena na „živé“ tabulce, do které byla data aktivně zapisována a čtena. Na internetu se objevilo prohlášení, že by to mohlo vést k nesprávné odpovědi při čtení dat. Pro kontrolu byl spuštěn proces, který generoval nová data a zapisoval je do tabulky. Načež jsem hned četl a kontroloval, zda se výsledná hodnota shoduje s tím, co bylo zapsáno. Zatímco tento proces probíhal, velké zhutňování bylo spuštěno asi 200krát a nebyla zaznamenána jediná porucha. Možná se problém objevuje zřídka a pouze při vysoké zátěži, takže je bezpečnější zastavit procesy zápisu a čtení podle plánu a provést čištění, aby se zabránilo takovým výpadkům GC.

Velké zhutnění také neovlivňuje stav MemStore, k jeho vyprázdnění na disk a zhutnění je třeba použít flush (connection.getAdmin().flush(název_tabulky.valueOf(název_tbl))).

8. Nastavení a výkon

Jak již bylo zmíněno, HBase vykazuje největší úspěch tam, kde nemusí nic dělat, při spouštění BulkLoad. To však platí pro většinu systémů a lidí. Tento nástroj je však vhodnější pro hromadné ukládání dat ve velkých blocích, zatímco pokud proces vyžaduje více konkurenčních požadavků na čtení a zápis, použijí se výše popsané příkazy Get a Put. Pro určení optimálních parametrů byly spuštěny různé kombinace parametrů a nastavení tabulky:

• 10 vláken bylo spuštěno současně 3x za sebou (říkejme tomu blok vláken).
• Provozní doba všech vláken v bloku byla zprůměrována a byla konečným výsledkem operace bloku.
• Všechna vlákna pracovala se stejnou tabulkou.
• Před každým začátkem závitového bloku bylo provedeno velké zhutnění.
• Každý blok provedl pouze jednu z následujících operací:

-Dát
-Dostat
-Získat + dát

• Každý blok provedl 50 000 iterací své operace.
• Velikost bloku záznamu je 100 bajtů, 1000 10000 bajtů nebo XNUMX XNUMX bajtů (náhodně).
• Bloky byly spouštěny s různým počtem požadovaných klíčů (buď jeden klíč nebo 10).
• Bloky byly spuštěny pod různými nastaveními tabulky. Parametry změněny:

— BlockCache = zapnuto nebo vypnuto
— Velikost bloku = 65 KB nebo 16 KB
— Oddíly = 1, 5 nebo 30
— MSLAB = povoleno nebo zakázáno

Takže blok vypadá takto:

A. Režim MSLAB byl zapnut/vypnut.
b. Byla vytvořena tabulka, pro kterou byly nastaveny následující parametry: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
C. Komprese byla nastavena na GZ.
d. 10 vláken bylo spuštěno současně a provádělo operace 1/10 put/get/get+put do této tabulky se záznamy 100/1000/10000 bajtů, které provedly 50 000 dotazů v řadě (náhodné klíče).
E. Bod d byl opakován třikrát.
F. Provozní doba všech vláken byla zprůměrována.

Byly testovány všechny možné kombinace. Dá se předvídat, že rychlost bude klesat s rostoucí velikostí záznamu nebo že deaktivace ukládání do mezipaměti způsobí zpomalení. Cílem však bylo porozumět míře a významnosti vlivu každého parametru, proto byla sesbíraná data vložena do vstupu lineární regresní funkce, která umožňuje posoudit významnost pomocí t-statistiky. Níže jsou uvedeny výsledky bloků provádějících operace Put. Kompletní sada kombinací 2*2*3*2*3 = 144 možností + 72 tk. některé byly provedeny dvakrát. Celkem tedy existuje 216 běhů:

Testování bylo prováděno na mini-clusteru sestávajícím ze 3 DataNodes a 4 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vláken). HBase verze 1.2.0-cdh5.14.2.

Nejvyšší rychlosti vkládání 3.7 sekundy bylo dosaženo s vypnutým režimem MSLAB, na stole s jedním oddílem, s povolenou BlockCache, BlockSize = 16, záznamy 100 bajtů, 10 kusů v balení.
Nejnižší rychlost vkládání 82.8 s byla dosažena s povoleným režimem MSLAB, na tabulce s jedním oddílem, s povolenou BlockCache, BlockSize = 16, záznamy 10000 1 bajtů, XNUMX každý.

Nyní se podíváme na model. Vidíme dobrou kvalitu modelu založeného na R2, ale je naprosto jasné, že zde je extrapolace kontraindikována. Skutečné chování systému při změně parametrů nebude lineární, tento model je potřeba nikoli pro predikce, ale pro pochopení toho, co se v rámci daných parametrů stalo. Například zde z kritéria studenta vidíme, že parametry BlockSize a BlockCache nejsou důležité pro operaci Put (což je obecně docela předvídatelné):

Ale to, že zvýšení počtu oddílů vede ke snížení výkonu, je poněkud neočekávané (pozitivní dopad zvýšení počtu oddílů s BulkLoad jsme již viděli), i když pochopitelné. Za prvé, pro zpracování musíte generovat požadavky do 30 regionů místo do jednoho a objem dat není takový, aby to přineslo zisk. Za druhé, celkový provozní čas je určen nejpomalejším RS, a protože počet DataNodes je menší než počet RS, některé regiony mají nulovou lokalitu. No, podívejme se na prvních pět:

Nyní vyhodnotíme výsledky provádění bloků Get:

Počet oddílů ztratil na významu, což je pravděpodobně vysvětleno tím, že data se dobře ukládají do mezipaměti a mezipaměť pro čtení je nejvýznamnějším (statisticky) parametrem. Zvýšení počtu zpráv v požadavku je samozřejmě také velmi užitečné pro výkon. Nejlepší skóre:

Nakonec se podívejme na model bloku, který nejprve provedl get a pak dal:

Všechny parametry jsou zde důležité. A výsledky vedoucích:

9. Zátěžové testování

No, konečně spustíme víceméně slušný náklad, ale vždy je zajímavější, když máte s čím porovnávat. Na webových stránkách společnosti DataStax, klíčového vývojáře Cassandry, existuje zjištění NT řady úložišť NoSQL, včetně HBase verze 0.98.6-1. Načítání probíhalo po 40 vláknech, velikost dat 100 bajtů, SSD disky. Výsledek testování operací Read-Modify-Write ukázal následující výsledky.

Pokud jsem pochopil, čtení bylo prováděno v blocích po 100 záznamech a pro 16 uzlů HBase ukázal test DataStax výkon 10 tisíc operací za sekundu.

Naštěstí náš cluster má také 16 uzlů, ale není moc „štěstí“, že každý má 64 jader (vlákna), zatímco v testu DataStax jsou pouze 4. Na druhou stranu mají SSD disky, zatímco my máme HDD nebo více se nová verze HBase a vytížení CPU při zátěži prakticky výrazně nezvýšilo (vizuálně o 5-10 procent). Zkusme však začít používat tuto konfiguraci. Výchozí nastavení tabulky, čtení se provádí v rozsahu klíčů od 0 do 50 milionů náhodně (tj. v podstatě pokaždé nové). Tabulka obsahuje 50 milionů záznamů rozdělených do 64 oddílů. Klíče jsou hashovány pomocí crc32. Nastavení tabulky je výchozí, MSLAB je povolen. Po spuštění 40 vláken každé vlákno přečte sadu 100 náhodných klíčů a okamžitě zapíše vygenerovaných 100 bajtů zpět do těchto klíčů.

Stojan: 16 DataNode a 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vláken). HBase verze 1.2.0-cdh5.14.2.

Průměrný výsledek se blíží 40 tisícům operací za vteřinu, což je výrazně lepší než v testu DataStax. Pro experimentální účely však můžete podmínky mírně změnit. Je docela nepravděpodobné, že veškerá práce bude prováděna výhradně na jednom stole a také pouze na jedinečných klíčích. Předpokládejme, že existuje určitá „horká“ sada klíčů, která generuje hlavní zatížení. Zkusme proto vytvořit zátěž s většími záznamy (10 KB), také v dávkách po 100, ve 4 různých tabulkách a s omezením rozsahu požadovaných klíčů na 50 tis.. Graf níže ukazuje spuštění 40 vláken, každé vlákno čte sadu 100 klíčů a okamžitě na tyto klíče zapíše náhodných 10 KB zpět.

Stojan: 16 DataNode a 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vláken). HBase verze 1.2.0-cdh5.14.2.

Během zátěže bylo několikrát spuštěno velké hutnění, jak je uvedeno výše, bez tohoto postupu bude výkon postupně degradovat, nicméně další zatížení vzniká i při provádění. Čerpání je způsobeno různými důvody. Někdy vlákna dokončila práci a došlo k pauze při jejich restartování, někdy aplikace třetích stran vytvořily zatížení clusteru.

Čtení a okamžité psaní je pro HBase jedním z nejobtížnějších pracovních scénářů. Pokud provádíte pouze malé put requesty, například 100 bajtů, které spojujete do balíčků po 10-50 tisících kusech, můžete získat stovky tisíc operací za sekundu a podobná situace je s požadavky pouze pro čtení. Za zmínku stojí, že výsledky jsou radikálně lepší než výsledky získané DataStaxem, a to především díky požadavkům v blocích po 50 tisících.

Stojan: 16 DataNode a 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 vláken). HBase verze 1.2.0-cdh5.14.2.

10. Závěry

Tento systém je poměrně flexibilně konfigurován, ale vliv velkého množství parametrů zůstává stále neznámý. Některé z nich byly testovány, ale nebyly zahrnuty do výsledné testovací sady. Například předběžné experimenty ukázaly nevýznamný význam takového parametru, jako je DATA_BLOCK_ENCODING, který kóduje informace pomocí hodnot ze sousedních buněk, což je pochopitelné pro náhodně generovaná data. Pokud použijete velké množství duplicitních objektů, zisk může být významný. Obecně lze říci, že HBase působí dojmem poměrně seriózní a promyšlené databáze, která může být poměrně produktivní při operacích s velkými bloky dat. Zejména pokud je možné časově oddělit procesy čtení a zápisu.

Pokud je podle vašeho názoru něco, co není dostatečně zveřejněno, jsem připraven vám to sdělit podrobněji. Zveme vás, abyste se podělili o své zkušenosti nebo diskutovali, pokud s něčím nesouhlasíte.

Zdroj: www.habr.com