Ulasan CockroachDB: Database SQL skala-out yang dibuat untuk bertahan hidup

Sampai saat ini, ketika Anda berbelanja untuk database, Anda harus memilih: Skalabilitas atau konsistensi? Database SQL seperti MySQL menjamin konsistensi yang kuat, tetapi tidak dapat diskalakan dengan baik secara horizontal. (Manual sharding untuk skalabilitas bukanlah ide yang menyenangkan.) Database NoSQL seperti MongoDB menskalakan dengan indah, tetapi hanya menawarkan konsistensi pada akhirnya. ("Tunggu cukup lama, dan Anda bisa membaca jawaban yang benar" —yang bukan merupakan cara apa pun untuk melakukan transaksi keuangan.)

Google Cloud Spanner, layanan database relasional terkelola sepenuhnya yang dijalankan di Google Compute Engine (GCE) yang dirilis pada Februari 2017, memiliki skalabilitas database NoSQL dengan tetap mempertahankan kompatibilitas SQL, skema relasional, transaksi ACID, dan konsistensi eksternal yang kuat. Spanner adalah database relasional yang dipecah, didistribusikan secara global, dan direplikasi yang menggunakan algoritme Paxos untuk mencapai konsensus di antara node-nya.

Salah satu alternatif untuk Spanner, dan subjek ulasan ini, adalah CockroachDB, database SQL terdistribusi open source yang dapat diskalakan secara horizontal yang dikembangkan oleh mantan karyawan Google yang terbiasa dengan Spanner. CockroachDB meminjam dari Google Spanner untuk desain sistem penyimpanan datanya, dan menggunakan algoritme Raft untuk mencapai konsensus di antara node-nya.

Seperti Cloud Spanner, CockroachDB adalah database SQL terdistribusi yang dibangun di atas penyimpanan nilai kunci yang transaksional dan konsisten, dalam kasus CockroachDB di RocksDB. Tujuan desain utama CockroachDB adalah dukungan untuk transaksi ACID, skalabilitas horizontal, dan (yang terpenting) survivabilitas, maka namanya.

CockroachDB dirancang untuk bertahan dari kegagalan disk, mesin, rak, dan bahkan pusat data dengan gangguan latensi minimal dan tidak ada intervensi manual. Tentu saja, untuk mencapai itu Anda perlu menjalankan sekumpulan banyak contoh node simetris CockroachDB, menggunakan beberapa disk, mesin, rak, dan pusat data.

Tidak seperti Cloud Spanner, yang menggunakan TrueTime API yang tersedia untuk sinkronisasi waktu di pusat data Google, CockroachDB tidak dapat mengandalkan kehadiran jam atom dan jam satelit GPS untuk menyinkronkan waktu secara akurat di seluruh node dan pusat data. Itu memiliki sejumlah implikasi. Pertama-tama, Google TrueTime memberikan batas atas untuk offset jam antara node dalam cluster tujuh milidetik. Itu cukup kecil sehingga node Spanner hanya menunggu tujuh milidetik setelah penulisan sebelum melaporkan bahwa transaksi telah dilakukan, untuk menjamin konsistensi eksternal.

Tanpa TrueTime atau fasilitas serupa, CockroachDB harus kembali ke NTP, yang memberikan batasan atas pada sinkronisasi jam antara 100 milidetik dan 250 milidetik. Mengingat jendela waktu yang lebih besar, CockroachDB tidak menunggu setelah menulis. Sebaliknya terkadang menunggu sebelum membaca, pada dasarnya memulai ulang transaksi jika membaca nilai dengan stempel waktu yang lebih besar dari awal transaksi, sekali lagi untuk menjamin konsistensi.

Ketika semua node dalam cluster CockroachDB memiliki batas atas kecil untuk offset jam yang dapat Anda peroleh dari GPS atau jam atom, yang baru saja tersedia di cloud publik utama, masuk akal untuk menjalankannya dengan --linearizable bendera. Itu membuat mereka menunggu offset jam maksimum sebelum mengembalikan komit yang berhasil, seperti Spanner.

