$FOGO z jednoho důvodu, který nemá nic společného s čísly na leaderboardu, a všechno má společného s tím, jak řetězec tiše tlačí stavitele, aby vyrostli ve své architektuře, protože když stavíte na SVM založeném L1, nevybíráte pouze rychlejší prostředí, ale vybíráte také model provádění, který odměňuje dobrý návrh stavu a bez milosti odhaluje špatný návrh stavu.
Fogo se zdá, že je formováno kolem myšlenky, že rychlost by neměla být kosmetickým tvrzením, protože pokud jsou bloky skutečně rychlé a runtime může zpracovávat nezávislou práci současně, pak se aplikace stává skutečným úzkým hrdlem, a tento posun je tím, kde se příběh SVM stává zajímavým, protože runtime v podstatě klade každému vývojáři stejnou otázku v okamžiku, kdy skuteční uživatelé přicházejí, což je, zda jsou jejich transakce skutečně nezávislé, nebo zda omylem navrhli jeden sdílený zámek, který musí každý dotknout.
Paralelní provádění zní jednoduše, když je vysvětleno jako transakce běžící společně, ale praktický detail, který mění vše, je ten, že to funguje pouze tehdy, když se dvě transakce nebojují o stejný stav, a na SVM není stav neviditelnou blob, kterou řetězec interpretuje, jak chce, stav je explicitní a konkrétní, a každá transakce musí deklarovat, co bude číst a co bude zapisovat, což znamená, že řetězec může plánovat práci s důvěrou, když se tyto deklarace nepřekrývají, a také to znamená, že řetězec vás nemůže zachránit před vaším vlastním uspořádáním, když donutíte všechno, aby se překrývalo.
Toto je část, kterou většina povrchních komentářů přehlíží, protože lidé hovoří, jako by výkon žil na úrovni řetězce, ale na Fogo v okamžiku, kdy začnete modelovat aplikaci, se výkon stává něčím, co navrhujete do způsobu, jakým jsou účty a data oddělena, a to je důvod, proč mohou dvě aplikace na stejném řetězci působit úplně jinak pod tlakem, přičemž jedna zůstává plynulá, zatímco druhá se stává podivně zaseknutou, i když obě sedí na stejném rychlém prostředí pro provádění.
Všiml jsem si, že když tvůrci přicházejí ze zvyklostí sekvenčního provádění, přenášejí jeden instinkt, který se cítí bezpečně, ale stává se nákladným na SVM, což je instinkt udržovat centrální objekt stavu, který každá akce aktualizuje, protože to činí uvažování o systému čistým, usnadňuje analytiku a činí kód takovým, že má jediný zdroj pravdy, ale na řetězci SVM se stejný design stává tichým zúžením, protože každá uživatelská akce se nyní snaží zapisovat na stejné místo, takže i když je runtime připraven provádět paralelně, vaše aplikace vytvořila jedinou dráhu, do které všechno musí vstoupit.
Co se mění na @Fogo Official je, že rozložení stavu přestává být jen úložištěm a začíná být politikou konkurence, protože každý zapisovatelný účet se stává jakýmsi zámkem, a když dáte příliš mnoho za jeden zámek, nezpomalujete jen malou komponentu, ale kolapsujete paralelismus pro celý tok, a řetězec nemusí být ucpaný, abyste to cítili, protože váš vlastní návrh smlouvy generuje ucpání tím, že nutí nesouvisející uživatele kolidovat na stejném zápisovém souboru.
Nejužitečnější způsob, jak o tom přemýšlet, je zacházet s každým zapisovatelným kusem stavu jako s rozhodnutím o tom, kdo může postoupit ve stejnou dobu, a cílem designu se stává snižování zbytečných kolizí, což neznamená úplné odstranění sdíleného stavu, protože některé sdílené stavy jsou zásadní, ale znamená to být disciplinovaný ohledně toho, co musí být sdíleno a co bylo sdíleno pouze pro pohodlí, protože pohodlí je tam, kde paralelní provádění tiše umírá.
Na Fogo vzory, které udržují aplikace rychlé, jsou zřídka složité, ale jsou přísné, protože vyžadují, aby vývojář agresivně oddělil uživatelský stav, aby izoloval tržní specifický stav místo toho, aby tlačil všechno přes jeden globální protokolový objekt, a aby přestal zapisovat do sdílených účtů, které jsou většinou tam pro sledování a viditelnost, protože tyto odvozené metriky mohou existovat, aniž by se staly součástí kritické cesty zápisu pro každou transakci.
Když se dívám na úspěšné návrhy přátelské k paralelnímu provádění, mají tendenci zacházet s uživatelskými akcemi jako většinou místními, kdy uživatel zasahuje do svého vlastního stavu a úzkého vzoru sdíleného stavu, který je skutečně nezbytný, a sdílený vzor je strukturován tak, aby nenutil nesouvisející uživatele soutěžit, což je důvod, proč separace podle uživatelů není jen šikovný organizační trik, je to strategie propustnosti, a separace podle trhu není jen čistou architektonickou volbou, je to rozdíl mezi jedním aktivním trhem, který všechno stahuje dolů, a více trhy, které plynou nezávisle.
Skrytá past je, že vývojáři často zapisují sdílený stav, protože chtějí okamžitou globální pravdu, jako jsou celkové poplatky, celkové objemy, sledovače aktivit, globální žebříčky nebo metriky protokolu, a problém není v tom, že tyto metriky jsou špatné, problém je, že když je aktualizujete ve stejné transakci jako každá uživatelská akce, injektujete sdílený zápis do každé cesty, takže každá cesta nyní konfliktuje, a najednou jste uvnitř paralelního runtime vytvořili sekvenční aplikaci, a nezáleží na tom, jak rychlý Fogo je, protože váš vlastní design nutí řetězec zacházet s nezávislou prací jako závislou.
Co paralelní provádění mění, v velmi praktickém smyslu, je, že tvůrci jsou tlačeni oddělit správný stav od stavu reportování a jsou tlačeni aktualizovat stav reportování na jiném rytmu, nebo jej zapisovat do shardovaných segmentů, nebo ho odvozovat z událostních stop, protože jakmile přestanete nutit každou transakci zapisovat do stejného reportovacího účtu, může runtime konečně naplánovat skutečnou paralelní práci, a aplikace začne působit, jako by patřila na řetězec SVM místo toho, aby na něm pouze běžela.
To se stává ještě viditelnějším v aplikacích stylu obchodování, což je místo, kde postoj Fogo činí diskusi pocitově zakotvenou, protože obchodování soustřeďuje aktivitu, a soustředění vytváří soutěž, a soutěž je nepřítelem paralelního provádění, takže pokud je obchodní systém navržen kolem jednoho centrálního stavu objednávkového listu, který musí být změněn pro každou interakci, řetězec tyto interakce serializuje bez ohledu na to, jak rychle jsou bloky, a uživatelská zkušenost se zhorší přesně v tom okamžiku, kdy je to nejdůležitější, což je důvod, proč jsou tvůrci nuceni do obtížnějších, ale lepších návrhů, kde jsou nejžhavější komponenty minimalizovány, kde je stav rozdělen, kde jsou cesty vyrovnání zúženy a kde jsou části, které není třeba měnit při každé akci, odstraněny z kritické cesty.
Stejná logika se objevuje v aplikacích v reálném čase, u kterých lidé předpokládají, že budou snadné na rychlém řetězci, jako jsou interaktivní systémy, které se často aktualizují, protože naivní přístup je udržovat jediný světový stav a neustále jej měnit, ale na @Fogo Official se to stává zaručeným místem kolize, protože každý účastník se snaží dotknout stejného zapisovatelného objektu, takže lepší přístup je izolovat stav podle účastníka, lokalizovat sdílené zóny místo jejich globalizace a zacházet se globálními agregáty jako s něčím, co je aktualizováno kontrolovanějším způsobem, protože v okamžiku, kdy přestanete způsobovat, aby každá akce zapisovala do stejného sdíleného objektu, může se doba běhu začít provádět mnoho akcí společně, a to je místo, kde se vnímaná rychlost stává skutečnou.
V logice vysokofrekvenčního stylu, což je místo, kde jsou řetězce s nízkou latencí často přísně hodnoceny, dělá paralelní provádění designové chyby nemožné skrýt, protože když mnoho aktérů rychle podává akce, jakýkoli sdílený zapisovatelný stav se stává bojištěm, a místo toho, abyste vybudovali systém, kde mnohé toky postupují nezávisle, vybudujete systém, kde všichni závodí o stejný zámek, a výsledek není jen pomalejší aplikace, je to jiná tržní dynamika, protože pořadí je dominováno soutěží spíše než strategií, což je důvod, proč nejlepší návrhy mají tendenci izolovat zápisy, snižovat sdílenou mutaci a zacházet s kontested komponenty jako úzkými a záměrnými spíše než širokými a náhodnými.
Aplikace s těžkými daty ukazují stejný vzor tišším způsobem, protože většina spotřebitelů dat potřebuje pouze číst, a čtení nejsou problém, ale když spotřebitelské toky začnou zapisovat sdílená data pro pohodlí, jako je razítkování hodnot do globálních účtů nebo aktualizace sdílených cache, otravují paralelismus bez skutečného zisku, a lepší přístup je nechat spotřebitele číst sdílená data a zapisovat pouze svá vlastní rozhodnutí, protože jakmile udržíte sdílené zápisy omezené na vyhrazené aktualizační toky, chráníte konkurenci pro všechny ostatní.
Vyvážení, které Fogo implicitně žádá vývojáře, aby přijali, je, že architektura přátelská k paralelnímu provádění není zdarma, protože jakmile rozdělíte stav a oddělíte účty, spravujete více komponent, uvažujete o více hranách a vybudujete systémy, kde je konkurence skutečná, nikoli teoretická, což znamená, že testování musí být přísnější, cesty upgradu musí být opatrnější a pozorovatelnost musí být lepší, ale odměnou je, že aplikace může škálovat způsobem, jakým je runtime SVM navržen na podporu, kde nezávislé akce skutečně postupují společně, místo aby čekaly za globálním úzkým hrdlem.
Chyba, která ničí většinu paralelní výhody, není pokročilá chyba, je to jednoduchá, a to je vytvoření jediné sdílené zapisovatelné účtu, kterého se dotýká každá transakce, a na řetězci jako Fogo je tato chyba obzvláště nákladná, protože čím rychlejší řetězec je, tím viditelnější je, že váš vlastní design je omezující, a tato viditelnost není selháním řetězce, je to řetězec, který odhaluje, co architektura skutečně je.
Fogo v tomto kontextu je to, že činí konverzaci s tvůrci upřímnější, protože nestačí říci, že řetězec je rychlý, model řetězce nutí vývojáře dokázat, že si zaslouží tuto rychlost, a důkaz je v tom, jak je stav tvarován, rozdělen a přístupný, což je důvod, proč paralelní provádění není marketingový detail, je to disciplína, která mění způsob, jakým jsou aplikace stavěny, a také proč L1 založený na SVM jako Fogo není jednoduše rychlejší, je to náročnější, protože žádá vývojáře, aby navrhli s ohledem na konflikt, aby zacházeli se stavem jako s plochou pro konkurenci a aby budovali systémy, které respektují myšlenku, že výkon je stejně důležitý jako uspořádání, jak je to o době běhu.
