Predstavitev
"Teči moraš čim hitreje, da ostaneš na mestu,
in da nekam prideš, moraš teči vsaj dvakrat hitreje!«
(c) Alica v čudežni deželi
Pred časom so me prosili za predavanje analitiki naše podjetje na temo oblikovanja podatkovnih modelov, saj z dolgotrajnim sedenjem na projektih (včasih tudi več let) izgubimo iz vida, kaj se dogaja okoli nas v svetu IT tehnologij. V našem podjetju (tako se zgodi) veliko projektov ne uporablja baz podatkov NoSQL (vsaj zaenkrat), zato sem jim v svojem predavanju posebej posvetil nekaj pozornosti na primeru HBase in skušal predstavitev gradiva usmeriti na te ki jih nikoli niso uporabljali, so delovali. Zlasti sem ponazoril nekatere značilnosti oblikovanja podatkovnega modela s primerom, ki sem ga prebral pred nekaj leti . Pri analizi primerov sem primerjal več možnosti za rešitev istega problema, da bi občinstvu bolje posredoval glavne ideje.
Pred kratkim sem si »brez opravka« postavil vprašanje (dolgi majski vikend v karanteni je temu še posebej naklonjen), koliko bodo teoretični izračuni ustrezali praksi? Pravzaprav se je tako porodila ideja za ta članek. Razvijalec, ki že nekaj dni dela z NoSQL, se morda ne bo naučil ničesar novega (in zato lahko takoj preskoči polovico članka). Ampak za analitikiZa tiste, ki še niso tesno sodelovali z NoSQL, mislim, da bo koristen za pridobitev osnovnega razumevanja funkcij oblikovanja podatkovnih modelov za HBase.
Primer analize
Po mojem mnenju morate, preden začnete uporabljati baze podatkov NoSQL, dobro premisliti in pretehtati prednosti in slabosti. Pogosto je težavo najverjetneje mogoče rešiti z uporabo tradicionalnih relacijskih DBMS. Zato je bolje, da ne uporabljate NoSQL brez pomembnih razlogov. Če ste se kljub temu odločili za uporabo baze podatkov NoSQL, potem morate upoštevati, da so pristopi oblikovanja tukaj nekoliko drugačni. Predvsem nekateri od njih so lahko nenavadni za tiste, ki so se prej ukvarjali samo z relacijskimi DBMS (po mojih opažanjih). Torej v »relacijskem« svetu običajno začnemo z modeliranjem problemske domene in šele nato, če je potrebno, denormaliziramo model. V NoSQL mi mora takoj upoštevati pričakovane scenarije za delo s podatki in na začetku denormalizirati podatke. Poleg tega obstajajo številne druge razlike, o katerih bomo razpravljali v nadaljevanju.
Razmislimo o naslednjem "sintetičnem" problemu, s katerim bomo nadaljevali delo:
Oblikovati je treba strukturo shranjevanja seznama prijateljev uporabnikov nekega abstraktnega socialnega omrežja. Za poenostavitev bomo predpostavili, da so vse naše povezave usmerjene (kot na Instagramu, ne na Linkedinu). Struktura vam mora omogočati učinkovito:
- Odgovorite na vprašanje, ali uporabnik A bere uporabnika B (bralni vzorec)
- Dovoli dodajanje/odstranjevanje povezav v primeru vpisa/odjave uporabnika A od uporabnika B (predloga za spremembo podatkov)
Seveda obstaja veliko možnosti za rešitev problema. V navadni relacijski podatkovni bazi bi najverjetneje preprosto naredili tabelo odnosov (po možnosti tipiziranih, če bi morali npr. shraniti skupino uporabnikov: družina, služba itd., ki vključuje tega »prijatelja«) in optimizirati hitrost dostopa bi dodala indekse/particioniranje. Najverjetneje bi končna miza izgledala nekako takole:
USER_ID
friend_id
Vasya
Petya
Vasya
Оля
v nadaljevanju bom zaradi jasnosti in boljšega razumevanja navedel imena namesto ID-jev
V primeru HBase vemo, da:
- možno je učinkovito iskanje, ki ne privede do pregleda celotne tabele izključno po ključu
- Pravzaprav je zato pisanje poizvedb SQL, ki jih poznajo mnogi, v takšne baze podatkov slaba ideja; tehnično seveda lahko pošljete poizvedbo SQL z Joins in drugo logiko v HBase iz iste Impale, ampak kako učinkovito bo ...
Zato smo primorani uporabiti ID uporabnika kot ključ. In moja prva misel na temo "kje in kako shraniti ID prijateljev?" morda ideja, da bi jih shranili v stolpce. Ta najbolj očitna in "naivna" možnost bo videti nekako takole (recimo temu 1. možnost (privzeto)za nadaljnje reference):
RowKey
Stolpec
Vasya
1: Petja
2: Olja
3: Daša
Petya
1: Maša
2: Vasja
Tukaj vsaka vrstica ustreza enemu uporabniku omrežja. Stolpci imajo imena: 1, 2, ... - glede na število prijateljev, v stolpcih pa so shranjeni ID-ji prijateljev. Pomembno je vedeti, da bo imela vsaka vrstica različno število stolpcev. V primeru na zgornji sliki ima ena vrstica tri stolpce (1, 2 in 3), druga pa samo dva (1 in 2) – tu smo sami uporabili dve lastnosti HBase, ki jih relacijske baze podatkov nimajo:
- možnost dinamičnega spreminjanja sestave stolpcev (dodaj prijatelja -> dodaj stolpec, odstrani prijatelja -> izbriši stolpec)
- različne vrstice imajo lahko različne sestave stolpcev
Preverimo našo strukturo glede skladnosti z zahtevami naloge:
- Branje podatkov: da bi razumeli, ali je Vasya naročen na Olyo, bomo morali odšteti cela linija s ključem RowKey = "Vasya" in razvrščamo vrednosti stolpcev, dokler v njih ne "srečamo" Olye. Ali ponovite vrednosti vseh stolpcev, "ne izpolnjujejo" Olya in vrnejo odgovor False;
- Urejanje podatkov: dodajanje prijatelja: za podobno nalogo moramo tudi odšteti cela linija s tipko RowKey = “Vasya” izračunati skupno število njegovih prijateljev. To skupno število prijateljev potrebujemo za določitev številke stolpca, v katerega moramo zapisati ID novega prijatelja.
- Spreminjanje podatkov: brisanje prijatelja:
- Treba je odšteti cela linija s ključem RowKey = "Vasya" in razvrstite po stolpcih, da poiščete tistega, v katerem je zabeležen prijatelj, ki ga želite izbrisati;
- Nato moramo po brisanju prijatelja vse podatke "premakniti" v en stolpec, da ne bi dobili "vrzeli" v njihovem oštevilčenju.
Zdaj pa ocenimo, kako produktivni bodo ti algoritmi, ki jih bomo morali implementirati na strani »pogojne aplikacije«, z uporabo . Označimo velikost našega hipotetičnega socialnega omrežja z n. Potem je največje število prijateljev, ki jih lahko ima en uporabnik, (n-1). To (-1) lahko za naše namene nadalje zanemarimo, saj je v okviru uporabe O-simbolov nepomembno.
- Branje podatkov: potrebno je odšteti celotno vrstico in iterirati skozi vse njene stolpce v limitu. To pomeni, da bo zgornja ocena stroškov približno O(n)
- Urejanje podatkov: dodajanje prijatelja: če želite določiti število prijateljev, morate iterirati po vseh stolpcih vrstice in nato vstaviti nov stolpec => O(n)
- Spreminjanje podatkov: brisanje prijatelja:
- Podobno kot pri seštevanju - iti morate skozi vse stolpce v limitu => O(n)
- Ko odstranimo stolpce, jih moramo "premakniti". Če implementirate to "čelno", boste v omejitvi potrebovali do (n-1) operacij. Toda tu in naprej v praktičnem delu bomo uporabili drugačen pristop, ki bo izvajal "psevdopremik" za določeno število operacij - to pomeni, da bo za to porabljen konstanten čas, ne glede na n. Ta konstantni čas (natančneje O(2)) lahko zanemarimo v primerjavi z O(n). Pristop je prikazan na spodnji sliki: preprosto kopiramo podatke iz »zadnjega« stolpca v tistega, iz katerega želimo podatke izbrisati, nato pa izbrišemo zadnji stolpec:
Skupaj smo v vseh scenarijih prejeli asimptotično računsko kompleksnost O(n).
Verjetno ste že opazili, da moramo skoraj vedno prebrati celotno vrstico iz podatkovne baze, v dveh primerih od treh pa samo zato, da preletimo vse stolpce in izračunamo skupno število prijateljev. Zato lahko kot poskus optimizacije dodate stolpec »štetje«, v katerem je shranjeno skupno število prijateljev posameznega uporabnika omrežja. V tem primeru ne moremo prebrati celotne vrstice, da bi izračunali skupno število prijateljev, ampak samo en stolpec »štetje«. Glavna stvar je, da pri obdelavi podatkov ne pozabite posodobiti »štetja«. to. se izboljšamo Možnost 2 (štetje):
RowKey
Stolpec
Vasya
1: Petja
2: Olja
3: Daša
štetje: 3
Petya
1: Maša
2: Vasja
štetje: 2
V primerjavi s prvo možnostjo:
- Branje podatkov: dobiti odgovor na vprašanje "Ali Vasja bere Oljo?" nič se ni spremenilo => O(n)
- Urejanje podatkov: dodajanje prijatelja: Poenostavili smo vstavljanje novega prijatelja, saj nam zdaj ni treba brati celotne vrstice in iterirati po njenih stolpcih, ampak lahko dobimo samo vrednost stolpca “count” itd. takoj določite številko stolpca za vstavljanje novega prijatelja. To vodi do zmanjšanja računske kompleksnosti na O(1)
- Spreminjanje podatkov: brisanje prijatelja: Pri brisanju prijatelja lahko ta stolpec uporabimo tudi za zmanjšanje števila V/I operacij, ko podatke »premikamo« za eno celico v levo. Toda potreba po iteraciji skozi stolpce, da bi našli tistega, ki ga je treba izbrisati, še vedno ostaja, tako da => O(n)
- Po drugi strani pa moramo zdaj pri posodabljanju podatkov vsakič posodobiti stolpec »štetje«, vendar to zahteva stalni čas, ki ga lahko zanemarimo v okviru O-simbolov
Na splošno se zdi možnost 2 nekoliko bolj optimalna, vendar je bolj podobna "evoluciji namesto revoluciji". Za "revolucijo" bomo potrebovali Možnost 3 (col).
Obrnimo vse "na glavo": dodelili bomo ime stolpca ID uporabnika! Kaj bo zapisano v samem stolpcu, za nas ni več pomembno, naj bo številka 1 (na splošno lahko tam shranimo uporabne stvari, na primer skupino »družina/prijatelji/itd.«). Ta pristop lahko preseneti nepripravljenega »laika«, ki nima predhodnih izkušenj pri delu z bazami podatkov NoSQL, vendar je ravno ta pristop tisti, ki vam omogoča veliko učinkovitejšo uporabo potenciala HBase pri tej nalogi:
RowKey
Stolpec
Vasya
Petja: 1
Olja: 1
Daša: 1
Petya
Maša: 1
Vasja: 1
Tu dobimo več prednosti hkrati. Da bi jih razumeli, analizirajmo novo strukturo in ocenimo računsko zahtevnost:
- Branje podatkov: da bi odgovorili na vprašanje, ali je Vasya naročen na Olya, je dovolj, da preberete en stolpec "Olya": če je tam, potem je odgovor True, če ne - False => O(1)
- Urejanje podatkov: dodajanje prijatelja: Dodajanje prijatelja: dodajte nov stolpec »ID prijatelja« => O(1)
- Spreminjanje podatkov: brisanje prijatelja: samo odstranite stolpec ID prijatelja => O(1)
Kot lahko vidite, je pomembna prednost tega modela shranjevanja ta, da v vseh scenarijih, ki jih potrebujemo, delujemo samo z enim stolpcem, s čimer se izognemo branju celotne vrstice iz baze podatkov in poleg tega naštejemo vse stolpce te vrstice. Lahko bi se ustavili tam, ampak ...
Lahko ste zmedeni in greste malo dlje po poti optimizacije zmogljivosti in zmanjšanja V/I operacij pri dostopu do baze podatkov. Kaj pa, če bi celotno informacijo o razmerju shranili neposredno v sam ključ vrstice? To pomeni, da je ključ sestavljen kot userID.friendID? V tem primeru nam sploh ni treba brati stolpcev vrstice (Možnost 4 (vrstica)):
RowKey
Stolpec
Vasja Petja
Petja: 1
Vasya.Olya
Olja: 1
Vasja Daša
Daša: 1
Petja Maša
Maša: 1
Petya.Vasya
Vasja: 1
Očitno bo ocena vseh scenarijev manipulacije podatkov v takšni strukturi, kot v prejšnji različici, O(1). Razlika z možnostjo 3 bo izključno v učinkovitosti V/I operacij v bazi podatkov.
No, zadnji "lok". Preprosto je videti, da bo v možnosti 4 ključ vrstice imel spremenljivo dolžino, kar lahko vpliva na zmogljivost (tu se spomnimo, da HBase shranjuje podatke kot nabor bajtov in so vrstice v tabelah razvrščene po ključu). Poleg tega imamo ločilo, ki ga bo morda treba obravnavati v nekaterih scenarijih. Da bi odpravili ta vpliv, lahko uporabite hashe iz userID in friendID, in ker bosta imela oba hasha konstantno dolžino, ju lahko enostavno združite brez ločila. Potem bodo podatki v tabeli videti tako (Možnost 5 (razpršitev)):
RowKey
Stolpec
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petja: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Olja: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Daša: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Maša: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasja: 1
Očitno bo algoritemska zapletenost dela s takšno strukturo v scenarijih, ki jih obravnavamo, enaka kot pri možnosti 4 - to je O(1).
Povzemimo vse naše ocene računske kompleksnosti v eni tabeli:
Dodajanje prijatelja
Preverjanje prijatelja
Odstranjevanje prijatelja
1. možnost (privzeto)
O (n)
O (n)
O (n)
Možnost 2 (štetje)
O (1)
O (n)
O (n)
3. možnost (stolpec)
O (1)
O (1)
O (1)
Možnost 4 (vrstica)
O (1)
O (1)
O (1)
Možnost 5 (zgoščena vrednost)
O (1)
O (1)
O (1)
Kot lahko vidite, se možnosti 3-5 zdijo najbolj zaželene in teoretično zagotavljajo izvajanje vseh potrebnih scenarijev manipulacije podatkov v konstantnem času. V pogojih naše naloge ni eksplicitne zahteve po pridobitvi seznama vseh uporabnikovih prijateljev, pri realnih projektnih aktivnostih pa bi bilo dobro, da kot dobri analitiki »predvidimo«, da se takšna naloga pojavi in "razširi slamico." Zato so moje simpatije na strani možnosti 3. Vendar je zelo verjetno, da bi bilo v realnem projektu to zahtevo že mogoče rešiti na drug način, zato je brez splošne vizije celotnega problema bolje, da ne končne zaključke.
Priprava poskusa
Zgornje teoretične argumente bi rad preizkusil v praksi – to je bil cilj ideje, ki se je porodila čez podaljšan vikend. Da bi to naredili, je treba oceniti hitrost delovanja naše "pogojne aplikacije" v vseh opisanih scenarijih uporabe baze podatkov, kot tudi povečanje tega časa z večanjem velikosti družbenega omrežja (n). Ciljni parameter, ki nas zanima in ki ga bomo merili med poskusom, je čas, ki ga »pogojna aplikacija« porabi za izvedbo ene »poslovne operacije«. S "poslovno transakcijo" mislimo na eno od naslednjega:
- Dodajanje enega novega prijatelja
- Preverjanje, ali je uporabnik A prijatelj uporabnika B
- Odstranjevanje enega prijatelja
Tako je ob upoštevanju zahtev, opisanih v začetni izjavi, scenarij preverjanja naslednji:
- Snemanje podatkov. Naključno ustvarite začetno mrežo velikosti n. Da bi se približali »resničnemu svetu«, je naključna spremenljivka tudi število prijateljev, ki jih ima vsak uporabnik. Izmerite čas, v katerem naša "pogojna aplikacija" zapiše vse ustvarjene podatke v HBase. Nato dobljeni čas delimo s skupnim številom dodanih prijateljev - tako dobimo povprečni čas za eno "poslovno operacijo"
- Branje podatkov. Za vsakega uporabnika ustvarite seznam »osebnosti«, za katere morate dobiti odgovor, ali je uporabnik nanje naročen ali ne. Dolžina seznama = približno številu uporabnikovih prijateljev, pri čemer naj bo za polovico označenih prijateljev odgovor »Da«, za drugo polovico pa »Ne«. Preverjanje poteka v takem vrstnem redu, da se izmenjujeta odgovora "Da" in "Ne" (to pomeni, da bomo morali v vsakem drugem primeru iti skozi vse stolpce vrstice za možnosti 1 in 2). Skupni čas presejanja se nato deli s številom testiranih prijateljev, da dobimo povprečni čas presejanja na osebo.
- Brisanje podatkov. Odstranite vse prijatelje od uporabnika. Poleg tega je vrstni red brisanja naključen (to pomeni, da »premešamo« prvotni seznam, ki se uporablja za zapis podatkov). Skupni čas preverjanja se nato deli s številom odstranjenih prijateljev, da dobimo povprečni čas preverjanja.
Scenariji je treba izvajati za vsako od 5 možnosti podatkovnega modela in za različne velikosti družbenega omrežja, da vidimo, kako se čas spreminja, ko raste. Znotraj enega n morajo biti povezave v omrežju in seznam uporabnikov za preverjanje seveda enaki za vseh 5 možnosti.
Za boljše razumevanje je spodaj primer ustvarjenih podatkov za n= 5. Zapisani »generator« kot izhod ustvari tri slovarje ID-jev:
- prvi je za vstavljanje
- drugi je za preverjanje
- tretji – za izbris
{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 друзей
Kot lahko vidite, so vsi ID-ji, večji od 10 v slovarju za preverjanje, ravno tisti, ki bodo zagotovo dali odgovor False. Vstavljanje, preverjanje in brisanje »prijateljev« poteka natančno v zaporedju, določenem v slovarju.
Poskus je bil izveden na prenosniku z operacijskim sistemom Windows 10, kjer je HBase deloval v enem vsebniku Docker, Python z Jupyter Notebook pa v drugem. Dockerju sta bili dodeljeni 2 jedri procesorja in 2 GB RAM-a. Vsa logika, kot je emulacija »pogojne aplikacije« in »cevi« za generiranje testnih podatkov in merjenje časa, je bila napisana v Pythonu. Knjižnica je bila uporabljena za delo s HBase , za izračun zgoščenih vrednosti (MD5) za možnost 5 - hashlib
Ob upoštevanju računalniške moči posameznega prenosnika je bil poskusno izbran zagon za n = 10, 30, …. 170 – ko je bil skupni čas delovanja celotnega cikla testiranja (vsi scenariji za vse možnosti za vse n) še bolj ali manj razumen in primeren za eno čajanko (povprečno 15 minut).
Tukaj je treba poudariti, da v tem poskusu ne ocenjujemo predvsem absolutnih številk uspešnosti. Tudi relativna primerjava različnih dveh možnosti morda ni povsem pravilna. Zdaj nas zanima narava spremembe časa v odvisnosti od n, saj je ob upoštevanju zgornje konfiguracije "testnega stojala" zelo težko dobiti časovne ocene, "očiščene" vpliva naključnih in drugih dejavnikov ( in taka naloga ni bila postavljena).
Rezultat poskusa
Prvi preizkus je, kako se spremeni čas, porabljen za izpolnjevanje seznama prijateljev. Rezultat je v spodnjem grafu.
Možnosti 3-5 pričakovano prikazujejo skoraj konstanten čas »poslovne transakcije«, ki ni odvisen od rasti velikosti omrežja in nerazločljive razlike v uspešnosti.
Možnost 2 prav tako kaže konstantno, vendar nekoliko slabšo učinkovitost, skoraj natančno 2-krat glede na možnosti 3-5. In to ne more razveseliti, saj je v skladu s teorijo - v tej različici je število V/I operacij v/iz HBase natančno 2-krat večje. To je lahko posreden dokaz, da naša preskusna naprava načeloma zagotavlja dobro natančnost.
Možnost 1 se prav tako po pričakovanjih izkaže za najpočasnejšo in dokazuje linearno povečanje časa, porabljenega za medsebojno dodajanje velikosti omrežja.
Poglejmo zdaj rezultate drugega testa.
Možnosti 3-5 se spet obnašajo po pričakovanjih - konstanten čas, neodvisen od velikosti omrežja. Možnosti 1 in 2 prikazujeta linearno povečanje časa, ko se poveča velikost omrežja, in podobno zmogljivost. Poleg tega se možnost 2 izkaže za nekoliko počasnejšo - očitno zaradi potrebe po lektoriranju in obdelavi dodatnega stolpca »štetje«, ki postane bolj opazen, ko n raste. Vendar se bom vseeno vzdržal kakršnih koli zaključkov, saj je točnost te primerjave relativno nizka. Poleg tega so se ta razmerja (katera možnost, 1 ali 2, je hitrejša) spreminjala od zagona do zagona (medtem ko se je ohranila narava odvisnosti in "grelo na vrat na nos").
No, zadnji graf je rezultat testiranja odstranitve.
Tudi tu ni presenečenj. Možnosti 3-5 izvajajo odstranitev v konstantnem času.
Poleg tega, zanimivo, možnosti 4 in 5, za razliko od prejšnjih scenarijev, kažeta opazno nekoliko slabšo zmogljivost kot možnost 3. Očitno je operacija brisanja vrstice dražja od operacije brisanja stolpca, kar je na splošno logično.
Možnosti 1 in 2 po pričakovanjih prikazujeta linearno povečanje časa. Hkrati je možnost 2 dosledno počasnejša od možnosti 1 - zaradi dodatne V/I operacije za "vzdrževanje" stolpca štetja.
Splošni zaključki poskusa:
- Možnosti 3–5 kažejo večjo učinkovitost, saj izkoriščajo HBase; Poleg tega se njihova zmogljivost med seboj razlikuje za konstanto in ni odvisna od velikosti omrežja.
- Razlika med možnostma 4 in 5 ni bila zabeležena. Vendar to ne pomeni, da možnosti 5 ne bi smeli uporabiti. Verjetno je, da uporabljeni eksperimentalni scenarij, ob upoštevanju značilnosti delovanja preskusne naprave, ni omogočil odkritja.
- Narava povečanja časa, potrebnega za opravljanje »poslovnih operacij« s podatki, je na splošno potrdila predhodno pridobljene teoretične izračune za vse možnosti.
Epilog
Opravljenih grobih poskusov ne bi smeli jemati kot absolutno resnico. Obstaja veliko dejavnikov, ki niso bili upoštevani in so popačili rezultate (ta nihanja so še posebej vidna na grafih z majhno velikostjo omrežja). Na primer hitrost varčevanja, ki jo uporablja happybase, obseg in način implementacije logike, ki sem jo napisal v Pythonu (ne morem trditi, da je bila koda napisana optimalno in je učinkovito izkoristila zmožnosti vseh komponent), morda funkcije predpomnjenja HBase, dejavnosti v ozadju sistema Windows 10 na mojem prenosniku itd. Na splošno lahko domnevamo, da so vsi teoretični izračuni eksperimentalno dokazali svojo veljavnost. No, ali pa jih vsaj ni bilo mogoče ovreči s takšnim "čelnim napadom".
Za zaključek priporočila za vse, ki šele začenjate oblikovati podatkovne modele v HBase: abstrahirajte prejšnje izkušnje pri delu z relacijskimi bazami podatkov in se spomnite »zapovedi«:
- Pri načrtovanju izhajamo iz naloge in vzorcev manipulacije podatkov in ne iz domenskega modela
- Učinkovit dostop (brez pregleda celotne tabele) – samo po ključu
- Denormalizacija
- Različne vrstice lahko vsebujejo različne stolpce
- Dinamična kompozicija zvočnikov
Vir: www.habr.com