Kapan TIDAK menggunakan Cassandra?

Ada banyak pembicaraan terkait Cassandra belakangan ini.

Twitter, Digg, Facebook, dll. Semua menggunakannya.

Kapan masuk akal untuk:

• gunakan Cassandra,
• tidak menggunakan Cassandra, dan
• gunakan RDMS, bukan Cassandra.

Tidak ada yang seperti peluru perak, semuanya dibangun untuk memecahkan masalah tertentu dan memiliki pro dan kontra sendiri. Terserah Anda, pernyataan masalah apa yang Anda miliki dan apa solusi pas terbaik untuk masalah itu.

Saya akan mencoba menjawab pertanyaan Anda satu per satu dalam urutan yang sama dengan yang Anda tanyakan. Karena Cassandra didasarkan pada keluarga basis data NoSQL, penting bagi Anda untuk memahami mengapa menggunakan basis data NoSQL sebelum saya menjawab pertanyaan Anda.

Mengapa menggunakan NoSQL

Dalam kasus RDBMS, membuat pilihan cukup mudah karena semua database seperti MySQL, Oracle, MS SQL, PostgreSQL dalam kategori ini menawarkan solusi yang hampir sama yang berorientasi pada properti ACID. Ketika datang ke NoSQL, keputusan menjadi sulit karena setiap basis data NoSQL menawarkan solusi yang berbeda dan Anda harus memahami mana yang paling cocok untuk persyaratan aplikasi / sistem Anda. Misalnya, MongoDB cocok untuk kasus penggunaan di mana sistem Anda membutuhkan penyimpanan dokumen tanpa skema. HBase mungkin cocok untuk mesin pencari, menganalisis data log, atau tempat di mana pemindaian tabel gabungan dua dimensi yang besar adalah persyaratan. Redis dibangun untuk menyediakan pencarian In-Memory untuk berbagai struktur data seperti pohon, antrian, daftar tertaut, dll dan dapat menjadi cocok untuk membuat papan peringkat waktu-nyata, jenis sistem pub-sub. Demikian pula ada database lain dalam kategori ini (Termasuk Cassandra) yang cocok untuk pernyataan masalah yang berbeda. Sekarang mari kita beralih ke pertanyaan awal, dan jawab satu per satu.

Kapan harus menggunakan Cassandra

Menjadi bagian dari keluarga NoSQL, Cassandra menawarkan solusi untuk masalah di mana salah satu persyaratan Anda adalah memiliki sistem penulisan yang sangat berat dan Anda ingin memiliki sistem pelaporan yang cukup responsif di atas data yang tersimpan. Pertimbangkan kasus penggunaan analitik Web di mana data log disimpan untuk setiap permintaan dan Anda ingin membangun platform analitik di sekitarnya untuk menghitung hit per jam, dengan browser, dengan IP, dll secara real time. Anda dapat merujuk ke posting blog ini untuk memahami lebih lanjut tentang kasus penggunaan yang cocok dengan Cassandra.

Kapan Menggunakan RDMS, bukan Cassandra

Cassandra didasarkan pada database NoSQL dan tidak menyediakan ACID dan properti data relasional. Jika Anda memiliki persyaratan kuat untuk properti ACID (misalnya data Keuangan), Cassandra tidak akan cocok dalam kasus itu. Jelas, Anda dapat membuat solusi untuk itu, namun Anda akhirnya akan menulis banyak kode aplikasi untuk mensimulasikan properti ACID dan akan kehilangan waktu untuk memasarkan dengan buruk. Juga mengelola sistem semacam itu dengan Cassandra akan menjadi rumit dan membosankan bagi Anda.

Saat tidak menggunakan Cassandra

Saya pikir itu tidak perlu dijawab jika penjelasan di atas masuk akal.

Saat mengevaluasi sistem data terdistribusi, Anda harus mempertimbangkan teorema CAP - Anda dapat memilih dua dari yang berikut: konsistensi, ketersediaan, dan toleransi partisi.

Cassandra adalah sistem, partisi-tolerant yang tersedia yang mendukung konsistensi akhirnya. Untuk informasi lebih lanjut lihat posting blog ini yang saya tulis: Panduan Visual untuk Sistem NoSQL .

Cassandra adalah jawaban untuk masalah tertentu: Apa yang Anda lakukan ketika Anda memiliki begitu banyak data sehingga tidak muat di satu server? Bagaimana Anda menyimpan semua data Anda di banyak server dan tidak merusak rekening bank Anda dan tidak membuat pengembang Anda gila? Facebook mendapat 4 Terabyte data terkompresi baru SETIAP HARI. Dan jumlah ini kemungkinan besar akan tumbuh lebih dari dua kali dalam setahun.

