Ulasan YugaByte: Cassandra dan Redis berskala planet

Selama beberapa dekade saya sebagai pengembang aplikasi database, saya tidak pernah membayangkan dalam mimpi terliar saya bahwa saya akan memiliki akses ke database terdistribusi yang transaksional, berskala planet, apalagi membandingkan banyak dari mereka. Tetapi dengan Google Cloud Spanner, CockroachDB, Azure Cosmos DB, Neo4j Enterprise, dan yang terbaru YugaByte DB semuanya tersedia dalam produksi, mimpi pipa satu kali itu sekarang menjadi nyata.

Secara umum, Google Cloud Spanner menawarkan database SQL yang skalabel, terdistribusi, dan sangat konsisten sebagai layanan yang dapat menangani sekitar 2.000 penulisan per detik dan 10.000 pembacaan per detik, per node, dengan latensi median sekitar lima milidetik. Untuk mempercepat pembacaan yang tidak memerlukan data yang benar-benar terbaru, Anda dapat meminta Spanner untuk pembacaan lama, karena Spanner mendukung kueri perjalanan waktu. Spanner menggunakan dialek SQL Google dan hanya berjalan di Google Cloud Platform.

CockroachDB adalah database SQL sumber terbuka seperti Spanner yang mendukung protokol wire PostgreSQL dan dialek SQL PostgreSQL. CockroachDB dibangun di atas RocksDB, penyimpanan nilai kunci transaksional sumber terbuka dan konsisten. Seperti Spanner, ini mendukung kueri perjalanan waktu. CockroachDB dapat berjalan di cloud apa pun, di container Docker dengan atau tanpa orkestrasi, atau di server Linux atau VM. Versi perusahaan dari CockroachDB menambahkan geo-partisi, kontrol akses berbasis peran, dan dukungan.

Azure Cosmos DB adalah database multimodel yang didistribusikan secara global dan dipartisi secara horizontal sebagai layanan. Ini menawarkan empat model data (nilai kunci, kelompok kolom, dokumen, dan grafik) dan lima tingkat konsistensi yang dapat disesuaikan (kuat, kedaluwarsa terbatas, sesi, awalan yang konsisten, dan akhirnya). Ini menawarkan lima set API: SQL (dialek), kompatibel dengan MongoDB, kompatibel dengan Azure Table, grafik (Gremlin), dan kompatibel dengan Apache Cassandra. Ini hanya berjalan di cloud Microsoft Azure.

Neo4j adalah database grafik yang dapat diskalakan dan bertahan yang menggunakan bahasa kueri Cypher. Anda dapat menginstal versi open-source, non-clustered di Windows, MacOS, dan Linux, di container Docker, dan di VM. Neo4j Enterprise mendukung ketersediaan tinggi dan cluster kausal; Kluster kausal memungkinkan klaster replika baca yang diperbarui secara asinkron, untuk memungkinkan kinerja tinggi untuk penerapan yang didistribusikan secara geografis.

Masukkan Yugabyte DB

YugaByte DB, subjek review ini, adalah open source, transaksional, database berkinerja tinggi untuk aplikasi berskala planet yang mendukung tiga set API: YCQL, kompatibel dengan Apache Cassandra Query Language (CQL); YEDIS, kompatibel dengan Redis; dan PostgreSQL (saat ini tidak lengkap dan dalam versi beta). YugaWare adalah lapisan orkestrasi untuk YugaByte DB Enterprise Edition. YugaWare membuat pekerjaan cepat untuk memutar dan menghancurkan kluster terdistribusi di Amazon Web Services, Google Cloud Platform, dan (jatuh tempo Q4 2018) Microsoft Azure. YugaByte DB mengimplementasikan multiversion concurrency control (MVCC), tetapi belum mendukung kueri perjalanan waktu.

YugaByte DB dibangun di atas fork yang disempurnakan dari penyimpanan nilai kunci RocksDB. YugaByte DB 1.0 dikirim pada Mei 2018.

