By Felipe Cardeneti Mendes Pada tahun 2008, Apache Cassandra menetapkan piawaian baru untuk keluasan pangkalan data. Dilahirkan untuk menyokong Pencarian Inbox Facebook, ia telah diadopsi oleh raksasa teknologi seperti Uber, Netflix, dan Apple - di mana ia dikendalikan oleh pakar-pakar yang juga berkhidmat sebagai penyumbang Cassandra (bersama dengan DataStax / IBM). Tetapi bagaimana dengan prestasi? kesederhanaan? kecekapan? elastisiti? Pada tahun 2015, ScyllaDB Segar daripada mencipta KVM dan hacking kernel Linux, pendiri percaya bahawa mereka masa yang ideal: hanya setahun yang lalu, Netflix telah menerbitkan nombor mereka menunjukkan bagaimana untuk mendorong Ini merupakan prestasi yang mengesankan, tetapi yang memerlukan pelaburan infrastruktur yang besar dan usaha tuning. dilahirkan untuk melampaui penggunaan sumber suboptimal Cassandra pendekatan kejuruteraan peringkat rendah Apache Cassandra kepada 1 juta menulis RPS Idea itu agak mudah (dalam teori, sekurang-kurangnya): mengambil seni bina yang boleh diperluas Apache Cassandra dan menerapkannya semula berhampiran dengan logam sambil mengekalkan keserasian protokol wayar. memaksimumkan keluasan pelayan walaupun di bawah beban sistem yang berat.Untuk mengelakkan pertikaian, segala-galanya dibuat asynchronous, dan semua optimisasi ini digabungkan dengan pelancar dalaman bebas untuk overhead operasi minimum. Arsitektur Shard-per-Core Walaupun saya tidak boleh bercakap dengan arah Cassandra semasa, ScyllaDB telah berkembang cukup signifikan sejak itu - beralih daripada " penyelesaian Cassandra yang lebih cepat kepada pangkalan data dengan identiti sendiri dan set ciri unik. sahaja Spoiler: Dalam video ini, saya memandu anda melalui beberapa perbezaan utama antara ScyllaDB dan bagaimana ia berbeza daripada Apache Cassandra. Saya membincangkan perbezaan dalam prestasi, elastisiti, dan keupayaan seperti prioriti beban kerja. Anda boleh melihat bagaimana ScyllaDB memaparkan data per teras CPU, skala secara paralel, dan perubahan topologi de-risks - membolehkan ia menangani berjuta-juta OPS dengan latensi rendah yang boleh diramalkan (dan tanpa tuning dan pengawasan bayi yang berterusan). Perkembangan ScyllaDB Generasi pertama ScyllaDB adalah tentang prestasi mentah.Itulah ketika kami memperkenalkan arsitektur asynchronous shard-per-core, cache berasaskan baris, dan pelancar lanjutan yang mencapai latensi rendah yang boleh diramalkan. Generasi kedua ScyllaDB bertujuan untuk pariti ciri dengan Cassandra, tetapi kami sebenarnya melampaui itu. (Sesuatu yang Cassandra Demikian juga, ScyllaDB juga memperkenalkan pada tahun yang sama; mereka baru diperkenalkan dalam Cassandra 5 (setelah sekurang-kurangnya Di samping itu, pelaksanaan Paxos kami untuk transaksi ringan dihapuskan Penggunaan Alternatif Cassandra Pandangan material dan Indeks Sekunder Global yang bersedia untuk pengeluaran Tag: bendera sebagai eksperimen Sokongan untuk indeks sekunder tempatan 3 Implementasi indeks yang berbeza Kebanyakan daripada overhead dan batasan Generasi ketiga menandakan peralihan kami ke awan, bersama-sama dengan inovasi berterusan.Ini ialah ketika ScyllaDB Alternator – API bersesuaian DynamoDB kami – diperkenalkan. Pada tahun 2020 (sesuatu Semasa tempoh ini, kami secara dramatik meningkatkan kelajuan pembaikan dengan pembaikan peringkat baris dan memperkenalkan keutamaan beban kerja (lebih lanjut mengenai ini dalam seksyen seterusnya). Kompresyen Cassandra hanya mengadopsi ia pada akhir 2021 Generasi keempat ScyllaDB muncul kira-kira ketika AWS mengumumkan keluarga instance i3en mereka, dengan nod kepadatan tinggi yang menyimpan sehingga 60TB data ( Semasa tempoh ini, kami memperkenalkan Strategi Kompaksi Peningkatan (ICS), membolehkan pengguna menggunakan sehingga 70% daripada storan mereka sebelum meluaskan. sesuatu Cassandra masih berjuang untuk menangani secara berkesan Kami juga memperkenalkan dengan pendekatan yang sangat berbeza daripada Cassandra. Dengan konsep-konsep seperti , BYPASS CACHE, per-query konfigurable TIMEOUTs, dan banyak lagi. Pengambilan Data Perubahan (CDC) Memperluaskan Protokol CQL Kesedaran Shard Akhirnya, kita tiba pada generasi kelima ScyllaDB, yang masih sedang dibangunkan. Fasa ini mewakili jalan kita ke arah konsistensi dan elastisiti yang kuat dengan Raft dan Tablet. Keupayaan yang membezakan ScyllaDB Berdasarkan interaksi saya dengan bekas pengguna Cassandra, saya fikir ini adalah yang paling menarik untuk dibincangkan di sini. Tablets Data Distribution Setiap jadual ScyllaDB dibahagikan kepada bahagian-bahagian yang lebih kecil (“tablet”) untuk mendistribusikan data dan beban secara merata di seluruh sistem. Tablet membawa elastisiti kepada ScyllaDB, membolehkan anda untuk dengan serta-merta menggandakan, menggandakan tiga atau bahkan 10 kali saiz cluster anda untuk menampung peningkatan lalu lintas yang tidak dapat diramalkan. Mereka juga membolehkan penggunaan penyimpanan yang lebih cekap, sehingga 90% penggunaan. Oleh kerana pasukan boleh dengan cepat meluas dalam menanggapi ketinggian lalu lintas, mereka boleh memenuhi SLA latency tanpa perlu berlebihan “hanya dalam kes.” Raft-Based: Kesesuaian yang kuat untuk metadata Raft memperkenalkan konsistensi yang kuat kepada metadata ScyllaDB. Telah berlalu hari-hari di mana perubahan skim boleh mendorong cluster anda kepada perselisihan atau anda akan kehilangan akses kerana anda lupa untuk mengemas kini faktor replikasi ruang kunci pengesahan anda (masalah yang masih mengganggu Cassandra). Workload Prioritization membolehkan anda mengkonsolidasikan banyak beban kerja di bawah satu cluster, masing-masing dengan SLA tersendiri. Pada asasnya, ia mengawal bagaimana beban kerja yang berbeza bersaing untuk sumber sistem. Pasukan menggunakannya untuk memberi keutamaan kepada permintaan aplikasi yang mendesak yang memerlukan masa respons segera berbanding yang lain yang boleh mentoleransi penundaan yang lebih ringan (contohnya, pemindaian besar). kes penggunaan biasa termasuk keseimbangan masa nyata berbanding pemprosesan batch, memisahkan tulis daripada bacaan, dan pengekalan beban kerja / infrastruktur. Prioriti kerja Repair-based Operations Operasi berasaskan pembaikan memastikan data cluster anda kekal disegerakkan, walaupun semasa perubahan topologi. , di mana operasi seperti menggantikan nod yang gagal boleh ScyllaDB juga sepenuhnya menghilangkan masalah pemulihan data, berkat . Kesilapan konsistensi data lama dalam Apache Cassandra result in data loss Rekabentuk Sampah Based Tombstone Incremental Compaction Kompaksi peningkatan (ICS) telah menjadi strategi kompaksi lalai dalam ScyllaDB selama lebih daripada lima tahun. ICS sangat mengurangkan penguatkuasaan ruang sementara, yang membawa kepada lebih banyak ruang cakera yang tersedia untuk menyimpan data pengguna - dan itu menghilangkan keperluan biasa untuk 50% ruang bebas dalam cakera anda.Tidak ada ciri Cassandra yang sebanding. Row-based Cache Cache berasaskan baris ScyllaDB juga unik. Ia diaktifkan secara lalai dan tidak memerlukan tuning manual. ekstensi, anda boleh mengelakkan pencemaran cache dengan mengekalkan item penting daripada dibatalkan. secara signifikan mengurangkan masa akses I/O apabila mengambil data daripada cakera. Penghapusan Cache Kegunaan indeks caching Per-shard Concurrency Limits and Rate Limiters ScyllaDB termasuk had concurrency per-shard dan pembatasan kadar per partisi untuk melindungi daripada puncak yang tidak dijangka. Sama ada berurusan dengan klien yang berkelakuan buruk atau banjir permintaan kepada kunci tertentu, ScyllaDB memastikan ketahanan di mana Cassandra sering kekurangan. DynamoDB Compatibility ScyllaDB juga menawarkan lapisan yang bersesuaian dengan DynamoDB, lebih jauh daripada asal-usul Apache Cassandra. Ini membolehkan pasukan menjalankan beban kerja DynamoDB mereka di mana-mana awan atau di tempat – tanpa perubahan kod, dan dengan kos 50% lebih rendah. Apa yang seterusnya? Pada Monster SCALE Summit yang baru-baru ini, CEO / co-founder Dor Laor berkongsi pandangan mengenai apa yang akan datang untuk ScyllaDB. Siap sekarang (lihat di sini) dan Untuk butiran : Maklumat Blog Halaman Produk Keupayaan untuk berjalan dengan selamat pada 90% penggunaan penyimpanan Sokongan untuk clusters dengan hub jenis instance campuran Pembiayaan dinamik dan kredit fleksibel Pencarian vektor jangka pendek : Jadual yang sangat konsisten Kesilapan perkhidmatan suntikan Perbaikan Transparan Penyimpanan objek dan tingkatan Raft untuk meja yang konsisten jangka panjang Transaksi Multi-Key Analisis dan transformasi dengan UDFs Penyeimbangan partisi besar automatik Infrastruktur yang tidak berubah untuk lebih banyak kestabilan dan kebolehpercayaan Mod replikasi untuk perubahan infrastruktur yang lebih fleksibel dan berkesan Untuk maklumat lanjut, lihat perbincangan lengkap di sini: Beranda » ScyllaDB lebih cepat daripada Cassandra (saya akan berkongsi hasil benchmark terbaru saya di sini segera).Tetapi kedua-dua ScyllaDB dan Cassandra telah berevolusi sehingga ScyllaDB tidak lagi "hanya" Cassandra yang lebih cepat.Kami telah berevolusi melampaui Cassandra.Jika projek anda memerlukan prestasi yang lebih dapat diprediksi - dan / atau boleh mendapat manfaat daripada pengoptimuman elastisiti, kecekapan, dan kesederhanaan yang kita telah memberi tumpuan kepada selama bertahun-tahun sekarang - anda mungkin juga ingin mempertimbangkan untuk berevolusi melampaui Cassandra. ialah Untuk mengetahui lebih lanjut mengenai ScyllaDB, kunjungi https://www.scylladb.com/ Anda boleh mengakses buku pangkalan data percuma, masterclass, dan banyak lagi di https://resources.scylladb.com/ https://www.scylladb.com/ https://resources.scylladb.com/
