Cassandra indeksering: den gode, den dårlige og den grimme

Posted on by admin
inden for Noskl er operationerne med indeksering, hentning og søgning efter information tæt knyttet til de fysiske lagringsmekanismer. Det er vigtigt at huske, at rækker gemmes på tværs af værter, men en enkelt række gemmes på en enkelt vært. (med replikaer) Kolonnefamilier gemmes i sorteret rækkefølge, hvilket gør forespørgsel på et sæt kolonner effektivt (forudsat at du spænder over rækker).

Den Dårlige : Partitionering

en af de hårde ting at vænne sig til i starten er, at uden indekser kan forespørgsler, der spænder over rækker, (meget) være dårlige. Når vi tænker tilbage på vores opbevaringsmodel, er det dog ikke overraskende. Den strategi, som Cassandra bruger til at distribuere rækkerne på tværs af værter, kaldes partitionering.

partitionering er handlingen med at udskære rækkevidden af rækketaster, der tildeler dem i “token ring”, som også tildeler ansvaret for et segment (dvs.partition) af rækketasteområdet til hver vært. Du har sikkert set dette, da du initialiserede din klynge med et “token”. Token giver værten en placering langs tokenringen, som tildeler ansvaret for en del af tokenområdet. Partitionering er handlingen med at kortlægge rækkenøglen i tokenområdet.

der er to primære partitionere: tilfældig og Ordrebevarelse. De er passende navngivet. RandomPartitioner hashes rækkerne i tokens. Med RandomPartitioner er token en hash af rækkenøglen. Dette gør et godt stykke arbejde med jævnt at distribuere dine data på tværs af et sæt noder, men gør det utroligt vanskeligt at forespørge på en række af rækkenøgleområdet. Fra kun en” start rækkenøgle “- værdi og en” slut rækkenøgle ” – værdi kan Cassandra ikke bestemme, hvilket interval af det tokenrum du har brug for. Det skal i det væsentlige udføre en “tabelscanning” for at besvare forespørgslen, og en “tabelscanning” i Cassandra er dårlig, fordi den skal gå til hver maskine (sandsynligvis alle maskiner, hvis du har en god hash-funktion) for at besvare forespørgslen.

nu, til de store omkostninger ved jævn datadistribution, kan du ansætte Ordrepreserveringspartitioner (opp). Jeg er * ikke * nede med OPP. OPP bevarer ordren, da den oversætter rækketaster til tokens. Nu, givet en start-værdi og en slut-værdi, kan Cassandra * * bestemme nøjagtigt, hvilke værter der har de data, du leder efter. Det beregner startværdien til et token slutværdien til et token, og vælger og returnerer simpelthen alt imellem. Men ved at bevare ordren, medmindre dine rækketaster er jævnt fordelt over rummet, vil dine tokens heller ikke være, og du får en skæv klynge, hvilket i høj grad øger omkostningerne ved konfiguration og administration af klyngen. (ikke det værd)

det gode: sekundære indekser

Cassandra giver en indfødt indekseringsmekanisme i sekundære indekser. Sekundære indekser arbejde ud af kolonnerne værdier. Du erklærer et sekundært indeks på en Kolonnefamilie. Dataskat har god dokumentation om brugen. Under hætten opretholder Cassandra en” skjult søjlefamilie ” som indeks. (Se Ed Anuffs præsentation for detaljer) da Cassandra ikke opretholder kolonneværdioplysninger i en enkelt node, og sekundære indekser er på kolonneværdi (snarere end rækketaster), skal der stadig sendes en forespørgsel til alle noder. Derudover anbefales sekundære indekser ikke til sæt med høj kardinalitet. Jeg har ikke kigget endnu, men jeg antager, at dette er på grund af den datamodel, der bruges i “hidden column family”. Hvis den skjulte kolonnefamilie gemmer en række pr.entydig værdi (med rækketaster som kolonner), betyder det at scanne rækkerne for at afgøre, om de er inden for området i forespørgslen.
fra Ed ‘ s præsentation:

  • anbefales ikke til høje kardinalitetsværdier(dvs.tidsstempler,fødselsdatoer,nøgleord osv.)
  • kræver mindst en lighedssammenligning i en forespørgsel-ikke fantastisk til forespørgsler med mindre end/større end / rækkevidde
  • usorteret-resultaterne er i token-rækkefølge, ikke forespørgselsværdiordre
  • begrænset til søgning på datatyper, Cassandra forstår oprindeligt

