Uvod
“Moraš trčati što brže možeš samo da ostaneš na mjestu,
a da biste negdje stigli, morate trčati barem duplo brže!”
(c) Alisa u zemlji čuda
Prije nekog vremena su me zamolili da održim predavanje analitičari našu kompaniju na temu projektovanja modela podataka, jer dugo sedeći na projektima (nekad i po nekoliko godina) gubimo iz vida šta se dešava oko nas u svetu IT tehnologija. U našoj kompaniji (tako se dešava) mnogi projekti ne koriste NoSQL baze podataka (barem za sada), pa sam im u svom predavanju posebno posvetio pažnju na primjeru HBase-a i pokušao orijentirati prezentaciju materijala na one koji ih nikada nisu koristili su radili. Posebno sam ilustrovao neke od karakteristika dizajna modela podataka koristeći primjer koji sam pročitao prije nekoliko godina . Prilikom analize primjera uporedio sam nekoliko opcija za rješavanje istog problema kako bih bolje prenio glavne ideje publici.
Nedavno sam se, „iz razloga što nisam radio“, postavio pitanje (dugi majski vikend u karantinu tome posebno pogoduje), koliko će teoretski proračuni odgovarati praksi? Zapravo, tako se rodila ideja za ovaj članak. Programer koji radi sa NoSQL-om nekoliko dana možda neće naučiti ništa novo iz njega (i stoga može odmah preskočiti pola članka). Ali za analitičariZa one koji još nisu blisko sarađivali sa NoSQL-om, mislim da će to biti korisno za sticanje osnovnog razumevanja karakteristika dizajniranja modela podataka za HBase.
Primjer analize
Po mom mišljenju, prije nego počnete koristiti NoSQL baze podataka, morate dobro razmisliti i odmjeriti prednosti i nedostatke. Često se problem najvjerovatnije može riješiti korištenjem tradicionalnih relacijskih DBMS-a. Stoga je bolje ne koristiti NoSQL bez značajnih razloga. Ako ste ipak odlučili da koristite NoSQL bazu podataka, onda biste trebali uzeti u obzir da su pristupi dizajnu ovdje nešto drugačiji. Pogotovo neki od njih mogu biti neobični za one koji su se ranije bavili samo relacionim DBMS-ovima (prema mojim zapažanjima). Dakle, u “relacionom” svijetu obično počinjemo modeliranjem domena problema, a tek onda, ako je potrebno, denormaliziramo model. U NoSQL mi treba odmah uzeti u obzir očekivane scenarije za rad sa podacima i inicijalno denormalizirati podatke. Osim toga, postoji niz drugih razlika, o kojima će biti riječi u nastavku.
Razmotrimo sljedeći "sintetički" problem, s kojim ćemo nastaviti raditi:
Potrebno je osmisliti strukturu skladištenja za listu prijatelja korisnika neke apstraktne društvene mreže. Da pojednostavimo, pretpostavit ćemo da su sve naše veze usmjerene (kao na Instagramu, a ne Linkedinu). Struktura treba da vam omogući da efikasno:
- Odgovorite na pitanje da li korisnik A čita korisnika B (uzorak čitanja)
- Dozvoli dodavanje/uklanjanje veza u slučaju pretplate/odjave korisnika A od korisnika B (šablon promjene podataka)
Naravno, postoji mnogo opcija za rješavanje problema. U redovnoj relacionoj bazi podataka, najvjerovatnije bismo jednostavno napravili tabelu odnosa (moguće tipiziranu ako, na primjer, trebamo pohraniti korisničku grupu: porodica, posao, itd., koja uključuje ovog „prijatelja“) i optimizirati brzina pristupa bi dodala indekse/particioniranje. Najvjerovatnije bi finalni sto izgledao otprilike ovako:
user_id
friend_id
Vasya
Petya
Vasya
Olya
u daljem tekstu, radi jasnoće i boljeg razumijevanja, navešću imena umjesto ID-a
U slučaju HBase-a, znamo da:
- moguća je efikasna pretraga koja ne rezultira potpunim skeniranjem tabele isključivo po ključu
- zapravo, zato je pisanje SQL upita poznatih mnogim takvim bazama podataka loša ideja; tehnički, naravno, možete poslati SQL upit sa Joins-om i drugom logikom na HBase sa iste Impale, ali koliko će to biti efikasno...
Stoga smo primorani koristiti korisnički ID kao ključ. I moja prva misao na temu "gdje i kako čuvati lične karte prijatelja?" možda ideja da ih spremite u kolone. Ova najočiglednija i "naivna" opcija će izgledati otprilike ovako (nazovimo je Opcija 1 (zadano)za dalju referencu):
RowKey
Zvučnici
Vasya
1: Petya
2: Olja
3: Daša
Petya
1: Maša
2: Vasja
Ovdje svaka linija odgovara jednom korisniku mreže. Kolone imaju nazive: 1, 2, ... - prema broju prijatelja, a ID-ovi prijatelja se čuvaju u kolonama. Važno je napomenuti da će svaki red imati različit broj kolona. U primjeru na slici iznad, jedan red ima tri stupca (1, 2 i 3), a drugi samo dva (1 i 2) - ovdje smo i sami koristili dva HBase svojstva koja nemaju relacijske baze podataka:
- mogućnost dinamičke promjene sastava kolona (dodaj prijatelja -> dodaj kolonu, ukloni prijatelja -> izbriši kolonu)
- različiti redovi mogu imati različite sastave kolona
Provjerimo usklađenost naše strukture sa zahtjevima zadatka:
- Čitanje podataka: da bismo razumjeli da li je Vasya pretplaćen na Olyu, morat ćemo oduzeti cela linija pomoću ključa RowKey = "Vasya" i sortiraj vrijednosti stupaca dok ne "upoznamo" Olyu u njima. Ili ponovite kroz vrijednosti svih stupaca, "ne upoznajte" Olyu i vratite odgovor False;
- Uređivanje podataka: dodavanje prijatelja: za sličan zadatak također trebamo oduzeti cela linija koristeći ključ RowKey = “Vasya” za izračunavanje ukupnog broja njegovih prijatelja. Ovaj ukupan broj prijatelja nam je potreban da odredimo broj kolone u koju treba da upišemo ID novog prijatelja.
- Promjena podataka: brisanje prijatelja:
- Treba oduzeti cela linija pomoću ključa RowKey = “Vasya” i sortirajte kolone kako biste pronašli onu u kojoj je zabilježen prijatelj kojeg treba izbrisati;
- Zatim, nakon brisanja prijatelja, moramo sve podatke "pomaknuti" u jednu kolonu kako ne bismo dobili "praznine" u njihovoj numeraciji.
Procijenimo sada koliko će ovi algoritmi, koje ćemo morati implementirati na strani „uslovne aplikacije“, biti produktivni, koristeći . Označimo veličinu naše hipotetičke društvene mreže sa n. Tada je maksimalni broj prijatelja koji jedan korisnik može imati (n-1). Ovo (-1) možemo dalje zanemariti za naše potrebe, jer je u okviru upotrebe O-simbola nevažno.
- Čitanje podataka: potrebno je oduzeti cijeli red i iterirati kroz sve njegove stupce u limitu. To znači da će gornja procjena troškova biti približno O(n)
- Uređivanje podataka: dodavanje prijatelja: da biste odredili broj prijatelja, morate iterirati kroz sve kolone reda, a zatim umetnuti novu kolonu => O(n)
- Promjena podataka: brisanje prijatelja:
- Slično kao kod dodavanja - potrebno je proći kroz sve kolone u limitu => O(n)
- Nakon što uklonimo kolone, trebamo ih "pomjeriti". Ako implementirate ovo "head-on", tada će vam u limitu trebati do (n-1) operacija. Ali ovdje i dalje u praktičnom dijelu koristit ćemo drugačiji pristup, koji će implementirati "pseudo-pomak" za fiksni broj operacija - to jest, na to će se trošiti konstantno vrijeme, bez obzira na n. Ovo konstantno vrijeme (tačnije O(2)) može se zanemariti u poređenju sa O(n). Pristup je ilustrovan na donjoj slici: jednostavno kopiramo podatke iz “zadnje” kolone u onu iz koje želimo da izbrišemo podatke, a zatim izbrišemo posljednju kolonu:
Ukupno, u svim scenarijima dobili smo asimptotičku računsku složenost od O(n).
Verovatno ste već primetili da skoro uvek moramo da pročitamo ceo red iz baze, a u dva od tri slučaja samo da bismo prošli kroz sve kolone i izračunali ukupan broj prijatelja. Stoga, kao pokušaj optimizacije, možete dodati kolonu “count” koja pohranjuje ukupan broj prijatelja svakog korisnika mreže. U ovom slučaju, ne možemo pročitati cijeli red da bismo izračunali ukupan broj prijatelja, već čitamo samo jednu kolonu „broj“. Glavna stvar je da ne zaboravite ažurirati "broj" kada manipulirate podacima. To. poboljšavamo se Opcija 2 (broj):
RowKey
Zvučnici
Vasya
1: Petya
2: Olja
3: Daša
broj: 3
Petya
1: Maša
2: Vasja
broj: 2
U poređenju sa prvom opcijom:
- Čitanje podataka: da dobijem odgovor na pitanje "Da li Vasja čita Olju?" ništa se nije promijenilo => O(n)
- Uređivanje podataka: dodavanje prijatelja: Pojednostavili smo umetanje novog prijatelja, jer sada ne moramo čitati cijeli red i iterirati njegove kolone, već možemo dobiti samo vrijednost kolone “count” itd. odmah odredite broj kolone za ubacivanje novog prijatelja. Ovo dovodi do smanjenja računske složenosti na O(1)
- Promjena podataka: brisanje prijatelja: Prilikom brisanja prijatelja, ovu kolonu također možemo koristiti da smanjimo broj I/O operacija prilikom „pomjeranja“ podataka za jednu ćeliju ulijevo. Ali i dalje ostaje potreba za iteracijom kroz kolone da se pronađe onaj koji treba izbrisati, tako da => O(n)
- S druge strane, sada prilikom ažuriranja podataka moramo svaki put ažurirati kolonu “count”, ali to zahtijeva konstantno vrijeme, što se može zanemariti u okviru O-simbola
Općenito, opcija 2 izgleda malo optimalnija, ali više liči na „evoluciju umjesto revolucije“. Trebaće nam da napravimo „revoluciju“. Opcija 3 (boja).
Okrenimo sve "naopačke": mi ćemo imenovati ime kolone ID korisnika! Ono što će biti napisano u samoj koloni za nas više nije važno, neka bude broj 1 (uglavnom, korisne stvari se mogu pohraniti tamo, na primjer, grupa „porodica/prijatelji/itd.”). Ovaj pristup može iznenaditi nespremnog „laika“ koji nema prethodnog iskustva u radu sa NoSQL bazama podataka, ali upravo ovaj pristup vam omogućava da iskoristite potencijal HBase-a u ovom zadatku mnogo efikasnije:
RowKey
Zvučnici
Vasya
Petja: 1
Olja: 1
Daša: 1
Petya
Maša: 1
Vasja: 1
Ovdje dobijamo nekoliko prednosti odjednom. Da bismo ih razumjeli, analizirajmo novu strukturu i procijenimo računsku složenost:
- Čitanje podataka: da biste odgovorili na pitanje da li je Vasya pretplaćen na Olyu, dovoljno je pročitati jednu kolonu "Olya": ako postoji, onda je odgovor Tačno, ako nije - Netačno => O(1)
- Uređivanje podataka: dodavanje prijatelja: Dodavanje prijatelja: samo dodajte novu kolonu “Friend ID” => O(1)
- Promjena podataka: brisanje prijatelja: samo uklonite kolonu ID prijatelja => O(1)
Kao što vidite, značajna prednost ovog modela skladištenja je ta što u svim scenarijima koji su nam potrebni, radimo samo sa jednom kolonom, izbjegavajući čitanje cijelog reda iz baze podataka i, osim toga, nabrajanje svih stupaca ovog reda. Mogli bismo tu stati, ali...
Možete biti zbunjeni i otići malo dalje na putu optimizacije performansi i smanjenja I/O operacija prilikom pristupa bazi podataka. Šta ako pohranimo kompletne informacije o odnosu direktno u sam ključ reda? Odnosno, napraviti kompozitni ključ kao što je userID.friendID? U ovom slučaju, uopće ne moramo čitati stupce reda (Opcija 4 (red)):
RowKey
Zvučnici
Vasya.Petya
Petja: 1
Vasya.Olya
Olja: 1
Vasya.Dasha
Daša: 1
Petya.Masha
Maša: 1
Petya.Vasya
Vasja: 1
Očigledno je da će procjena svih scenarija manipulacije podacima u takvoj strukturi, kao u prethodnoj verziji, biti O(1). Razlika sa opcijom 3 će biti isključivo u efikasnosti I/O operacija u bazi podataka.
Pa, posljednji “naklon”. Lako je vidjeti da će u opciji 4, ključ reda imati promjenjivu dužinu, što bi moglo utjecati na performanse (ovdje se sjećamo da HBase pohranjuje podatke kao skup bajtova, a redovi u tabelama sortirani po ključu). Osim toga, imamo separator kojim će se možda trebati rukovati u nekim scenarijima. Da biste eliminisali ovaj uticaj, možete koristiti heševe iz ID-a korisnika i FriendID-a, a pošto će oba heša imati konstantnu dužinu, možete ih jednostavno spojiti, bez separatora. Tada će podaci u tabeli izgledati ovako (Opcija 5 (heš)):
RowKey
Zvučnici
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petja: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Olja: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Daša: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Maša: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasja: 1
Očigledno je da će algoritamska složenost rada sa takvom strukturom u scenarijima koje razmatramo biti ista kao kod opcije 4 – to jest, O(1).
Sveukupno, sumiramo sve naše procjene složenosti računanja u jednu tabelu:
Dodavanje prijatelja
Provjeravam prijatelja
Uklanjanje prijatelja
Opcija 1 (zadano)
O (n)
O (n)
O (n)
Opcija 2 (broj)
O (1)
O (n)
O (n)
Opcija 3 (kolona)
O (1)
O (1)
O (1)
Opcija 4 (red)
O (1)
O (1)
O (1)
Opcija 5 (heš)
O (1)
O (1)
O (1)
Kao što vidite, čini se da su opcije 3-5 najpoželjnije i teoretski osiguravaju izvršenje svih potrebnih scenarija manipulacije podacima u stalnom vremenu. U uslovima našeg zadatka ne postoji izričit zahtev za dobijanje liste svih prijatelja korisnika, ali u stvarnim projektnim aktivnostima bilo bi dobro da mi kao dobri analitičari „predvidimo“ da bi se takav zadatak mogao pojaviti i "raširi slamku." Stoga su moje simpatije na strani opcije 3. Ali vrlo je vjerovatno da je u stvarnom projektu ovaj zahtjev već mogao biti riješen drugim sredstvima, stoga je bez generalne vizije cjelokupnog problema bolje ne postavljati konačni zaključci.
Priprema eksperimenta
Želio bih u praksi provjeriti gore navedene teorijske argumente - to je bio cilj ideje koja se pojavila tokom dugog vikenda. Da bismo to učinili, potrebno je procijeniti brzinu rada naše „uvjetne aplikacije“ u svim opisanim scenarijima korištenja baze podataka, kao i povećanje tog vremena sa povećanjem veličine društvene mreže (n). Ciljni parametar koji nas interesuje i koji ćemo meriti tokom eksperimenta je vreme koje „uslovna aplikacija“ potroši da izvrši jednu „poslovnu operaciju“. Pod "poslovnom transakcijom" podrazumijevamo jedno od sljedećeg:
- Dodavanje jednog novog prijatelja
- Provjera da li je korisnik A prijatelj korisnika B
- Uklanjanje jednog prijatelja
Stoga, uzimajući u obzir zahtjeve navedene u početnoj izjavi, scenario verifikacije se pojavljuje na sljedeći način:
- Snimanje podataka. Nasumično generirajte početnu mrežu veličine n. Da bismo se približili „stvarnom svijetu“, broj prijatelja koji svaki korisnik ima također je slučajna varijabla. Izmjerite vrijeme koje je potrebno našoj “uvjetnoj aplikaciji” da upiše sve generirane podatke u HBase. Zatim podijelite rezultirajuće vrijeme sa ukupnim brojem dodatih prijatelja - ovako dobijamo prosječno vrijeme za jednu „poslovnu operaciju“
- Čitanje podataka. Za svakog korisnika napravite listu “osobnosti” za koje trebate dobiti odgovor da li je korisnik pretplaćen na njih ili ne. Dužina liste = približno broj prijatelja korisnika, a za polovinu označenih prijatelja odgovor treba da bude „Da“, a za drugu polovinu – „Ne“. Provjera se vrši takvim redoslijedom da se odgovori „Da“ i „Ne“ izmjenjuju (odnosno, u svakom drugom slučaju morat ćemo proći kroz sve stupce reda za opcije 1 i 2). Ukupno vrijeme skrininga se zatim dijeli sa brojem testiranih prijatelja kako bi se dobilo prosječno vrijeme skrininga po subjektu.
- Brisanje podataka. Uklonite sve prijatelje od korisnika. Štaviše, redoslijed brisanja je nasumičan (to jest, "promiješamo" originalnu listu koja se koristi za snimanje podataka). Ukupno vrijeme provjere se zatim podijeli s brojem uklonjenih prijatelja da bi se dobilo prosječno vrijeme po provjeri.
Potrebno je pokrenuti scenarije za svaku od 5 opcija modela podataka i za različite veličine društvene mreže kako bi se vidjelo kako se vrijeme mijenja kako raste. Unutar jednog n, veze u mreži i lista korisnika za provjeru moraju, naravno, biti isti za svih 5 opcija.
Za bolje razumijevanje, ispod je primjer generiranih podataka za n= 5. Napisani “generator” proizvodi tri ID rječnika kao izlaz:
- prvi je za umetanje
- drugi je za provjeru
- treće – za brisanje
{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей
{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов
{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей
Kao što vidite, svi ID-ovi veći od 10 u rječniku za provjeru su upravo oni koji će sigurno dati odgovor False. Umetanje, provjera i brisanje „prijatelja“ se izvode tačno u redoslijedu navedenom u rječniku.
Eksperiment je izveden na laptopu sa Windows 10, gdje je HBase radio u jednom Docker kontejneru, a Python sa Jupyter Notebookom u drugom. Docker-u su dodijeljena 2 CPU jezgra i 2 GB RAM-a. Sva logika, poput emulacije „uslovne aplikacije“ i „cevovoda“ za generisanje testnih podataka i merenje vremena, napisana je u Pythonu. Biblioteka je korištena za rad sa HBase-om , za izračunavanje hashova (MD5) za opciju 5 - hashlib
Uzimajući u obzir računarsku snagu određenog laptopa, eksperimentalno je odabrano lansiranje za n = 10, 30, …. 170 – kada je ukupno vrijeme rada punog ciklusa testiranja (svi scenariji za sve opcije za sve n) bilo čak više ili manje razumno i odgovaralo za jednu čajanku (u prosjeku 15 minuta).
Ovdje je potrebno napomenuti da u ovom eksperimentu ne procjenjujemo prvenstveno apsolutne brojke performansi. Čak i relativno poređenje dve različite opcije možda neće biti sasvim ispravno. Sada nas zanima priroda promjene vremena u zavisnosti od n, budući da je, uzimajući u obzir gornju konfiguraciju “testnog postolja”, vrlo je teško dobiti procjene vremena “očišćene” od utjecaja slučajnih i drugih faktora ( a takav zadatak nije postavljen).
Rezultat eksperimenta
Prvi test je kako se mijenja vrijeme provedeno na popunjavanju liste prijatelja. Rezultat je na grafikonu ispod.
Opcije 3-5, kao što se i očekivalo, pokazuju gotovo konstantno vrijeme "poslovne transakcije", koje ne ovisi o rastu veličine mreže i nerazlučivoj razlici u performansama.
Opcija 2 također pokazuje konstantne, ali nešto lošije performanse, skoro tačno 2 puta u odnosu na opcije 3-5. I to ne može a da ne raduje, jer je u korelaciji sa teorijom - u ovoj verziji broj I/O operacija do/iz HBase-a je tačno 2 puta veći. Ovo može poslužiti kao indirektan dokaz da naš testni sto u principu pruža dobru tačnost.
Opcija 1 se također, kao što se i očekivalo, pokazuje kao najsporija i pokazuje linearno povećanje vremena utrošenog na međusobno dodavanje na veličinu mreže.
Pogledajmo sada rezultate drugog testa.
Opcije 3-5 se opet ponašaju kako se očekuje - konstantno vrijeme, neovisno o veličini mreže. Opcije 1 i 2 pokazuju linearno povećanje vremena kako se povećava veličina mreže i slične performanse. Štoviše, opcija 2 se ispostavlja malo sporijom - očito zbog potrebe za lektoriranjem i obradom dodatnog stupca "broj", koji postaje uočljiviji kako n raste. Ali ipak ću se suzdržati od izvođenja bilo kakvih zaključaka, budući da je tačnost ovog poređenja relativno niska. Osim toga, ovi omjeri (koja opcija, 1 ili 2, je brža) mijenjali su se od trčanja do trčanja (uz zadržavanje prirode ovisnosti i „pokretanja vrata i vrata“).
Pa, posljednji grafikon je rezultat testiranja uklanjanja.
Opet, ovdje nema iznenađenja. Opcije 3-5 vrše uklanjanje u stalnom vremenu.
Štaviše, zanimljivo je da opcije 4 i 5, za razliku od prethodnih scenarija, pokazuju primetno nešto lošije performanse od opcije 3. Očigledno je operacija brisanja reda skuplja od operacije brisanja kolone, što je generalno logično.
Opcije 1 i 2, kako se očekivalo, pokazuju linearno povećanje vremena. U isto vrijeme, opcija 2 je konstantno sporija od opcije 1 - zbog dodatne I/O operacije za „održavanje“ stupca brojanja.
Opšti zaključci eksperimenta:
- Opcije 3-5 pokazuju veću efikasnost jer koriste prednosti HBase-a; Štaviše, njihove performanse se međusobno razlikuju za konstantu i ne zavise od veličine mreže.
- Razlika između opcija 4 i 5 nije zabilježena. Ali to ne znači da opciju 5 ne treba koristiti. Vjerovatno je da korišteni eksperimentalni scenario, uzimajući u obzir karakteristike performansi ispitnog stola, nije omogućio njegovo detektiranje.
- Priroda povećanja vremena potrebnog za obavljanje „poslovnih operacija“ sa podacima generalno je potvrdila prethodno dobijene teorijske proračune za sve opcije.
Epilog
Provedeni grubi eksperimenti ne bi se trebali uzeti kao apsolutna istina. Mnogo je faktora koji nisu uzeti u obzir i iskrivili su rezultate (ova fluktuacija su posebno vidljiva na grafovima sa malom veličinom mreže). Na primjer, brzina štedljivosti koju koristi happybase, obim i način implementacije logike koju sam napisao u Pythonu (ne mogu tvrditi da je kod napisan optimalno i da je efikasno koristio mogućnosti svih komponenti), možda karakteristike HBase keširanja, pozadinske aktivnosti Windows 10 na mom laptopu, itd. Općenito, možemo pretpostaviti da su svi teorijski proračuni eksperimentalno pokazali svoju valjanost. Pa, ili ih barem nije bilo moguće opovrgnuti takvim „napadom u glavu“.
U zaključku, preporuke za sve koji tek počinju da dizajniraju modele podataka u HBase-u: apstrahujte iz prethodnog iskustva rada sa relacionim bazama podataka i zapamtite „zapovijedi“:
- Prilikom projektovanja polazimo od zadatka i obrazaca manipulacije podacima, a ne od modela domene
- Efikasan pristup (bez kompletnog skeniranja tabele) – samo ključem
- Denormalizacija
- Različiti redovi mogu sadržavati različite stupce
- Dinamička kompozicija govornika
izvor: www.habr.com