Dua dari teknologi utama yang digunakan untuk membuat database transaksional terdistribusi konsisten dan cepat adalah algoritma konsensus klaster dan sinkronisasi jam node. Google Cloud Spanner dan Azure Cosmos DB menggunakan algoritme konsensus Paxos yang diusulkan oleh Leslie Lamport. CockroachDB dan YugaByte DB menggunakan algoritma konsensus Raft yang diusulkan oleh Diego Ongaro dan John Ousterhout.

Google Cloud Spanner menggunakan TrueTime API milik Google, berdasarkan GPS dan jam atom. Azure Cosmos DB, CockroachDB, dan YugaByte DB menggunakan cap waktu jam logika hibrid (HLC) dan sinkronisasi jam Network Time Protocol (NTP).

Tujuan desain YugaByte

Pendiri YugaByte — Kannan Muthukkaruppan, Karthik Ranganathan, dan Mikhail Bautin — adalah pemegang Apache HBase, insinyur awal Apache Cassandra, dan pembuat platform NoSQL Facebook (didukung oleh Apache HBase). Sasaran mereka untuk YugaByte DB adalah server database terdistribusi secara filosofis di antara Azure Cosmos DB dan Google Cloud Spanner; artinya, mereka ingin menggabungkan atribut multimodel dan performa tinggi Cosmos DB dengan transaksi ACID dan konsistensi global Spanner. Cara lain untuk menjelaskan tujuan mereka adalah bahwa mereka ingin YugaByte DB menjadi transaksional, berkinerja tinggi, dan berskala planet, sekaligus.

Mereka membagi proses menjadi lima langkah, yang masing-masing membutuhkan waktu sekitar enam bulan untuk membangun. Langkah pertama adalah membuat versi RocksDB yang sangat konsisten, penyimpanan nilai-kunci berkinerja tinggi yang ditulis dalam C ++, dengan menambahkan protokol konsensus Raft, sharding, dan load balancing, dan menghapus pencatatan transaksi, pencadangan waktu tertentu, dan pemulihan, yang perlu diterapkan di lapisan yang lebih tinggi.

Langkah selanjutnya adalah membangun mesin penyimpanan kunci-ke-dokumen terstruktur log, menambahkan jenis non-primitif dan bersarang, seperti baris, peta, koleksi, dan JSON. Kemudian mereka menambahkan lapisan API yang dapat dicolokkan, seperti Azure Cosmos DB, mengimplementasikan API yang kompatibel dengan Cassandra dan kompatibel dengan Redis, dan menunda API SQL yang kompatibel dengan PostgreSQL ke tahap selanjutnya. Kemudian datanglah bahasa kueri yang diperluas.

YugaByte Cloud Query Language (YCQL) memperluas Cassandra API dengan dukungan untuk transaksi terdistribusi, indeks sekunder yang sangat konsisten, dan JSON. YugaByte Dictionary Service (YEDIS) adalah API yang kompatibel dengan Redis dengan tambahan persistensi bawaan, sharding otomatis, dan skalabilitas linier. Secara opsional, YEDIS memungkinkan pembacaan yang konsisten dengan garis waktu, latensi rendah dari pusat data terdekat, sementara operasi tulis yang kuat menjaga konsistensi global. YEDIS juga menyertakan tipe data deret waktu baru.

Terakhir, dengan versi 1.0, YugaByte DB Enterprise menambahkan lapisan untuk mengatur, mengamankan, dan memantau penerapan tingkat produksi di beberapa wilayah dan beberapa cloud, dan menyimpan cadangan terdistribusi ke titik akhir yang dapat dikonfigurasi seperti Amazon S3. Dukungan PostgreSQL tetap tidak lengkap dan pada tingkat pengujian beta.

Transaksi ACID yang didistribusikan 

Dengan risiko menyederhanakan proses sepenuhnya, izinkan saya mencoba meringkas cara YugaByte melakukan transaksi ACID terdistribusi. ACID (yang berarti atomicity, konsistensi, isolasi, dan daya tahan) digunakan untuk dianggap sebagai properti yang terbatas pada database SQL.

