Cassandra: pemeliharaan

Saya tidak berpengalaman dengan Cassandra, tetapi saya memiliki beberapa pengalaman dengan basis data relasional berbasis SQL.

Saya tidak dapat menemukan informasi praktik terbaik tentang cara mempertahankan Cassandra setelah dikerahkan. Apakah perlu untuk VACUUM database? Saya harus berpikir bahwa beban baca / tulis menyebabkan fragmentasi dalam penyimpanan.

Atau lebih umum: apa praktik terbaik untuk mempertahankan penyebaran produksi Cassandra? Apa yang harus dilakukan secara berkala untuk menjaga kesehatan sistem? Manual Operasi benar-benar tidak membahas aspek ini.

Terima kasih.

Secara umum, cluster yang dirancang dengan baik dapat hidup selama bertahun-tahun tanpa disentuh. Saya sudah memiliki kelompok yang berjalan selama bertahun-tahun lepas tangan. Namun, berikut beberapa pedoman:

Pemantauan sangat penting:

1) Memantau latensi. Gunakan opscenter atau alat metrik favorit Anda untuk melacak latensi. Latensi yang naik dapat menjadi tanda masalah yang datang, termasuk jeda GC (lebih umum pada beban kerja baca daripada beban kerja tulis), masalah stabil, dan sejenisnya.

2) Monitor jumlah yang stabil. Hitungan SSTable akan meningkat jika Anda overrun pemadatan (setiap sstable ditulis tepat satu kali - penghapusan ditangani dengan menggabungkan sstable lama ke sstable baru melalui pemadatan).

3) Monitor perubahan status simpul (atas / bawah, dll). Jika Anda melihat node mengepak, selidiki, karena itu tidak normal.

4) Melacak penggunaan disk Anda - secara tradisional, Anda harus tetap di bawah 50% (terutama jika Anda menggunakan pemadatan STCS).

Ada beberapa hal dasar yang harus dan tidak seharusnya Anda lakukan secara teratur:

1) Jangan lari secara eksplisit nodetool compact. Anda menyebutkan bahwa Anda telah melakukannya, itu tidak fatal, tetapi hal itu menciptakan sstables yang sangat besar, yang kemudian cenderung berpartisipasi dalam pemadatan bergerak maju. Anda tidak perlu terus menjalankannya, tetapi kadang-kadang mungkin membantu untuk menyingkirkan data yang dihapus / ditimpa.

2) nodetool repairbiasanya direkomendasikan setiap gc_grace_seconds(10 hari secara default). Ada beban kerja di mana ini kurang penting - alasan terbesar Anda MEMBUTUHKAN perbaikan adalah untuk memastikan penanda penghapusan ( tombstones) ditransmisikan sebelum habis masa berlakunya (mereka hidup gc_grace_seconds, jika sebuah simpul turun saat penghapusan terjadi, data dapat hidup kembali. tanpa perbaikan!). Jika Anda tidak mengeluarkan penghapusan, dan Anda kueri dengan tingkat konsistensi yang cukup (baca dan tulis di QUORUM, misalnya), Anda sebenarnya dapat menjalani kehidupan tanpa perbaikan.

3) Jika Anda akan memperbaiki, pertimbangkan untuk menggunakan perbaikan tambahan, dan memperbaiki rentang kecil sekaligus.

4) Strategi pemadatan penting - banyak. STCS bagus untuk menulis, LCS bagus untuk membaca. DTCS memiliki beberapa kebiasaan.

5) Model data penting - seperti lingkungan RDBMS / SQL yang bermasalah ketika kueri yang tidak diindeks menghantam tabel besar, Cassandra dapat bermasalah dengan baris / partisi yang sangat besar.

6) Snapshots murah. Sangat murah. Hampir instan, hanya tautan keras, harganya hampir tidak ada ruang disk segera. Gunakan snapshot sebelum Anda meningkatkan versi, terutama versi utama.

7) Hati-hati dengan penghapusan. Seperti yang diisyaratkan di # 2, delete membuat lebih banyak data pada disk, dan tidak membebaskannya sesekali gc_grace_seconds.

Ketika semuanya gagal:

Saya telah melihat artikel yang menyarankan Cassandra di prod memerlukan kepala yang berdedikasi untuk mengelola setiap cluster berukuran - Saya tidak tahu bahwa itu benar, tetapi jika Anda khawatir, Anda mungkin ingin menyewa konsultan pihak ketiga (TheLastPickle, Pythian ) atau memiliki kontrak dukungan (Datastax) untuk memberi Anda ketenangan pikiran.

Menurut dokumentasi perbaikan Cassandra , nodetool repairharus dijalankan dalam situasi berikut:

• Sebagai praktik terbaik, Anda harus menjadwalkan perbaikan setiap minggu. Catatan: Jika penghapusan tidak pernah terjadi, Anda harus tetap menjadwalkan perbaikan reguler. Sadarilah bahwa pengaturan kolom ke nol adalah penghapusan.
• Selama pemulihan node. Misalnya, ketika membawa simpul kembali ke gugus setelah kegagalan.
• Pada node yang berisi data yang tidak sering dibaca.
• Untuk memperbarui data pada simpul yang telah turun.

Saya harus berpikir bahwa beban baca / tulis menyebabkan fragmentasi dalam penyimpanan.

Data dalam Cassandra tidak "terpecah-pecah" dengan cara yang Anda pikirkan. Namun, penghapusan memang memicu penempatan batu nisan, dan proses pemadatan normal menghilangkan batu nisan.

Saya mengerti sekarang bahwa pemadatan adalah masalah besar dan berjalan secara otomatis

Benar. Saya diberitahu oleh perwakilan DataStax bahwa setelah Anda menjalankan compactsecara manual, Anda harus selalu menjalankannya secara manual. Alasannya adalah bahwa pemadatan bekerja dengan "memadatkan" semua SSTABLES yang ada di ruang kunci ke file SSTABLE tunggal. Anda mungkin memiliki beberapa keluarga kolom dalam file SSTABLE yang kecil, dan akan membutuhkan waktu begitu lama untuk meningkat melampaui ambang pemadatan, sehingga kemungkinan pemadatan otomatis yang pernah berjalan lagi sangat rendah.

Pada dasarnya, pastikan untuk menjadwalkan yang teratur nodetool repair, tidak pernah berjalan nodetool compact, dan menerapkan strategi cadangan (snapshot, cadangan inkremental, atau keduanya).