Dokumen ini membantu developer software dan administrator database memigrasikan aplikasi Aerospike yang ada dengan Bigtable sebagai database. Bagian ini menggunakan pengetahuan Anda tentang Aerospike untuk menjelaskan konsep yang perlu Anda pahami sebelum bermigrasi ke Bigtable.
Untuk membantu Anda mulai bekerja dengan Bigtable dan Aerospike, dokumen ini melakukan hal berikut:
- Membandingkan terminologi antara Aerospike dan Bigtable.
- Memberikan ringkasan operasi Bigtable dan menjelaskan tata letak data dalam Bigtable.
- Menjelaskan pemodelan data dan pertimbangan desain utama.
- Memperjelas cara replikasi dilakukan dan dampaknya.
Untuk mengetahui informasi tentang proses migrasi dan alat open source yang dapat Anda gunakan untuk menyelesaikan migrasi, lihat Memigrasikan dari Aerospike ke Bigtable.
Perbandingan terminologi
Aerospike dan Bigtable adalah database NoSQL terdistribusi, tetapi keduanya memiliki perbedaan yang signifikan dalam desain, operasi, dan terminologinya.
Di Aerospike, data disimpan dalam data. Setiap data berisi satu atau beberapa bin bernama, beserta metadata seperti ukuran data (dalam byte), time to live (TTL), dan waktu pembaruan terakhir (LUT).
Bigtable menyimpan data dalam tabel yang skalabel, yang masing-masing merupakan peta nilai kunci yang diurutkan. Tabel terdiri dari baris yang diindeks oleh kunci baris dan kolom yang diidentifikasi oleh penentu kolom. Jika terkait satu sama lain, kolom dapat membentuk grup kolom. Struktur ini memungkinkan Anda menyimpan beberapa versi nilai dengan kunci yang sama. Setiap versi diidentifikasi dengan stempel waktu yang unik. Versi sebelumnya dapat difilter selama operasi baca atau dihapus melalui pengumpulan sampah berdasarkan kebijakan yang dikonfigurasi.
Untuk mengetahui informasi selengkapnya, lihat Model penyimpanan Bigtable.
Tabel berikut menguraikan dan menjelaskan konsep bersama dan terminologi yang sesuai yang digunakan setiap produk:
| Aerospike | Bigtable |
|---|---|
| Tidak ada item yang sesuai secara langsung. | instance: grup cluster terkelola di berbagai Google Cloud zona atau region yang menjadi tempat terjadinya replikasi dan perutean koneksi. |
| cluster: deployment Aerospike yang terdiri dari kumpulan node. | cluster: sekelompok node di zona geografis Google Cloud yang sama. |
| node: server yang menyediakan komputasi dan memiliki penyimpanannya. | node: server yang hanya menyediakan komputasi. Penyimpanan ditangani oleh Colossus, sistem file terdistribusi terpisah. |
| namespace: menyimpan parameter seperti TTL atau jenis penyimpanan. Dalam namespace, data dibagi lagi menjadi set dan rekaman. | table: padanan terdekat dengan namespace Aerospike. Beberapa parameter ditetapkan untuk semua tabel di tingkat cluster. Kontrol yang lebih baik dapat dilakukan di tingkat tabel atau grup kolom. |
| set: digunakan untuk pembagian logis data dan parameter seperti TTL dan ukuran pembatasan. Kunci harus unik dalam satu set. | Tidak ada item yang sesuai secara langsung. |
| Tidak ada item yang sesuai secara langsung. | table: resource tingkat instance yang otomatis direplikasi ke setiap cluster. Tabel berisi sekumpulan nilai yang diidentifikasi oleh kunci baris unik. Tabel bersifat jarang, yang berarti tabel tidak menggunakan ruang tambahan untuk menyimpan kolom yang tidak berisi nilai apa pun. |
| Tidak ada item yang sesuai secara langsung. | tablet: rentang baris berkelanjutan yang disimpan bersama. Bigtable menggunakan tablet untuk load balancing dengan menetapkannya ke node. Batas tablet bersifat dinamis—dapat dipisahkan atau digabungkan dari waktu ke waktu. |
| rekaman: sekumpulan bin bernama yang digunakan untuk menyimpan data. Ukuran maksimumnya adalah 8 MB. | baris: sekumpulan nilai yang diidentifikasi oleh grup kolom, penentu kolom, stempel waktu. Semua operasi bersifat atomik di tingkat baris. |
| Tidak ada item yang sesuai secara langsung. | grup kolom: grup kolom yang diurutkan dalam urutan leksikografis. Pengumpulan sampah ditetapkan di tingkat ini. |
| bin: pasangan nilai kunci dengan nama bin sebagai ID nilai dalam sebuah rekaman. | penentu kolom: label untuk nilai yang disimpan dalam tabel. |
| Tidak ada item yang sesuai secara langsung. | sel: label untuk nilai berstempel waktu yang disimpan dalam tabel. |
| (record) digest: hash tiga tuple yang mengidentifikasi sebuah data: namespace, set, dan kunci. | Tidak ada item yang sesuai secara langsung. |
| key: ID data yang unik dalam satu set. | kunci baris: ID baris, unik dalam tabel. |
| AQL:alat command line untuk menjelajahi data dan mengembangkan fungsi yang ditentukan pengguna untuk database Aerospike. | GoogleSQL: bahasa kueri yang digunakan oleh beberapa layanan, termasuk Spanner, BigQuery, dan Bigtable. Google Cloud |
Batas jenis data
Tabel berikut membandingkan batas untuk jenis data yang digunakan oleh Aerospike dan Bigtable:
| Aerospike | Bigtable |
|---|---|
| namespace: Jumlah maksimum namespace untuk Edisi Enterprise adalah 32. | table: Satu instance dapat memiliki hingga 1.000 tabel. Nama tabel tidak boleh melebihi 50 karakter. |
| set: Cluster dapat memiliki hingga 4.095 set. Nama set tidak boleh melebihi 63 byte. | Tidak ada item yang sesuai secara langsung. |
| record: Ukuran maksimum rekaman adalah 8 MB. | baris: Ukuran baris maksimum adalah 256 MB. |
| Tidak ada item yang sesuai secara langsung. | grup kolom: Jumlah grup kolom tidak terbatas, tetapi lebih dari 100 dapat menyebabkan penurunan performa. |
| bin: Jumlah bin tidak terbatas, tetapi setiap bin dapat menampung tidak lebih dari 1 MB data. Nama bin tidak boleh melebihi 15 byte. | penentu kolom: Batasnya adalah 100 MB, tetapi sebaiknya tidak melebihi 10 MB. Jumlah kolom tidak terbatas. |
| kunci: Ukuran kunci maksimum adalah 8 KB. | kunci baris: Ukuran kunci baris maksimum adalah 4 KB. |
Untuk mengetahui informasi selengkapnya tentang batas Bigtable dan Aerospike, lihat Kuota dan Batas serta Batas dan nilai minimum sistem Aerospike.
Arsitektur
Bagian berikut memberikan ringkasan arsitektur Bigtable dan Aerospike.
Bigtable
Node Bigtable terpisah dari lapisan penyimpanan, yang berarti node tidak memengaruhi daya tahan data. Klien tabel Bigtable tidak mengetahui distribusi data pokok. Lapisan perutean tambahan mendistribusikan permintaan ke node yang benar. Setiap node menangani sebagian permintaan ke cluster. Tabel Bigtable di-sharding menjadi blok baris yang berdekatan, yang disebut tablet, yang disimpan di Colossus, sistem file terdistribusi yang memberikan daya tahan tinggi. Setiap tablet dikaitkan dengan node Bigtable tertentu.
Arsitektur Bigtable memberikan manfaat berikut:
- Klien Bigtable tidak perlu mengetahui distribusi data dan load balancing. Kompleksitas tersebut ditangani oleh lapisan perutean.
- Penyeimbangan ulang terjadi sangat cepat dan pemulihan dari kegagalan juga cepat karena data sebenarnya tidak disalin antar-node.
- Jika node Bigtable gagal, tidak ada data yang hilang.
Aerospike
Berbeda dengan Bigtable, penyimpanan Aerospike berada di node yang melayannya. Setiap node (server) dalam cluster Aerospike identik. Data di setiap namespace dibagi menjadi tepat 4.096 partisi dengan melakukan hashing pada nama rekaman. Partisi ini didistribusikan secara merata di antara node.
Node saling mengetahui dan menyeimbangkan kembali partisi yang disimpan saat cluster berubah. Setiap kali perubahan cluster terjadi, replika akan memilih replika utama yang mengoordinasikan penyeimbangan ulang. Library klien diharapkan melacak replika mana yang menyimpan partisi utama dan mengirim permintaan tulis ke replika yang tepat. Jika klien mengirim permintaan ke node yang salah (hal ini dapat terjadi selama penyeimbangan ulang), permintaan akan dialihkan oleh node.
Replikasi
Bagian ini membandingkan proses replikasi untuk Aerospike dan Bigtable.
Bigtable
Instance Bigtable dapat terdiri dari satu cluster atau beberapa cluster yang direplikasi. Tabel selalu direplikasi ke semua cluster dalam instance. Cluster dapat ditambahkan atau dihapus dari instance dengan dampak minimal pada cluster lain.
Bigtable menyediakan konsistensi read-your-write dalam satu cluster. Operasi tulis dilakukan pada satu cluster dan pada akhirnya menjadi konsisten di seluruh cluster lain dalam instance. Tidak seperti Aerospike, Bigtable tidak kehilangan update perantara karena setiap sel diberi versi secara internal, sehingga tidak ada penulisan yang hilang. Setiap cluster melayani sel yang memiliki stempel waktu terbaru yang tersedia.
Bigtable API menawarkan token konsistensi tingkat tabel, yang dapat digunakan untuk memverifikasi apakah semua perubahan yang dilakukan sebelum pembuatan token direplikasi sepenuhnya.
Aerospike
Aerospike menangani replikasi dalam cluster di tingkat partisi. Namespace dibagi menjadi partisi yang didistribusikan secara merata di antara node. Konsistensi yang kuat dipastikan dalam cluster. Operasi tulis hanya dikonfirmasi setelah semua replika dalam cluster mengakuinya.
Replikasi lintas pusat data (XDR) dapat dikonfigurasi untuk sinkronisasi data antara berbagai cluster. Konvergensi bin Aerospike memastikan bahwa data pada akhirnya sama di semua pusat data pada akhir replikasi, tetapi update perantara dapat hilang.
Untuk daya tahan, algoritma konsistensi berbasis daftar Aerospike memerlukan N+1 salinan untuk menangani N kegagalan.
Model data
Bagian ini membandingkan model data yang digunakan oleh Bigtable dan Aerospike.
Skema fleksibel
Aerospike tidak menerapkan batasan skema, sehingga setiap data dapat memiliki bin yang berbeda dengan berbagai jenis nilai. Demikian pula, Bigtable mendukung kolom renggang, sehingga tidak ada penyimpanan yang digunakan untuk kolom tanpa nilai. Meskipun tidak ada batasan ketat pada jumlah kolom atau family kolom, sebaiknya jumlah family kolom tidak lebih dari 100 karena alasan performa.
Desain kunci baris
Bigtable mengidentifikasi baris berdasarkan kunci baris yang harus unik dalam tabel. Turunan ini diurutkan secara leksikografis dan dikelompokkan dalam tablet. Hal ini berbeda dengan Aerospike, yang mendistribusikan data di seluruh node berdasarkan hash-nya. Kunci baris harus didesain untuk memastikan bahwa baris yang sering diakses bersama juga disimpan bersama.
Jenis data
Aerospike mendukung jenis data lanjutan, termasuk skalar, GeoJSON, HyperLogLog, daftar, dan objek bertingkat. Jenis ini dapat diindeks dan dikueri dengan dukungan indeks sekunder. Selain itu, Aerospike menyediakan API sisi server yang memungkinkan operasi kompleks pada jenis data ini, seperti memfilter menurut geolokasi atau memanipulasi konten daftar.
Bigtable API terutama berfokus pada penanganan byte mentah dengan beberapa pengecualian. Library ini juga secara native menggunakan INT64 untuk stempel waktu dan penghitung yang dapat di-increment sebagai operasi atomik. Bahasa kueri juga mendukung banyak jenis kompleks seperti skalar, objek JSON, dan bin HLL. Jenis lanjutan mungkin akan semakin didukung pada masa mendatang, tetapi pada saat penulisan dokumen ini, tidak ada cara untuk memasukkan jenis tersebut ke Bigtable, semuanya diserialisasi di sisi klien. Anda dapat menggunakan library adaptor dari aerospike-migration-tools untuk melakukan serialisasi jenis data.
Grup kolom
Di Bigtable, grup kolom menentukan kolom mana dalam tabel yang disimpan dan diambil bersama-sama, dan setidaknya satu grup kolom harus ada untuk setiap tabel. Kolom terkait harus dikelompokkan ke dalam grup yang sama. Data dengan persyaratan retensi yang berbeda harus dipisahkan ke dalam grup kolom yang berbeda, karena kebijakan pengumpulan sampah berlaku di tingkat grup kolom.
Penentu kolom
Di Bigtable, penentu kolom digunakan dalam grup kolom untuk menentukan kolom individual. Tabel dapat mendukung jutaan kolom, tetapi praktik terbaiknya adalah membatasi jumlah kolom dalam satu baris. Secara opsional, kualifikasi kolom dapat diperlakukan sebagai data, sehingga nilai dapat disematkan langsung dalam nama kolom untuk menghemat ruang.
Sel
Di Bigtable, sel adalah persimpangan antara row key dan nama kolom (grup kolom yang dikombinasikan dengan penentu kolom). Setiap sel berisi satu atau beberapa nilai berstempel waktu yang dapat diberikan oleh klien atau diterapkan secara otomatis oleh layanan.
Indeks sekunder
Tampilan terwujud berkelanjutan dapat bertindak sebagai indeks sekunder asinkron, sehingga memungkinkan tabel dikueri menggunakan pola atau atribut penelusuran yang berbeda. Untuk mengetahui informasi selengkapnya, lihat Membuat indeks sekunder asinkron.
Transaksi
Bigtable dan Aerospike sama-sama tidak mendukung transaksi multi-baris, tetapi berbeda dalam kemampuan baris tunggalnya. Bigtable menyediakan penulisan baris tunggal yang sepenuhnya konsisten dalam cluster dan mendukung transaksi baris tunggal melalui permintaan mutate-row. Fungsi ini memungkinkan beberapa operasi pada satu baris, yang semuanya dijalankan secara atomik dan semuanya berhasil atau semuanya gagal. Selain itu, ada operasi baca-ubah-tulis dan periksa-dan-ubah, meskipun operasi ini tidak tersedia dengan profil perutean multi-cluster. Sebaliknya, Aerospike memperluas transaksi baris tunggal dengan manipulasi data sisi server dan eksekusi fungsi yang ditentukan klien.
Load balancing dan failover
Aerospike menggunakan Smart Client untuk menangani load balancing di sisi klien. Proses yang berjalan di sisi klien yang mengetahui status cluster dan distribusi data. Klien ini bertanggung jawab untuk merutekan permintaan.
Jika node gagal atau node baru ditambahkan, cluster harus diseimbangkan kembali. Primary sementara dipilih untuk mengatur tindakan penyeimbangan ulang dan pendistribusian ulang partisi antar-node. Selama hal itu terjadi, cluster tetap beroperasi, tetapi klien harus melacak perubahan untuk perutean permintaan. Jika permintaan mencapai node yang salah, permintaan tersebut akan dirutekan secara internal ke node yang benar.
Klien Bigtable adalah klien tipis, yang menyembunyikan semua kompleksitas seperti status cluster dan distribusi data dari pengguna. Perutean permintaan ditangani oleh lapisan berikutnya, yaitu klien tebal di dalam infrastruktur Bigtable Google Cloud.
Perbedaan lainnya adalah kebijakan perutean yang tidak tersedia di Aerospike. Bigtable menggunakan profil aplikasi untuk mengelola perutean permintaan, dengan prioritas yang dapat dikonfigurasi untuk mengontrol urutan permintaan ditayangkan. Ada dua jenis kebijakan perutean: satu cluster dan multi-cluster. Profil multi-cluster merutekan operasi ke cluster terdekat yang tersedia. Cluster di region yang sama dianggap berjarak sama dari perspektif perute operasi. Jika node yang bertanggung jawab atas rentang kunci yang diminta kelebihan beban atau tidak tersedia untuk sementara di cluster, profil ini menyediakan failover otomatis. Sebaliknya, Aerospike tidak menyediakan failover otomatis jika terjadi kegagalan cluster secara keseluruhan.
Pencadangan dan pemulihan
Aerospike menyediakan alat pencadangan dan pemulihan eksternal yang disebut asbackup dan asrestore yang membuat pencadangan logis di sisi klien dan serupa dengan melakukan pemindaian. Pengelolaan pencadangan juga dapat ditangani melalui Aerospike Backup Service atau Aerospike Kubernetes Operator, yang keduanya menggunakan asbackup dan asrestore secara internal, serta menyediakan penjadwalan dan koordinasi multi-proses. Pencadangan tidak bersifat atomik, yang berarti operasi tulis yang terjadi selama pencadangan mungkin tidak dicatat.
Bigtable menyediakan dua metode untuk memenuhi kebutuhan pencadangan umum: pencadangan Bigtable dan ekspor data terkelola. Cadangan membuat salinan tabel yang dapat dipulihkan yang disimpan sebagai objek anggota cluster. Anda dapat memulihkan cadangan sebagai tabel baru di cluster yang memulai pencadangan. Pencadangan dirancang untuk membuat titik pemulihan jika terjadi kerusakan tingkat aplikasi. Pencadangan Bigtable juga tidak bersifat atomik. Perubahan mungkin dilakukan di bagian tabel yang telah disalin oleh cadangan.
Perbedaan utama dalam penanganan pencadangan
- Cadangan Aerospike dibuat di sisi klien. Metode ini tidak memerlukan ruang tambahan di sisi server, tetapi lebih lambat. Di Bigtable, cadangan berbagi penyimpanan fisik dengan tabel sumber dan cadangan lain dari tabel tersebut.
- Pengguna Aerospike perlu menangani ekspor, penyimpanan, dan penghapusan cadangan yang sudah tidak berlaku. Karena pencadangan di Bigtable terintegrasi sepenuhnya, semua tindakan ini ditangani secara otomatis oleh layanan Bigtable.
Pertimbangan performa
Karena Aerospike dan Bigtable memperlakukan operasi baca dan tulis secara berbeda, keduanya memiliki perbedaan performa yang penting untuk dipertimbangkan. Tabel berikut mencakup beberapa contoh perbedaan performa antara kedua database. Untuk mengetahui informasi selengkapnya, lihat Panduan performa Bigtable.
| Pertimbangan | Bigtable | Aerospike |
|---|---|---|
| Baris aktif | Mendistribusikan tablet dan operasi untuk menyamakan penggunaan resource. Baris yang sering diakses dapat diisolasi ke tablet satu baris di satu node, sehingga membatasi dampak pada baris lain. | Mendistribusikan baris berdasarkan hash di semua node, terlepas dari traffic. Baris aktif dapat memengaruhi performa seluruh partisi. |
| Memindai kunci yang diurutkan | Menyimpan data secara leksikografis, sehingga sangat efektif untuk mengalirkan data yang diurutkan. | Mendistribusikan data berdasarkan hash, sehingga memindai banyak kunci berurutan memerlukan kueri beberapa node dan menggabungkan hasil, yang dapat lebih lambat. Mendukung indeks sekunder, termasuk jenis lanjutan, yang dapat mengurangi kebutuhan pemindaian. |
| Memasukkan banyak kunci berturut-turut | Menyimpan data secara leksikografis, yang berarti satu node menangani banyak operasi tulis kunci berurutan. Akibatnya, pola baca atau tulis dapat berakhir di node yang menyimpan tablet yang bertanggung jawab atas akhir ruang kunci baris, sehingga secara efektif membebani node tersebut. | Mendistribusikan kunci berdasarkan hash, mendistribusikan beban di antara beberapa node saat menulis kunci berurutan. |
| Baris dengan jumlah kolom yang sangat banyak | Meskipun Bigtable dapat mendukung baris hingga 256 MB, pemrosesan baris besar dapat memengaruhi performa. Bigtable dioptimalkan untuk baris yang lebih kecil, itulah sebabnya organisasi sel dan akses ke data harus dipertimbangkan selama desain skema untuk menghindari penyebaran data di banyak sel jika tidak diperlukan. | Berperforma kurang optimal saat menemukan baris atau data dengan jumlah kolom atau bin yang sangat besar. |
| Cold start | Berperforma terbaik dengan tabel besar yang sering diakses. Jika Anda mulai mengirim permintaan setelah tidak menggunakan layanan selama beberapa waktu (cold start), Anda mungkin melihat latensi yang tinggi. Hal ini terjadi karena pemisahan ke dalam tablet dan distribusinya di antara node mungkin tidak optimal dan karena cache tidak aktif. Distribusi antar-node mungkin tidak sepenuhnya optimal hingga beberapa menit selama cold start dan selama penyeimbangan ulang. | Performa tidak berubah seiring waktu karena distribusi data tidak berbasis beban. Meskipun cache perlu di-warm-up, indeks disimpan dalam memori, sehingga meminimalkan waktu penelusuran disk dan mengurangi pentingnya caching. |
| Banyak tabel kecil | Hindari membuat banyak tabel kecil. Tabel terpisah dapat dibenarkan untuk kasus penggunaan atau skema yang berbeda, tetapi tidak untuk data serupa, karena tidak meningkatkan load balancing dan meningkatkan overhead pengelolaan. | Sebagian besar data berada di satu namespace, yang dikelompokkan ke dalam set. Set tidak memiliki skema tertentu, tetapi indeks sekunder atau operasi pemindaian dapat ditetapkan per set. Membagi data menjadi beberapa set tidak memengaruhi performa. |
| Set data besar | Mampu menyimpan set data skala exabyte. Performa tidak terpengaruh oleh ukuran total set data karena arsitektur dan pemisahan tablet dinamisnya. | Secara teknis, database Aerospike tidak memiliki batas ukuran, tetapi Aerospike menyimpan indeks dan catatan secara terpisah. Kedua jenis data dapat disimpan di berbagai jenis perangkat penyimpanan untuk meningkatkan performa. Menyimpan indeks dalam RAM sangat penting untuk latensi rendah, tetapi mungkin tidak dapat dilakukan untuk set data yang sangat besar. Misalnya, dengan 4 miliar objek dan faktor replikasi 2 (RF2), memori yang digunakan terkait dengan indeks utama di seluruh cluster dalam All Flash adalah 2,5 GiB. Dengan contoh yang sama dalam konfigurasi Memori Hybrid, dengan indeks utama dalam memori, 476,8 GiB memori akan digunakan. |
| Penskalaan | Pemrosesan dan penyimpanan tidak terikat dan dapat diskalakan secara terpisah. Satu node dapat menangani potongan data berukuran ratusan terabyte atau bahkan petabyte. | Menyimpan indeks dalam RAM sangat penting untuk latensi rendah. Dalam kasus seperti itu, mesin harus diskalakan secara vertikal bersama dengan kapasitas penyimpanan untuk memperhitungkan indeks utama. |
Langkah berikutnya
- Baca tentang desain skema Bigtable.
- Pelajari lebih lanjut Aerospike.
- Pelajari emulator Bigtable.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.