med alt det sagt fungerer sekundære indekser ud af kassen, og vi har haft god succes med at bruge dem på enkle værdier.

den grimme: gør-det-selv (DIY) / brede rækker

nu, skønhed er i øjet af beskueren. En af de smukke ting ved Noskl er enkelheden. Konstruktionerne er enkle: Keyspaces, kolonne familier, rækker og kolonner. At holde det enkelt betyder dog nogle gange, at du skal tage tingene i egne hænder.

dette er tilfældet med brede rækker indekser. Ved hjælp af Cassandras lagringsmodel er det nemt at opbygge dine egne indekser, hvor hver række-nøgle bliver en kolonne i indekset. Dette er undertiden svært at få hovedet rundt, men lad os forestille os, at vi har en sag, hvor vi ønsker at vælge alle brugere i et Postnummer. De vigtigste brugere kolonne familie er indtastet på userid, postnummer er en kolonne på hver bruger række. Vi kunne bruge sekundære indekser, men der er en hel del postnumre. I stedet kunne vi opretholde en kolonnefamilie med en enkelt række kaldet “id_sipcode”. Vi kunne derefter skrive kolonner i denne række af formularen “sipcode_userid”. Da kolonnerne er gemt i sorteret rækkefølge, er det hurtigt at forespørge efter alle kolonner, der starter med “18964” (f.eks.

en åbenbar ulempe ved denne tilgang er, at rækker er selvstændige på en vært. (igen undtagen replikaer) det betyder, at alle forespørgsler kommer til at ramme en enkelt node. Jeg har endnu ikke fundet et godt svar på dette.

derudover, og IMHO, den grimeste del af DIY-indeksering i bred række er fra et klientperspektiv. I vores implementering har vi gjort vores bedste for at være Sprog agnostiker på klientsiden, så folk kan vælge det bedste værktøj til jobbet til at interagere med dataene i Cassandra. Med den mentalitet giver DIY-indekserne nogle problemer. Brede rækker bruger ofte sammensatte nøgler (forestil dig, om du havde en idks_state_sip, som giver dig mulighed for at forespørge efter stat og derefter lynlås). Selvom der er” native ” support til sammensatte nøgler, implementerer alle klientbibliotekerne deres egen version af dem (Hector, Astyanaks og sparsommelighed). Dette betyder, at klient, der har brug for at forespørge data, skal have den tilføjede logik til først at forespørge indekset, og derudover skal alle klienter konstruere den sammensatte nøgle på samme måde.

Gør Det Bedre…

af denne grund har vi besluttet at frigive to open source-projekter, der hjælper med at skubbe denne logik til serversiden. Det første projekt er Cassandra-Triggers. Dette giver dig mulighed for at vedhæfte asynkrone aktiviteter til at skrive i Cassandra. (en sådan aktivitet kunne være indeksering) vi har også udgivet Cassandra-indeksering. Det understøtter kun Ut8typer i indekset), men hensigten er at give en generisk server-side mekanisme, der indekserer data som dens skrevet til Cassandra. Anvender den samme server-side teknik, som vi brugte i Cassandra-indeksering, du konfigurerer blot de kolonner, du vil indeksere, og AOP-koden gør resten, mens du skriver til målet jf. Som altid er spørgsmål, kommentarer og tanker velkomne. (især hvis jeg er off-base et eller andet sted)

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.