Bagaimana CockroachDB bekerja

Setiap node CockroachDB terdiri dari lima lapisan:

  • SQL, yang menerjemahkan kueri SQL klien menjadi operasi nilai kunci
  • Transaction, yang memungkinkan perubahan atomik ke beberapa entri nilai kunci
  • Distribusi, yang menyajikan rentang nilai kunci yang direplikasi sebagai satu entitas
  • Replikasi, yang secara konsisten dan sinkron mereplikasi rentang nilai kunci di banyak node, dan memungkinkan pembacaan yang konsisten melalui sewa
  • Penyimpanan, yang menulis dan membaca data nilai kunci pada disk

Lapisan SQL mem-parsing kueri terhadap file Yacc dan mengubahnya menjadi pohon sintaksis abstrak. Dari pohon sintaksis abstrak, CockroachDB menghasilkan pohon node rencana, yang berisi kode nilai kunci. Node rencana kemudian dieksekusi, berkomunikasi dengan lapisan transaksi.

Lapisan transaksi mengimplementasikan semantik transaksi ACID dengan komitmen dua fase di seluruh kluster termasuk transaksi lintas-rentang dan lintas-tabel, memperlakukan pernyataan tunggal sebagai transaksi (juga disebut mode komitmen otomatis). Komit dua fase diselesaikan dengan memposting catatan transaksi dan menulis maksud, menjalankan operasi baca, dan memperlakukan maksud tulis apa pun yang ditemui sebagai konflik transaksi.

Lapisan distribusi menerima permintaan dari lapisan transaksi pada node yang sama. Ini kemudian mengidentifikasi node mana yang harus menerima permintaan, dan mengirimkan permintaan ke lapisan replikasi node yang tepat.

Lapisan replikasi menyalin data antar node dan memastikan konsistensi antara salinan ini dengan menerapkan algoritme konsensus Raft. Anda dapat mengontrol faktor replikasi di tingkat cluster, database, dan tabel menggunakan zona replikasi. Algoritme konsensus hanya digunakan untuk penulisan, dan mengharuskan kuorum replika menyetujui setiap perubahan pada rentang sebelum perubahan tersebut dilakukan.

Lapisan penyimpanan menyimpan data sebagai pasangan nilai kunci pada disk menggunakan RocksDB. CockroachDB sangat bergantung pada kontrol konkurensi multi-versi (MVCC) untuk memproses permintaan bersamaan dan menjamin konsistensi. Sebagian besar pekerjaan ini dilakukan dengan menggunakan cap waktu hybrid logical clock (HLC).

Seperti Spanner, CockroachDB mendukung kueri perjalanan waktu (diaktifkan oleh MVCC). Ini bisa kembali ke pengumpulan sampah database terbaru Anda, dilakukan secara default setiap hari.

Instalasi dan penggunaan CockroachDB

CockroachDB berjalan di sistem operasi Mac, Linux, dan Windows, setidaknya untuk pengembangan dan pengujian. Database Kecoa Produksi biasanya berjalan di VM Linux atau kontainer yang diatur, sering kali dihosting di cloud publik di beberapa pusat data. Biner Windows dari CockroachDB masih dalam fase beta dan tidak direkomendasikan untuk produksi, dan Apple tidak lagi membuat perangkat keras server.

Lab Kecoa

Seperti yang Anda lihat pada gambar di atas, ada empat opsi untuk menginstal CockroachDB di Mac. Saya memilih Homebrew sebagai yang paling mudah dari keempatnya.

Ngomong-ngomong, Cockroach Labs memposting peringatan di situs yang mengatakan menjalankan aplikasi stateful seperti CockroachDB di Docker itu rumit, tidak disarankan untuk penerapan produksi, dan untuk menggunakan alat orkestrasi seperti Kubernetes atau Docker Swarm untuk menjalankan cluster sebagai gantinya. Saya akan membahas opsi orkestrasi kontainer di bagian selanjutnya.

