skalbar, distribuerad sekundär indexering i Scylla

datamodellen i Scylla och Apache Cassandra partitionerar data mellan klusternoder med hjälp av en partitionsnyckel, som definieras av databasschemat. Att använda en partitionsnyckel ger ett effektivt sätt att slå upp rader med partitionsnyckeln eftersom du kan hitta noden som äger raden genom att Hasha partitionsnyckeln. Tyvärr betyder det också att hitta en rad med en icke-partitionsnyckel kräver en fullständig tabellsökning som är ineffektiv. Sekundära index är en mekanism i Apache Cassandra som möjliggör effektiva sökningar på icke-partitionsnycklar genom att skapa ett index.

i det här blogginlägget lär du dig:

• hur Apache Cassandra implementerar sekundära index med lokal indexering
• varför vi bestämde oss för att ta en annan implementeringsstrategi för Scylla med global indexering
• hur global indexering påverkar hur du ska använda sekundär indexering
• hur du skapar dina egna sekundära index och använder dem i din ansökan CQL-frågor

bakgrund

storleken på ett index är proportionell mot storleken på indexerade data. Eftersom data i Scylla och Apache Cassandra distribueras till flera noder är det opraktiskt att lagra hela indexet på en enda nod. Apache Cassandra implementerar sekundära index som lokala index, vilket innebär att indexet lagras på samma nod som data som indexeras från den noden. Fördelen med ett lokalt index är att skrivningar är mycket snabba, men nackdelen är att läsningar måste potentiellt fråga varje nod för att hitta indexet för att utföra en sökning på, vilket gör lokala index unscalable till stora kluster. Förutom de inhemska sekundära indexerna har Apache Cassandra också ett annat lokalt indexeringsschema, SSTable Attached Secondary Index (SASI), som stöder komplexa frågor och sökningar. Men ur skalbarhetssynpunkt har den exakt samma egenskaper som de ursprungliga sekundära indexen.

materialiserade vyer i Scylla och Apache Cassandra är en mekanism för att automatiskt denormalisera data från en bastabell till en vytabell med en annan partitionsnyckel. Detta löser skalbarhetsproblemet för lokala index men kommer till en lagringskostnad eftersom du i värsta fall måste duplicera hela tabellen. Materialiserade vyer ersätter därför inte sekundära index för alla användningsfall. Materialiserade vyer ger emellertid den nödvändiga infrastrukturen för att implementera sekundära index med global indexering, vilket är implementeringsmetoden för Scylla.

Global indexering

Scylla tar ett annat tillvägagångssätt än Apache Cassandra och implementerar sekundära index med global indexering. Med global indexering skapas en materialiserad vy för varje index. Den materialiserade Vyn har den indexerade kolumnen som partitionsnyckel och primärnyckel (partitionsnyckel och klustringstangenter) i den indexerade raden som klustringstangenter. Scylla delar indexerade frågor i två delar: (1) en fråga i indextabellen för att hämta partitionstangenter för den indexerade tabellen och (2) en fråga till den indexerade tabellen med de hämtade partitionstangenterna. Fördelen med detta tillvägagångssätt är att vi kan använda värdet på den indexerade kolumnen för att hitta motsvarande indextabellrad i klustret så läsningar är skalbara. Nackdelen med tillvägagångssättet är att skrivningar är långsammare än med lokal indexering på grund av alla kostnader från att hålla indexvyn uppdaterad.

fråga på en indexerad kolumn ser ut som följer. Låt oss anta ett bord som ser ut så här:

och en fråga i kolumnen email, som inte är en partitionsnyckel, men har ett index:

i fas (1) kommer frågan på nod 7, som fungerar som en koordinator för frågan. Noden märker att vi frågar på en indexerad kolumn och därför i fas (2) utfärdar en read to index-tabell på nod 2, som har indextabellraden för “”. Frågan returnerar en uppsättning användar-ID som används i fas (3) för att hämta innehållet i den indexerade tabellen.

exempel

vi måste först skapa ett schema. I det här exemplet har vi en tabell som representerar användarinformation med userid som partitionsnyckel och namn, e-post och land som vanliga kolumner:

vi fyller sedan tabellen med några testdata genererade med Mockaroo:

sekundära index är utformade för att möjliggöra effektiv sökning av nyckelkolumner som inte är partitioner. Medan Apache Cassandra också stöder frågor om icke-partitionsnyckelkolumner med ALLOW FILTERING, är det mycket ineffektivt (kräver skanning av hela tabellen) och stöds för närvarande inte av Scylla (se problem #2200 för detaljer).

du kan indexera tabellkolumner med uttrycket skapa INDEX. Till exempel, för att skapa index för e-post-och landskolumner, kör följande CQL-uttalanden:

Scylla skapar automatiskt en materialiserad vy som har den indexerade kolumnen som partitionsnyckel och måltabellens primärnyckel (partitionsnyckel och klustertangenter) som klustertangenter.

till exempel ser den materialiserade vyn för indexet på kolumnen email ut som följer:

om ovanstående vy skulle skapas som en vanlig tabell skulle den effektivt se ut som följer:

kolumnen email används som partitionsnyckel för indextabellen och userid ingår som en klusternyckel, vilket gör att vi effektivt kan hitta partitionsnycklar för måltabellen med bara email.

du kan använda kommandot DESCRIBE för att se hela schemat för tabellen ks.users, inklusive skapade index och vyer:

nu med det sekundära indexet på plats kan du fråga indexerade kolumner som om de var partitionstangenter:

vi är klara med exemplet!

När ska man använda sekundära index?

sekundära index är (mestadels) transparenta för applikationen. Frågor har tillgång till alla kolumner i tabellen och du kan lägga till och ta bort index utan att ändra programmet. Sekundära index kan också ha mindre lagringskostnader än materialiserade vyer eftersom sekundära index bara behöver duplicera den indexerade kolumnen och primärnyckeln, inte de frågade kolumnerna som med en materialiserad vy. Av samma anledning kan uppdateringar dessutom vara mer effektiva med sekundära index eftersom endast ändringar i primärnyckeln och den indexerade kolumnen orsakar en uppdatering i indexvyn. När det gäller en materialiserad vy kräver en uppdatering av någon av kolumnerna som visas i vyn att backing-vyn uppdateras.

som alltid beror beslutet om att använda sekundära index eller materialiserade vyer verkligen på kraven i din ansökan. Om du behöver maximal prestanda och sannolikt kommer att fråga en viss uppsättning kolumner, bör du använda materialiserade vyer. Men om applikationen behöver fråga olika uppsättningar kolumner är sekundära index ett bättre val eftersom de kan läggas till och tas bort med mindre lagringsutrymme beroende på applikationsbehov.

vill du lära dig mer om sekundära index? Kolla in min presentation från Scylla Summit 2017 på SlideShare. Om du vill prova den här funktionen förväntas den vara i den kommande Scylla 2.2-utgåvan.