Het Slechte : Partitionering
een van de moeilijke dingen om aan te wennen op het eerste is dat zonder indexen query ‘ s die rijen overspannen (zeer) slecht kan zijn. Terugdenkend aan ons opslagmodel is dat echter niet verwonderlijk. De strategie die Cassandra gebruikt om de rijen over hosts te verdelen heet partitioneren.
partitioneren is de handeling van het uitsnijden van het bereik van rowkeys toewijzen aan de” token ring”, die ook de verantwoordelijkheid voor een segment (dat wil zeggen partitie) van de RowKey bereik aan elke host toewijst. Je hebt dit waarschijnlijk gezien toen je je cluster initialiseerde met een “token”. Het token geeft de host een locatie langs de token ring, die de verantwoordelijkheid voor een deel van het token bereik toewijst. Partitioneren is de handeling van het toewijzen van de rowkey in het token bereik.
er zijn twee primaire partitioners: Random en Order behoud. Ze hebben een passende naam. De RandomPartitioner hashes de rowkeys in tokens. Met de RandomPartitioner is het token een hash van de rowkey. Dit doet een goed werk van gelijkmatig verdelen van uw gegevens over een set van knooppunten, maar maakt het opvragen van een bereik van de rowkey ruimte ongelooflijk moeilijk. Van alleen een “start rowkey” waarde en een “end rowkey” waarde, Cassandra kan niet bepalen welk bereik van de token ruimte die u nodig hebt. Het moet in wezen een “table scan” uitvoeren om de query te beantwoorden, en een “table scan” in Cassandra is slecht omdat het naar elke machine moet gaan (waarschijnlijk alle machines als je een goede hash-functie hebt) om de query te beantwoorden.
de Goede : secundaire indexen
Cassandra biedt een native indexeringsmechanisme in secundaire indexen. Secundaire indexen werken af van de kolommen waarden. Je declareert een secundaire index op een Kolomfamilie. Datastax heeft goede documentatie over het gebruik. Onder de motorkap, Cassandra onderhoudt een “verborgen kolom familie” als de index. (Zie ed Anuff ‘ s presentatie voor details) aangezien Cassandra geen kolomwaarde-informatie in een knooppunt onderhoudt, en secundaire indexen op kolomwaarde staan (in plaats van rowkeys), moet een query nog steeds naar alle knooppunten worden verzonden. Daarnaast worden secundaire indexen niet aanbevolen voor sets met een hoge kardinaliteit. Ik heb nog niet gekeken, maar ik neem aan dat dit komt door het datamodel dat wordt gebruikt binnen de “verborgen kolom familie”. Als de verborgen kolomfamilie een Rij per unieke waarde opslaat (met rowkeys als kolommen), betekent dit dat de rijen moeten worden gescand om te bepalen of ze binnen het bereik in de query liggen.
uit de presentatie van Ed:
- niet aanbevolen voor hoge kardinaliteitswaarden (dat wil zeggen tijdstempels,geboortedata,trefwoorden,enz.)
- vereist ten minste één gelijkheidsvergelijking in een query–niet geweldig voor minder-dan/groter-dan/range queries
- Ongesorteerde resultaten zijn in tokenvolgorde, geen query-waardevolgorde
- beperkt tot zoeken op datatypes, begrijpt Cassandra native
met dat alles gezegd, secundaire indexen werken uit de doos en we hebben goed succes met behulp van hen op eenvoudige waarden.
het lelijke: Doe-het-zelf (DIY) / brede rijen
nu, schoonheid is in het oog van de toeschouwer. Een van de mooie dingen over NoSQL is de eenvoud. De constructies zijn eenvoudig: Keyspaces, Kolomfamilies, rijen en kolommen. Het houden van het eenvoudig betekent echter soms moet je dingen in eigen handen te nemen.
Dit is het geval bij indexen met brede rijen. Met behulp van Cassandra ‘ s storage model, zijn gemakkelijk om uw eigen indexen te bouwen waar elke rij-toets wordt een kolom in de index. Dit is soms moeilijk om je hoofd rond te krijgen, maar laten we ons voorstellen dat we een geval hebben waarbij we alle gebruikers in een Postcode willen selecteren. De belangrijkste gebruikers kolom familie is ingetoetst op userid, postcode is een kolom op elke gebruikers rij. We kunnen secundaire indexen gebruiken, maar er zijn nogal wat postcodes. In plaats daarvan zouden we een kolomfamilie kunnen onderhouden met een enkele rij genaamd “idx_zipcode”. We kunnen dan kolommen schrijven in deze rij van het formulier “zipcode_userid”. Aangezien de kolommen in gesorteerde volgorde worden opgeslagen, is het snel om alle kolommen te bevragen die beginnen met” 18964 ” (we zouden bijvoorbeeld 18964_ en 18964_ZZZZZZ als begin-en eindwaarden kunnen gebruiken).
een duidelijk nadeel van deze aanpak is dat rijen op zichzelf staan op een host. (nogmaals, behalve voor replica ‘s) dit betekent dat alle query’ s gaan om een enkele knooppunt te raken. Ik heb hier nog geen goed antwoord op gevonden.