Pozdrav, stanovnici Khabrovsk. Kao i obično, nastavljamo dijeliti zanimljive materijale uoči početka novih tečajeva. Danas smo, posebno za vas, objavili članak o Google Cloud Spanneru koji se podudara s pokretanjem tečaja .
Izvorno objavljeno u .
Kao tvrtka koja nudi razna POS rješenja temeljena na oblaku trgovcima, ugostiteljima i online prodavačima diljem svijeta, Lightspeed koristi nekoliko različitih vrsta platformi baza podataka za različite transakcijske, analitičke i pretraživačke slučajeve. Svaka od ovih platformi baze podataka ima svoje snage i slabosti. Stoga, kada je Google predstavio Cloud Spanner na tržištu - obećavajuće značajke neviđene u svijetu relacijskih baza podataka, kao što je praktički neograničena horizontalna skalabilnost i 99,999% ugovor o razini usluge (SLA), — nismo mogli propustiti priliku da ga se dočepamo!
Kako bismo pružili sveobuhvatan pregled našeg iskustva s Cloud Spannerom, kao i kriterije ocjenjivanja koje smo koristili, obradit ćemo sljedeće teme:
- Naši kriteriji ocjenjivanja
- Cloud Spanner ukratko
- Naša procjena
- Naši nalazi
1. Naši kriteriji ocjenjivanja
Prije nego što uđemo u specifičnosti Cloud Spannera, njegove sličnosti i razlike s drugim rješenjima na tržištu, razgovarajmo o glavnim slučajevima upotrebe koje smo imali na umu kada smo razmatrali gdje implementirati Cloud Spanner u našoj infrastrukturi:
- Kao zamjena za (pretežno) tradicionalno rješenje SQL baze podataka
- Kako do OLTP rješenja s OLAP podrškom
Napomena: Radi jednostavnosti i lakše usporedbe, ovaj članak uspoređuje Cloud Spanner s MySQL varijantama obitelji rješenja GCP Cloud SQL i Amazon AWS RDS.
Korištenje Cloud Spannera kao zamjene za tradicionalno rješenje SQL baze podataka
U okruženju tradicionalni baze podataka, kada se vrijeme odgovora na upit baze podataka približi ili čak premaši unaprijed definirane pragove aplikacije (uglavnom zbog povećanja broja korisnika i/ili zahtjeva), postoji nekoliko načina za smanjenje vremena odgovora na prihvatljivu razinu. Međutim, većina tih rješenja uključuje ručnu intervenciju.
Na primjer, prvi korak koji treba poduzeti jest pogledati različite parametre baze podataka koji se odnose na performanse i prilagoditi ih kako bi najbolje odgovarali uzorcima upotrebe aplikacije. Ako to nije dovoljno, možete odabrati okomito ili vodoravno skaliranje baze podataka.
Vertikalno skaliranje aplikacije podrazumijeva nadogradnju instance poslužitelja, obično dodavanjem više procesora/jezgri, više RAM-a, bržom pohranom itd. Dodavanje više hardverskih resursa rezultira povećanjem performansi baze podataka, mjereno primarno u transakcijama u sekundi, i kašnjenju transakcija za OLTP sustave. Sustavi relacijskih baza podataka (koji koriste višenitni pristup) kao što je MySQL dobro se vertikalno skaliraju.
Postoji nekoliko nedostataka ovog pristupa, ali najočitiji je najveća veličina poslužitelja na tržištu. Nakon što se dosegne ograničenje najveće instance poslužitelja, preostaje samo jedna opcija: horizontalno skaliranje.
Horizontalno skaliranje je pristup pri kojem se klasteru dodaje više poslužitelja, idealno povećavajući performanse linearno kako se dodaje broj poslužitelja. Većina tradicionalni Sustavi baza podataka ne skaliraju se horizontalno dobro ili se uopće ne skaliraju. Na primjer, MySQL može horizontalno skalirati za operacije čitanja dodavanjem pomoćnih čitača, ali ne može horizontalno skalirati za pisanje.
S druge strane, zbog svoje prirode, Cloud Spanner može lako vodoravno skalirati uz minimalnu intervenciju.
Potpuno opremljen DBMS kao usluga treba procijeniti iz različitih kutova. Kao osnovu uzeli smo najpopularniji DBMS u oblaku - za Google, GCP Cloud SQL i za Amazon, AWS RDS. U našoj smo se procjeni usredotočili na sljedeće kategorije:
- Mapiranje značajki: opseg SQL, DDL, DML; biblioteke povezivanja/konektori, podrška za transakcije i tako dalje.
- Razvojna podrška: jednostavan razvoj i testiranje.
- Administrativna podrška: upravljanje instancama - na primjer, povećanje/smanjenje i nadogradnja instanci; SLA, backup i oporavak; sigurnost/kontrola pristupa.
Korištenje Cloud Spannera kao OLTP rješenja omogućenog za OLAP
Iako Google izričito ne tvrdi da je Cloud Spanner dizajniran za analitičku obradu, on dijeli neke atribute s drugim motorima kao što su Apache Impala & Kudu i YugaByte, koji su dizajnirani za OLAP radna opterećenja.
Čak i ako postoji samo mala vjerojatnost da Cloud Spanner uključuje konzistentan skalirani HTAP (hibridnu transakcijsku/analitičku obradu) mehanizam s (manje-više) upotrebljivim skupom OLAP značajki, mislimo da bi bio vrijedan naše pažnje.
Imajući to na umu, pogledali smo sljedeće kategorije:
- Podrška za učitavanje podataka, indekse i particioniranje
- Izvedba upita i DML
2. Cloud Spanner ukratko
Google Spanner je klasterirani sustav upravljanja relacijskom bazom podataka (RDBMS) koji Google koristi za nekoliko svojih usluga. Google ga je učinio općenito dostupnim korisnicima Google Cloud Platforme početkom 2017.
Evo nekih atributa Cloud Spannera:
- Visoko konzistentan skalabilni RDBMS klaster: koristi hardversku vremensku sinkronizaciju kako bi se osigurala konzistentnost podataka.
- Podrška za transakcije između tablica: Transakcije mogu obuhvatiti više tablica - nisu nužno ograničene na jednu tablicu (za razliku od Apache HBase ili Apache Kudu).
- Tablice temeljene na primarnom ključu: Sve tablice moraju imati deklarirani primarni ključ (PC), koji se može sastojati od više stupaca u tablici. Tablični podaci pohranjuju se u redoslijedu na računalu, što ga čini vrlo učinkovitim i brzim za pretraživanje na računalu. Poput drugih sustava temeljenih na osobnom računalu, implementacija se mora modelirati s unaprijed dizajniranim slučajevima upotrebe na umu da bi se postigla .
- Prugasti stolovi: stolovi mogu imati fizičke ovisnosti jedni o drugima. Redovi u podređenoj tablici mogu se usporediti s redovima u nadređenoj tablici. Ovaj pristup ubrzava traženje odnosa koji se mogu identificirati tijekom faze modeliranja podataka, kao što je zajedničko lociranje kupaca i njihovih faktura.
- Indeksi: Cloud Spanner podržava sekundarne indekse. Indeks se sastoji od indeksiranih stupaca i svih PC stupaca. Po želji, indeks može sadržavati i druge neindeksirane stupce. Indeks se može ispreplesti s nadređenom tablicom kako bi se ubrzali upiti. Na indekse se primjenjuje nekoliko ograničenja, kao što je maksimalan broj dodatnih stupaca pohranjenih u indeksu. Također, upiti kroz indekse možda neće biti tako jednostavni kao u drugim RDBMS-ovima.
“Cloud Spanner automatski odabire indeks samo u rijetkim slučajevima. Konkretno, Cloud Spanner ne odabire automatski sekundarni indeks ako upit zahtijeva stupce koji nisu pohranjeni u ".
- Ugovor o razini usluge (SLA): implementacija u jednoj regiji sa SLA od 99,99%; višeregionalne implementacije s 99,999% SLA. Iako je SLA sam po sebi samo sporazum, a ne jamstvo bilo koje vrste, vjerujem da ljudi u Googleu imaju neke čvrste podatke za tako jaku tvrdnju. (Za referencu, 99,999% znači 26,3 sekunde nedostupnosti usluge mjesečno.)
- više:
Napomena: Projekt Apache Tephra dodaje poboljšanu podršku za transakcije u Apache HBase (također sada implementiran u Apache Phoenix kao beta).
3. Naša procjena
Dakle, svi smo čitali Googleove tvrdnje o prednostima Cloud Spannera - gotovo neograničeno horizontalno skaliranje uz održavanje visoke dosljednosti i vrlo visokog SLA. Iako su ovi zahtjevi u svakom slučaju izuzetno teško ostvarivi, naš cilj nije bio da ih pobijemo. Umjesto toga, usredotočimo se na druge stvari do kojih je većina korisnika baze podataka stalo: paritet i upotrebljivost.
Procijenili smo Cloud Spanner kao zamjenu za Sharded MySQL
Google Cloud SQL i Amazon AWS RDS, dva najpopularnija OLTP DBMS-a na tržištu oblaka, imaju vrlo velik skup značajki. Međutim, da skalirate ove baze podataka iznad veličine jednog čvora, morate izvršiti particioniranje aplikacije. Ovaj pristup stvara dodatnu složenost za aplikacije i administraciju. Pogledali smo kako se Spanner uklapa u scenarij kombiniranja višestrukih fragmenata u jednu instancu i koje značajke (ako ih ima) treba žrtvovati.
Podrška za SQL, DML i DDL, kao i konektor i biblioteke?
Prvo, kada počinjete s bilo kojom bazom podataka, morate stvoriti podatkovni model. Ako mislite da možete povezati JDBC Spanner sa svojim omiljenim SQL alatom, otkrit ćete da možete postavljati upite svojim podacima s njim, ali ga ne možete koristiti za stvaranje tablice ili modificiranje (DDL) ili bilo kakvo umetanje/ažuriranje/brisanje operacije (DML). Googleov službeni JDBC ne podržava ni jedno od toga.
"Upravljački programi trenutno ne podržavaju DML ili DDL izjave."
Spanner dokumentacija
Ništa bolja situacija nije ni s GCP konzolom - možete slati samo SELECT upite. Srećom, postoji JDBC upravljački program s podrškom za DML i DDL iz zajednice, uključujući transakcije . Iako je ovaj upravljački program izuzetno koristan, iznenađuje nedostatak Googleovog JDBC upravljačkog programa. Srećom, Google nudi prilično široku podršku za klijentske biblioteke (temeljene na gRPC): C#, Go, Java, node.js, PHP, Python i Ruby.
Gotovo obavezna upotreba prilagođenih API-ja Cloud Spanner (zbog nedostatka DDL-a i DML-a u JDBC-u) rezultira nekim ograničenjima za povezana područja koda kao što su skupovi veza ili okviri za vezanje baze podataka (npr. Spring MVC). Obično, kada koristite JDBC, slobodni ste odabrati svoj omiljeni skup veza (npr. HikariCP, DBCP, C3PO, itd.) koji je testiran i dobro radi. U slučaju prilagođenih Spanner API-ja, moramo se osloniti na okvire/poolove/sesije koje smo sami izradili.
Dizajn usmjeren na primarni ključ (PC) omogućuje Cloud Spanneru da bude vrlo brz pri pristupu podacima putem računala, ali također uvodi neke probleme s upitima.
- Ne možete ažurirati vrijednost primarnog ključa; Prvo morate izbrisati unos s izvornog računala i ponovno ga umetnuti s novom vrijednošću. (Ovo je slično drugim PC-orijentiranim motorima baze podataka/pohrane.)
- Sve izjave UPDATE i DELETE moraju navesti PC u WHERE, stoga ne mogu biti prazne DELETE sve izjave - uvijek mora postojati podupit, na primjer: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Nedostatak opcije automatskog povećanja ili bilo čega sličnog što postavlja slijed za PC polje. Da bi ovo radilo, odgovarajuća vrijednost mora biti kreirana na strani aplikacije.
Sekundarni indeksi?
Google Cloud Spanner ima ugrađenu podršku za sekundarne indekse. Ovo je vrlo zgodna značajka koja nije uvijek prisutna u drugim tehnologijama. Apache Kudu trenutačno uopće ne podržava sekundarne indekse, a Apache HBase ne podržava izravno indekse, ali ih može dodati putem Apache Phoenixa.
Indeksi u Kudu i HBase mogu se modelirati kao zasebne tablice s drugačijim sastavom primarnih ključeva, ali atomičnost operacija izvedenih na nadređenoj tablici i pridruženim tablicama indeksa mora se izvršiti na razini aplikacije i nije trivijalno za ispravnu implementaciju.
Kao što je spomenuto u recenziji Cloud Spannera, njegovi se indeksi mogu razlikovati od MySQL indeksa. Stoga treba posvetiti posebnu pozornost prilikom izrade upita i profiliranja kako bi se osiguralo korištenje odgovarajućeg indeksa tamo gdje je to potrebno.
Reprezentacija?
Vrlo popularan i koristan objekt u bazi podataka su pogledi. Mogu biti korisni za veliki broj slučajeva upotrebe; moja dva favorita su sloj logičke apstrakcije i sigurnosni sloj. Nažalost, Cloud Spanner NE podržava prikaze. Međutim, to nas samo djelomično ograničava jer ne postoji granularnost za dozvole pristupa na razini stupca gdje bi prikazi mogli biti održivo rješenje.
Pogledajte dokumentaciju Cloud Spannera za odjeljak s pojedinostima o kvotama i ograničenjima (), posebno postoji jedna koja može biti problematična za neke aplikacije: Cloud Spanner izvan kutije ima ograničenje od najviše 100 baza podataka po instanci. Očito, ovo može biti veliko usko grlo za bazu podataka koja je dizajnirana za skaliranje na više od 100 baza podataka. Srećom, nakon razgovora s našim tehničkim predstavnikom Googlea, saznali smo da se to ograničenje može povećati na gotovo bilo koju vrijednost putem Google podrške.
Razvojna podrška?
Cloud Spanner nudi prilično pristojnu podršku za programski jezik za rad sa svojim API-jem. Službeno podržane biblioteke su u područjima C#, Go, Java, node.js, PHP, Python i Ruby. Dokumentacija je prilično detaljna, ali kao i kod drugih naprednih tehnologija, zajednica je prilično mala u usporedbi s najpopularnijim tehnologijama baza podataka, što može dovesti do više vremena provedenog u rješavanju manje uobičajenih slučajeva ili problema.
Pa što je s potporom lokalnom razvoju?
Nismo pronašli način za stvaranje instance Cloud Spannera na lokaciji. Najbliža stvar koju smo dobili bila je Docker slika. , što je u načelu slično, ali u praksi vrlo različito. Na primjer, CockroachDB može koristiti PostgreSQL JDBC. Budući da razvojno okruženje treba biti što bliže proizvodnom okruženju, Cloud Spanner nije idealan jer se mora oslanjati na punu instancu Spanner-a. Kako biste uštedjeli troškove, možete odabrati instancu jedne regije.
Podrška administracije?
Stvaranje instance Cloud Spannera vrlo je jednostavno. Vi samo trebate odabrati između stvaranja instance s više regija ili jedne regije, odrediti regiju(e) i broj čvorova. Za manje od minute vaša će instanca biti spremna za rad.
Nekoliko rudimentarnih mjernih podataka izravno je dostupno sa stranice Spanner na Google konzoli. Detaljniji prikazi dostupni su putem Stackdrivera, gdje također možete postaviti metričke pragove i pravila upozorenja.
Pristup resursima?
MySQL nudi opsežne i vrlo detaljne postavke za korisnička dopuštenja/uloge. Možete jednostavno konfigurirati pristup određenoj tablici ili čak samo podskupu njezinih stupaca. Cloud Spanner koristi Googleov alat za upravljanje identitetom i pristupom (IAM), koji vam omogućuje samo postavljanje pravila i dopuštenja na vrlo visokoj razini. Najdetaljnija opcija je razlučivost na razini baze podataka, koja se ne uklapa u većinu slučajeva proizvodne upotrebe. Ovo ograničenje vas prisiljava da dodate dodatne sigurnosne mjere svom kodu, infrastrukturi ili oboje kako biste spriječili neovlaštenu upotrebu resursa Spannera.
Sigurnosne kopije?
Jednostavno rečeno, u Cloud Spanneru nema sigurnosnih kopija. Iako Googleovi visoki SLA zahtjevi mogu osigurati da ne izgubite podatke zbog kvarova hardvera ili baze podataka, ljudskih pogrešaka, nedostataka aplikacija itd. Svi znamo pravilo: visoka dostupnost nije zamjena za dobru strategiju sigurnosnog kopiranja. Trenutačno je jedini način sigurnosnog kopiranja podataka njihovo programsko prenošenje iz baze podataka u zasebno okruženje za pohranu.
Izvedba upita?
Koristili smo Yahoo! za učitavanje podataka i testiranje upita. Referentna vrijednost posluživanja u oblaku. Donja tablica prikazuje YCSB radno opterećenje B s omjerom čitanja od 95% prema 5% pisanja.
* Test opterećenja proveden je na n1-standard-32 Compute Engine (CE) (32 vCPU-a, 120 GB memorije), a testna instanca nikada nije bila usko grlo u testovima.
** Maksimalni broj niti u jednoj YCSB instanci je 400. Moralo se pokrenuti ukupno šest paralelnih instanci YCSB testova da bi se dobilo ukupno 2400 niti.
Gledajući rezultate benchmarka, posebice kombinaciju CPU opterećenja i TPS-a, možemo jasno vidjeti da se Cloud Spanner prilično dobro mjeri. Veliko opterećenje koje stvara veliki broj niti nadoknađuje veliki broj čvorova u klasteru Cloud Spanner. Iako se latencija čini prilično visokom, posebno kada se izvodi s 2400 niti, ponovno testiranje sa 6 manjih instanci računalnog mehanizma može biti potrebno kako bi se dobili točniji brojevi. Svaka će instanca pokrenuti jedan YCSB test umjesto jedne velike CE instance sa 6 paralelnih testova. Na taj će način biti lakše razlikovati kašnjenje zahtjeva Cloud Spannera od kašnjenja koje je dodala mrežna veza između Cloud Spannera i CE instance koja izvodi test.
Kako Cloud Spanner radi kao OLAP?
Particioniranje?
Dijeljenje podataka u fizički i/ili logički neovisne segmente, zvane particije, vrlo je popularan koncept koji se nalazi u većini OLAP motora. Particije mogu značajno poboljšati izvedbu upita i mogućnost održavanja baze podataka. Ići dublje u particioniranje bio bi poseban članak(i), pa spomenimo samo važnost postojanja sheme particioniranja i podparticioniranja. Sposobnost raščlanjivanja podataka na particije i još dalje na podparticije ključna je za izvedbu analitičkih upita.
Cloud Spanner ne podržava particije kao takve. Podatke interno dijeli na tzv Split-s na temelju raspona primarnog ključa. Particioniranje se izvodi automatski kako bi se uravnotežilo opterećenje u klasteru Cloud Spanner. Vrlo korisna značajka Cloud Spannera je dijeljenje osnovnog opterećenja nadređene tablice (tablica koja nije isprepletena s drugom). Spanner automatski otkriva sadrži li Split podaci koji se čitaju češće nego podaci u drugima Split-ah, i može odlučiti o daljnjem razdvajanju. Na ovaj način, više čvorova može biti uključeno u zahtjev, što također učinkovito povećava propusnost.
Učitavanje podataka?
Metoda Cloud Spanner za skupne podatke ista je kao i za normalno učitavanje. Da biste postigli maksimalnu učinkovitost, morate slijediti neke smjernice, uključujući:
- Razvrstajte podatke po primarnom ključu.
- Podijelite ih s 10*broj čvorova odvojene sekcije.
- Napravite skup radnih zadataka koji paralelno učitavaju podatke.
Ovo učitavanje podataka koristi sve čvorove Cloud Spannera.
Koristili smo YCSB radno opterećenje A za generiranje skupa podataka od 10 milijuna redaka.
* Test opterećenja proveden je na n1-standard-32 compute engineu (32 vCPU-a, 120 GB memorije), a testna instanca nikada nije bila usko grlo u testovima.
**Postavljanje jednog čvora ne preporučuje se za bilo kakvo radno opterećenje proizvodnje.
Kao što je gore spomenuto, Cloud Spanner automatski obrađuje podjele na temelju njihovog opterećenja, tako da se rezultati poboljšavaju nakon nekoliko uzastopnih ponavljanja testa. Ovdje predstavljeni rezultati najbolji su rezultati koje smo dobili. Gledajući gornje brojke, možemo vidjeti kako se Cloud Spanner skalira (dobro) kako se broj čvorova u klasteru povećava. Brojevi koji se ističu su izuzetno niske prosječne latencije, koje su u suprotnosti s rezultatima za mješovita radna opterećenja (95% čitanja i 5% pisanja) kao što je opisano u gornjem odjeljku.
Skaliranje?
Povećanje i smanjenje broja Cloud Spanner čvorova zadatak je jednim klikom. Ako želite brzo učitati podatke, razmislite o povećanju svoje instance do maksimuma (u našem slučaju to je bilo 25 čvorova u US-EAST regiji), a zatim smanjite broj čvorova koji ispunjavaju uvjete za vaše normalno učitavanje kada svi podaci budu u bazu podataka, pozivajući se na ograničenje od 2TB/čvoru.
Podsjetili smo se na to ograničenje čak i s puno manjom bazom podataka. Nakon nekoliko pokretanja testova opterećenja, naša je baza podataka bila velika oko 155 GB, a kada je smanjena na instancu od 1 čvora, primili smo sljedeću pogrešku:
Uspjeli smo smanjiti s 25 na 2 instance, ali smo zapeli na dva čvora.
Povećanje i smanjenje broja čvorova u klasteru Cloud Spannera može se automatizirati pomoću REST API-ja. Ovo može biti posebno korisno za smanjenje povećanog opterećenja sustava tijekom radnog vremena.
Izvedba OLAP upita?
Prvotno smo planirali potrošiti dosta vremena na našu procjenu Spannera na ovaj dio. Nakon nekoliko SELECT COUNT-ova, odmah smo shvatili da će testiranje biti kratko i da Spanner NEĆE biti prikladan mehanizam za OLAP. Bez obzira na broj čvorova u klasteru, jednostavno odabiranje broja redaka u tablici redaka od 10 milijuna trajalo je između 55 i 60 sekundi. Osim toga, svaki upit koji je zahtijevao više memorije za pohranjivanje međurezultata nije uspio s OOM pogreškom.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Neki brojevi za TPC-H upite mogu se pronaći u članku Todda Lipcona , slajdovi 42 i 43. Ovi brojevi su u skladu s našim vlastitim rezultatima (nažalost).
4. Naši zaključci
S obzirom na trenutno stanje značajki Cloud Spannera, teško je zamisliti da je to jednostavna zamjena za vaše postojeće OLTP rješenje, pogotovo kada ga vaše potrebe prerastu. Značajnu količinu vremena moralo bi se potrošiti na izgradnju rješenja oko nedostataka Cloud Spannera.
Kada smo počeli ocjenjivati Cloud Spanner, očekivali smo da će njegove značajke upravljanja biti jednake, ili barem ne previše udaljene od drugih Google SQL rješenja. Ali bili smo iznenađeni potpunim nedostatkom sigurnosnih kopija i vrlo ograničenom kontrolom nad pristupom resursima. Da ne spominjemo da nema pogleda, nema lokalnog razvojnog okruženja, nepodržane sekvence, JDBC bez DML i DDL podrške, i tako dalje.
Gdje ide netko tko treba skalirati transakcijsku bazu podataka? Čini se da ne postoji niti jedno rješenje na tržištu koje odgovara svim slučajevima upotrebe. Postoji mnogo rješenja zatvorenog i otvorenog koda (od kojih su neka spomenuta u ovom članku), svako sa svojim prednostima i slabostima, ali nijedno od njih ne nudi SaaS s 99,999% SLA i visokom dosljednošću. Ako je vaš glavni cilj visoki SLA i niste skloni izradi prilagođenog multi-cloud rješenja, Cloud Spanner može biti rješenje koje tražite. Ali trebali biste biti svjesni svih njegovih ograničenja.
Da budemo pošteni, Cloud Spanner je pušten u javnost tek u proljeće 2017., pa je razumno očekivati da bi neki od njegovih trenutnih nedostataka mogli s vremenom nestati (nadajmo se), a kada se to dogodi, mogao bi promijeniti igru. Na kraju krajeva, Cloud Spanner nije samo usporedni projekt za Google. Google ga koristi kao osnovu za druge Google proizvode. A kada je Google nedavno zamijenio Megastore u Google Cloud Storageu s Cloud Spannerom, omogućio je Google Cloud Storageu da postane vrlo konzistentan za popise objekata na globalnoj razini (što još uvijek nije slučaj za ).
Dakle, još ima nade... nadamo se.
To je sve. Kao i autor članka, i mi se nastavljamo nadati, ali što vi mislite o ovome? Pišite u komentarima
Pozivamo sve da nas posjete u sklopu koje ćemo vam detaljno ispričati tečaj od OTUS-a.
Izvor: www.habr.com