Mereka mengatakan bahwa dalam hidup semuanya layak dicoba setidaknya sekali. Dan jika Anda terbiasa bekerja dengan DBMS relasional, maka berkenalan dengan NoSQL adalah sepadan, pertama-tama, setidaknya untuk pengembangan umum. Sekarang, karena pesatnya perkembangan teknologi ini, ada banyak pendapat yang saling bertentangan dan perdebatan sengit tentang topik ini, yang terutama memicu minat.
Jika Anda mempelajari esensi dari semua perselisihan ini, Anda dapat melihat bahwa perselisihan itu muncul karena pendekatan yang salah. Mereka yang menggunakan database NoSQL tepat di tempat mereka dibutuhkan merasa puas dan mendapatkan semua keuntungannya dari solusi ini. Dan para peneliti yang mengandalkan teknologi ini sebagai obat mujarab di mana itu tidak berlaku sama sekali, kecewa kehilangan kekuatan database relasional tanpa mendapatkan manfaat yang signifikan.
Saya akan bercerita tentang pengalaman kami dalam mengimplementasikan solusi berdasarkan Cassandra DBMS: apa yang harus kami hadapi, bagaimana kami keluar dari situasi sulit, apakah kami berhasil mendapatkan manfaat dari menggunakan NoSQL dan di mana kami harus menginvestasikan usaha / uang ekstra.
Tugas awal adalah membangun sistem yang merekam panggilan ke penyimpanan tertentu.
Prinsip sistem adalah sebagai berikut. File dengan struktur tertentu yang menggambarkan struktur panggilan datang ke input. Kemudian aplikasi memastikan bahwa struktur ini disimpan di kolom yang sesuai. Di masa depan, panggilan yang disimpan digunakan untuk menampilkan informasi tentang konsumsi lalu lintas untuk pelanggan (biaya, panggilan, riwayat saldo).
Mengapa Kassandra terpilih cukup bisa dimengerti - ia menulis sebagai senapan mesin, mudah diukur, dan toleran terhadap kesalahan.
Jadi, inilah pengalaman yang kami berikan
Ya, simpul yang mogok bukanlah tragedi. Itulah inti dari toleransi kesalahan Cassandra. Tetapi node dapat hidup dan pada saat yang sama mulai melorot pada kinerja . Ternyata, ini segera mempengaruhi kinerja seluruh cluster.
Cassandra tidak melakukan lindung nilai di mana Oracle disimpan dengan konstanta . Dan jika penulis aplikasi tidak memahami ini sebelumnya, maka pengambilan yang diterbangkan untuk Cassandra tidak lebih buruk dari aslinya. Begitu dia datang, maka kita akan memasukkannya.
Kassandra gratis "di luar kotak" tidak menyukai keamanan informasi secara tajam: tidak ada pencatatan tindakan pengguna, dan tidak ada pembedaan hak . Informasi tentang panggilan terkait dengan data pribadi, yang berarti bahwa semua upaya untuk meminta / mengubahnya dengan cara apa pun harus dicatat dengan kemungkinan audit berikutnya. Selain itu, Anda perlu mengetahui perlunya memisahkan hak di berbagai tingkat untuk pengguna yang berbeda. Seorang insinyur operasi sederhana dan admin super yang dapat dengan bebas menghapus seluruh ruang kunci adalah peran yang berbeda, tanggung jawab berbeda, kompetensi. Tanpa pembedaan hak akses, nilai dan integritas data akan segera dipertanyakan lebih cepat daripada dengan tingkat konsistensi APAPUN.
Kami tidak memperhitungkan bahwa panggilan memerlukan analitik serius, serta sampel berkala untuk berbagai kondisi. Karena catatan yang dipilih kemudian seharusnya dihapus dan ditulis ulang (dalam kerangka tugas, kita harus mendukung proses memperbarui data ketika loop data awalnya dimasukkan secara salah), Kassandra bukan teman kita di sini. Cassandra, seperti celengan, mudah untuk dimasukkan ke dalamnya, tetapi Anda tidak akan bisa menghitungnya.
Menghadapi masalah mentransfer data ke zona uji (5 node dalam tes versus 20 di prom). Dalam hal ini, dump tidak dapat digunakan.
Masalah memperbarui skema data penulisan aplikasi ke Kassandra. Kembalikan ini akan memunculkan banyak sekali batu nisan, yang dengan cara yang tidak terduga dapat menurunkan produktivitas kita . Cassandra dioptimalkan untuk merekam, dan sebelum merekam, tidak banyak berpikir. Operasi apa pun dengan data yang ada di dalamnya juga merupakan catatan. Artinya, setelah menghapus kelebihan, kami hanya menelurkan lebih banyak catatan, dan hanya sebagian dari mereka yang akan ditandai dengan batu nisan.
Timeout pada saat insert. Cassandra memang cantik dalam rekaman itu, tetapi terkadang aliran yang masuk bisa sangat membingungkan baginya . Ini terjadi ketika aplikasi mulai melingkari beberapa catatan yang tidak dapat dimasukkan dengan alasan apa pun. Dan kita akan membutuhkan DBA yang nyata, yang akan mengikuti gc.log, sistem, dan log debug untuk permintaan lambat, metrik untuk pemadatan pemadatan.
Beberapa pusat data dalam sebuah cluster. Di mana membaca dan di mana untuk menulis?
Mungkin dibagi menjadi membaca dan menulis? Dan jika demikian, haruskah ada DC untuk menulis atau membaca lebih dekat ke aplikasi? Dan bukankah kita akan mendapatkan otak yang benar-benar pecah jika kita memilih tingkat konsistensi yang salah? Banyak pertanyaan, banyak pengaturan yang belum dijelajahi, fitur yang benar-benar ingin saya putar.
Bagaimana kami memutuskan
Bahwa node tidak menyia-nyiakan, menonaktifkan SWAP . Dan sekarang dengan kekurangan memori, simpul harus berbaring, dan tidak menghasilkan gc yang besar berhenti.
Jadi, kami tidak lagi berharap untuk logika dalam database. Pengembang aplikasi mempelajari kembali dan mulai aktif membuat aman dalam kode mereka sendiri. Pemisahan yang jelas untuk penyimpanan dan pemrosesan data.
Kami membeli dukungan dari DataStax. Kotak Kassandra sudah berhenti berkembang (komit terakhir pada Februari 2018). Pada saat yang sama, Datastax menawarkan layanan yang sangat baik dan sejumlah besar dimodifikasi dan disesuaikan dengan solusi IC yang ada.
Saya juga ingin mencatat bahwa Kassandra tidak terlalu nyaman untuk menanyakan sampel. Tentu saja, CQL adalah langkah besar menuju pengguna (dibandingkan dengan Trift). Tetapi jika Anda memiliki seluruh departemen, terbiasa dengan gabungan nyaman seperti itu, pemfilteran gratis berdasarkan bidang apa pun dan opsi pengoptimalan kueri, dan departemen ini berupaya menutup klaim dan kecelakaan, maka keputusan tentang Kassandra baginya adalah musuh dan bodoh. Dan kami mulai membahas masalah bagaimana kolega kami dapat membuat sampel.
Kami mempertimbangkan dua opsi. Pada opsi pertama, kami menulis panggilan tidak hanya dalam C *, tetapi juga dalam database arsip Oracle. Hanya, tidak seperti C *, panggilan disimpan dalam database ini hanya untuk bulan berjalan (kedalaman penyimpanan panggilan yang cukup untuk kasus sertifikasi ulang). Di sini kita segera melihat masalah berikut: jika Anda menulis secara serempak, maka kami kehilangan semua kelebihan C * yang terkait dengan penyisipan cepat, jika tidak sinkron, tidak ada jaminan bahwa semua panggilan yang diperlukan umumnya mengenai Oracle. Ada satu nilai tambah, tetapi besar: untuk eksploitasi, Pengembang PL / SQL yang sama tetap, yaitu, kami secara praktis menerapkan pola "Fasad". Opsi alternatif. Kami menerapkan mekanisme yang membongkar panggilan dari C *, menarik beberapa data untuk pengayaan dari tabel terkait di Oracle, bergabung dengan sampel yang diterima dan memberi kami hasilnya, yang kemudian kami gunakan (memutar kembali, mengulangi ulang, menganalisis, mengagumi). Cons: prosesnya cukup multi-langkah, dan di samping itu, tidak ada antarmuka untuk personel operasi.
Akibatnya, kami masih memilih opsi kedua. Apache Spark digunakan untuk sampel dari kaleng yang berbeda. Inti dari mekanisme tersebut adalah kode Java, yang, menggunakan kunci yang ditentukan (pelanggan, kunci bagian waktu panggilan), menarik data dari C *, serta data yang diperlukan untuk pengayaan dari basis data lain. Kemudian ia bergabung dengan mereka di memori dan menampilkan hasilnya di tabel yang dihasilkan. Sebuah moncong web ditarik di atas percikan dan ternyata cukup bisa digunakan.
Saat memecahkan masalah dengan memperbarui data, uji promo kembali memeriksa beberapa solusi. Baik transfer melalui Sstloader, dan opsi untuk membagi cluster di zona uji menjadi dua bagian, yang masing-masing secara bergantian masuk ke cluster yang sama dengan promo, sehingga diberdayakan darinya. Saat memperbarui tes, direncanakan untuk mengubah tempat mereka: bagian yang bekerja dalam tes dihapus dan dimasukkan ke dalam prom, dan yang lainnya mulai bekerja dengan data secara terpisah. Namun, berpikir lagi, kami lebih rasional mengevaluasi data yang harus ditransfer, dan menyadari bahwa panggilan itu sendiri adalah entitas yang tidak konsisten untuk pengujian, cepat dihasilkan jika perlu, dan kumpulan data promo yang tidak layak ditransfer ke tes. Ada beberapa objek penyimpanan yang layak untuk dipindahkan, tetapi ini benar-benar beberapa tabel, dan tidak terlalu berat. Oleh karena itu , Spark kembali membantu kami sebagai solusi, dengan bantuan yang kami tulis dan mulai aktif menggunakan transfer data antara tabel skrip prom-test.
Kebijakan penerapan kami saat ini memungkinkan kami untuk bekerja tanpa suap. Sebelum prom, ada roll wajib untuk tes, di mana kesalahannya tidak begitu mahal. Jika terjadi kegagalan, Anda selalu dapat meletakkan ruang kasus dan menggulung seluruh skema dari awal.
Untuk memastikan ketersediaan Cassandra yang berkelanjutan, Anda perlu dba dan bukan hanya itu. Setiap orang yang bekerja dengan aplikasi harus memahami di mana dan bagaimana cara melihat situasi saat ini dan cara mendiagnosis masalah secara tepat waktu. Untuk melakukan ini, kami secara aktif menggunakan DataStax OpsCenter (Administrasi dan Pemantauan Beban Kerja), metrik sistem Driver Cassandra (jumlah batas waktu untuk menulis ke C *, jumlah batas waktu untuk membaca dari C *, latensi maksimum, dll.), Pemantauan karya aplikasi itu sendiri, bekerja dengan Kassandra.
Ketika kami memikirkan pertanyaan sebelumnya, kami menyadari di mana risiko utama kami berada. Ini adalah formulir tampilan data yang menghasilkan data dari beberapa permintaan penyimpanan yang tidak saling tergantung. Dengan cara ini kita bisa mendapatkan informasi yang sangat tidak konsisten. Tetapi masalah ini akan sama relevannya jika kita bekerja hanya dengan satu pusat data. Jadi hal yang paling masuk akal di sini adalah, tentu saja, untuk melakukan fungsi batch dari membaca data pada aplikasi pihak ketiga, yang akan memastikan bahwa data diterima dalam satu periode waktu. Adapun pemisahan antara membaca dan menulis dalam hal kinerja, di sini kita terhenti oleh risiko bahwa, dengan beberapa kehilangan koneksi antara DC, kita bisa mendapatkan dua cluster yang sama sekali tidak konsisten.
Akibatnya, saat ini kami berhenti pada tingkat konsistensi untuk catatan EACH_QUORUM, untuk membaca - LOCAL_QUORUM
Kesan dan kesimpulan singkat
Untuk mengevaluasi solusi yang dihasilkan dari sudut pandang dukungan operasional dan prospek untuk pengembangan lebih lanjut, kami memutuskan untuk memikirkan di mana lagi pengembangan semacam itu dapat diterapkan.
Jika bergerak, kemudian mencetak data untuk program-program seperti "Bayar saat nyaman" (kami memuat informasi ke dalam C *, perhitungan menggunakan skrip Spark), menghitung klaim dengan agregasi berdasarkan arahan, menyimpan peran, dan menghitung hak akses pengguna menggunakan matriks peran.
Seperti yang Anda lihat, repertoarnya luas dan beragam. Dan jika kita memilih kubu pendukung / penentang NoSQL, maka kita akan bergabung dengan pendukung, karena kita mendapat nilai plus kita, dan tepat di tempat yang kita harapkan.
Bahkan opsi Cassandra di luar kotak memungkinkan penskalaan horizontal dalam waktu nyata, benar-benar tanpa kesulitan menyelesaikan masalah peningkatan data dalam sistem. Kami berhasil menempatkan ke dalam sirkuit terpisah mekanisme yang sangat tinggi untuk menghitung agregat untuk panggilan, dan juga untuk memisahkan skema dan logika aplikasi, menghilangkan praktik ganas penulisan pekerjaan kustom dan objek dalam database itu sendiri. Kami mendapat kesempatan untuk memilih dan mengonfigurasi, untuk mempercepat, DC mana yang akan kami hitung dan catatan data mana, kami mengasuransikan diri kami sendiri untuk tetes dari masing-masing node dan keseluruhan DC.
Menerapkan arsitektur kami ke proyek-proyek baru, dan sudah memiliki pengalaman, saya ingin segera mempertimbangkan nuansa yang dijelaskan di atas, dan mencegah beberapa kesalahan, melicinkan beberapa sudut tajam yang tidak dapat dihindari pada awalnya.
Misalnya, lacak pembaruan ke Cassandra tepat waktu , karena beberapa masalah yang kami terima sudah diketahui dan diperbaiki.
Jangan letakkan database itu sendiri dan Spark pada node yang sama (atau bagi mereka secara ketat dengan jumlah penggunaan sumber daya yang dapat diterima), karena Spark dapat memakan OP lebih dari yang diharapkan, dan kami akan segera mendapatkan masalah nomor 1 dari daftar kami.
Untuk memompa pemantauan dan kompetensi operasi pada tahap pengujian proyek. Awalnya, perhitungkan maksimum semua konsumen potensial dari solusi kami , karena struktur basis data pada akhirnya akan bergantung pada ini.
Putar sirkuit yang dihasilkan beberapa kali untuk kemungkinan optimasi. Pilih bidang mana yang dapat diserialisasi. Memahami tabel tambahan apa yang dapat kita lakukan untuk memperhitungkan yang paling benar dan optimal, dan kemudian mengembalikan informasi yang diperlukan berdasarkan permintaan (misalnya, dengan asumsi bahwa kita dapat menyimpan data yang sama di tabel yang berbeda, dengan mempertimbangkan rincian yang berbeda sesuai dengan kriteria yang berbeda, dapat secara signifikan menghemat waktu prosesor untuk permintaan baca).
Sebaiknya segera pasang TTL dan bersihkan data yang sudah usang.
Saat membongkar data dari Cassandra, logika aplikasi harus bekerja sesuai dengan prinsip FETCH, sehingga tidak semua baris dimuat ke memori pada suatu waktu, tetapi dipilih dalam batch.
Sebelum mentransfer proyek ke solusi yang dijelaskan, disarankan untuk memeriksa toleransi kesalahan sistem dengan melakukan serangkaian tes kerusakan , seperti kehilangan data di satu pusat data, pemulihan data yang rusak untuk periode tertentu, dan penarikan jaringan antara pusat data. Tes semacam itu tidak hanya akan memungkinkan Anda untuk menilai pro dan kontra dari arsitektur yang diusulkan, tetapi juga memberikan praktik pemanasan yang baik untuk para insinyur yang melaksanakannya, dan keterampilan yang dihasilkan akan jauh dari berlebihan jika kegagalan sistem direproduksi dalam prom.
Jika kita bekerja dengan informasi penting (seperti data tagihan, perhitungan utang pelanggan), ada baiknya juga memperhatikan alat yang akan mengurangi risiko yang muncul karena karakteristik DBMS. Misalnya, gunakan utilitas nodesync (Datastax), setelah mengembangkan strategi yang optimal untuk penggunaannya, sehingga demi konsistensi agar tidak membentuk beban berlebihan pada Cassandra dan menggunakannya hanya untuk tabel tertentu dalam periode tertentu.
Nah, setelah enam bulan hidup, dengan Cassandra? Secara umum, tidak ada masalah yang belum terpecahkan. Kecelakaan serius dan kehilangan data, kami juga tidak mengizinkan. Ya, saya harus memikirkan untuk mengkompensasi beberapa masalah yang sebelumnya tidak muncul, tetapi pada akhirnya itu tidak menaungi solusi arsitektur kami. Jika Anda ingin dan tidak takut untuk mencoba sesuatu yang baru, dan pada saat yang sama tidak ingin menjadi sangat kecewa, maka bersiaplah untuk kenyataan bahwa tidak ada yang terjadi secara gratis. Anda harus mencari tahu, menggali dokumentasi dan mengumpulkan rake individual Anda daripada dalam solusi lawas dan tidak ada teori yang akan memberi tahu Anda terlebih dahulu persis rake mana yang menunggu Anda.