Mereka mengatakan bahwa segala sesuatu dalam hidup patut dicoba setidaknya sekali. Dan jika Anda terbiasa bekerja dengan DBMS relasional, maka ada baiknya Anda mengenal NoSQL dalam praktiknya, pertama-tama, setidaknya untuk pengembangan umum. Sekarang, karena pesatnya perkembangan teknologi ini, terdapat banyak pendapat yang saling bertentangan dan perdebatan sengit mengenai topik ini, yang khususnya memicu minat.
Jika Anda mempelajari esensi dari semua perselisihan ini, Anda akan melihat bahwa perselisihan tersebut muncul karena pendekatan yang salah. Mereka yang menggunakan database NoSQL tepat di tempat yang dibutuhkan akan merasa puas dan menerima semua keuntungan dari solusi ini. Dan para peneliti yang mengandalkan teknologi ini sebagai obat mujarab yang tidak dapat diterapkan sama sekali akan kecewa karena kehilangan kekuatan database relasional tanpa memperoleh manfaat yang signifikan.
Saya akan bercerita tentang pengalaman kami dalam menerapkan solusi berdasarkan Cassandra DBMS: apa yang harus kami hadapi, bagaimana kami keluar dari situasi sulit, apakah kami dapat memperoleh manfaat dari penggunaan NoSQL dan di mana kami harus menginvestasikan upaya/dana tambahan .
Tugas awalnya adalah membangun sistem yang mencatat panggilan di beberapa jenis penyimpanan.
Prinsip pengoperasian sistem adalah sebagai berikut. Masukannya mencakup file dengan struktur tertentu yang menjelaskan struktur panggilan. Aplikasi kemudian memastikan bahwa struktur ini disimpan di kolom yang sesuai. Nantinya, panggilan tersimpan digunakan untuk menampilkan informasi konsumsi lalu lintas pelanggan (biaya, panggilan, riwayat saldo).
Cukup jelas mengapa mereka memilih Cassandra - dia menulis seperti senapan mesin, mudah diskalakan, dan toleran terhadap kesalahan.
Jadi, inilah pengalaman yang diberikan kepada kami
Ya, node yang gagal bukanlah sebuah tragedi. Inilah inti dari toleransi kesalahan Cassandra. Tetapi sebuah node bisa hidup dan pada saat yang sama mulai mengalami penurunan kinerja. Ternyata, hal ini langsung mempengaruhi kinerja seluruh cluster.
Cassandra tidak akan melindungi Anda di mana Oracle menyelamatkan Anda dengan batasannya. Dan jika pembuat aplikasi tidak memahami hal ini sebelumnya, maka kembaran yang diberikan kepada Cassandra tidak lebih buruk dari aslinya. Setelah tiba, kami akan memasukkannya.
IB sangat tidak menyukai Cassandra yang gratis: Tidak ada pencatatan tindakan pengguna, tidak ada pembedaan hak. Informasi tentang panggilan dianggap sebagai data pribadi, yang berarti bahwa semua upaya untuk meminta/mengubahnya dengan cara apa pun harus dicatat dengan kemungkinan audit berikutnya. Selain itu, Anda perlu menyadari perlunya memisahkan hak pada tingkat yang berbeda untuk pengguna yang berbeda. Insinyur operasi sederhana dan admin super yang dapat dengan bebas menghapus seluruh keyspace memiliki peran, tanggung jawab, dan kompetensi yang berbeda. Tanpa pembedaan hak akses seperti itu, nilai dan integritas data akan langsung dipertanyakan lebih cepat dibandingkan dengan tingkat konsistensi APAPUN.
Kami tidak memperhitungkan bahwa panggilan memerlukan analisis serius dan pengambilan sampel berkala untuk berbagai kondisi. Karena catatan yang dipilih kemudian seharusnya dihapus dan ditulis ulang (sebagai bagian dari tugas, kita harus mendukung proses pembaruan data ketika data awalnya salah dimasukkan ke loop kita), Cassandra bukanlah teman kita di sini. Cassandra itu seperti celengan - nyaman untuk menaruh sesuatu, tetapi Anda tidak dapat menghitungnya.
Kami mengalami masalah saat mentransfer data ke zona pengujian (5 node dalam tes versus 20 di pesta prom). Dalam hal ini, dump tidak dapat digunakan.
Masalah dengan memperbarui skema data penulisan aplikasi ke Cassandra. Kemunduran akan menghasilkan banyak sekali batu nisan, yang dapat menyebabkan hilangnya produktivitas dengan cara yang tidak dapat diprediksi.. Cassandra dioptimalkan untuk perekaman, dan tidak banyak berpikir sebelum menulis.Setiap operasi dengan data yang ada di dalamnya juga merupakan rekaman. Artinya, dengan menghapus yang tidak perlu, kita hanya akan menghasilkan lebih banyak catatan, dan hanya sebagian yang akan ditandai dengan batu nisan.
Batas waktu saat memasukkan. Cassandra cantik dalam rekamannya, tapi terkadang arus masuk bisa sangat membingungkannya. Ini terjadi ketika aplikasi mulai memutar beberapa catatan yang tidak dapat dimasukkan karena alasan tertentu. Dan kita memerlukan DBA sungguhan yang akan memantau gc.log, sistem, dan log debug untuk kueri lambat, metrik pemadatan tertunda.
Beberapa pusat data dalam satu cluster. Dari mana membaca dan menulis?
Mungkin dibagi menjadi membaca dan menulis? Dan jika demikian, haruskah ada DC yang lebih dekat dengan aplikasi untuk menulis atau membaca? Dan bukankah kita akan mengalami otak terbelah jika kita memilih tingkat konsistensi yang salah? Ada banyak pertanyaan, banyak pengaturan yang tidak diketahui, kemungkinan yang benar-benar ingin Anda atasi.
Bagaimana kami memutuskan
Untuk mencegah node tenggelam, SWAP dinonaktifkan. Dan sekarang, jika ada kekurangan memori, node harus turun dan tidak membuat jeda gc yang besar.
Jadi, kita tidak lagi mengandalkan logika dalam database. Pengembang aplikasi sedang melatih kembali diri mereka sendiri dan mulai secara aktif mengambil tindakan pencegahan dalam kode mereka sendiri. Pemisahan penyimpanan dan pemrosesan data yang ideal dan jelas.
Kami membeli dukungan dari DataStax. Pengembangan Cassandra dalam kotak telah dihentikan (komitmen terakhir dilakukan pada Februari 2018). Pada saat yang sama, Datastax menawarkan layanan terbaik dan sejumlah besar solusi yang dimodifikasi dan disesuaikan untuk solusi IP yang ada.
Saya juga ingin mencatat bahwa Cassandra sangat tidak nyaman untuk permintaan seleksi. Tentu saja, CQL merupakan langkah maju yang besar bagi pengguna (dibandingkan dengan Trift). Namun jika Anda memiliki seluruh departemen yang terbiasa dengan penggabungan yang nyaman, pemfilteran gratis berdasarkan bidang apa pun, dan kemampuan pengoptimalan kueri, dan departemen ini berupaya menyelesaikan keluhan dan kecelakaan, maka solusi di Cassandra tampaknya bermusuhan dan bodoh bagi mereka. Dan kami mulai memutuskan bagaimana rekan kami harus membuat sampel.
Kami mempertimbangkan dua opsi: Pada opsi pertama, kami menulis panggilan tidak hanya di C*, tetapi juga di database Oracle yang diarsipkan. Hanya saja, tidak seperti C*, database ini hanya menyimpan panggilan untuk bulan ini (kedalaman penyimpanan panggilan cukup untuk kasus pengisian ulang). Di sini kita segera melihat masalah berikut: jika kita menulis secara sinkron, maka kita kehilangan semua keuntungan C* yang terkait dengan penyisipan cepat; jika kita menulis secara asinkron, tidak ada jaminan bahwa semua panggilan yang diperlukan masuk ke Oracle sama sekali. Ada satu kelebihan, namun satu hal yang besar: untuk pengoperasiannya, Pengembang PL/SQL yang sama tetap ada, yaitu kami secara praktis mengimplementasikan pola “Fasad”. Kami menerapkan mekanisme yang membongkar panggilan dari C*, mengambil beberapa data untuk pengayaan dari tabel terkait di Oracle, menggabungkan sampel yang dihasilkan dan memberi kami hasilnya, yang kemudian kami gunakan (memutar kembali, mengulangi, menganalisis, mengagumi). Kekurangan: prosesnya cukup banyak langkah, dan selain itu, tidak ada antarmuka untuk karyawan operasi.
Pada akhirnya, kami memilih opsi kedua. Apache Spark digunakan untuk mengambil sampel dari toples yang berbeda. Inti dari mekanisme ini telah direduksi menjadi kode Java, yang, dengan menggunakan kunci yang ditentukan (pelanggan, waktu panggilan - kunci bagian), mengeluarkan data dari C*, serta data yang diperlukan untuk pengayaan dari database lain. Setelah itu ia menggabungkannya ke dalam memorinya dan menampilkan hasilnya di tabel yang dihasilkan. Kami menggambar tampilan web di atas percikan api dan ternyata cukup berguna.
Saat memecahkan masalah pemutakhiran data uji industri, kami kembali mempertimbangkan beberapa solusi. Baik transfer melalui Sstloader maupun opsi untuk membagi cluster di zona pengujian menjadi dua bagian, yang masing-masing secara bergantian termasuk dalam cluster yang sama dengan cluster promosi, sehingga didukung olehnya. Saat memperbarui pengujian, direncanakan untuk menukarnya: bagian yang berfungsi dalam pengujian dibersihkan dan dimasukkan ke dalam produksi, dan bagian lainnya mulai bekerja dengan data secara terpisah. Namun, setelah berpikir ulang, kami menilai secara lebih rasional data yang layak untuk ditransfer, dan menyadari bahwa panggilan itu sendiri adalah entitas yang tidak konsisten untuk pengujian, dibuat dengan cepat jika diperlukan, dan kumpulan data promosilah yang tidak memiliki nilai untuk ditransfer ke tes. Ada beberapa objek penyimpanan yang layak untuk dipindahkan, tetapi ini sebenarnya hanyalah beberapa meja, dan tidak terlalu berat. Oleh karena itu kita sebagai solusinya, Spark kembali datang untuk menyelamatkan, dengan bantuan yang kami tulis dan mulai aktif menggunakan skrip untuk mentransfer data antar tabel, prom-test.
Kebijakan penerapan kami saat ini memungkinkan kami bekerja tanpa kemunduran. Sebelum promo ada test run wajib yang kesalahannya tidak begitu mahal. Jika terjadi kegagalan, Anda selalu dapat menghapus casespace dan memutar seluruh skema dari awal.
Untuk memastikan ketersediaan Cassandra secara berkelanjutan, Anda memerlukan dba dan bukan hanya dia. Setiap orang yang bekerja dengan aplikasi ini harus memahami di mana dan bagaimana melihat situasi saat ini dan bagaimana mendiagnosis masalah secara tepat waktu. Untuk melakukan ini, kami secara aktif menggunakan DataStax OpsCenter (Administrasi dan pemantauan beban kerja), metrik sistem Cassandra Driver (jumlah waktu tunggu untuk menulis ke C*, jumlah waktu tunggu untuk membaca dari C*, latensi maksimum, dll.), memantau operasi dari aplikasi itu sendiri, bekerja dengan Cassandra.
Ketika kami memikirkan pertanyaan sebelumnya, kami menyadari di mana letak risiko utama kami. Ini adalah formulir tampilan data yang menampilkan data dari beberapa kueri independen ke penyimpanan. Dengan cara ini kita bisa mendapatkan informasi yang cukup tidak konsisten. Namun masalah ini akan menjadi relevan jika kita bekerja hanya dengan satu pusat data. Jadi hal yang paling masuk akal di sini tentu saja adalah membuat fungsi batch untuk membaca data pada aplikasi pihak ketiga, yang akan memastikan bahwa data diterima dalam satu periode waktu. Mengenai pembagian kinerja menjadi membaca dan menulis, di sini kami terhenti oleh risiko bahwa jika koneksi antar DC terputus, kami dapat memperoleh dua cluster yang sama sekali tidak konsisten satu sama lain.
Hasilnya, untuk saat ini berhenti pada tingkat konsistensi untuk menulis EACH_QUORUM, untuk membaca - LOCAL_QUORUM
Kesan dan kesimpulan singkat
Untuk mengevaluasi solusi yang dihasilkan dalam hal dukungan operasional dan prospek pengembangan lebih lanjut, kami memutuskan untuk memikirkan di mana lagi pengembangan tersebut dapat diterapkan.
Langsung saja, kemudian penilaian data untuk program seperti “Bayar saat nyaman” (kami memuat informasi ke dalam C*, perhitungan menggunakan skrip Spark), menghitung klaim dengan agregasi berdasarkan area, menyimpan peran, dan menghitung hak akses pengguna berdasarkan peran matriks.
Seperti yang Anda lihat, repertoarnya luas dan beragam. Dan jika kita memilih kubu pendukung/penentang NoSQL, maka kita akan bergabung dengan pendukung tersebut, karena kita mendapatkan keuntungan, dan persis seperti yang kita harapkan.
Bahkan opsi Cassandra yang siap pakai memungkinkan penskalaan horizontal secara real-time, menyelesaikan masalah peningkatan data dalam sistem tanpa kesulitan. Kami dapat memindahkan mekanisme beban sangat tinggi untuk menghitung agregat panggilan ke dalam sirkuit terpisah, dan juga memisahkan skema dan logika aplikasi, menghilangkan praktik buruk dalam menulis pekerjaan dan objek khusus dalam database itu sendiri. Kami mendapat kesempatan untuk memilih dan mengonfigurasi, untuk mempercepat, DC mana yang akan kami hitung dan DC mana yang akan kami rekam datanya, kami mengasuransikan diri kami sendiri terhadap kerusakan pada masing-masing node dan DC secara keseluruhan.
Menerapkan arsitektur kami pada proyek-proyek baru, dan sudah memiliki beberapa pengalaman, saya ingin segera mempertimbangkan nuansa yang dijelaskan di atas, dan mencegah beberapa kesalahan, memuluskan beberapa sudut tajam yang pada awalnya tidak dapat dihindari.
Misalnya, melacak pembaruan Cassandra secara tepat waktukarena cukup banyak permasalahan yang kami dapatkan yang sudah diketahui dan diperbaiki.
Jangan letakkan database itu sendiri dan Spark pada node yang sama (atau dibagi secara ketat dengan jumlah penggunaan sumber daya yang diizinkan), karena Spark dapat memakan lebih banyak OP dari yang diharapkan, dan kami akan segera mendapatkan masalah nomor 1 dari daftar kami.
Meningkatkan kompetensi pemantauan dan operasional pada tahap pengujian proyek. Awalnya, perhitungkan semaksimal mungkin semua calon konsumen solusi kami, karena pada akhirnya struktur database akan bergantung pada hal ini.
Putar sirkuit yang dihasilkan beberapa kali untuk kemungkinan optimasi. Pilih bidang mana yang dapat diserialkan. Pahami tabel tambahan apa yang harus kita buat agar dapat memperhitungkan dengan paling benar dan optimal, lalu berikan informasi yang diperlukan berdasarkan permintaan (misalnya, dengan asumsi bahwa kita dapat menyimpan data yang sama di tabel yang berbeda, dengan mempertimbangkan pengelompokan yang berbeda menurut kriteria yang berbeda, kita dapat menghemat waktu CPU secara signifikan untuk permintaan baca).
Tidak buruk Segera sediakan untuk melampirkan TTL dan membersihkan data usang.
Saat mengunduh data dari Cassandra Logika aplikasi harus bekerja berdasarkan prinsip FETCH, sehingga tidak semua baris dimuat ke dalam memori sekaligus, tetapi dipilih secara batch.
Dianjurkan sebelum mentransfer proyek ke solusi yang dijelaskan periksa toleransi kesalahan sistem dengan melakukan serangkaian uji tabrakan, seperti kehilangan data dalam satu pusat data, pemulihan data yang rusak dalam jangka waktu tertentu, putusnya jaringan antar pusat data. Pengujian semacam itu tidak hanya akan memungkinkan seseorang untuk mengevaluasi pro dan kontra dari arsitektur yang diusulkan, namun juga akan memberikan praktik pemanasan yang baik bagi para insinyur yang melaksanakannya, dan keterampilan yang diperoleh akan jauh dari berlebihan jika kegagalan sistem direproduksi dalam produksi.
Jika kita bekerja dengan informasi penting (seperti data untuk penagihan, perhitungan utang pelanggan), maka perlu juga memperhatikan alat yang akan mengurangi risiko yang timbul karena fitur DBMS. Misalnya, gunakan utilitas nodesync (Datastax), setelah mengembangkan strategi optimal untuk penggunaannya secara berurutan demi konsistensi, jangan membebani Cassandra secara berlebihan dan menggunakannya hanya untuk tabel tertentu dalam jangka waktu tertentu.
Apa yang terjadi pada Cassandra setelah enam bulan hidup? Secara umum, tidak ada permasalahan yang belum terselesaikan. Kami juga tidak mengizinkan terjadinya kecelakaan serius atau kehilangan data. Ya, kami harus memikirkan untuk mengkompensasi beberapa masalah yang belum pernah muncul sebelumnya, tetapi pada akhirnya hal ini tidak terlalu mengaburkan solusi arsitektur kami. Jika Anda ingin dan tidak takut untuk mencoba sesuatu yang baru, sekaligus tidak ingin terlalu kecewa, maka bersiaplah dengan kenyataan bahwa tidak ada yang gratis. Anda harus memahami, mempelajari dokumentasi, dan merakit penggaruk pribadi Anda lebih dari solusi lama, dan tidak ada teori yang akan memberi tahu Anda sebelumnya penggaruk mana yang menunggu Anda.
Sumber: www.habr.com