Bună ziua, locuitorii din Khabrovsk. Ca de obicei, continuăm să împărtășim materiale interesante înainte de începerea noilor cursuri. Astăzi, special pentru tine, am publicat un articol despre Google Cloud Spanner, pentru a coincide cu lansarea cursului .
Publicat inițial în .
Fiind o companie care oferă o varietate de soluții POS bazate pe cloud retailerilor, restauratorilor și vânzătorilor online din întreaga lume, Lightspeed utilizează mai multe tipuri diferite de platforme de baze de date pentru o varietate de cazuri de utilizare tranzacționale, analitice și de căutare. Fiecare dintre aceste platforme de baze de date are propriile puncte forte și puncte slabe. Prin urmare, atunci când Google a introdus pe piață Cloud Spanner - caracteristici promițătoare nevăzute în lumea bazelor de date relaționale, cum ar fi scalabilitate orizontală practic nelimitată și un acord de nivel de servicii (SLA) de 99,999 %, — nu puteam rata ocazia de a pune mâna pe ea!
Pentru a oferi o privire de ansamblu asupra experienței noastre cu Cloud Spanner, precum și a criteriilor de evaluare pe care le-am folosit, vom acoperi următoarele subiecte:
- Criteriile noastre de evaluare
- Cloud Spanner pe scurt
- Evaluarea noastră
- Descoperirile noastre
1. Criteriile noastre de evaluare
Înainte de a aborda specificul Cloud Spanner, asemănările și diferențele sale cu alte soluții de pe piață, să vorbim mai întâi despre principalele cazuri de utilizare pe care le-am avut în vedere când ne gândim unde să implementăm Cloud Spanner în infrastructura noastră:
- Ca înlocuitor pentru soluția tradițională de baze de date SQL (predominante).
- Cum să OLTP soluție cu suport OLAP
Nota: Pentru simplitate și ușurință în comparație, acest articol compară Cloud Spanner cu variantele MySQL ale familiilor de soluții GCP Cloud SQL și Amazon AWS RDS.
Folosind Cloud Spanner ca înlocuitor pentru o soluție tradițională de baze de date SQL
În mediu tradițional baze de date, atunci când timpul de răspuns la interogarea bazei de date se apropie sau chiar depășește pragurile predefinite ale aplicației (în principal datorită creșterii numărului de utilizatori și/sau solicitări), există mai multe modalități de a reduce timpul de răspuns la niveluri acceptabile. Cu toate acestea, majoritatea acestor soluții implică intervenție manuală.
De exemplu, primul pas de făcut este să priviți diferiții parametri ai bazei de date legați de performanță și să-i reglați pentru a se potrivi cel mai bine cu modelele de cazuri de utilizare ale aplicației. Dacă acest lucru nu este suficient, puteți alege să scalați baza de date vertical sau orizontal.
Scalarea verticală a unei aplicații implică actualizarea instanței serverului, de obicei prin adăugarea mai multor procesoare/nuclee, mai multă RAM, stocare mai rapidă etc. Adăugarea mai multor resurse hardware are ca rezultat creșterea performanței bazei de date, măsurată în primul rând în tranzacții în secundă și latența tranzacțiilor pentru sistemele OLTP. Sistemele de baze de date relaționale (care folosesc o abordare multi-threaded), cum ar fi MySQL, se scalează bine pe verticală.
Există mai multe dezavantaje ale acestei abordări, dar cel mai evident este dimensiunea maximă a serverului de pe piață. Odată atinsă limita celei mai mari instanțe de server, mai rămâne o singură opțiune: scalarea orizontală.
Scalare orizontală este o abordare în care se adaugă mai multe servere la un cluster, în mod ideal crescând performanța liniar pe măsură ce se adaugă numărul de servere. Majoritate tradițional Sistemele de baze de date nu se scalează bine orizontal sau nu se scalează deloc. De exemplu, MySQL poate scala orizontal pentru operațiuni de citire adăugând cititoare slave, dar nu poate scala orizontal pentru scrieri.
Pe de altă parte, datorită naturii sale, Cloud Spanner poate scala cu ușurință orizontal cu o intervenție minimă.
Complet cu caracteristici DBMS ca serviciu trebuie evaluat din diferite unghiuri. Ca bază, am luat cel mai popular DBMS din cloud - pentru Google, GCP Cloud SQL și pentru Amazon, AWS RDS. În evaluarea noastră ne-am concentrat pe următoarele categorii:
- Maparea caracteristicilor: extent SQL, DDL, DML; biblioteci de conexiune/conectori, suport pentru tranzacții și așa mai departe.
- Suport pentru dezvoltare: dezvoltare și testare ușoară.
- Suport administrativ: managementul instanțelor - de exemplu, creșterea/descărcarea și actualizarea instanțelor; SLA, backup și recuperare; securitate/control acces.
Folosind Cloud Spanner ca soluție OLTP activată pentru OLAP
Deși Google nu susține în mod explicit că Cloud Spanner este conceput pentru procesare analitică, împărtășește unele atribute cu alte motoare, cum ar fi Apache Impala & Kudu și YugaByte, care sunt concepute pentru sarcinile de lucru OLAP.
Chiar dacă a existat doar o mică șansă ca Cloud Spanner să includă un motor HTAP (procesare hibridă tranzacțională/analitică) cu un set de caracteristici OLAP (mai mult sau mai puțin) utilizabil, credem că ar merita atenția noastră.
Având în vedere acest lucru, am analizat următoarele categorii:
- Suport pentru încărcarea datelor, indexuri și partiționare
- Performanța interogărilor și DML
2. Cloud Spanner pe scurt
Google Spanner este un sistem de gestionare a bazelor de date relaționale în cluster (RDBMS) pe care Google îl utilizează pentru mai multe dintre propriile sale servicii. Google l-a pus la dispoziție în general pentru utilizatorii Google Cloud Platform la începutul anului 2017.
Iată câteva dintre atributele Cloud Spanner:
- Cluster scalabil RDBMS extrem de consistent: folosește sincronizarea de timp hardware pentru a asigura coerența datelor.
- Suport pentru tranzacții încrucișate: Tranzacțiile se pot întinde pe mai multe tabele - nu neapărat limitate la un singur tabel (spre deosebire de Apache HBase sau Apache Kudu).
- Tabelele bazate pe chei primare: toate tabelele trebuie să aibă o cheie primară (PC) declarată, care poate consta din mai multe coloane din tabel. Datele tabelare sunt stocate în ordinea PC-ului, ceea ce face că este foarte eficient și rapid pentru căutarea pe computer. Ca și alte sisteme bazate pe PC, implementarea trebuie să fie modelată ținând cont de cazuri de utilizare pre-proiectate .
- Tabelele cu dungi: Tabelele pot avea dependențe fizice unele de altele. Rândurile dintr-un tabel copil pot fi asociate cu rândurile dintr-un tabel părinte. Această abordare accelerează căutarea relațiilor care pot fi identificate în timpul fazei de modelare a datelor, cum ar fi colocarea clienților și a facturilor acestora.
- Indecși: Cloud Spanner acceptă indecși secundari. Indexul este format din coloanele indexate și toate coloanele PC. Dacă se dorește, indexul poate conține și alte coloane neindexate. Indexul poate fi intercalat cu tabelul părinte pentru a accelera interogările. Mai multe restricții se aplică indicilor, cum ar fi numărul maxim de coloane suplimentare stocate în index. De asemenea, interogările prin indexuri pot să nu fie la fel de simple ca în alte RDBMS-uri.
„Cloud Spanner selectează automat un index numai în cazuri rare. În special, Cloud Spanner nu selectează automat un index secundar dacă o interogare solicită coloane care nu sunt stocate în ".
- Service Level Agreement (SLA): Implementare într-o regiune cu un SLA de 99,99%; implementări multi-regionale cu 99,999% SLA. În timp ce SLA în sine este doar un acord și nu o garanție de niciun fel, cred că oamenii de la Google au niște date solide pentru a face o afirmație atât de puternică. (Pentru referință, 99,999% înseamnă 26,3 secunde de indisponibilitate a serviciului pe lună.)
- Mai mult:
Nota: Proiectul Apache Tephra adaugă suport îmbunătățit pentru tranzacții la Apache HBase (de asemenea, acum implementat în Apache Phoenix ca beta).
3. Evaluarea noastră
Deci, cu toții am citit afirmațiile Google despre beneficiile Cloud Spanner - scalare orizontală practic nelimitată, menținând în același timp o consistență ridicată și un SLA foarte ridicat. Deși aceste cerințe sunt, în orice caz, extrem de greu de realizat, scopul nostru nu a fost să le respingem. În schimb, să ne concentrăm asupra altor lucruri la care pasă majoritatea utilizatorilor bazei de date: paritate și utilizare.
Am evaluat Cloud Spanner ca înlocuitor pentru Sharded MySQL
Google Cloud SQL și Amazon AWS RDS, două dintre cele mai populare SGBD-uri OLTP de pe piața cloud, au un set foarte mare de caracteristici. Cu toate acestea, pentru a scala aceste baze de date dincolo de dimensiunea unui singur nod, trebuie să efectuați partiționarea aplicației. Această abordare creează o complexitate suplimentară atât pentru aplicații, cât și pentru administrare. Am analizat cum se încadrează Spanner în scenariul combinării mai multor fragmente într-o singură instanță și ce caracteristici (dacă există) ar trebui să fie sacrificate.
Suport SQL, DML și DDL, precum și conector și biblioteci?
În primul rând, atunci când începeți cu orice bază de date, trebuie să creați un model de date. Dacă credeți că puteți conecta JDBC Spanner la instrumentul dvs. SQL preferat, veți descoperi că vă puteți interoga datele cu acesta, dar nu îl puteți utiliza pentru a crea un tabel sau modifica (DDL) sau orice inserare/actualizare/ștergere operațiuni (DML). JDBC oficial al Google nu acceptă niciunul dintre acestea.
„Driverele nu acceptă în prezent instrucțiunile DML sau DDL.”
Documentație cheie
Situația nu este mai bună cu consola GCP - puteți trimite doar interogări SELECT. Din fericire, există un driver JDBC cu suport pentru DML și DDL de la comunitate, inclusiv tranzacții . În timp ce acest driver este extrem de util, lipsa propriului driver JDBC al Google este surprinzătoare. Din fericire, Google oferă suport destul de larg pentru bibliotecile client (bazat pe gRPC): C#, Go, Java, node.js, PHP, Python și Ruby.
Utilizarea aproape obligatorie a API-urilor personalizate Cloud Spanner (datorită lipsei DDL și DML în JDBC) are ca rezultat unele limitări pentru zonele de cod asociate, cum ar fi grupurile de conexiuni sau cadrele de legare la baze de date (de exemplu, Spring MVC). De obicei, atunci când utilizați JDBC, sunteți liber să alegeți pool-ul de conexiuni preferat (de exemplu, HikariCP, DBCP, C3PO etc.) care este testat și funcționează bine. În cazul API-urilor Spanner personalizate, trebuie să ne bazăm pe cadre/pool-uri de legare/sesiuni pe care le-am creat noi înșine.
Designul centrat pe cheia primară (PC) permite Cloud Spanner să fie foarte rapid atunci când accesează date prin computer, dar introduce și unele probleme de interogare.
- Nu puteți actualiza valoarea cheii primare; Mai întâi trebuie să ștergeți intrarea de pe computerul original și să o reintroduceți cu noua valoare. (Acest lucru este similar cu alte baze de date/motoare de stocare orientate spre PC.)
- Orice instrucțiuni UPDATE și DELETE trebuie să specifice PC în WHERE, prin urmare nu pot exista instrucțiuni DELETE goale - trebuie să existe întotdeauna o subinterogare, de exemplu: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Lipsa opțiunii de auto-increment sau ceva similar care stabilește secvența pentru câmpul PC. Pentru ca acest lucru să funcționeze, trebuie creată valoarea corespunzătoare din partea aplicației.
Indici secundari?
Google Cloud Spanner are suport încorporat pentru indici secundari. Aceasta este o caracteristică foarte frumoasă care nu este întotdeauna prezentă în alte tehnologii. Apache Kudu nu acceptă deloc indecși secundari, iar Apache HBase nu acceptă indici direct, dar îi poate adăuga prin Apache Phoenix.
Indecii din Kudu și HBase pot fi modelați ca un tabel separat cu o compoziție diferită a cheilor primare, dar atomicitatea operațiilor efectuate pe tabelul părinte și tabelele de index asociate trebuie făcută la nivel de aplicație și nu este trivial de implementat corect.
După cum sa menționat în analiza Cloud Spanner, indecșii săi pot diferi de indecșii MySQL. Prin urmare, ar trebui să se acorde o atenție deosebită la construirea interogărilor și a profilării pentru a se asigura că indexul adecvat este utilizat acolo unde este necesar.
Reprezentare?
Un obiect foarte popular și util într-o bază de date sunt vizualizările. Ele pot fi utile pentru un număr mare de cazuri de utilizare; cele două preferate ale mele sunt stratul de abstractizare logică și stratul de securitate. Din păcate, Cloud Spanner NU acceptă vizualizări. Cu toate acestea, acest lucru ne limitează doar parțial, deoarece nu există o granularitate pentru permisiunile de acces la nivel de coloană, unde vizualizările ar putea fi o soluție viabilă.
Consultați documentația Cloud Spanner pentru o secțiune care detaliază cotele și restricțiile (), există una în special care poate fi problematică pentru unele aplicații: Cloud Spanner din cutie are o limită de maximum 100 de baze de date per instanță. Evident, acesta poate fi un blocaj major pentru o bază de date care este proiectată să se extindă la peste 100 de baze de date. Din fericire, după ce am vorbit cu reprezentantul nostru tehnic Google, am aflat că această limită poate fi mărită la aproape orice valoare prin intermediul Asistenței Google.
Sprijin pentru dezvoltare?
Cloud Spanner oferă suport pentru limbajul de programare destul de decent pentru lucrul cu API-ul său. Bibliotecile acceptate oficial sunt în domeniile C#, Go, Java, node.js, PHP, Python și Ruby. Documentația este destul de detaliată, dar ca și în cazul altor tehnologii avansate, comunitatea este destul de mică în comparație cu cele mai populare tehnologii de baze de date, ceea ce poate duce la mai mult timp petrecut în rezolvarea unor cazuri de utilizare sau probleme mai puțin frecvente.
Deci, ce zici de sprijinirea dezvoltării locale?
Nu am găsit o modalitate de a crea o instanță Cloud Spanner la nivel local. Cel mai apropiat lucru pe care l-am primit a fost o imagine Docker. , care este similar în principiu, dar foarte diferit în practică. De exemplu, CockroachDB poate folosi PostgreSQL JDBC. Deoarece mediul de dezvoltare ar trebui să fie cât mai aproape de mediul de producție, Cloud Spanner nu este ideal, deoarece trebuie să se bazeze pe o instanță Spanner completă. Pentru a economisi costuri, puteți selecta o instanță cu o singură regiune.
Suport administrativ?
Crearea unei instanțe Cloud Spanner este foarte simplă. Trebuie doar să alegeți între crearea unei instanțe cu mai multe regiuni sau cu o singură regiune, să specificați regiunea (regiunile) și numărul de noduri. În mai puțin de un minut, instanța dvs. va fi funcțională.
Mai multe valori rudimentare sunt accesibile direct din pagina Spanner din Consola Google. Vizualizări mai detaliate sunt disponibile prin Stackdriver, unde puteți seta, de asemenea, praguri de valori și politici de alertă.
Acces la resurse?
MySQL oferă setări extinse și foarte granulare pentru permisiunile/rolurile utilizatorului. Puteți configura cu ușurință accesul la un anumit tabel sau chiar doar la un subset al coloanelor acestuia. Cloud Spanner folosește instrumentul Google Identity & Access Management (IAM), care vă permite doar să setați politici și permisiuni la un nivel foarte înalt. Opțiunea cea mai granulară este rezoluția la nivel de bază de date, care nu se încadrează în majoritatea cazurilor de utilizare în producție. Această limitare vă obligă să adăugați măsuri de securitate suplimentare codului, infrastructurii sau ambelor pentru a preveni utilizarea neautorizată a resurselor Spanner.
Backup-uri?
Pentru a spune simplu, nu există copii de rezervă în Cloud Spanner. Deși cerințele ridicate ale SLA ale Google vă pot asigura că nu veți pierde date din cauza defecțiunilor hardware sau a bazei de date, erori umane, defecte ale aplicațiilor etc. Cu toții cunoaștem regula: disponibilitatea ridicată nu înlocuiește o strategie de backup solidă. În prezent, singura modalitate de a face o copie de rezervă a datelor este să le transmiteți în flux programatic dintr-o bază de date într-un mediu de stocare separat.
Interogați performanța?
Am folosit Yahoo! pentru a încărca date și a testa interogări. Benchmark de servire în cloud. Tabelul de mai jos arată volumul de lucru B YCSB cu un raport de citire de 95% până la scriere de 5%.
* Testul de încărcare a fost rulat pe n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB memorie), iar instanța de testare nu a fost niciodată un blocaj în teste.
** Numărul maxim de fire într-o singură instanță YCSB este de 400. A trebuit rulat un total de șase instanțe paralele de teste YCSB pentru a obține un total de 2400 de fire.
Privind rezultatele benchmark-ului, în special combinația dintre încărcarea procesorului și TPS, putem vedea clar că Cloud Spanner se scalează destul de bine. Sarcina mare creată de numărul mare de fire este compensată de numărul mare de noduri din clusterul Cloud Spanner. În timp ce latența pare destul de mare, mai ales când rulează cu 2400 de fire, poate fi necesară retestarea cu 6 instanțe mai mici ale motorului de calcul pentru a obține numere mai precise. Fiecare instanță va rula un test YCSB în loc de o instanță mare CE cu 6 teste paralele. În acest fel, va fi mai ușor de diferențiat între latența cererii Cloud Spanner și latența adăugată de conexiunea la rețea dintre Cloud Spanner și instanța CE care execută testul.
Cum funcționează Cloud Spanner ca OLAP?
Partiționare?
Împărțirea datelor în segmente independente fizic și/sau logic, numite partiții, este un concept foarte popular întâlnit în majoritatea motoarelor OLAP. Partițiile pot îmbunătăți semnificativ performanța interogărilor și mentenabilitatea bazei de date. Aprofundarea în partiționare ar fi un articol(e) separat(e), așa că să menționăm doar importanța de a avea o schemă de partiționare și sub-partiționare. Capacitatea de a descompune datele în partiții și chiar mai mult în subpartiții este cheia performanței interogărilor analitice.
Cloud Spanner nu acceptă partiții ca atare. Împarte datele intern în așa-numitele împărţi-s bazate pe intervale de chei primare. Partiționarea este efectuată automat pentru a echilibra încărcarea într-un cluster Cloud Spanner. O caracteristică foarte utilă a Cloud Spanner este împărțirea încărcării de bază a tabelului părinte (un tabel care nu este intercalat cu altul). Spanner detectează automat dacă conține împărţi date care sunt citite mai frecvent decât datele din altele împărţi-ah, și poate decide despre separarea ulterioară. În acest fel, mai multe noduri pot fi implicate într-o solicitare, ceea ce crește efectiv debitul.
Încărcare date?
Metoda Cloud Spanner pentru datele în bloc este aceeași ca și pentru încărcarea normală. Pentru a obține performanță maximă, trebuie să urmați câteva recomandări, inclusiv:
- Sortați-vă datele după cheia principală.
- Împărțiți-le la 10*numărul de noduri secțiuni separate.
- Creați un set de sarcini de lucru care încarcă date în paralel.
Această încărcare a datelor utilizează toate nodurile Cloud Spanner.
Am folosit volumul de lucru A YCSB pentru a genera un set de date de 10 milioane de rânduri.
* Testul de încărcare a fost rulat pe motorul de calcul n1-standard-32 (32 vCPU, 120 GB memorie), iar instanța de testare nu a fost niciodată un blocaj în teste.
**Configurarea unui singur nod nu este recomandată pentru nicio sarcină de lucru de producție.
După cum s-a menționat mai sus, Cloud Spanner procesează automat divizările în funcție de sarcina lor, astfel încât rezultatele se îmbunătățesc după mai multe repetări consecutive de test. Rezultatele prezentate aici sunt cele mai bune rezultate pe care le-am obținut. Privind numerele de mai sus, putem vedea cum Cloud Spanner se scalează (bine) pe măsură ce numărul de noduri din cluster crește. Cifrele care ies în evidență sunt latențele medii extrem de scăzute, care contrastează cu rezultatele pentru sarcini mixte (95% citire și 5% scris), așa cum este descris în secțiunea de mai sus.
Scalare?
Creșterea și scăderea numărului de noduri Cloud Spanner este o sarcină cu un singur clic. Dacă doriți să încărcați datele rapid, ați putea lua în considerare creșterea maximă a instanței (în cazul nostru a fost de 25 de noduri în regiunea SUA-EAST) și apoi să reduceți numărul de noduri eligibile pentru încărcarea normală, odată ce toate datele sunt introduse. baza de date, referindu-se la limita de 2TB/nod.
Ni s-a reamintit de această limită chiar și cu o bază de date mult mai mică. După mai multe teste de încărcare, baza noastră de date avea o dimensiune de aproximativ 155 GB și, atunci când a fost redusă la o instanță cu 1 nod, am primit următoarea eroare:
Am reușit să reducem de la 25 la 2 instanțe, dar am rămas blocați la două noduri.
Creșterea și scăderea numărului de noduri dintr-un cluster Cloud Spanner poate fi automatizată folosind API-ul REST. Acest lucru poate fi util în special pentru reducerea încărcării crescute a sistemului în timpul orelor de lucru aglomerate.
Performanța interogărilor OLAP?
Inițial, am plănuit să petrecem o cantitate semnificativă de timp în evaluarea noastră a Spanner din această parte. După mai multe SELECT COUNT, ne-am dat seama imediat că testarea va fi scurtă și că Spanner NU ar fi un motor potrivit pentru OLAP. Indiferent de numărul de noduri din cluster, simpla selectare a numărului de rânduri dintr-un tabel de 10 milioane de rânduri a durat între 55 și 60 de secunde. În plus, orice interogare care necesita mai multă memorie pentru stocarea rezultatelor intermediare a eșuat cu o eroare OOM.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Unele numere pentru interogările TPC-H pot fi găsite în articolul lui Todd Lipcon , diapozitivele 42 și 43. Aceste numere sunt în concordanță cu propriile noastre rezultate (din păcate).
4. Concluziile noastre
Având în vedere starea actuală a funcțiilor Cloud Spanner, este greu de imaginat că acesta este un simplu înlocuitor pentru soluția dvs. OLTP existentă, mai ales când nevoile dvs. depășesc. Ar trebui să se aloce o cantitate semnificativă de timp pentru a construi o soluție în jurul deficiențelor Cloud Spanner.
Când am început să evaluăm Cloud Spanner, ne așteptam ca funcțiile sale de management să fie la egalitate cu alte soluții Google SQL sau cel puțin nu prea departe de acestea. Dar am fost surprinși de lipsa completă a backup-urilor și de controlul foarte limitat asupra accesului la resurse. Ca să nu mai vorbim de nicio vizualizare, nici un mediu de dezvoltare locală, secvențe neacceptate, JDBC fără suport DML și DDL și așa mai departe.
Deci, unde se duce cineva care trebuie să scaleze o bază de date tranzacțională? Nu pare să existe o singură soluție pe piață care să se potrivească tuturor cazurilor de utilizare. Există multe soluții închise și open source (dintre care unele sunt menționate în acest articol), fiecare cu propriile puncte forte și puncte slabe, dar niciuna dintre ele nu oferă SaaS cu un SLA de 99,999% și consistență ridicată. Dacă un SLA ridicat este obiectivul tău principal și nu ești înclinat să construiești o soluție multi-cloud personalizată, Cloud Spanner poate fi soluția pe care o cauți. Dar ar trebui să fii conștient de toate limitările sale.
Pentru a fi corect, Cloud Spanner a fost lansat publicului abia în primăvara lui 2017, așa că este rezonabil să ne așteptăm ca unele dintre deficiențele sale actuale să dispară în cele din urmă (sperăm) și, atunci când o vor face, ar putea schimba jocul. La urma urmei, Cloud Spanner nu este doar un proiect secundar pentru Google. Google îl folosește ca bază pentru alte produse Google. Și când Google a înlocuit recent Megastore în Google Cloud Storage cu Cloud Spanner, a permis Google Cloud Storage să devină foarte consistent pentru listele de obiecte la scară globală (ceea ce încă nu este cazul pentru ).
Deci, mai există speranță... sperăm.
Asta e tot. La fel ca și autorul articolului, și noi continuăm să sperăm, dar ce părere aveți despre asta? Scrieți în comentarii
Îi invităm pe toți să ne viziteze în cadrul căruia vă vom povesti în detaliu despre curs de la OTUS.
Sursa: www.habr.com