Kaixo Habr.
Nire izena Misha Butrimov da, Cassandrari buruz apur bat kontatu nahiko nuke. Nire istorioa erabilgarria izango da inoiz NoSQL datu-baseak topatu ez dituztenentzat - jakin behar dituzun inplementazio-ezaugarri eta hutsune asko ditu. Eta Oracle edo beste datu-base erlazional bat baino beste ezer ikusi ez baduzu, gauza hauek zure bizitza salbatuko dute.
Zer da hain ona Cassandra? Ondo eskalatzen den huts-puntu bakar bat gabe diseinatutako NoSQL datu-base bat da. Datu-base batzuetarako terabyte pare bat gehitu behar badituzu, eraztunean nodoak gehitu besterik ez duzu. Beste datu-zentro batera zabaldu nahi duzu? Gehitu nodoak clusterra. Prozesatutako RPS handitu? Gehitu nodoak clusterra. Kontrako norabidean ere funtzionatzen du.
Zer gehiagotan da ona? Eskaera asko kudeatzea da. Baina zenbat da asko? 10, 20, 30, 40 mila eskaera segundoko ez dira asko. Grabatzeko 100 mila eskaera segundoko ere bai. Badira segundoko 2 milioi eskaera mantentzen dituztela esan duten enpresak. Seguruenik sinetsi beharko dute.
Eta, printzipioz, Cassandra-k desberdintasun handi bat du datu erlazionalekiko - ez da batere antzekoa. Eta hori oso garrantzitsua da gogoratzea.
Itxura berdina duen guztiak ez du berdin funtzionatzen
Behin lankide bat etorri zitzaidan eta galdetu zidan: “Hona hemen CQL Cassandra kontsulta-lengoaia bat, eta hautatutako adierazpena du, non dauka, dauka eta. Gutunak idazten ditut eta ez du funtzionatzen. Zergatik?". Cassandra datu-base erlazional gisa tratatzea bere buruaz beste bortitza egiteko modu ezin hobea da. Eta ez dut sustatzen ari, debekatuta dago Errusian. Zerbait gaizki diseinatuko duzu.
Esaterako, bezero bat etortzen zaigu eta honela esaten du: “Eraiki dezagun telesailentzako datu-base bat, edo errezeten direktorio baterako datu-base bat. Bertan janari-platerak edo telesail eta aktoreen zerrenda bat izango dugu bertan». Pozik esaten dugu: «Goazen!». Bi byte, seinale pare bat bidali eta listo, dena oso azkar eta fidagarrian funtzionatuko du. Eta dena ondo dago bezeroak etortzen diren arte etxekoandreak ere kontrako arazoa konpontzen ari direla: produktuen zerrenda dute, eta jakin nahi dute zer plater prestatu nahi duten. Hilda zaude.
Cassandra datu-base hibrido bat delako gertatzen da: aldi berean gako-balio bat ematen du eta datuak zutabe zabaletan gordetzen ditu. Javan edo Kotlin-en, honela deskriba liteke:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Hau da, mapa ordenatua ere baduena. Mapa honetako lehen gakoa Errenkada-gakoa edo Partizio-gakoa da - partizio-gakoa. Bigarren gakoa, dagoeneko ordenatuta dagoen mapa baten gakoa, Clustering gakoa da.
Datu-basearen banaketa ilustratzeko, marraz ditzagun hiru nodo. Orain datuak nodoetan nola deskonposatu ulertu behar duzu. Zeren dena bakarrean sartzen badugu (bide batez, mila, bi mila, bost izan daitezke - nahi adina), hau ez da benetan banaketa. Beraz, zenbaki bat itzuliko duen funtzio matematiko bat behar dugu. Zenbaki bat besterik ez, tarte batean eroriko den int luze bat. Eta nodo bat izango dugu barruti baten arduraduna, bigarrena bigarrena, ngarrena ngarrena.
Zenbaki hau hash funtzio bat erabiliz hartzen da, Partizio-gakoa deitzen diogun horri aplikatzen zaiona. Hau da Lehen mailako gako zuzentarauan zehazten den zutabea, eta mapako lehen eta oinarrizko gako izango den zutabea da. Zein nodok zein datu jasoko dituen zehazten du. Cassandran taula bat sortzen da SQLren ia sintaxi berdinarekin:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Lehen gakoa, kasu honetan, zutabe batez osatuta dago, eta zatiketa-gakoa ere bada.
Nola egingo dute gure erabiltzaileek? Batzuk nodo batera joango dira, beste batzuk beste batera eta beste batzuk hirugarren batera. Emaitza hash taula arrunt bat da, mapa gisa ere ezagutzen dena, Python-en hiztegi gisa ere ezagutzen dena, edo gako-balioen egitura soil bat, non balio guztiak irakur ditzakegun, gakoz irakurri eta idatzi.
Hautatu: baimendu iragazketa eskaneatu osoa bihurtzen denean edo zer egin ez
Idatz ditzagun aukeratutako adierazpen batzuk: select * from users where, userid = . Oracle-n bezala gertatzen da: hautatu idazten dugu, baldintzak zehaztu eta dena funtzionatzen du, erabiltzaileek lortzen dute. Baina, adibidez, jaiotza-urte jakin bat duen erabiltzaile bat hautatzen baduzu, Cassandra salatu du ezin duela eskaera bete. Ez dakilako ezer nola banatzen ditugun jaiotze-urteari buruzko datuak - zutabe bakarra du gako gisa adierazita. Orduan esaten du: "Ongi, eskaera hau bete dezaket oraindik. Gehitu baimendu iragazketa." Zuzentaraua gehitzen dugu, dena funtzionatzen du. Eta momentu honetan zerbait izugarria gertatzen da.
Proba datuekin exekutatzen dugunean, dena ondo dago. Eta ekoizpenean kontsulta bat exekutatzen duzunean, non, adibidez, 4 milioi erregistro ditugun, orduan dena ez da oso ona guretzat. Baimendu iragazketa zuzentarau bat delako, Cassandra-k taula honetako datu guztiak nodo guztietatik, datu-zentro guztietatik (hauetako asko badaude kluster honetan) biltzeko aukera ematen duelako, eta orduan bakarrik iragaztea. Hau Full Scan-en analogoa da, eta ia inor ez dago gustura.
NAN bidez soilik erabiltzaileak beharko bagenitu, ondo egongo ginateke. Baina batzuetan beste kontsulta batzuk idatzi behar ditugu eta aukeraketari beste murrizketa batzuk ezarri. Hori dela eta, gogoan dugu: hau guztia partizio-gako bat duen mapa bat da, baina barruan mapa ordenatua dago.
Eta gako bat ere badu, Clustering Key deitzen dioguna. Gako hau, aldi berean, hautatzen ditugun zutabeek osatzen dute, eta horren laguntzaz Cassandrak ulertzen du nola bere datuak fisikoki ordenatzen diren eta nodo bakoitzean kokatuko diren. Hau da, Partizio-gako batzuentzat, Clustering gakoak esango dizu zehazki nola bidali datuak zuhaitz honetara, zein leku hartuko duen bertan.
Hau benetan zuhaitz bat da, konparatzaile bat besterik ez da deitzen bertan, zeinari zutabe multzo jakin bat pasatzen diogu objektu moduan, eta zutabeen zerrenda gisa ere zehazten da.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Erreparatu Lehen mailako gakoaren zuzentarauari; bere lehen argumentua (gure kasuan, urtea) beti da Partizio-gakoa. Zutabe batez edo gehiagoz osatuta egon daiteke, berdin dio. Hainbat zutabe badaude, berriro parentesi artean kendu behar da hizkuntza-aurreprozesadoreak uler dezan hau Lehen mailako gakoa dela, eta horren atzean beste zutabe guztiak Clustering gakoa daudela. Kasu honetan, konparatzailean transmitituko dira, agertzen diren ordenan. Hau da, lehen zutabea esanguratsuagoa da, bigarrena ez hain esanguratsua, eta abar. Nola idazten dugun, adibidez, datu-klaseetarako eremuak berdinak dira: eremuak zerrendatzen ditugu, eta haientzat zeintzuk diren handiagoak eta zein txikiagoak idazten ditugu. Cassandra-n, hauek dira, erlatiboki hitz eginez, datu-klasearen eremuak, eta horretarako idatzitako berdinak aplikatuko zaizkie.
Sailkapena ezarri eta murrizketak ezartzen ditugu
Gogoratu behar duzu ordenaren ordena (beheranzkoa, goranzkoa, dena delakoa) gakoa sortzen den une berean ezartzen dela, eta ezin dela geroago aldatu. Datuak nola ordenatuko diren eta nola gordeko diren fisikoki zehazten du. Clustering gakoa edo ordenatzeko ordena aldatu behar baduzu, taula berri bat sortu eta hara datuak transferitu beharko dituzu. Honek ez du funtzionatuko lehendik dagoen batekin.
Gure mahaia erabiltzailez bete genuen eta ikusi genuen eraztun batean erortzen zirela, lehenengo jaiotze-urtearen arabera, eta ondoren nodo bakoitzaren barruan soldata eta erabiltzailearen IDaren arabera. Orain murrizketak ezarriz hauta dezakegu.
Gure lanean berriro agertzen da where, and, eta erabiltzaileak lortzen ditugu, eta dena ondo dago berriro. Baina Clustering gakoaren zati bat bakarrik erabiltzen saiatzen bagara, eta ez hain esanguratsua den beste bat, orduan Cassandra berehala salatuko da ezin duela aurkitu gure mapan konparatzaile nulurako eremu hauek dituen objektu honek eta hau. hori ezarri berri zen, - non dagoen. Nodo honetako datu guztiak berriro atera eta iragazi beharko ditut. Eta hau nodo baten barruan eskaneatzea osoaren analogoa da, hau txarra da.
Argi ez dagoen edozein egoeratan, sortu taula berri bat
Erabiltzaileak NANaren, edo adinaren, edo soldataren arabera bideratu ahal izan nahi baditugu, zer egin behar dugu? Ezer ez. Erabili bi mahai besterik ez. Erabiltzaileengana hiru modu ezberdinetara iritsi behar baduzu, hiru mahai egongo dira. Joan dira torlojuan lekua aurrezten genuen garaiak. Hau da baliabide merkeena. Erantzun denbora baino askoz gutxiago kostatzen da, eta horrek kaltegarria izan dezake erabiltzailearentzat. Erabiltzailearentzat askoz atseginagoa da segundo batean zerbait jasotzea 10 minututan baino.
Behar ez den espazioa eta datu desnormalizatuak trukatzen ditugu ondo eskalatzeko eta modu fidagarrian funtzionatzeko. Azken finean, izan ere, hiru datu-zentroz osatutako kluster bat, bakoitzak bost nodo dituena, datuen kontserbazio-maila onargarria duena (ezer galtzen ez denean), datu-zentro baten heriotzatik guztiz bizirauteko gai da. Eta beste bi nodo gainontzeko bietan. Eta honen ondoren bakarrik hasten dira arazoak. Hau nahiko erredundantzia ona da, SSD unitate eta prozesadore gehigarri pare bat merezi du. Hori dela eta, Cassandra erabiltzeko, inoiz SQL ez dena, harremanik ez dagoenean, atzerriko gakoak, arau errazak ezagutu behar dituzu.
Dena zure eskaeraren arabera diseinatzen dugu. Gauza nagusia ez dira datuak, aplikazioak nola funtzionatuko duen baizik. Datu desberdinak modu ezberdinetan edo datu berdinak modu ezberdinetan jaso behar baditu, aplikaziorako erosoa den moduan jarri behar dugu. Bestela, Full Scann huts egingo dugu eta Cassandrak ez digu inolako abantailarik emango.
Datuak desnormalizatzea normala da. Forma normalak ahazten ditugu, jada ez ditugu datu-base erlazionalak. Zerbait 100 aldiz jartzen badugu, 100 aldiz etzango da. Oraindik gelditzea baino merkeagoa da.
Partiziorako gakoak hautatzen ditugu normaltasunez banatu daitezen. Ez dugu nahi gure giltzen hash-a sorta estu batean erortzea. Hau da, goiko adibideko jaiotza urtea adibide txarra da. Zehatzago esanda, ona da gure erabiltzaileak jaiotza-urtearen arabera banatzen badira normalean, eta txarra 5. mailako ikasleei buruz ari bagara - han banatzea ez da oso ona izango.
Ordenatzea behin hautatzen da Clustering Key sortzeko fasean. Aldatu behar bada, gure taula eguneratu beharko dugu beste gako batekin.
Eta garrantzitsuena: datu berdinak 100 modu ezberdinetan berreskuratu behar baditugu, orduan 100 taula ezberdin izango ditugu.
Iturria: www.habr.com