Hei Habr.
Nimeni on Misha Butrimov, haluaisin kertoa sinulle hieman Cassandrasta. Tarinani on hyödyllinen niille, jotka eivät ole koskaan törmänneet NoSQL-tietokantoihin - siinä on paljon toteutusominaisuuksia ja sudenkuoppia, jotka sinun on tiedettävä. Ja jos et ole nähnyt mitään muuta kuin Oraclen tai minkä tahansa muun relaatiotietokannan, nämä asiat pelastavat henkesi.
Mikä Cassandrassa on niin hyvää? Se on NoSQL-tietokanta, joka on suunniteltu ilman yhtäkään vikakohtaa ja joka skaalautuu hyvin. Jos joudut lisäämään pari teratavua johonkin tietokantaan, lisää vain solmuja renkaaseen. Laajenna se toiseen datakeskukseen? Lisää solmuja klusteriin. Lisätäänkö käsiteltyä RPS:ää? Lisää solmuja klusteriin. Toimii myös päinvastaiseen suuntaan.
Missä muussa hän on hyvä? Kyse on monien pyyntöjen käsittelystä. Mutta kuinka paljon on paljon? 10, 20, 30, 40 tuhatta pyyntöä sekunnissa ei ole paljon. 100 tuhatta tallennuspyyntöä sekunnissa - myös. Jotkut yritykset sanoivat säilyttävänsä 2 miljoonaa pyyntöä sekunnissa. Heidän on luultavasti uskottava se.
Ja periaatteessa Cassandralla on yksi suuri ero relaatiodataan - se ei ole ollenkaan samanlainen kuin he. Ja tämä on erittäin tärkeää muistaa.
Kaikki, mikä näyttää samalta, ei toimi samalla tavalla
Kerran eräs kollega tuli luokseni ja kysyi: "Tässä on CQL Cassandra -kyselykieli, ja siinä on select-lause, sillä on missä, sillä on ja. Kirjoitan kirjeitä ja se ei toimi. Miksi?". Cassandran kohtelu relaatiotietokannana on täydellinen tapa tehdä väkivaltainen itsemurha. Enkä mainosta sitä, se on kielletty Venäjällä. Suunnittelet vain jotain väärin.
Esimerkiksi asiakas tulee meille ja sanoo: ”Rakennetaan tietokanta tv-sarjoille tai tietokanta reseptihakemistolle. Meillä on siellä ruoka-annoksia tai luettelo tv-sarjoista ja näyttelijöistä." Sanomme iloisesti: "Mennään!" Lähetä vain kaksi tavua, pari merkkiä ja olet valmis, kaikki toimii erittäin nopeasti ja luotettavasti. Ja kaikki on hyvin, kunnes asiakkaat tulevat ja sanovat, että kotiäidit ratkaisevat myös päinvastaisen ongelman: heillä on tuotelista ja he haluavat tietää, mitä ruokaa he haluavat valmistaa. Olet kuollut.
Tämä johtuu siitä, että Cassandra on hybriditietokanta: se tarjoaa samanaikaisesti avainarvon ja tallentaa tiedot leveisiin sarakkeisiin. Javalla tai Kotlinilla sitä voitaisiin kuvata näin:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
Eli kartta, joka sisältää myös lajitellun kartan. Ensimmäinen avain tälle kartalle on riviavain tai osioavain - osiointiavain. Toinen avain, joka on avain jo lajiteltuun karttaan, on klusteriavain.
Havainnollistaaksemme tietokannan jakautumista piirretään kolme solmua. Nyt sinun on ymmärrettävä, kuinka tiedot jaetaan solmuihin. Koska jos kokoamme kaiken yhdeksi (muuten, niitä voi olla tuhat, kaksi tuhatta, viisi - niin monta kuin haluat), tämä ei todellakaan ole jakelusta. Siksi tarvitsemme matemaattisen funktion, joka palauttaa luvun. Vain numero, pitkä int, joka osuu jollekin alueelle. Ja meillä on yksi solmu, joka vastaa yhdestä alueesta, toinen toisesta, n:s yksi n:nnestä.
Tämä numero otetaan käyttämällä hash-funktiota, jota käytetään osioavaimeksi kutsumaan. Tämä on sarake, joka on määritetty Primary Key -direktiivissä, ja tämä on sarake, joka on kartan ensimmäinen ja perusavain. Se määrittää, mikä solmu vastaanottaa mitkä tiedot. Cassandrassa luodaan taulukko lähes samalla syntaksilla kuin SQL:ssä:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
Ensisijainen avain koostuu tässä tapauksessa yhdestä sarakkeesta, ja se on myös osiointiavain.
Miten käyttäjämme pärjäävät? Jotkut siirtyvät yhteen solmuun, toiset toiseen ja jotkut kolmanteen. Tuloksena on tavallinen hash-taulukko, joka tunnetaan myös nimellä kartta, joka tunnetaan myös Pythonissa sanakirjana, tai yksinkertainen Key-arvorakenne, josta voimme lukea kaikki arvot, lukea ja kirjoittaa avaimella.
Valitse: milloin salli suodatus muuttuu täydelliseksi skannaukseksi tai mitä ei tehdä
Kirjoitetaan jokin valittu lausunto: select * from users where, userid = . Se käy kuin Oraclessa: kirjoitamme Select, määritämme ehdot ja kaikki toimii, käyttäjät saavat sen. Mutta jos valitset esimerkiksi käyttäjän, jolla on tietty syntymävuosi, Cassandra valittaa, ettei se pysty täyttämään pyyntöä. Koska hän ei tiedä yhtään mitään siitä, kuinka jaamme tietoja syntymävuodesta - hänellä on vain yksi sarake merkittynä avaimeksi. Sitten hän sanoo: "Okei, voin silti täyttää tämän pyynnön. Lisää salli suodatus." Lisäämme direktiivin, kaikki toimii. Ja tällä hetkellä tapahtuu jotain kauheaa.
Kun käytämme testitietoja, kaikki on kunnossa. Ja kun suoritat kyselyn tuotannossa, jossa meillä on esimerkiksi 4 miljoonaa tietuetta, niin kaikki ei ole kovin hyvin meille. Koska salli suodatus on käsky, jonka avulla Cassandra voi kerätä kaikki tiedot tästä taulukosta kaikista solmuista, kaikista datakeskuksista (jos niitä on useita tässä klusterissa) ja vasta sitten suodattaa ne. Tämä on Full Scanin analogi, ja tuskin kukaan on siitä iloinen.
Jos tarvitsisimme käyttäjiä vain tunnuksella, pärjäisimme tässä. Mutta joskus meidän on kirjoitettava muita kyselyitä ja asetettava valinnalle muita rajoituksia. Siksi muistamme: tämä kaikki on kartta, jossa on osiointiavain, mutta sen sisällä on lajiteltu kartta.
Ja hänellä on myös avain, jota kutsumme klusteriavaimeksi. Tämä avain, joka puolestaan koostuu valitsemistamme sarakkeista, joiden avulla Cassandra ymmärtää, kuinka sen tiedot fyysisesti lajitellaan ja sijaitsevat jokaisessa solmussa. Toisin sanoen jollekin osioavaimelle klusteriavain kertoo tarkalleen, kuinka tiedot työnnetään tähän puuhun, minkä paikan se vie siellä.
Tämä on todella puu, siellä kutsutaan yksinkertaisesti vertailijaa, jolle välitämme tietyn joukon sarakkeita objektin muodossa, ja se määritetään myös sarakeluetteloksi.
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
Kiinnitä huomiota Primary Key -direktiiviin; sen ensimmäinen argumentti (tapauksessamme vuosi) on aina osioavain. Se voi koostua yhdestä tai useammasta sarakkeesta, sillä ei ole väliä. Jos sarakkeita on useita, se on poistettava uudelleen suluissa, jotta kielen esikäsittelijä ymmärtää, että tämä on ensisijainen avain ja sen takana kaikki muut sarakkeet ovat Clustering-avain. Tässä tapauksessa ne lähetetään vertailijassa siinä järjestyksessä, jossa ne näkyvät. Eli ensimmäinen sarake on merkittävämpi, toinen vähemmän merkittävä ja niin edelleen. Kirjoitustapa vastaa esimerkiksi tietoluokkien kenttiä: listaamme kentät ja kirjoitamme niille, mitkä ovat suurempia ja mitkä pienempiä. Cassandrassa nämä ovat suhteellisesti sanottuna tietoluokan kenttiä, joihin sovelletaan sille kirjoitettuja yhtäläisiä.
Asetamme lajittelun ja asetamme rajoituksia
Sinun tulee muistaa, että lajittelujärjestys (laskeva, nouseva, mikä tahansa) asetetaan avaimen luomisen yhteydessä, eikä sitä voi muuttaa myöhemmin. Se määrittää fyysisesti, kuinka tiedot lajitellaan ja kuinka ne tallennetaan. Jos sinun on muutettava klusteriavainta tai lajittelujärjestystä, sinun on luotava uusi taulukko ja siirrettävä siihen tiedot. Tämä ei toimi olemassa olevan kanssa.
Täytimme pöytämme käyttäjillä ja näimme, että he putosivat kehään ensin syntymävuoden mukaan ja sitten jokaisen solmun sisällä palkan ja käyttäjätunnuksen mukaan. Nyt voimme valita asettamalla rajoituksia.
Toimivamme ilmestyy taas where, and, ja saamme käyttäjiä, ja kaikki on taas hyvin. Mutta jos yritämme käyttää vain osaa klusteriavaimesta ja vähemmän merkittävää, Cassandra valittaa heti, ettei se löydä karttastamme paikkaa, jossa tämä objekti, jolla on nämä kentät nollavertailijalle, ja tämä se oli juuri asetettu , - missä hän makaa. Minun on haettava kaikki tiedot tästä solmusta uudelleen ja suodatettava se. Ja tämä on analoginen Full Scanin solmussa, tämä on huono.
Jos tilanne on epäselvä, luo uusi taulukko
Jos haluamme kohdistaa käyttäjiä tunnuksen, iän tai palkan perusteella, mitä meidän pitäisi tehdä? Ei mitään. Käytä vain kahta pöytää. Jos haluat tavoittaa käyttäjät kolmella eri tavalla, taulukkoja on kolme. Menneet ovat ajat, jolloin säästimme tilaa ruuvilla. Tämä on halvin resurssi. Se maksaa paljon vähemmän kuin vasteaika, mikä voi olla haitallista käyttäjälle. Käyttäjälle on paljon miellyttävämpää saada jotain sekunnissa kuin 10 minuutissa.
Vaihdamme tarpeettoman tilan ja denormaalin datan, jotta voimme skaalata hyvin ja toimia luotettavasti. Itse asiassa klusteri, joka koostuu kolmesta palvelinkeskuksesta, joissa kussakin on viisi solmua ja joiden tietojen säilytystaso on hyväksyttävä (kun mitään ei häviä), pystyy selviytymään täysin yhden palvelinkeskuksen kuolemasta. Ja kaksi muuta solmua jokaisessa jäljellä olevassa kahdessa. Ja vasta tämän jälkeen ongelmat alkavat. Tämä on melko hyvä redundanssi, parin ylimääräisen SSD-aseman ja prosessorin arvoinen. Siksi, jotta voit käyttää Cassandraa, joka ei koskaan ole SQL, jossa ei ole suhteita, vieraita avaimia, sinun on tiedettävä yksinkertaiset säännöt.
Suunnittelemme kaiken toiveidesi mukaan. Tärkeintä ei ole tiedot, vaan se, miten sovellus toimii niiden kanssa. Jos sen tarvitsee vastaanottaa erilaista dataa eri tavoin tai samaa dataa eri tavoilla, meidän on asetettava se sovellukselle sopivalla tavalla. Muuten epäonnistumme Full Scanissa, eikä Cassandra anna meille mitään etua.
Tietojen denormalisointi on normaalia. Unohdamme normaalit muodot, meillä ei ole enää relaatiotietokantoja. Jos laitamme jotain maahan 100 kertaa, se makaa 100 kertaa. Se on silti halvempaa kuin pysähtyminen.
Valitsemme osiointiavaimet niin, että ne jakautuvat normaalisti. Emme halua avaimemme hajautusarvon putoavan yhdelle kapealle alueelle. Eli syntymävuosi yllä olevassa esimerkissä on huono esimerkki. Tarkemmin sanottuna on hyvä, jos käyttäjämme jakautuvat normaalisti syntymävuosien mukaan, ja huono, jos puhumme 5. luokan oppilaista - osiointi siellä ei ole kovin hyvä.
Lajittelu valitaan kerran klusteriavaimen luontivaiheessa. Jos sitä on muutettava, meidän on päivitettävä taulukkomme toisella avaimella.
Ja mikä tärkeintä: jos meidän on haettava samat tiedot 100 eri tavalla, meillä on 100 erilaista taulukkoa.
Lähde: will.com