Cassandra ne zaman KULLANILMAZ?

Son zamanlarda Cassandra ile ilgili çok fazla konuşma oldu .

Twitter, Digg, Facebook vb.

Ne zaman mantıklı:

• Cassandra kullan,
• Cassandra kullanmayın ve
• Cassandra yerine RDMS kullanın.

Gümüş kurşun gibi bir şey yoktur, her şey belirli sorunları çözmek için inşa edilmiştir ve kendi artıları ve eksileri vardır. Hangi sorun bildirimine sahip olduğunuz ve bu sorun için en uygun çözüm size kalmış.

Sorularınızı sorduğunuz sırayla tek tek cevaplamaya çalışacağım. Cassandra, NoSQL veritabanı ailesine dayandığından, sorularınızı cevaplamadan önce neden bir NoSQL veritabanı kullandığınızı anlamanız önemlidir.

Neden NoSQL kullanılır?

RDBMS durumunda, seçim yapmak oldukça kolaydır, çünkü bu kategorideki MySQL, Oracle, MS SQL, PostgreSQL gibi tüm veritabanları ACID özelliklerine yönelik neredeyse aynı tür çözümler sunar. NoSQL söz konusu olduğunda, karar zorlaşır çünkü her NoSQL veritabanı farklı çözümler sunar ve hangisinin uygulama / sistem gereksinimleriniz için en uygun olduğunu anlamanız gerekir. Örneğin, MongoDB, sisteminizin şemasız bir belge deposu talep ettiği kullanım durumları için uygundur. HBase, arama motorlarına, günlük verilerini analiz etmeye veya devasa, iki boyutlu birleşimsiz tabloların taranmasının gerekli olduğu herhangi bir yere uygun olabilir. Redis, ağaçlar, kuyruklar, bağlantılı listeler, vb. Benzer şekilde, bu kategoride (Cassandra dahil) farklı sorun ifadelerine uygun başka veritabanları da vardır. Şimdi orijinal sorulara geçelim ve bunları tek tek cevaplayalım.

Cassandra ne zaman kullanılır?

NoSQL ailesinin bir parçası olan Cassandra, gereksinimlerinizden birinin çok ağır bir yazma sistemine sahip olması ve saklanan verilerin üstünde oldukça duyarlı bir raporlama sistemine sahip olmak istediğiniz sorunlara bir çözüm sunar. Her bir istek için günlük verilerinin depolandığı ve gerçek zamanlı olarak tarayıcı, IP, vb. İle saat başına isabet sayısını hesaplamak için bir analitik platform oluşturmak istediğiniz Web analitiğinin kullanım durumunu düşünün. BaşvurabilirsinizCassandra'nın uyduğu kullanım durumları hakkında daha fazla bilgi edinmek bu blog yayınına .

Cassandra yerine RDMS ne zaman kullanılır?

Cassandra bir NoSQL veritabanına dayanır ve ACID ve ilişkisel veri özellikleri sağlamaz. ASİT mülkleri için güçlü bir gereksiniminiz varsa (örneğin, Finansal veriler), Cassandra bu durumda uygun olmaz. Açıkçası, bunun için bir geçici çözüm yapabilirsiniz, ancak ACID özelliklerini simüle etmek için çok sayıda uygulama kodu yazacaksınız ve kötü pazarlanma zamanı kaybedeceksiniz. Cassandra ile bu tür bir sistemi yönetmek sizin için karmaşık ve sıkıcı olacaktır.

Cassandra ne zaman kullanılmaz

Yukarıdaki açıklama mantıklıysa cevaplanması gerektiğini düşünmüyorum.

Dağıtılmış veri sistemlerini değerlendirirken, CAP teoremini göz önünde bulundurmalısınız - aşağıdakilerden iki tanesini seçebilirsiniz: tutarlılık, kullanılabilirlik ve bölüm toleransı.

Cassandra, nihai tutarlılığı destekleyen, bölümlere toleranslı bir sistemdir. Daha fazla bilgi için bu blog yazısına bakın yazdım: NoSQL Sistemleri Görsel Kılavuzu .

Cassandra belirli bir sorunun cevabıdır: Tek bir sunucuya sığmayacak kadar çok veriniz varsa ne yaparsınız? Tüm verilerinizi birçok sunucuda nasıl saklarsınız ve banka hesabınızı kırmaz ve geliştiricilerinizi delirtmezsiniz? Facebook HER GÜN 4 Terabaytlık yeni sıkıştırılmış veri alır. Ve bu sayı büyük olasılıkla bir yıl içinde iki katından fazla artacaktır.