Misalkan Anda mengirimkan kueri YCQL yang berisi pembaruan di dalam transaksi, misalnya debit dan kredit berpasangan yang keduanya harus dibatalkan jika salah satunya gagal untuk menjaga konsistensi database keuangan. YugaByte DB menerima transaksi di manajer transaksi stateless, salah satunya berjalan di setiap node di cluster. Manajer transaksi kemudian mencoba menjadwalkan transaksi di server tablet yang memiliki sebagian besar data yang diakses oleh transaksi, untuk tujuan kinerja.

Manajer transaksi menambahkan entri transaksi dengan ID unik ke dalam tabel status transaksi. Kemudian ia menulis catatan sementara ke semua tablet yang bertanggung jawab atas kunci yang coba diubah oleh transaksi. Jika ada konflik, salah satu transaksi yang berkonflik akan dibatalkan.

Setelah semua catatan sementara berhasil ditulis, manajer transaksi meminta tablet status transaksi untuk mengganti semua catatan sementara dengan catatan biasa menggunakan stempel waktu dari entri "transaksi yang dilakukan" di log Raftnya. Akhirnya, tablet status transaksi mengirimkan permintaan pembersihan ke setiap tablet yang berpartisipasi dalam transaksi.

Untuk meningkatkan kinerja, YugaByte secara agresif menyimpan informasi untuk transaksi yang sedang berlangsung, menerapkan penguncian yang halus, dan menggunakan sewa pemimpin waktu hybrid untuk mencegah klien membaca nilai-nilai basi dari para pemimpin lama. Transaksi ACID baris tunggal dioptimalkan untuk memiliki latensi rendah saat tidak ada operasi yang bentrok. Transaksi ACID terdistribusi mempertahankan kebenaran dengan mengorbankan latensi yang lebih tinggi.

YCQL, YEDIS, dan PostgreSQL

YugaByte menyertakan implementasi CQL yang hampir lengkap, ditambah beberapa ekstensi. Satu peningkatan besar atas Cassandra adalah YugaByte sangat konsisten, sedangkan Cassandra pada akhirnya konsisten. Penyempurnaan lainnya adalah untuk transaksi terdistribusi, indeks sekunder yang sangat konsisten, dan JSON. YugaByte mengungguli Cassandra untuk setiap operasi kecuali untuk pemindaian jarak pendek, setidaknya sebagian karena konsistensinya yang kuat, yang memungkinkan untuk pembacaan tunggal daripada pembacaan kuorum yang diperlukan di Cassandra.

Cassandra mendukung empat tipe data primitif yang belum didukung di YugaByte: tanggal, waktu, tuple, dan varint. YugaByte juga memiliki beberapa batasan pada ekspresi. 

Penerapan Redis YugaByte tidak memiliki tipe data daftar, tetapi menambahkan tipe data deret waktu. Ini menambahkan persistensi bawaan, sharding otomatis, dan skalabilitas linier serta kemampuan untuk membaca dari pusat data terdekat untuk latensi rendah.

Implementasi PostgreSQL YugaByte tidak terlalu jauh. Saat ini ia tidak memiliki pernyataan UPDATE dan DELETE, ekspresi, dan pernyataan SELECT tidak memiliki klausa gabungan.

Instalasi dan pengujian YugaByte

Anda dapat menginstal YugaByte DB open-source dari kode sumber, dari tarball di MacOS, Centos 7, dan Ubuntu 16.04 atau yang lebih baru, dan dari image Docker di Docker atau Kubernetes. Anda kemudian dapat membuat cluster dan menguji tiga API kueri dan beberapa contoh generator beban kerja.

Saya memilih untuk menginstal YugaByte DB Enterprise di Google Cloud Platform. Meskipun ada lebih banyak langkah manual yang harus diambil daripada yang saya inginkan, saya dapat melalui instalasi dan pengujian saya dalam satu sore setelah saya memiliki kunci lisensi Edisi Enterprise.

