Den Dåliga : Partitionering
en av de tuffa sakerna att vänja sig vid först är att utan några indexfrågor som spänner över rader kan (mycket) vara dåliga. Att tänka tillbaka till vår lagringsmodell är dock inte förvånande. Strategin som Cassandra använder för att distribuera raderna över värdar kallas partitionering.
partitionering är handlingen att skära upp utbudet av rowkeys som tilldelar dem till ”token ring”, som också tilldelar ansvaret för ett segment (dvs. partition) av rowkey-intervallet till varje värd. Du har förmodligen sett detta när du initierade ditt kluster med en ”token”. Token ger värden en plats längs tokenringen, som tilldelar ansvaret för en del av tokenområdet. Partitionering är handlingen att kartlägga radnyckeln i tokenområdet.
det finns två primära partitioners: Random och ordning bevara. De är lämpligt namngivna. Den RandomPartitioner hashes rowkeys i tokens. Med RandomPartitioner är token en hash av rowkey. Detta gör ett bra jobb med att jämnt fördela dina data över en uppsättning noder, men gör det otroligt svårt att fråga ett intervall av rowkey-utrymmet. Från bara ett ”start rowkey” – värde och ett ”end rowkey” – värde kan Cassandra inte bestämma vilket intervall av tokenutrymmet du behöver. Det behöver i huvudsak utföra en” tabellsökning ”för att svara på frågan, och en” tabellsökning ” i Cassandra är dålig eftersom den måste gå till varje maskin (troligtvis alla maskiner om du har en bra hashfunktion) för att svara på frågan.
det goda: sekundära index
Cassandra tillhandahåller en inbyggd indexeringsmekanism i sekundära index. Sekundära index fungerar av kolumnvärdena. Du deklarerar ett sekundärt index på en Kolumnfamilj. Datastax har bra dokumentation om användningen. Under huven upprätthåller Cassandra en” dold kolumnfamilj ” som index. (Se Ed Anuffs presentation för detaljer) eftersom Cassandra inte behåller kolumnvärdesinformation i någon nod och sekundära index är på kolumnvärde (snarare än rowkeys), måste en fråga fortfarande skickas till alla noder. Dessutom rekommenderas inte sekundära index för uppsättningar med hög kardinalitet. Jag har inte tittat ännu, men jag antar att det här beror på datamodellen som används inom ”hidden column family”. Om den dolda kolumnfamiljen lagrar en rad per unikt värde (med radnycklar som kolumner), skulle det innebära att skanna raderna för att avgöra om de ligger inom intervallet i frågan.
från Eds presentation:
- rekommenderas inte för höga kardinalitetsvärden (dvs. tidsstämplar,födelsedatum,nyckelord etc.)
- kräver minst en jämlikhetsjämförelse i en fråga-inte bra för mindre än/större än / intervallfrågor
- osorterade-resultaten är i tokenordning, inte frågevärdesordning
- begränsad till sökning på datatyper, Cassandra förstår nativt
med allt detta sagt, sekundära index fungerar ur lådan och vi har haft god framgång med att använda dem på enkla värden.
den fula: gör-det-själv (DIY) / breda rader
nu är skönheten i betraktarens öga. En av de vackra sakerna med NoSQL är enkelheten. Konstruktionerna är enkla: Nyckelrum, kolumnfamiljer, rader och kolumner. Att hålla det enkelt men betyder ibland att du måste ta saker i egna händer.
Detta är fallet med breda radindex. Med hjälp av Cassandras lagringsmodell är det enkelt att bygga egna index där varje radnyckel blir en kolumn i indexet. Detta är ibland svårt att få huvudet runt, men låt oss föreställa oss att vi har ett fall där vi vill välja alla användare i ett Postnummer. Huvudanvändarkolumnfamiljen är knappad på userid, postnummer är en kolumn på varje användarrad. Vi kan använda sekundära index, men det finns en hel del Postnummer. Istället kunde vi behålla en kolumnfamilj med en enda rad som heter ”idx_zipcode”. Vi kunde sedan skriva kolumner i denna rad i formuläret ”zipcode_userid”. Eftersom kolumnerna lagras i sorterad ordning är det snabbt att fråga efter alla kolumner som börjar med ”18964” (t.ex. kan vi använda 18964_ och 18964_zzzzzz som start-och slutvärden).
en uppenbar nackdel med detta tillvägagångssätt är att rader är fristående på en värd. (igen med undantag för repliker) detta innebär att alla frågor kommer att träffa en enda nod. Jag har ännu inte hittat ett bra svar på detta.