Bu kadar veriye sahip değilseniz veya Enterprise Oracle / DB2 küme yüklemesi için milyonlarca paranız varsa ve bunu kurmak ve bakımını yapmak için gereken uzmanlarınız varsa, SQL veritabanında sorun yoktur.

Ancak Facebook artık cassandra kullanmıyor ve şimdi daha hızlı performans ve daha iyi kontrol için neredeyse sadece uygulama yığınında bölümlemeyi yukarı hareket ettiren MySQL kullanıyor.

NoSQL'in genel fikri, uygulamanız için en uygun veri deposunu kullanmanız gerektiğidir. Bir finansal veriler tablonuz varsa SQL kullanın. İlişkisel bir şemaya eşlemek için karmaşık / yavaş sorgular gerektiren nesneleriniz varsa, bir nesne veya anahtar / değer deposu kullanın.

Elbette karşılaştığınız herhangi bir gerçek dünya problemi bu iki uç arasında bir yerdedir ve her iki çözüm de mükemmel olmayacaktır. Her mağazanın yeteneklerini ve birini diğerinin üzerinde kullanmanın sonuçlarını düşünmelisiniz, ki bu çözmeye çalıştığınız soruna çok özel olacaktır.

Cassandra'nın ne zaman kullanılacağı ve ne zaman kullanılamayacağı ile ilgili yukarıda verilen cevapların yanı sıra, Cassandra'yı kullanmaya karar verirseniz, Cassandra'nın kendisini değil, oradaki birçok kuzeninden birini kullanmayı düşünebilirsiniz.

Yukarıdaki bazı cevaplar, Cassandra ile birçok özelliği paylaşan, bazı küçük veya büyük farklılıklarla çeşitli "NoSQL" sistemlerine işaret etti ve belirli ihtiyaçlarınız için Cassandra'nın kendisinden daha iyi olabilir.

Ayrıca, son zamanlarda (bu sorunun ilk sorulmasından birkaç yıl sonra), Scylla adlı bir Cassandra klonu (bkz. Https://en.wikipedia.org/wiki/Scylla_(database) ). Scylla, C ++ 'da Cassandra'nın orijinal Java Cassandra'dan önemli ölçüde daha yüksek verim ve daha düşük gecikme süresine sahip olduğunu ve bununla daha çok uyumlu olduğunu iddia eden (özellikler, API'ler ve dosya formatlarında) açık kaynaklı bir yeniden uygulamadır. Eğer Cassandra'yı zaten düşünüyorsanız, Scylla'yı da düşünebilirsiniz.

Cassandra'yı konuşlandırmanın ortasında biriyle konuşmak, çoktan çoğa iyi işlemiyor. İlk testlerini yapmak için hack işi yapıyorlar. Bu konuda bir Cassandra danışmanı ile konuştum ve bu problem seti olsaydı tavsiye etmeyeceğini söyledi.

Kendinize aşağıdaki soruları sormalısınız:

1. (Cilt, Hız) TON bilgisini yazacak ve okuyacak mısınız, o kadar çok bilgi yazıyor ki hiç kimse yazamaz.
2. (Global) Dünyanın bir yerindeki yazmalara dünyanın başka bir yerinden erişilebilmesi için bu yazma ve okuma yeteneğine ihtiyacınız olacak mı?
3. (Güvenilirlik) Bu veritabanının her zaman çalışır durumda olması ve hangi Bulut, hangi ülke, VM, Container veya Bare metal olduğuna bakılmaksızın hiçbir zaman yere düşmemesi gerekiyor mu?
4. (Ölçeklendirme yeteneği) Kolayca büyümeye ve doğrusal ölçeklemeye devam edebilmek için bu veritabanına ihtiyacınız var mı?
5. (Tutarlılık) Bazı yazma işlemlerinin eşzamansız olarak gerçekleşebileceği yerlerde TUNABLE tutarlılığına mı ihtiyacınız var?
6. (Beceri) Bu teknolojiyi ve herkes için her yerde hızlı olabilen küresel olarak dağıtılmış bir veritabanı oluşturmakla birlikte gelen veri modellemesini öğrenmek için ne yapmaya istekli misiniz?

Bu sorulardan herhangi biri için "belki" ya da "hayır" diye düşündüyseniz, başka bir şey kullanmalısınız. Eğer hepsine bir cevap olarak “cehennem evet” e sahipseniz, o zaman Cassandra'yı kullanmalısınız.

RDBMS'yi kullanarak her şeyi tek bir kutuda yapabilirsiniz. Muhtemelen çoğundan daha kolaydır ve herkes onunla çalışabilir.

Buradaki diğer yanıtlara ek olarak, ağır tek sorgu ile gazillion hafif sorgu yükünün dikkate alınması gereken başka bir nokta vardır. NoSql tarzı bir DB'de tek bir sorguyu otomatik olarak optimize etmek doğal olarak daha zordur. MongoDB kullandım ve karmaşık bir sorgu hesaplamaya çalışırken performans sorunları ile karşılaştım. Cassandra'yı kullanmadım ama aynı soruna sahip olmasını bekliyorum.

Öte yandan, yükünüzün çok fazla küçük sorgunun olması bekleniyorsa ve kolayca ölçeklendirmek istiyorsanız, çoğu NoSql DB tarafından sunulan nihai tutarlılıktan yararlanabilirsiniz. Nihai tutarlılığın gerçekten ilişkisel olmayan bir veri modelinin bir özelliği olmadığını, ancak NoSql tabanlı bir sistemde uygulanması ve kurulması çok daha kolay olduğunu unutmayın.

Tek, çok ağır bir sorgu için, herhangi bir modern RDBMS motoru, sorgunun bölümlerini paralel hale getiren iyi bir iş yapabilir ve ona attığınız kadar CPU ve bellekten (tek bir makinede) yararlanabilir. NoSql veritabanları, büyük bir sorgunun gerçekten akıllı paralelleştirilmesini sağlayacak varsayımlar yapabilmek için verilerin yapısı hakkında yeterli bilgiye sahip değildir. Daha fazla sunucuyu (veya çekirdeği) kolayca ölçeklendirmenize izin verir, ancak sorgu bir karmaşıklık düzeyine ulaştığında, temel olarak NoSql motorunun akıllıca nasıl başa çıkacağını bildiği parçalara el ile ayırmak zorunda kalırsınız.

MongoDB ile yaşadığım deneyimde, sonunda sorgunun karmaşıklığı nedeniyle Mongo'nun onu optimize etmek ve bölümlerini birden çok veri üzerinde çalıştırmak için yapabileceği çok fazla şey yoktu. Mongo birden fazla sorguyu paralel hale getirir , ancak tek bir sorguyu optimize etmekte o kadar iyi değildir.

Bazı gerçek dünya vakalarını okuyalım:

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

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

MySql'yi seçmemelerinin nedenini db senkronizasyonu çok yavaş olduğu için detaylandırdılar.

(Ayrıca 2 cümlelik taahhüt nedeniyle, FK, PK)

Cassandra Amazon Dinamo gazetesine dayanıyor

Özellikleri:

istikrar

Yüksek kullanılabilirlik

Yedekleme iyi performans gösterir

Okuma ve Yazma HBase'den daha iyidir (Java'daki BigTable klonu).

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

