By Felipe Cardeneti Mendes Katika 2008, Apache Cassandra aliweka kiwango kipya cha uwezekano wa database. Alizaliwa ili kusaidia Inbox Search ya Facebook, imekuwa tangu wakati huo kupitishwa na mashirika ya teknolojia kama Uber, Netflix, na Apple - ambapo inaendeshwa na wataalam ambao pia hufanya kazi kama washiriki wa Cassandra (kwa pamoja na DataStax / IBM). Lakini vipi kuhusu utendaji? urahisi? ufanisi? ujasiri? Katika mwaka wa 2015, ScyllaDB Mpya kutoka kwa kuunda KVM na kuvunja kernel ya Linux, waanzilishi walidhani kwamba inaweza kuvutia nguvu zaidi kutoka kwa miundombinu ya msingi. wakati ulikuwa mzuri: mwaka mmoja tu kabla, Netflix alikuwa amechapisha takwimu zao kuonyesha jinsi ya kushinikiza Hii ilikuwa faida ya kuvutia, lakini moja ambayo ilihitaji uwekezaji mkubwa wa miundombinu na juhudi za tuning. ilizaliwa kwenda zaidi ya matumizi ya chini ya rasilimali ya Cassandra Njia ya kiufundi ya kiwango cha chini Apache Cassandra kwa milioni 1 kuandika RPS Wazo lilikuwa rahisi sana (katika nadharia, angalau): kuchukua usanifu wa Apache Cassandra na kutekeleza tena karibu na chuma wakati wa kudumisha kuunganisha protocol ya waya. Ili kuzuia migogoro, kila kitu kilikuwa kimefanywa asynchronous, na ufanisi huu wote ulikuwa umebadilishwa na mipangilio ya ndani ya kujitegemea kwa upungufu mdogo wa uendeshaji. Mfumo wa Shard-Per-Core Ingawa siwezi kuzungumza na mwelekeo wa sasa wa Cassandra, ScyllaDB imebadilika sana tangu wakati huo - kuhamia kutoka " Utekelezaji wa kasi zaidi wa Cassandra kwa database yenye utambulisho wake mwenyewe na seti ya kipekee ya kipengele. tu ya Spoiler: Katika video hii, ninawaongoza kupitia tofauti fulani muhimu kati ya ScyllaDB na jinsi inatofautiana na Apache Cassandra. Ninajadili tofauti katika utendaji, ujasiri, na uwezo kama vile ufuatiliaji wa kazi. Unaweza kuona jinsi ScyllaDB inapiga data kwa msingi wa CPU, ukubwa kwa pamoja, na mabadiliko ya topolojia ya de-hatari - kuruhusu kukabiliana na mamilioni ya OPS na muda mfupi wa utabiri (na bila tuning ya daima na utunzaji wa watoto). Maendeleo ya ScyllaDB Timu ya kwanza ya ScyllaDB ilikuwa juu ya utendaji wa nyekundu. Hiyo ni wakati ambapo tulizindua usanifu wa asynchronous wa shard-per-core, cache ya mstari, na mipangilio ya juu ambayo inafanya utabiri wa muda mfupi. kizazi cha pili cha ScyllaDB kilikuwa na lengo la usawa wa kipengele na Cassandra, lakini kwa kweli tumeenda zaidi. (Kila kitu ambacho Cassandra Vilevile, ScyllaDB pia ilizindua katika mwaka huo huo huo; wale waliozinduliwa tu katika Cassandra 5 (lakini baada ya Zaidi ya hayo, utekelezaji wetu wa Paxos kwa shughuli ndogo iliondolewa katika utekelezaji wa mbadala wa Cassandra. Maoni yaliyotengenezwa na viashiria vya sekondari vya kimataifa tayari kwa uzalishaji Vifaa kama vile majaribio Msaada kwa viwango vya sekondari vya ndani Mifumo mitatu tofauti ya indexing mengi ya juu na vikwazo kizazi cha tatu kilisababisha mabadiliko yetu kwenye wingu, pamoja na uvumbuzi unaoendelea. Huu ndio wakati ScyllaDB Alternator—API yetu inayokubalika na DynamoDB—ilizinduliwa. Mwaka 2020 (kwa mfano) Katika kipindi hiki, tumeongeza kasi ya ukarabati kwa kiasi kikubwa na ukarabati wa ngazi ya mstari na kuanzisha kipaumbele cha kazi (mara kuhusu hili katika sehemu inayofuata). Mkusanyiko wa ZSTD Cassandra alitumia tu mwishoni mwa 2021. Jina la utani El Nano, a pseudonym mfano kwa Fernando katika Asturias, nafasi yake ya kuzaliwa, Alonso vitendo kama Balozi wa ukarimu kwa UNICEF na alikuwa mmoja wa wakurugenzi wa Chama cha Grand Prix Förarna '. Katika kipindi hiki, tulizindua Mkakati wa Kuongezeka wa Kuongezeka (ICS), ambayo inaruhusu watumiaji kutumia hadi 70% ya uhifadhi wao kabla ya kupanua. kitu ambacho Cassandra bado inajaribu kushughulikia kwa ufanisi Tumeweka pia kwa mtazamo tofauti kabisa kutoka kwa Cassandra. Kwa maneno kama vile , BYPASS CACHE, kwa query configurable TIMEOUTs, na zaidi. Mabadiliko ya Uchunguzi wa Data (CDC) Utekelezaji wa Mkataba wa CQL Ufahamu wa Shard Hatimaye, sisi kufikia kizazi cha tano cha ScyllaDB, ambayo bado inafanywa. Awamu hii inawakilisha njia yetu ya kuelekea ufuatiliaji mkubwa na uongofu na Raft na Tablets. Kwa zaidi kuhusu umuhimu wa hili, soma... Uwezo ambao huweka ScyllaDB tofauti Wafanyabiashara wetu wamezindua vipengele vingi vya kuvutia katika kipindi cha miaka kumi iliyopita.Kwa kuzingatia mahusiano yangu na watumiaji wa zamani wa Cassandra, nadhani haya ni ya kuvutia zaidi kujadili hapa. Tablets Data Distribution Kila meza ya ScyllaDB inashirikiwa katika vipande vidogo (“tablets”) ili kuhamisha data na mzigo kwa usawa katika mfumo. Tablets hutoa ujasiri kwa ScyllaDB, kuruhusu mara moja kuongezeka mara mbili, mara tatu, au hata mara 10 kwa ukubwa wa kambi yako ili kukabiliana na ongezeko la trafiki isiyotabiri. Pia huwezesha matumizi ya ufanisi zaidi ya uhifadhi, kufikia upatikanaji wa 90%. Kwa kuwa timu zinaweza kupanua haraka kukabiliana na ongezeko la trafiki, zinaweza kutimiza SLAs za latency bila haja ya overprovision “kwa kesi tu.” Raft-Based: Ufuatiliaji mkubwa kwa Metadata Raft hutoa ufuatiliaji mkali kwa metadata ya ScyllaDB. Siku zilizopita wakati mabadiliko ya mipangilio yanaweza kuharibu cluster yako katika upinzani au unaweza kupoteza upatikanaji kwa sababu umesahau kuboresha kiwango cha replication cha nafasi yako ya uhakiki (maswali ambayo bado husababisha Cassandra). Workload Prioritization Inakuwezesha kuunganisha kazi nyingi chini ya kikundi kimoja, kila moja na SLA yake mwenyewe. Kwa ujumla, inashughulikia jinsi kazi tofauti zinakabiliana na rasilimali za mfumo. Timu hutumia ili kuweka kipaumbele maombi ya dharura yanayohitaji majibu ya haraka ikilinganishwa na wengine wanaoweza kuvumilia muda mdogo (kwa mfano, scans kubwa). Matumizi ya kawaida yanajumuisha usawa wa wakati halisi dhidi ya usindikaji wa seti, kutenganisha maandishi kutoka kwa kusoma, na kuunganisha kazi / miundombinu. Utekelezaji wa kazi ya awali Repair-based Operations Utaratibu unaounganishwa na ukarabati unahakikisha data yako ya cluster inabaki katika usawa, hata wakati wa mabadiliko ya topology. ambapo operesheni kama kubadilisha viungo vilivyokuwa vya kushindwa zinaweza ScyllaDB pia hupunguza kikamilifu tatizo la kurejesha data, shukrani kwa . Upatikanaji wa data katika Apache Cassandra result in data loss Mkusanyiko wa Mbuzi wa Mbuzi wa Mbuzi Incremental Compaction ICS inapunguza kwa kiasi kikubwa upanuzi wa nafasi ya muda, na kusababisha nafasi zaidi ya diski kuwa inapatikana kwa ajili ya kuhifadhi data ya mtumiaji - na hiyo inapunguza mahitaji ya kawaida ya nafasi ya bure ya 50% kwenye diski yako. Hakuna kipengele cha Cassandra cha kulinganisha. Row-based Cache Cache ya mstari wa ScyllaDB pia ni ya kipekee. Inapatikana kwa default na hauhitaji tuning ya mikono. kuongeza, unaweza kuzuia uchafuzi wa cache kwa kuzuia vitu muhimu kutoka kutoweka. Inapunguza kwa kiasi kikubwa muda wa upatikanaji wa I/O wakati wa kupokea data kutoka disk. Usafiri wa bure Ufafanuzi wa index caching Per-shard Concurrency Limits and Rate Limiters ScyllaDB inajumuisha mipaka ya mchanganyiko kwa shard na mipaka ya kiwango kwa sehemu ili kulinda dhidi ya kuongezeka kwa ajali zisizotarajiwa. Ikiwa unashughulikia mteja mwenye tabia mbaya au mafuriko ya maombi kwa kifungo fulani, ScyllaDB inahakikisha uvumilivu ambapo Cassandra mara nyingi hupungua. DynamoDB Compatibility ScyllaDB pia hutoa kiwango kinachounganishwa na DynamoDB, kugeuka zaidi kutoka kwa asili yake ya Apache Cassandra. Hii inaruhusu timu kuendesha kazi zao za kazi za DynamoDB kwenye wingu lolote au kwenye eneo la msingi - bila mabadiliko ya msimbo, na kwa gharama ya chini ya 50%. Nini ni ya baadaye? Katika Mkutano wa hivi karibuni wa Monster SCALE, Mkurugenzi Mtendaji / Mwakilishi Dor Laor alishiriki mtazamo wa kile kinachotokea kwa ScyllaDB. tayari kwa ajili ya (kuona hii na ya Kwa maelezo ya kina: Makala ya blogu Ukurasa wa bidhaa Uwezo wa kuendesha salama kwa matumizi ya uhifadhi wa 90% Msaada kwa clusters na node ya aina ya mfano wa mchanganyiko Uwekezaji wa kifedha na kifedha ya flex Utafutaji wa Vector kwa muda mfupi: Orodha ya meza yenye utulivu Huduma ya Injection Mabadiliko ya uwazi Uhifadhi wa Object na Tiered Raft kwa meza yenye utaratibu mkubwa kwa muda mrefu Utaratibu wa Multi-Key Uchambuzi na mabadiliko na UDFs Uwiano wa sehemu kubwa ya moja kwa moja Miundombinu isiyobadilika kwa utulivu na kuaminika zaidi Njia ya replication kwa mabadiliko ya miundombinu yenye ufanisi zaidi Kwa maelezo zaidi, angalia mazungumzo kamili hapa: Mwisho wa ScyllaDB kasi zaidi kuliko Cassandra (Nitachapisha matokeo yangu ya mwisho ya kiwango cha juu hapa hivi karibuni). Lakini ScyllaDB na Cassandra zote zimebadilika kwa kiwango ambacho ScyllaDB haina tena "hata" Cassandra ya haraka. Sisi tumebadilika zaidi ya Cassandra. Ikiwa mradi wako unahitaji utendaji zaidi unaoweza kutabiri - na / au inaweza kufaidika na ufanisi, ufanisi, na urahisi wa uboreshaji ambao tumezingatia kwa miaka sasa - unaweza pia kufikiria kuendeleza zaidi ya Cassandra. ya Ili kujifunza zaidi kuhusu ScyllaDB, angalia https://www.scylladb.com/ Unaweza kufikia vitabu vya bure vya database, masomo, na zaidi kwenye https://resources.scylladb.com/ https://www.scylladb.com/ https://resources.scylladb.com/