Jika Anda tidak memiliki data sebanyak ini atau jika Anda memiliki jutaan untuk membayar instalasi kluster Enterprise Oracle / DB2 dan spesialis yang diperlukan untuk mengatur dan memeliharanya, maka Anda baik-baik saja dengan database SQL.

Namun Facebook tidak lagi menggunakan cassandra dan sekarang menggunakan MySQL hampir secara eksklusif memindahkan partisi ke dalam tumpukan aplikasi untuk kinerja yang lebih cepat dan kontrol yang lebih baik.

Gagasan umum NoSQL adalah bahwa Anda harus menggunakan penyimpanan data mana saja yang paling cocok untuk aplikasi Anda. Jika Anda memiliki tabel data keuangan, gunakan SQL. Jika Anda memiliki objek yang membutuhkan kueri kompleks / lambat untuk memetakan ke skema relasional, gunakan objek atau penyimpanan kunci / nilai.

Tentu saja hampir semua masalah dunia nyata yang Anda temui ada di antara dua ekstrim itu dan tidak ada solusi yang sempurna. Anda perlu mempertimbangkan kemampuan masing-masing toko dan konsekuensi penggunaan satu di atas yang lain, yang akan sangat spesifik untuk masalah yang Anda coba selesaikan.

Selain jawaban yang diberikan di atas tentang kapan harus menggunakan dan kapan tidak menggunakan Cassandra, jika Anda memutuskan untuk menggunakan Cassandra Anda mungkin ingin mempertimbangkan untuk tidak menggunakan Cassandra sendiri, tetapi salah satu dari banyak sepupunya di luar sana.

Beberapa jawaban di atas sudah menunjuk ke berbagai sistem "NoSQL" yang berbagi banyak properti dengan Cassandra, dengan beberapa perbedaan kecil atau besar, dan mungkin lebih baik daripada Cassandra sendiri untuk kebutuhan spesifik Anda.