Sonuç :

We looked at HBase, Dynamo, Mongo and Cassandra. 

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

2018 itibariyle,

Sırt desteğine ihtiyacınız varsa, klasik cassandra'nın yerine ScyllaDB kullanmanızı tavsiye ederim.

Postgres kv eklentisi de cassandra'dan daha hızlıdır. Nasıl çok örnekli ölçeklenebilirlik olmaz.

Burada gerçekten Cassandra'ya ihtiyacınız olup olmadığına karar vermenize yardımcı olabilecek bazı önemli noktalara odaklanacağım. Liste kapsamlı değil, sadece aklıma gelen bazı noktalar-

• İlişki konusunda sıkı bir gereksiniminiz olduğunda (veri kümeniz genelinde) Cassandra'yı ilk seçenek olarak düşünmeyin.

• Cassandra varsayılan olarak AP sistemidir (CAP). Ancak, ayarlanabilir tutarlılığı destekler, yani CP'yi de destekleyecek şekilde yapılandırılabilir. Bu yüzden bunu bir yerde okuduğunuz ve AP sistemleri aradığınız için görmezden gelmeyin. Cassandra daha doğru bir şekilde “ayarlanabilir tutarlı” olarak adlandırılır; bu da, kullanılabilirlik düzeyine uygun olarak, ihtiyaç duyduğunuz tutarlılık düzeyine kolayca karar vermenizi sağlar.

• Ölçeğiniz fazla değilse veya dağıtılmamış bir DB ile başa çıkabiliyorsanız Cassandra'yı kullanmayın.

• Cassandra gibi dağıtılmış DB'ler kullanırsanız, ekibiniz tüm sorunlarınızın çözüleceğini düşünüyorsa daha fazla düşünün. Bu DB'lerle başlamak, birçok varsayılanla birlikte geldiği için çok basittir, ancak belirli bir sorunu çözmek için optimize etmek ve mastering yapmak, çok fazla miktarda mühendislik çabası gerektirecektir.

• Cassandra sütun yönelimlidir, ancak aynı zamanda her satırın da benzersiz bir anahtarı vardır. Bu nedenle, dizine alınmış, sıra odaklı bir mağaza olarak düşünmek yararlı olabilir. Hatta belge deposu olarak da kullanabilirsiniz.

