By Felipe Cardeneti Mendes I 2008 satte Apache Cassandra en ny standard for databaseskalerbarhed.Født til at understøtte Facebooks Inbox Search, er det siden blevet vedtaget af teknologigiganter som Uber, Netflix og Apple - hvor det drives af eksperter, der også tjener som Cassandras bidragsydere (sammen med DataStax / IBM). Men hvad med ydeevne? enkelhed? effektivitet? elasticitet? I 2015 blev ScyllaDB Frisk fra at skabe KVM og hacke Linux-kernen, troede grundlæggerne, at deres Timingen var ideel: blot et år tidligere havde Netflix offentliggjort deres tal, der viste, hvordan man skubber Dette var en imponerende præstation, men en, der krævede betydelige infrastrukturinvesteringer og tilpasningsindsats. blev født til at gå ud over Cassandras suboptimale ressourceudnyttelse Lavt niveau ingeniørtilgang Apache Cassandra til 1 million skrive RPS Ideen var ganske enkel (i teorien i det mindste): tag Apache Cassandras skalerbare arkitektur og genimplementer den tæt på metallet, mens du bevarer trådprotokollekompatibiliteten. For at undgå kontroverser blev alt gjort asynkront, og alle disse optimeringer blev parret med autonome interne tidsplanlæggere for minimal operationel overhead. Shard-Per-Core arkitektur Selvom jeg ikke kan tale med Cassandras nuværende retning, har ScyllaDB udviklet sig ganske betydeligt siden da - skiftende fra " En hurtigere implementering af Cassandra til en database med sin egen identitet og unikke funktioner. lige Spoiler: I denne video går jeg dig gennem nogle centrale forskelle mellem ScyllaDB og hvordan det adskiller sig fra Apache Cassandra. Jeg diskuterer forskellene i ydeevne, elasticitet og muligheder som prioritering af arbejdsbyrde. Du kan se, hvordan ScyllaDB kortlægger data pr. CPU-core, skalaer parallelt og de-risiko topologi ændringer - så det kan håndtere millioner af OPS med forudsigelige lave latencer (og uden konstant tuning og babysitting). ScyllaDB’s udvikling Den første generation af ScyllaDB handlede om rå ydeevne. Det var da vi introducerede shard-per-core asynkron arkitektur, rækkebaseret cache og avancerede tidsplanlæggere, der opnåede forudsigelige lave latencer. Den anden generation af ScyllaDB sigtede mod funktionsparitet med Cassandra, men vi gik faktisk ud over det. Noget, som Cassandra På samme måde introducerede ScyllaDB også samme år; de blev netop introduceret i Cassandra 5 (efter mindst Desuden er vores Paxos implementering for lette transaktioner elimineret. Den alternative anvendelse af Cassandra. Materialiserede synspunkter og produktionsklare globale sekundære indekser Flag som et eksperiment Støtte til lokale sekundære indekser Tre forskellige indekseringsimplementeringer Meget af overhead og begrænsninger Den tredje generation markerede vores skift til skyen, sammen med fortsat innovation. Det var her, at ScyllaDB Alternator – vores DynamoDB-kompatible API – blev introduceret. I 2020 (næsten) I løbet af denne periode forbedrede vi dramatisk reparationshastigheden med reparation på linjeniveau og indførte arbejdsbyrdeprioritering (mere om dette i næste afsnit). ZSTD kompression Cassandra vedtog det først sent i 2021 Den fjerde generation af ScyllaDB opstod omkring den tid, hvor AWS annoncerede deres i3en-instansfamilie, med højdensitetsnoder, der opbevarer op til 60TB data ( I løbet af denne periode introducerede vi Incremental Compaction Strategy (ICS), som tillod brugerne at udnytte op til 70% af deres lagerplads, før de skalerede ud. noget Cassandra stadig kæmper for at håndtere effektivt Vi har også introduceret med en grundlæggende forskellig tilgang fra Cassandras. Med begreber som , BYPASS CACHE, per-forespørgsel konfigurerbare TIMEOUTs og meget mere. Ændring af dataindsamling (CDC) Udvidelse af CQL-protokollen Shardbevidsthed Endelig kommer vi til den femte generation af ScyllaDB, som stadig er under udvikling. Denne fase repræsenterer vores vej mod stærk konsistens og elasticitet med Raft og Tablets. Funktioner, der skiller ScyllaDB ud Vores ingeniører har introduceret mange interessante funktioner i løbet af det sidste årti.Baseret på mine interaktioner med tidligere Cassandra-brugere, synes jeg, at disse er de mest interessante at diskutere her. Tablets Data Distribution Hver ScyllaDB-tabel er opdelt i mindre fragmenter ("tabletter") for jævnt at distribuere data og belastning på tværs af systemet. Tabletter bringer elasticitet til ScyllaDB, så du øjeblikkeligt kan fordoble, tredoble eller endda 10x din klyngestørrelse for at imødekomme uforudsigelige trafikpropper. De muliggør også en mere effektiv brug af lagring, der når op til 90% udnyttelse. Da teams hurtigt kan skalere ud som reaktion på trafikspikes, kan de tilfredsstille latens SLA'er uden behov for overforsyning "bare i tilfælde". Raft-baseret: Stærk sammenhæng for metadata Raft introducerer stærk konsistens til ScyllaDB's metadata. Gone er de dage, hvor en ændring i skemaet kunne skubbe din klynge ind i uenighed, eller du ville miste adgang, fordi du glemte at opdatere replikationsfaktoren i dit godkendelsesnøgleområde (problemer, der stadig plager Cassandra). Workload Prioritization Det giver dig mulighed for at konsolidere flere arbejdsbyrder under en enkelt klynge, hver med sin egen SLA. Det styrer grundlæggende, hvordan forskellige arbejdsbyrder konkurrerer om systemressourcer. Teams bruger det til at prioritere presserende applikationsforespørgsler, der kræver øjeblikkelige responstider i forhold til andre, der kan tolerere mindre forsinkelser (f.eks. store scanninger). Fælles brugstilfælde omfatter balancering i realtid mod batchbehandling, opdeling af skrivninger fra læsninger og arbejdsbelastning/infrastrukturkonsolidering. Prioritering af arbejdskraft Repair-based Operations Reparationsbaserede operationer sikrer, at dine clusterdata forbliver synkroniseret, selv under topologiændringer. , hvor operationer som udskiftning af mislykkede knuder kan ScyllaDB eliminerer også fuldstændigt problemet med data genoprettelse, takket være . Datakonsistensfejl i Apache Cassandra result in data loss reparationsbaseret gravsten affaldssamling Incremental Compaction Incrementel komprimering (ICS) har været standardkomprimeringsstrategien i ScyllaDB i over fem år. ICS reducerer betydeligt den midlertidige pladsforstærkning, hvilket resulterer i, at der er mere diskplads til rådighed til lagring af brugerdata – og det eliminerer det typiske krav om 50% ledig plads på din disk. Row-based Cache ScyllaDB's rækkebaserede cache er også unik. Den er aktiveret som standard og kræver ingen manuel tuning. udvidelse, kan du forhindre cacheforurening ved at holde vigtige elementer fra at blive ugyldige. Reducerer I/O-adgangstiden betydeligt, når du henter data fra disk. Bypass Cache Indikatorer til indeksering Per-shard Concurrency Limits and Rate Limiters ScyllaDB indeholder per-shard-konkurrencegrænser og satsbegrænsere pr. partition for at beskytte mod uventede spikes. Uanset om du beskæftiger dig med en misbehavende klient eller en oversvømmelse af anmodninger til en bestemt nøgle, sikrer ScyllaDB modstandsdygtighed, hvor Cassandra ofte falder for lidt. DynamoDB Compatibility ScyllaDB tilbyder også et DynamoDB-kompatibelt lag, der yderligere distancerer sig fra Apache Cassandras oprindelse. Dette giver teams mulighed for at køre deres DynamoDB-arbejdsbelastninger på en hvilken som helst cloud eller on-prem - uden kodeændringer og med 50% lavere omkostninger. Hvad er næste? På det seneste Monster SCALE-topmøde delte administrerende direktør / medstifter Dor Laor et kig på, hvad der er næste for ScyllaDB. Klar nu (se her) og For yderligere detaljer): Blog Posts Produktside Evnen til at køre sikkert ved 90% lagerudnyttelse Støtte til klynger med knudepunkter af blandet instanstype Dynamisk provisionering og fleksibel kredit Vektor søgning På kort sigt: Meget konsekvente tabeller Forkert injektionsservice Gennemsigtige reparationer Objekter og lagerplads Raft til stærkt konsistente tabeller Langsigtet Multi-nøgle transaktioner Analyse og transformationer med UDF'er Automatisk stor partitionsbalancering Uændret infrastruktur for større stabilitet og pålidelighed En replikationstilstand for mere fleksible og effektive infrastrukturændringer For mere information se hele samtalen her: Til slut, ScyllaDB hurtigere end Cassandra (jeg vil dele mine seneste benchmark-resultater her snart). men både ScyllaDB og Cassandra har udviklet sig til det punkt, at ScyllaDB ikke længere er "bare" en hurtigere Cassandra. Vi har udviklet sig ud over Cassandra. Hvis dit projekt har brug for mere forudsigelig ydeevne - og / eller kunne drage fordel af de elasticitet, effektivitet og enkelhedsoptimeringer, vi har fokuseret på i årevis nu - kan du også overveje at udvikle sig ud over Cassandra. er For at lære mere om ScyllaDB, besøg https://www.scylladb.com/ Du kan få adgang til gratis databasebøger, masterclasses og meget mere på https://resources.scylladb.com/ https://www.scylladb.com/ https://resources.scylladb.com/