Selain itu, baru-baru ini (beberapa tahun setelah pertanyaan ini awalnya diajukan), klon Cassandra bernama Scylla (lihat https://en.wikipedia.org/wiki/Scylla_(database) ) dirilis. Scylla adalah implementasi ulang open source Cassandra di C ++, yang mengklaim memiliki throughput yang jauh lebih tinggi dan latensi lebih rendah daripada Java Cassandra asli, sementara sebagian besar kompatibel dengan itu (dalam fitur, API, dan format file). Jadi, jika Anda sudah mempertimbangkan Cassandra, Anda mungkin ingin mempertimbangkan Scylla juga.

Berbicara dengan seseorang di tengah-tengah penempatan Cassandra, itu tidak menangani banyak-ke-banyak dengan baik. Mereka melakukan pekerjaan hack untuk melakukan pengujian awal mereka. Saya berbicara dengan konsultan Cassandra tentang ini dan dia berkata dia tidak akan merekomendasikan hal ini jika Anda memiliki masalah ini.

Anda harus bertanya pada diri sendiri pertanyaan-pertanyaan berikut:

1. (Volume, Velocity) Apakah Anda akan menulis dan membaca BANYAK informasi, begitu banyak informasi sehingga tidak ada komputer yang bisa menangani penulisan.
2. (Global) Apakah Anda memerlukan kemampuan menulis dan membaca ini di seluruh dunia sehingga tulisan di satu bagian dunia dapat diakses di bagian lain dunia?
3. (Keandalan) Apakah Anda memerlukan basis data ini untuk beroperasi dan beroperasi setiap saat dan tidak pernah turun terlepas dari Cloud mana, negara mana, apakah itu VM, Container, atau Bare metal?
4. (Skala-kemampuan) Apakah Anda memerlukan database ini untuk dapat terus tumbuh dengan mudah dan skala secara linear
5. (Konsistensi) Apakah Anda memerlukan konsistensi TUNABLE di mana beberapa penulisan dapat terjadi secara serempak di mana yang lain perlu disertifikasi?
6. (Keterampilan) Apakah Anda bersedia melakukan apa yang diperlukan untuk mempelajari teknologi ini dan pemodelan data yang sesuai dengan pembuatan basis data yang didistribusikan secara global yang bisa cepat untuk semua orang, di mana saja?

Jika untuk pertanyaan-pertanyaan ini Anda berpikir "mungkin" atau "tidak," Anda harus menggunakan sesuatu yang lain. Jika Anda memiliki "neraka ya" sebagai jawaban untuk semuanya, maka Anda harus menggunakan Cassandra.

Gunakan RDBMS ketika Anda dapat melakukan semuanya di satu kotak. Mungkin lebih mudah daripada kebanyakan orang dan siapa pun dapat bekerja dengannya.

Permintaan tunggal yang berat vs beban kuota gazillion ringan adalah hal lain yang perlu dipertimbangkan, selain jawaban lain di sini. Secara inheren lebih sulit untuk secara otomatis mengoptimalkan satu permintaan dalam DB gaya NoSql. Saya telah menggunakan MongoDB dan mengalami masalah kinerja ketika mencoba menghitung kueri yang kompleks. Saya belum pernah menggunakan Cassandra, tetapi saya berharap memiliki masalah yang sama.

Di sisi lain, jika beban Anda diharapkan dari kueri yang sangat kecil, dan Anda ingin dapat dengan mudah mengurangi, Anda bisa memanfaatkan konsistensi akhirnya yang ditawarkan oleh sebagian besar DB NoSql. Perhatikan bahwa konsistensi akhirnya sebenarnya bukan fitur dari model data non-relasional, tetapi jauh lebih mudah untuk diimplementasikan dan diatur dalam sistem berbasis NoSql.

Untuk permintaan tunggal, yang sangat berat, mesin RDBMS modern mana pun dapat melakukan pekerjaan yang baik dengan memparalelkan bagian-bagian dari permintaan dan memanfaatkan sebanyak mungkin CPU dan memori yang Anda gunakan (pada satu mesin). Basis data NoSql tidak memiliki cukup informasi tentang struktur data untuk dapat membuat asumsi yang akan memungkinkan paralelisasi yang benar-benar cerdas dari sebuah permintaan besar. Mereka memungkinkan Anda untuk dengan mudah mengurangi server (atau inti), tetapi begitu kueri mencapai tingkat kerumitan, Anda pada dasarnya dipaksa untuk membaginya secara manual ke bagian-bagian yang diketahui oleh mesin NoSql bagaimana menangani dengan cerdas.

Dalam pengalaman saya dengan MongoDB, pada akhirnya karena kompleksitas kueri tidak ada banyak yang bisa dilakukan Mongo untuk mengoptimalkannya dan menjalankan bagiannya pada banyak data. Mongo memparalelkan banyak pertanyaan tetapi tidak begitu baik dalam mengoptimalkan satu.

Mari kita baca beberapa kasus dunia nyata:

http://planetcassandra.org/apache-cassandra-use-cases/

Dalam artikel ini: http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

Mereka menjelaskan alasan mengapa mereka tidak memilih MySql adalah karena sinkronisasi db terlalu lambat.

(Juga karena komit 2-frasa, FK, PK)

Cassandra didasarkan pada kertas Amazon Dynamo

Fitur:

Stabilitas

Ketersediaan tinggi

Cadangan berkinerja baik

Baca dan Tulis lebih baik daripada HBase, (Klon BigTable di java).

wiki http://en.wikipedia.org/wiki/Apache_Cassandra

Kesimpulan mereka adalah:

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

Pada 2018,

Saya akan merekomendasikan menggunakan ScyllaDB untuk menggantikan cassandra klasik, jika Anda membutuhkan dukungan kembali.

Plugin Postgres kv juga lebih cepat daripada cassandra. Bagaimana pun tidak akan memiliki skalabilitas multi-instance.

Saya akan fokus di sini pada beberapa aspek penting yang dapat membantu Anda memutuskan apakah Anda benar-benar membutuhkan Cassandra. Daftar ini tidak lengkap, hanya beberapa poin yang saya miliki di atas pikiran saya-

• Jangan menganggap Cassandra sebagai pilihan pertama ketika Anda memiliki persyaratan yang ketat pada hubungan (di seluruh dataset Anda).

• Cassandra secara default adalah sistem AP (CAP). Tapi, itu mendukung konsistensi merdu yang berarti dapat dikonfigurasi untuk mendukung CP juga. Jadi jangan abaikan saja karena Anda membaca di suatu tempat bahwa itu AP dan Anda sedang mencari sistem CP. Cassandra lebih tepat disebut "konsisten tuneably," yang berarti memungkinkan Anda untuk dengan mudah menentukan tingkat konsistensi yang Anda butuhkan, seimbang dengan tingkat ketersediaan.

• Jangan gunakan Cassandra jika skalanya tidak terlalu banyak atau jika Anda dapat menangani DB yang tidak didistribusikan.

• Berpikir lebih keras jika tim Anda berpikir bahwa semua masalah Anda akan terpecahkan jika Anda menggunakan DB yang didistribusikan seperti Cassandra. Untuk memulainya dengan DB ini sangat sederhana karena dilengkapi dengan banyak default tetapi mengoptimalkan dan menguasainya untuk memecahkan masalah tertentu akan membutuhkan upaya rekayasa yang baik (jika tidak banyak).

• Cassandra berorientasi pada kolom tetapi pada saat yang sama setiap baris juga memiliki kunci unik. Jadi, mungkin berguna untuk menganggapnya sebagai toko yang diindeks dan berorientasi baris. Anda bahkan dapat menggunakannya sebagai penyimpanan dokumen.

• Cassandra tidak memaksa Anda untuk mendefinisikan bidang sebelumnya. Jadi, jika Anda berada dalam mode startup atau fitur Anda berkembang (seperti gesit) - Cassandra merangkulnya. Jadi lebih baik, pikirkan dulu tentang pertanyaan dan pikirkan tentang data untuk menjawabnya.

• Cassandra dioptimalkan untuk throughput menulis yang sangat tinggi. Jika use case Anda adalah read-heavy (seperti cache) maka Cassandra mungkin bukan pilihan yang ideal.

situasi lain yang membuat pilihan lebih mudah adalah ketika Anda ingin menggunakan fungsi agregat seperti jumlah, min, maks, dan sebagainya dan pertanyaan kompleks (seperti dalam sistem keuangan yang disebutkan di atas) maka database relasional mungkin lebih nyaman daripada database nosql karena keduanya tidak mungkin pada database nosql kecuali Anda benar-benar menggunakan banyak indeks terbalik. Ketika Anda menggunakan nosql, Anda harus melakukan fungsi agregat dalam kode atau menyimpannya secara terpisah di keluarga kolomnya sendiri tetapi ini membuat semuanya sangat kompleks dan mengurangi kinerja yang Anda peroleh dengan menggunakan nosql.

Jika Anda memerlukan database yang sepenuhnya konsisten dengan SQL semantik, Cassandra BUKAN solusi untuk Anda. Cassandra mendukung pencarian nilai kunci. Itu tidak mendukung permintaan SQL. Data dalam Cassandra "pada akhirnya konsisten". Pencarian data secara bersamaan mungkin tidak konsisten, tetapi pada akhirnya pencarian konsisten.

Jika Anda memerlukan semantik ketat dan memerlukan dukungan untuk pertanyaan SQL, pilih solusi lain seperti MySQL, PostGres, atau kombinasikan penggunaan Cassandra dengan Solr.

Cassandra adalah pilihan yang baik jika:

1. Anda tidak memerlukan properti ACID dari DB Anda.

2. Akan ada banyak sekali tulisan di DB.

3. Ada persyaratan untuk berintegrasi dengan Big Data, Hadoop, Hive dan Spark.

4. Ada kebutuhan analisis data waktu nyata dan pembuatan laporan.

5. Ada persyaratan mekanisme toleransi kesalahan yang mengesankan.

6. Ada persyaratan sistem yang homogen.

7. Ada persyaratan banyak penyesuaian untuk penyetelan.

Mongodb memiliki fungsi agregat yang sangat kuat dan kerangka agregat ekspresif. Ini memiliki banyak fitur yang biasa digunakan pengembang dari dunia basis data relasional. Dokumen data / struktur penyimpanan memungkinkan untuk model data yang lebih kompleks daripada Cassandra, misalnya.

Semua ini tentu saja disertai dengan kompromi. Jadi ketika Anda memilih database Anda (NoSQL, NewSQL, atau RDBMS) lihat masalah apa yang Anda coba selesaikan dan pada kebutuhan skalabilitas Anda. Tidak ada satu pun database yang melakukan semuanya.

Menurut DataStax, Cassandra bukan kasus penggunaan terbaik ketika ada kebutuhan

1- Perangkat perangkat keras kelas atas. 2- Sesuai ACID tanpa gulung balik (transaksi bank)

• Itu tidak mendukung manajemen transaksi yang lengkap di seluruh tabel.
• Indeks Sekunder tidak didukung.
• Harus mengandalkan pencarian Elastis / Solr untuk indeks Sekunder dan komponen sinkronisasi khusus harus ditulis.
• Bukan sistem yang sesuai dengan ACID.
• Dukungan kueri terbatas.

Apache cassandra adalah database terdistribusi untuk mengelola sejumlah besar data terstruktur di banyak server komoditas, sambil menyediakan layanan yang sangat tersedia dan tidak ada titik kegagalan tunggal.

Archichecture murni didasarkan pada teorema topi, yaitu ketersediaan, dan toleransi partisi, dan akhirnya menarik secara konsisten.

Jangan gunakan itu, jika Anda tidak menyimpan volume data di rak cluster, jangan gunakan jika Anda tidak menyimpan data deret waktu, jangan gunakan jika Anda tidak mematenkan server Anda, jangan gunakan jika Anda memerlukan konsistensi yang kuat.