• Cassandra sizi önceden alanları tanımlamaya zorlamaz. Yani, bir başlangıç ​​modundaysanız veya özellikleriniz gelişiyorsa (çevik gibi) - Cassandra bunu kucaklar. Daha iyisi, önce sorguları düşünün ve sonra bunları yanıtlamak için veriyi düşünün.

• Cassandra, yazma işlemlerinde gerçekten yüksek verimlilik için optimize edilmiştir. Kullanım durumunuz ağırsa (önbellek gibi), Cassandra ideal bir seçim olmayabilir.

seçimi kolaylaştıran bir başka durum da, toplam, min, maks, vb. gibi toplama işlevlerini ve karmaşık sorguları (yukarıda belirtilen finansal sistemde olduğu gibi) kullanmak istediğinizde ilişkisel bir veritabanı muhtemelen bir nosql veritabanından daha uygundur. Çok fazla Tersine çevrilmiş dizin kullanmadığınız sürece bir nosql veritabanında mümkün değildir. Nosql kullandığınızda, toplu işlevleri kod içinde yapmanız veya bunları kendi sütun ailesinde ayrı olarak depolamanız gerekir, ancak bu oldukça karmaşık hale getirir ve nosql kullanarak elde ettiğiniz performansı azaltır.

SQL semantiği ile tamamen tutarlı bir veritabanına ihtiyacınız varsa, Cassandra sizin için bir çözüm DEĞİLDİR. Cassandra anahtar / değer aramalarını destekler. SQL sorgularını desteklemez. Cassandra'daki veriler "sonunda tutarlı". Eşzamanlı veri aramaları tutarsız olabilir, ancak nihayetinde aramalar tutarlıdır.

Sıkı semantiğe ve SQL sorguları için desteğe ihtiyacınız varsa, MySQL, PostGres gibi başka bir çözüm seçin veya Cassandra'nın kullanımını Solr ile birleştirin.

Cassandra şu durumlarda iyi bir seçimdir:

1. DB'nizden ACID özelliklerine gerek yoktur.

2. DB üzerinde çok sayıda yazı olacaktı.

3. Büyük Veri, Hadoop, Kovan ve Kıvılcım ile entegre olma şartı vardır.

4. Gerçek zamanlı veri analizi ve rapor oluşturma nesnelerine ihtiyaç vardır.

5. Etkileyici hataya dayanıklı mekanizma gereksinimi vardır.

6. Homojen bir sistem gereksinimi vardır.

7. Ayarlama için çok sayıda özelleştirme gereksinimi vardır.

Mongodb çok güçlü toplama işlevlerine ve etkileyici bir toplama çerçevesine sahiptir. Geliştiricilerin ilişkisel veritabanı dünyasından kullanmaya alışkın olduğu birçok özelliğe sahiptir. Belge verileri / depolama yapısı, örneğin Cassandra'dan daha karmaşık veri modellerine izin verir.

Bütün bunlar elbette değiş tokuşlarla geliyor. Veritabanınızı (NoSQL, NewSQL veya RDBMS) seçtiğinizde, hangi sorunu çözmeye çalıştığınıza ve ölçeklenebilirlik gereksinimlerinize bakın. Tek bir veritabanı hepsini yapmaz.

DataStax'a göre Cassandra, ihtiyaç duyulduğunda en iyi kullanım örneği değil

1- İleri teknoloji donanım aygıtları. 2- Geri dönüşü olmayan ASİT uyumlu (banka işlemi)

• Tablolar arasında tam işlem yönetimini desteklemez.
• İkincil Dizin desteklenmiyor.
• İkincil dizin için Elastik arama / Solr'a güvenmeniz gerekir ve özel senkronizasyon bileşeni yazılmalıdır.
• ASİT uyumlu sistem değil.
• Sorgu desteği sınırlıdır.

Apache cassandra, birçok emtia sunucusunda büyük miktarda yapılandırılmış veriyi yönetirken dağıtılmış bir veritabanıdır ve yüksek düzeyde kullanılabilir hizmet sağlar ve tek bir hata noktası yoktur.

Mimarlık tamamen kullanılabilirlik ve bölüm toleransı olan kapak teoremine dayanmaktadır ve ilginç bir şekilde sürekli olarak ortaya çıkmaktadır.

Kullanmayın, eğer kümeler raflarında hacimli veri depolamıyorsanız, Zaman serisi verilerini saklamıyorsanız kullanmayın, Sunucunuzu pating etmiyorsanız kullanmayın, Güçlü Tutarlılığa ihtiyacınız varsa kullanmayın.