Instalasi di Mac semudah yang brew install cockroachditunjukkan di atas. Dalam kasus saya, pembaruan otomatis Homebrew membutuhkan waktu lebih lama (cukup waktu untuk menyeduh teh) daripada pemasangan CockroachDB sebenarnya, yang hanya membutuhkan beberapa detik.

Setelah Anda menginstal CockroachDB, cukup mudah untuk menjalankan cluster lokal, meskipun ada langkah ekstra untuk menghasilkan sertifikat keamanan dengan cockroach certperintah jika Anda ingin cluster tersebut aman. Setelah Anda menjalankan cluster (menggunakan cockroach startperintah sekali untuk setiap node, dengan node berikutnya diatur untuk bergabung dengan cluster node pertama), Anda dapat terhubung ke halaman administrasi web pada node mana pun dengan browser, dan menggunakan cockroach sqlklien yang disematkan untuk mengirim SQL kueri ke node mana pun. Sebagian besar browser akan mengeluh tentang situs dengan sertifikat yang dibuat oleh CockroachDB, tetapi Anda harus dapat mengeklik peringatan mengerikan itu dan melanjutkan ke situs tersebut.

Pengaturan produksi CockroachDB yang disarankan berbeda dari default, yang disiapkan untuk pengembangan dan uji coba. Anda dapat mengembangkan pada cluster satu node jika Anda mau. Untuk produksi, Anda harus memiliki minimal tiga node, menjalankan setiap node pada mesin, VM, atau container terpisah, dan memberikan cache ekstra dan memori SQL untuk setiap instance. Pengaturan default masing-masing 128 MB untuk cache dan memori SQL; pengaturan produksi yang disarankan adalah memberikan masing-masing 25 persen RAM:

cockroach start --cache=25% --max-sql-memory=25%

Semakin banyak node yang Anda jalankan, semakin baik ketahanannya. Semakin besar dan cepat node-nya, semakin baik performanya. Jika Anda ingin memiliki node dengan kinerja yang kira-kira sebanding dengan node Google Cloud Spanner, yang menghasilkan 2.000 penulisan per detik dan 10.000 pembacaan per detik, Anda akan menginginkan sesuatu seperti instance n1-highcpu-8 GCE, yang memiliki delapan CPU dan RAM 8 GB , dengan disk SSD lokal (bukan disk yang berputar).

Semakin banyak Anda mendistribusikan node Anda ke pusat data yang berbeda, semakin baik Anda dapat memastikan kekebalan terhadap kegagalan tingkat pusat data. Namun ada biayanya: Latensi bolak-balik antara pusat data akan berdampak langsung pada kinerja basis data Anda, dengan kluster lintas benua berkinerja jauh lebih buruk daripada kluster di mana semua node secara geografis berdekatan.

Cockroach Labs menyediakan instruksi rinci untuk penerapan di AWS, Digital Ocean, GCE, dan Azure. Konfigurasi yang direkomendasikan menggunakan penyeimbang beban, baik layanan penyeimbangan beban terkelola bawaan atau penyeimbang beban sumber terbuka seperti HAProxy.

Orkestrasi dapat menurunkan overhead pengoperasian cluster CockroachDB menjadi hampir tidak ada. Cockroach Labs mendokumentasikan bagaimana melakukan ini untuk produksi dengan Kubernetes dan Docker Swarm. Repositori CockroachDB-CloudFormation di GitHub menunjukkan cara menggunakan AWS CloudFormation dan Kubernetes dalam satu zona ketersediaan untuk pengembangan dan pengujian. Menyesuaikan ini untuk produksi akan melibatkan modifikasi template CloudFormation untuk menggunakan beberapa zona ketersediaan.

Pemrograman dan pengujian CockroachDB