Setelah instance YugaWare berjalan pada instance empat CPU di Google Cloud, saya mengonfigurasi Google Cloud Platform sebagai penyedia cloud untuk cluster database saya.

Kemudian saya membuat cluster tiga node dari delapan instance CPU di wilayah AS-Timur.

Saya menjalankan tes beban menggunakan CQL dan Redis API.

Saya dapat meminta data CQL dan Redis dari baris perintah.

Saya juga membuat cluster tiga node di berbagai wilayah yang tersebar di seluruh dunia (di bawah). Ini membutuhkan waktu lebih lama untuk dibuat (sekitar 45 menit) dan memiliki latensi tulis yang jauh lebih tinggi, seperti yang diharapkan. Sayangnya, Anda tidak bisa menyimpang dari kecepatan cahaya.

Biaya YugaByte

Harga lisensi YugaByte DB Enterprise Edition tiga node mulai dari $ 40K per tahun. Selain itu, Anda perlu memperhitungkan biaya server. Untuk cluster tiga node di Google Cloud Platform yang menggunakan instance VM delapan CPU, biayanya berkisar antara $ 800 hingga $ 900 sebulan ditambah lalu lintas jaringan, mungkin $ 11K setahun.

Biaya saya sendiri untuk pengujian sore hari adalah $ 0,38 untuk instans, dan $ 0,01 untuk jalan keluar antar-zona. Menghapus cluster database dari antarmuka YugaByte DB Enterprise sangatlah mudah, dan setelah saya menghentikan instance VM yang menjalankan antarmuka administrasi dan orkestrasi, biaya yang tidak lagi signifikan tidak lagi dikenakan.

Lebih cepat, lebih baik, terdistribusi

Secara keseluruhan, YugaByte DB tampil seperti yang diiklankan. Pada titik ini dalam perkembangannya, ini berguna sebagai Redis dan Cassandra yang lebih cepat, lebih baik, dan didistribusikan. Itu pada akhirnya juga harus menjadi PostgreSQL yang lebih baik, meskipun menurut pengalaman saya itu membutuhkan waktu lama (bertahun-tahun daripada bulan), terutama ketika Anda sampai pada titik mencoba menyesuaikan gabungan relasional.

YugaByte DB belum bersaing dengan Google Cloud Spanner, CockroachDB, atau antarmuka SQL ke Azure Cosmos DB karena kurangnya antarmuka SQL yang sempurna. Itu belum bersaing dengan Neo4j atau antarmuka grafik ke Cosmos DB karena kurangnya dukungan database grafik. Itu bersaing dengan Redis, Cassandra, dan antarmuka yang kompatibel dengan Cassandra ke Cosmos DB.

Haruskah Anda mencoba YugaByte DB sendiri? Jika Anda memerlukan versi Redis atau Cassandra terdistribusi, atau Anda perlu mengganti MongoDB untuk skenario yang didistribusikan secara global, maka ya. YugaByte DB juga dapat digunakan untuk melakukan standarisasi pada satu database untuk berbagai tujuan, seperti menggabungkan database Cassandra dengan cache Redis, seperti yang telah dilakukan oleh pelanggan YugaByte, Narvar. YugaByte DB juga menambahkan indeks sekunder berkinerja tinggi dan tipe JSON ke Cassandra, meningkatkan kegunaannya sebagai database transaksional.

Apakah Anda menginginkan versi open-source atau enterprise dari YugaByte DB bergantung pada anggaran Anda. Pada umumnya, jika Anda adalah pemula, Anda mungkin menginginkan versi open source. Jika Anda adalah perusahaan global yang mapan dengan banyak aplikasi database transaksional, terutama jika Anda perlu sering menskalakan cluster ke atas dan ke bawah, Anda mungkin mendapatkan keuntungan dari fitur tambahan dalam versi perusahaan.