Mereka mengatakan bahawa segala-galanya dalam hidup patut dicuba sekurang-kurangnya sekali. Dan jika anda terbiasa bekerja dengan DBMS relasional, maka adalah berbaloi untuk membiasakan diri dengan NoSQL dalam amalan, pertama sekali, sekurang-kurangnya untuk pembangunan umum. Kini, disebabkan perkembangan pesat teknologi ini, terdapat banyak pendapat yang bercanggah dan perdebatan hangat mengenai topik ini, yang terutamanya menyemarakkan minat.
Jika anda menyelidiki intipati semua pertikaian ini, anda dapat melihat bahawa ia timbul kerana pendekatan yang salah. Mereka yang menggunakan pangkalan data NoSQL tepat di tempat yang diperlukan berpuas hati dan menerima semua kelebihan daripada penyelesaian ini. Dan penguji yang bergantung pada teknologi ini sebagai ubat mujarab di mana ia tidak boleh digunakan sama sekali kecewa, telah kehilangan kekuatan pangkalan data hubungan tanpa mendapat faedah yang ketara.
Saya akan memberitahu anda tentang pengalaman kami dalam melaksanakan penyelesaian berdasarkan DBMS Cassandra: perkara yang perlu kami hadapi, bagaimana kami keluar daripada situasi yang sukar, sama ada kami boleh mendapat manfaat daripada menggunakan NoSQL dan di mana kami perlu melaburkan usaha/dana tambahan .
Tugas awal adalah untuk membina sistem yang merekodkan panggilan dalam beberapa jenis storan.
Prinsip operasi sistem adalah seperti berikut. Input termasuk fail dengan struktur khusus yang menerangkan struktur panggilan. Aplikasi kemudian memastikan bahawa struktur ini disimpan dalam lajur yang sesuai. Pada masa hadapan, panggilan yang disimpan digunakan untuk memaparkan maklumat mengenai penggunaan trafik untuk pelanggan (caj, panggilan, sejarah baki).
Agak jelas sebab mereka memilih Cassandra - dia menulis seperti mesingan, mudah berskala, dan tahan terhadap kesalahan.
Jadi, inilah pengalaman yang diberikan kepada kami
Ya, nod yang gagal bukanlah tragedi. Ini adalah intipati toleransi kesalahan Cassandra. Tetapi nod boleh hidup dan pada masa yang sama mula menderita dalam prestasi. Ternyata, ini serta-merta menjejaskan prestasi keseluruhan kluster.
Cassandra tidak akan melindungi anda di mana Oracle menyelamatkan anda dengan kekangannya. Dan jika pengarang aplikasi tidak memahami ini terlebih dahulu, maka dua kali ganda yang tiba untuk Cassandra tidak lebih buruk daripada yang asal. Sebaik sahaja ia tiba, kami akan memasukkannya ke dalam.
IB sangat tidak menyukai Cassandra yang percuma di luar kotak: Tiada pengelogan tindakan pengguna, tiada pembezaan hak. Maklumat tentang panggilan dianggap sebagai data peribadi, yang bermaksud bahawa semua percubaan untuk meminta/mengubahnya dalam apa jua cara mesti dilog dengan kemungkinan pengauditan seterusnya. Selain itu, anda perlu sedar tentang keperluan untuk memisahkan hak pada tahap yang berbeza untuk pengguna yang berbeza. Jurutera operasi mudah dan pentadbir super yang boleh memadamkan keseluruhan ruang kekunci secara bebas adalah peranan yang berbeza, tanggungjawab dan kecekapan yang berbeza. Tanpa pembezaan hak capaian sedemikian, nilai dan integriti data akan segera dipersoalkan dengan lebih cepat berbanding dengan mana-mana tahap ketekalan.
Kami tidak mengambil kira bahawa panggilan memerlukan analitis yang serius dan pensampelan berkala untuk pelbagai keadaan. Memandangkan rekod yang dipilih kemudiannya sepatutnya dipadamkan dan ditulis semula (sebagai sebahagian daripada tugas, kami mesti menyokong proses mengemas kini data apabila data pada mulanya memasuki gelung kami secara tidak betul), Cassandra bukan rakan kami di sini. Cassandra seperti bank celengan - mudah untuk memasukkan barang, tetapi anda tidak boleh mengira di dalamnya.
Kami menghadapi masalah memindahkan data ke zon ujian (5 nod dalam ujian berbanding 20 dalam prom). Dalam kes ini, tempat pembuangan tidak boleh digunakan.
Masalah dengan mengemas kini skema data permohonan menulis kepada Cassandra. Pemulihan semula akan menghasilkan banyak batu nisan, yang boleh menyebabkan kehilangan produktiviti dengan cara yang tidak dapat diramalkan.. Cassandra dioptimumkan untuk rakaman, dan tidak banyak berfikir sebelum menulis. Sebarang operasi dengan data sedia ada di dalamnya juga merupakan rakaman. Iaitu, dengan memadamkan yang tidak perlu, kami hanya akan menghasilkan lebih banyak rekod, dan hanya sebahagian daripadanya akan ditandakan dengan batu nisan.
Tamat masa semasa memasukkan. Cassandra cantik dalam rakaman, tetapi kadangkala aliran masuk boleh membingungkan dia dengan ketara. Ini berlaku apabila aplikasi mula mengitari beberapa rekod yang tidak boleh dimasukkan atas sebab tertentu. Dan kami memerlukan DBA sebenar yang akan memantau gc.log, sistem dan log nyahpepijat untuk pertanyaan perlahan, metrik pada pemadatan belum selesai.
Beberapa pusat data dalam kelompok. Dari mana hendak membaca dan dari mana hendak menulis?
Mungkin berpecah kepada membaca dan menulis? Dan jika ya, patutkah ada DC yang lebih dekat dengan permohonan untuk menulis atau membaca? Dan tidakkah kita akan berakhir dengan otak berpecah yang sebenar jika kita memilih tahap konsistensi yang salah? Terdapat banyak soalan, banyak tetapan yang tidak diketahui, kemungkinan yang anda benar-benar mahu bermain-main.
Bagaimana kami membuat keputusan
Untuk mengelakkan nod daripada tenggelam, SWAP telah dilumpuhkan. Dan sekarang, jika terdapat kekurangan memori, nod harus turun dan tidak membuat jeda gc yang besar.
Jadi, kita tidak lagi bergantung kepada logik dalam pangkalan data. Pembangun aplikasi sedang melatih semula diri mereka dan mula aktif mengambil langkah berjaga-jaga dalam kod mereka sendiri. Pemisahan storan dan pemprosesan data yang sesuai dengan jelas.
Kami membeli sokongan daripada DataStax. Pembangunan Cassandra berkotak telah pun dihentikan (komit terakhir adalah pada Februari 2018). Pada masa yang sama, Datastax menawarkan perkhidmatan cemerlang dan sejumlah besar penyelesaian yang diubah suai dan disesuaikan untuk penyelesaian IP sedia ada.
Saya juga ingin ambil perhatian bahawa Cassandra tidak begitu mudah untuk pertanyaan pemilihan. Sudah tentu, CQL adalah satu langkah besar ke hadapan untuk pengguna (berbanding dengan Trift). Tetapi jika anda mempunyai keseluruhan jabatan yang terbiasa dengan sambungan yang mudah seperti itu, penapisan percuma oleh mana-mana medan dan keupayaan pengoptimuman pertanyaan, dan jabatan ini sedang berusaha untuk menyelesaikan aduan dan kemalangan, maka penyelesaian mengenai Cassandra kelihatan bermusuhan dan bodoh bagi mereka. Dan kami mula memutuskan cara rakan sekerja kami perlu membuat sampel.
Kami mempertimbangkan dua pilihan. Dalam pilihan pertama, kami menulis panggilan bukan sahaja dalam C*, tetapi juga dalam pangkalan data Oracle yang diarkibkan. Hanya, tidak seperti C*, pangkalan data ini menyimpan panggilan hanya untuk bulan semasa (kedalaman storan panggilan yang mencukupi untuk kes pengecasan semula). Di sini kami segera melihat masalah berikut: jika kami menulis serentak, maka kami kehilangan semua kelebihan C* yang dikaitkan dengan sisipan pantas; jika kami menulis secara tidak segerak, tidak ada jaminan bahawa semua panggilan yang diperlukan masuk ke Oracle sama sekali. Terdapat satu tambahan, tetapi yang besar: untuk operasi, Pembangun PL/SQL yang sama masih kekal, iaitu kami secara praktikal melaksanakan corak "Fasad". Pilihan alternatif. Kami melaksanakan mekanisme yang memunggah panggilan daripada C*, menarik beberapa data untuk pengayaan daripada jadual yang sepadan dalam Oracle, menyertai sampel yang terhasil dan memberikan kami hasilnya, yang kemudiannya kami gunakan (gulung semula, ulangi, analisis, kagumi). Cons: prosesnya agak berbilang langkah, dan sebagai tambahan, tiada antara muka untuk pekerja operasi.
Pada akhirnya, kami menyelesaikan pilihan kedua. Apache Spark digunakan untuk mengambil sampel dari balang yang berbeza. Intipati mekanisme telah dikurangkan kepada kod Java, yang, menggunakan kunci yang ditentukan (pelanggan, masa panggilan - kunci bahagian), mengeluarkan data dari C*, serta data yang diperlukan untuk pengayaan dari mana-mana pangkalan data lain. Selepas itu ia menyertai mereka dalam ingatannya dan memaparkan hasilnya dalam jadual yang terhasil. Kami melukis muka web di atas percikan api dan ternyata boleh digunakan.
Apabila menyelesaikan masalah mengemas kini data ujian industri, kami sekali lagi mempertimbangkan beberapa penyelesaian. Kedua-dua pemindahan melalui Sstloader dan pilihan untuk membahagikan kluster dalam zon ujian kepada dua bahagian, setiap satunya tergolong dalam kluster yang sama dengan kluster promosi secara bergilir-gilir, dengan itu dikuasakan olehnya. Apabila mengemas kini ujian, ia telah dirancang untuk menukarnya: bahagian yang berfungsi dalam ujian dibersihkan dan dimasukkan ke dalam pengeluaran, dan yang lain mula berfungsi dengan data secara berasingan. Walau bagaimanapun, selepas berfikir semula, kami menilai secara lebih rasional data yang patut dipindahkan, dan menyedari bahawa panggilan itu sendiri adalah entiti yang tidak konsisten untuk ujian, dijana dengan cepat jika perlu, dan set data promosi yang tidak mempunyai nilai untuk dipindahkan ke ujian. Terdapat beberapa objek storan yang berbaloi untuk dialihkan, tetapi ini sebenarnya adalah beberapa jadual, dan bukan yang sangat berat. Oleh itu kita sebagai penyelesaian, Spark sekali lagi datang untuk menyelamatkan, dengan bantuan yang kami tulis dan mula aktif menggunakan skrip untuk memindahkan data antara jadual, ujian prom.
Dasar penggunaan semasa kami membolehkan kami bekerja tanpa penarikan balik. Sebelum promo ada test run wajib, silapnya tak berapa mahal. Sekiranya berlaku kegagalan, anda sentiasa boleh menggugurkan ruang kes dan melancarkan keseluruhan skema dari awal.
Untuk memastikan ketersediaan berterusan Cassandra, anda memerlukan dba dan bukan sahaja dia. Setiap orang yang bekerja dengan aplikasi mesti memahami di mana dan bagaimana untuk melihat keadaan semasa dan bagaimana untuk mendiagnosis masalah tepat pada masanya. Untuk melakukan ini, kami secara aktif menggunakan DataStax OpsCenter (Pentadbiran dan pemantauan beban kerja), metrik sistem Pemacu Cassandra (bilangan tamat masa untuk menulis ke C*, bilangan tamat masa untuk membaca daripada C*, kependaman maksimum, dll.), memantau operasi daripada aplikasi itu sendiri, bekerja dengan Cassandra.
Apabila kita memikirkan soalan sebelumnya, kita menyedari di mana risiko utama kita mungkin terletak. Ini adalah borang paparan data yang memaparkan data daripada beberapa pertanyaan bebas kepada storan. Dengan cara ini kita boleh mendapatkan maklumat yang agak tidak konsisten. Tetapi masalah ini akan menjadi sama relevan jika kami bekerja dengan hanya satu pusat data. Jadi perkara yang paling munasabah di sini ialah, sudah tentu, untuk mencipta fungsi kelompok untuk membaca data pada aplikasi pihak ketiga, yang akan memastikan data diterima dalam satu tempoh masa. Bagi pembahagian membaca dan menulis dari segi prestasi, di sini kami dihentikan oleh risiko bahawa dengan beberapa kehilangan sambungan antara DC, kami boleh berakhir dengan dua kelompok yang tidak konsisten antara satu sama lain.
Akibatnya, buat masa ini berhenti pada tahap konsisten untuk menulis EACH_QUORUM, untuk membaca - LOCAL_QUORUM
Tanggapan dan kesimpulan ringkas
Untuk menilai penyelesaian yang terhasil dari sudut pandangan sokongan operasi dan prospek untuk pembangunan selanjutnya, kami memutuskan untuk memikirkan di mana lagi pembangunan sedemikian boleh digunakan.
Terus sahaja, kemudian pemarkahan data untuk program seperti "Bayar apabila sesuai" (kami memuatkan maklumat ke dalam C*, pengiraan menggunakan skrip Spark), mengambil kira tuntutan dengan pengagregatan mengikut kawasan, menyimpan peranan dan mengira hak akses pengguna berdasarkan peranan matriks.
Seperti yang anda lihat, repertoirnya luas dan pelbagai. Dan jika kami memilih kem penyokong/penentang NoSQL, maka kami akan menyertai penyokong, kerana kami menerima kelebihan kami, dan tepat seperti yang kami jangkakan.
Malah pilihan Cassandra di luar kotak membenarkan penskalaan mendatar dalam masa nyata, benar-benar menyelesaikan isu peningkatan data dalam sistem tanpa rasa sakit. Kami dapat mengalihkan mekanisme beban yang sangat tinggi untuk mengira agregat panggilan ke dalam litar yang berasingan, dan juga memisahkan skema dan logik aplikasi, menyingkirkan amalan buruk menulis tugas dan objek tersuai dalam pangkalan data itu sendiri. Kami mendapat peluang untuk memilih dan mengkonfigurasi, untuk mempercepatkan, DC yang mana kami akan melakukan pengiraan dan yang mana kami akan merekodkan data, kami menginsuranskan diri kami terhadap ranap kedua-dua nod individu dan DC secara keseluruhan.
Menggunakan seni bina kami untuk projek baharu, dan sudah mempunyai sedikit pengalaman, saya ingin segera mengambil kira nuansa yang diterangkan di atas, dan mengelak daripada membuat beberapa kesilapan, melicinkan beberapa sudut tajam yang tidak dapat dielakkan pada mulanya.
Sebagai contoh, menjejaki kemas kini Cassandra tepat pada masanyakerana agak sedikit masalah yang kami dapat telah diketahui dan diperbaiki.
Jangan letakkan kedua-dua pangkalan data itu sendiri dan Spark pada nod yang sama (atau bahagikan dengan ketat dengan jumlah penggunaan sumber yang dibenarkan), memandangkan Spark boleh makan lebih banyak OP daripada yang dijangkakan, dan kami akan segera mendapatkan masalah nombor 1 daripada senarai kami.
Meningkatkan kecekapan pemantauan dan operasi pada peringkat ujian projek. Pada mulanya, ambil kira sebanyak mungkin semua bakal pengguna penyelesaian kami, kerana inilah yang akhirnya akan bergantung kepada struktur pangkalan data.
Putar litar yang terhasil beberapa kali untuk pengoptimuman yang mungkin. Pilih medan yang boleh disiri. Fahami jadual tambahan yang perlu kami buat untuk mengambil kira dengan paling betul dan optimum, dan kemudian berikan maklumat yang diperlukan atas permintaan (contohnya, dengan mengandaikan bahawa kami boleh menyimpan data yang sama dalam jadual yang berbeza, dengan mengambil kira pecahan yang berbeza mengikut kriteria yang berbeza, kami boleh menjimatkan masa CPU dengan ketara untuk permintaan baca).
Purata Segera sediakan untuk melampirkan TTL dan membersihkan data lapuk.
Apabila memuat turun data daripada Cassandra Logik aplikasi harus berfungsi pada prinsip FETCH, supaya tidak semua baris dimuatkan ke dalam memori sekaligus, tetapi dipilih dalam kelompok.
Adalah dinasihatkan sebelum memindahkan projek ke penyelesaian yang diterangkan semak toleransi kesalahan sistem dengan menjalankan satu siri ujian ranap, seperti kehilangan data dalam satu pusat data, pemulihan data yang rosak dalam tempoh tertentu, keciciran rangkaian antara pusat data. Ujian sedemikian bukan sahaja akan membolehkan seseorang menilai kebaikan dan keburukan seni bina yang dicadangkan, tetapi juga akan menyediakan amalan pemanasan badan yang baik untuk jurutera yang menjalankannya, dan kemahiran yang diperolehi akan jauh daripada berlebihan jika kegagalan sistem diterbitkan semula dalam pengeluaran.
Jika kita bekerja dengan maklumat kritikal (seperti data untuk pengebilan, pengiraan hutang pelanggan), maka ia juga patut diberi perhatian kepada alat yang akan mengurangkan risiko yang timbul disebabkan oleh ciri-ciri DBMS. Sebagai contoh, gunakan utiliti nodesync (Datastax), setelah membangunkan strategi optimum untuk penggunaannya mengikut urutan demi konsistensi, jangan buat beban berlebihan pada Cassandra dan gunakannya hanya untuk jadual tertentu dalam tempoh tertentu.
Apa yang berlaku kepada Cassandra selepas enam bulan hidup? Secara umum, tiada masalah yang tidak dapat diselesaikan. Kami juga tidak membenarkan sebarang kemalangan serius atau kehilangan data. Ya, kami perlu memikirkan tentang mengimbangi beberapa masalah yang tidak pernah timbul sebelum ini, tetapi pada akhirnya ini tidak terlalu mengaburkan penyelesaian seni bina kami. Jika anda mahu dan tidak takut untuk mencuba sesuatu yang baru, dan pada masa yang sama tidak mahu terlalu kecewa, maka bersiaplah untuk fakta bahawa tiada apa yang percuma. Anda perlu memahami, menyelidiki dokumentasi dan memasang rake individu anda lebih daripada penyelesaian lama, dan tiada teori akan memberitahu anda terlebih dahulu rake yang sedang menunggu anda.
Sumber: www.habr.com