CockroachDB mendukung protokol wire PostgreSQL, jadi Anda menulis kode Anda seolah-olah Anda memprogram terhadap Postgres, atau setidaknya sebagian dari Postgres. Halaman ini mencantumkan driver yang diuji untuk berbagai binding bahasa pemrograman, termasuk bahasa sisi server yang paling populer. Halaman ini mencantumkan contoh dalam 10 bahasa pemrograman dan lima ORM. Saya tidak menemukan kejutan besar ketika saya membaca kodenya, meskipun saya menemukan beberapa kemungkinan bug kecil di daftar dalam dokumentasi. Anda juga dapat menjalankan SQL Anda menggunakan klien interaktif yang dibangun ke dalam cockroachfile yang dapat dieksekusi.

Meskipun ada repo yang didedikasikan untuk generator beban CockroachDB dan satu lagi untuk pengujian kinerja, membuat tolok ukur cluster CockroachDB tidaklah mudah, terutama jika Anda mencoba membandingkan CockroachDB ke database lain dengan cara yang berarti. Satu masalah adalah bahwa jaringan di antara node dapat menjadi langkah pembatas kecepatan dalam cluster CockroachDB.

Fakta lain yang perlu dipertimbangkan adalah bahwa kebanyakan database SQL konvensional tidak berjalan dalam mode isolasi SERIALIZABLE secara default; sebagai gantinya mereka menggunakan mode yang tidak terlalu ketat dengan kinerja yang lebih baik. CockroachDB menggunakan mode isolasi serial secara default. Selain itu, akan sedikit tidak adil untuk menguji kinerja gabungan SQL CockroachDB, yang masih dalam proses, dengan suite TPC-C.

Namun Anda dapat dengan mudah melihat kekuatan operasional CockroachDB. Misalnya, banyak database perlu dihentikan dan dimulai ulang untuk meningkatkan skalanya. Menambahkan node yang sedang dimuat di CockroachDB sangatlah mudah, terutama jika Anda menggunakan alat orkestrasi. Misalnya, screenshot di atas menunjukkan perintah untuk mengubah dan menampilkan node dalam cluster Kubernetes, dan screenshot di bawah ini menunjukkan cluster yang dipantau saat node ditambahkan. Alat penghasil beban terus berjalan selama proses.

Demonstrasi yang lebih mengesankan menunjukkan migrasi lintas cloud otomatis dalam klaster CockroachDB. Ini benar-benar membutuhkan video untuk melakukannya dengan adil; video tersebut dihosting di postingan blog yang ditautkan.

CockroachDB SQL 

SQL di CockroachDB kurang lebih standar, tidak seperti SQL di Cloud Spanner, yang menggunakan sintaks non-standar untuk manipulasi data. CockroachDB SQL masih kehilangan banyak fitur.

Misalnya, V1.1 kekurangan dukungan JSON, yang direncanakan untuk V1.2. Itu juga tidak memiliki penguraian XML, yang tidak ada di peta jalan. Ini tidak memiliki kaskade tingkat baris, direncanakan untuk V1.2, dan tidak memiliki kursor dan pemicu, yang tidak ada di peta jalan. Indeks geospasial adalah tambahan "potensial" yang dapat menjadi peta jalan di masa depan.

Terutama, implementasi awal CockroachDB dari gabungan SQL pada tahun 2016 sengaja disederhanakan dan dipamerkan penskalaan kuadrat, sehingga tidak berguna untuk meminta kumpulan data besar. Versi di V1.0, dikerjakan oleh seorang siswa co-op, menerapkan hash join, membuat banyak operasi gabungan berskala linier; yang membuat CockroachDB hampir ke level SQLite. Suatu saat di tahun 2018, mengingat putaran pendanaan baru-baru ini, CockroachDB seharusnya memiliki kinerja gabungan yang berskala lebih seperti gabungan PostgreSQL, serta pemrosesan gabungan SQL yang didistribusikan melalui kluster.