Cassandra ile Elasticsearch, Cassandra ve Elasticsearch

NoSQL öğreniyorum ve müşterimin gereksinimlerinden biri için farklı seçeneklere bakıyorum. Bu soruyu sormadan önce çeşitli kaynaklardan geçtim (NoSQL konusunda çok az bilgisi olan bir kişi)

• Verileri daha hızlı depolamam ve verileri okumam gerekiyor.
• Tamamen arıza korumalı ve kolayca ölçeklenebilir.
• Analytics için verilerde arama yapabilir.

Kısa bir liste hazırladım: Cassandra and Elasticsearch

Anladığım şey, Cassandra'nın benim için mükemmel bir NoSQL depolama çözümü olduğu, çünkü veri yazabildiğim ve dizinleri kullanarak veri okuyabildiğimden. Başarısız olduğu veya başarısız olabileceği yer Analytics'tedir. Gelecekte, veri almak istersem from_date to to_dateveya analitik için veri elde etmenin daha fazla yolunu istersem, Veri modelini düzgün tasarlamazsam veya uzun vadeli bakış açısına sahip olursam, bu sürekli değişen dünyada oldukça zor olabilir.

While Elastic Search, indekslemede en iyisidir (Lucene tarafından desteklenmektedir) ve rastgele bir metin atarak verileri rastgele arayabilir. Ama verileri almak istesem bile aynı şekilde çalışıyor mu from_date to to_date(öyle olmasını bekliyorum). Ama asıl soru şu: bir Arama Motoru mu yoksa Cassandra gibi mükemmel NoSQL veri depolaması mı? Cevabınız evet ise, neden Cassandra'ya ihtiyacımız var?

Her ikisi de farklı bir dünyadaysa, lütfen bunu açıklayın! Daha etkili bir çözüm elde etmek için bunları nasıl birleştiririz?

Uygulamalarımızdan biri hem Cassandra hem de ElasticSearch'te depolanan verileri kullanıyor. Bu kayıtlara mümkün olduğunca erişmek için Cassandra'yı kullanıyoruz ve verileri, belirli uygulama tarafı taleplerine uyacak şekilde tasarlanmış sorgu tablolarına kopyaladık. Sorgu tablolarımızın izin verdiğinden daha liberal bir arama için ElasticSearch bu işlevi güzel bir şekilde gerçekleştirir.

Aynı soruyu da sorduk (kendimize) ... "Neden her şeyi ElastsicSearch'ten alamıyoruz?"

Cevap, ElasticSearch'ün kalıcı bir veri deposu değil, bir arama motoru olarak tasarlanmış olmasıdır. Bazen ElasticSearch yazma işlemlerini kaybeder. ElasticSearch'te her şeyi boşa harcamadan ve yeniden yüklemeden şema değişiklikleri yapmak zordur. Bu amaçla, ElasticSearch'ü Cassandra kümemizle senkronize halde tutmak için tasarlanmış işler yazdım. Bir de yoktu bu konuyla ilgili Quora'daki oldukça son tartışma benzer noktaları vermiştir.

Bununla birlikte, ElasticSearch bir arama motoru olarak harika çalışıyor . Ve Cassandra ölçeklenebilir, yüksek performanslı bir veri deposu olarak harika çalışıyor . Ancak verileri sorgulamak, veri aramaktan farklıdır . Birine veya diğerine ihtiyaç duyduğumuz zamanlar vardır ve bu ikisinin kombinasyonu uygulamamız için iyi sonuç verir. Sizin için iyi çalışabilir (veya çalışmayabilir).

Analitiğe gelince, daha karmaşık OLAP sorguları sunmak için Cassandra Spark bağlayıcısını kullanma konusunda bazı başarılar elde ettim. Umarım yardımcı olur.

Düzenle 20200421

Benzer bir soruya daha yeni bir cevap yazdım:

ElasticSearch ve ElasticSearch + Cassandra

Cassandra + Lucene harika bir seçenektir. Bu sorun için farklı girişimler var, örneğin:

• Stratio'nun Cassandra Lucene Dizini - Stratio Cassandra'dan türetilmiştir, dizin işlevselliğini artıran bir Apache Cassandra eklentisidir. ( https://github.com/Stratio/cassandra-lucene-index )
• Stratio Cassandra, bu Apache Lucene ile yerel bir entegrasyon, çok ilginç. ( https://github.com/Stratio/stratio-cassandra ) - BU PROJE, Stratio'nun Cassandra Lucene Endeksinin FAVORUNDA DURDURULDU
• Tuplejump Calliope, Stratio Cassandra gibi, ama daha az aktif. ( https://github.com/tuplejump/stargate-core )
• Datastax ile DSE Araması. Cassandra'yı Apache Solr ile kullanmaya izin verir, ancak tescilli bir seçenektir. ( Http://www.datastax.com/what-we-offer/products-services/datastax-enterprise )

Bu sorun üzerinde çalıştıktan sonra, casandra gibi NoSQL veritabanlarının, veri şemanızı güvenilir yazma işlemi ile koruduğunuzdan ve elasticsearch'ün sunduğu indeksleme işlemlerinden yararlanmak istemediğinizde iyi olduğunu fark ettim. Bazı dizin verilerini korumak istemeniz durumunda, planınıza güveniyorsanız ve yalnızca yazma işleminden çok daha fazla okuma yapacaksanız elasticsearch iyidir.

Benim durumum veri analiziydi. Bu yüzden, daha sonra bir sonraki adımımın ne olması gerektiğini görmek için veriler arasında çok fazla gezinmek istediğimden beri esnek aramada Latice'imin çoğunu korudum. Analitik temellerimdeki verilerin şemasında çok fazla değişiklik olmasını isteseydim, Casandra'yı kullanırdım.

Ayrıca, verilerinizi iyi grafiklerle sunmak için kullanabileceğiniz kibana gibi birçok güzel temsil aracı vardır. Belki tembelim ama çok güzel görünüyorlar ve bana yardımcı oldular.

Verileri Cassandra ve ElasticSearch kombinasyonunda depolamak size çoğu işlevi sağlar. Anahtar-değer tablolarını aramanıza ve ayrıca dizinlerde veri aramanıza olanak tanır.

Kombinasyon size uygulamanız için ideal olan çok fazla esneklik sağlar.

Elassandra , Cassandra + Elastic aramanın birleşik çözümüdür, Verileri indekslemek için Elastic arama ve veri deposu olarak Cassandra'yı kullanır, performanstan emin değilim, ancak bu makaleye göre performansı iyi.
Uygulamanızın arama özelliğine ihtiyacı varsa, Elassandra en iyi açık kaynak seçeneğidir. DSE araması mevcuttur ancak pahalıdır.

Elasticsearch ve Cassandra'yı kullandığımız bir uygulama geliştirmiştik. Benzer veriler Cassandra'da saklandı ve Elasticsearch'e indekslendi.

Uygulamamızın kullanıcı arabirimi aramalar, toplamalar, veri aktarımı vb. Gibi özelliklere sahipti. Arka uç mikro hizmetleri sürekli olarak büyük veriler (Kafka konularında) alıyor ve Cassandra'da depoluyordu. Veriler Cassandra'da depolandıktan sonra, hizmetler verilerin Elasticsearch'e indekslenmesini sağlayacaktır.

Cassandra, Elasticsearch için "Gerçeğin Kaynağı" olarak hareket ediyordu. ES indeksinin yeniden indekslenmesinin gerekli olduğu durumlarda, Cassandra'yı sorguladık ve verileri ES'de yeniden indeksledik.

Ölçeklendirmesi çok kolay olduğundan ve aramalar ve toplamalar çok daha hızlı olduğundan bu çözüm bize yardımcı oldu.

• Elasticsearch, Lucene indeksi üzerine inşa edildiğinden ve indekslemeyi elasticsearch'te saklamak istiyorsanız, verileri almak için Cassandra'nın kendi indekslemesine kıyasla en iyi performansı gösterir.
• Gereksinimleriniz gerçek zamanlı erişimle ilgili değilse, elasticsearch'ü NoSQL veritabanı olarak da kullanabilirsiniz, ElasticSearch'ün yazma işlemlerini kaybettiğine ve Schema değişikliklerinin zor olduğuna dair düşünceler vardır, ancak veri hacminiz çok büyük değilse. Elasticsearch'ü aNoSQL veritabanı olarak elasticsearch ile birlikte en iyi indeksleme ile bir arama motoru olarak kolayca elde edebilirsiniz. Bunu engellemenin birkaç yolu var. Elasticsearch'te şema değişiklikleri üzerinde çalıştım, veri yapınız tutarlıysa herhangi bir sorun yaratacaktır.
• ElasticSearch veya SOlr'ın destekçisi olmak. Hem arama motorları üzerinde çalıştım hem de doğru yapılandırmanız halinde her iki arama motorunun da akıcı bir şekilde kullanılabileceğini deneyimledim.
• Sadece gerçek zamanlı sonucu hedefliyorsanız ve cevabınızı milisaniye geciktiremezseniz, düşünebileceğim eksiler. O zaman cassandra veya couchbase gibi diğer NoSQL veritabanlarından yardım almak daha iyidir.
• Solr ile Cassandra, ElasticSearch ile Cassandra'dan daha iyi çalışır.

Cassandra kimliğe göre veri alma konusunda harikadır . İkincil dizin performansı hakkında pek bir şey bilmiyorum, ancak Elasticsearch kadar hızlı olduğundan şüpheliyim. Elasticsearch, tam metin arama işlevi ( metin analizi , alaka düzeyi puanlaması , vb.) Söz konusu olduğunda kesinlikle kazanır .

Cassandra güncelleme performansını da kazanır . Elasticsearch güncellemeleri destekler, ancak bir güncelleme gerçekten atomik bir işlemde reindex + soft silmedir.

Cassandra'nın çok güzel bir çoğaltma modeli var (eğer ekstra hata korumalı olmanız gerekiyorsa). Elasticsearch de sorun değil, ES'nin özellikle güvenilmez olduğunu söyleyen kampta değilim (tüm yazılımlar gibi bazen sorunları oluyor).

Elasticsearch ayrıca gerçek zamanlı analitik için toplamalara sahiptir . Ve aramalar çok hızlı olduğu için, bir veri alt kümesindeki analizler de hızlı olacaktır .

Gereksinimleriniz bunlardan biri tarafından yeterince iyi karşılanırsa (burada olduğu gibi ES iyi çalışıyor gibi görünüyor), sadece birini kullanırdım. Her iki dünyadan da gereksinimleriniz varsa, şunlardan birini yapabilirsiniz:

• bunlardan birini kullanın ve olumsuz yönleri aşın. Örneğin, Elasticsearch ile birçok güncellemeyi işleyebilirsiniz, ancak daha fazla parça ve daha fazla donanımla
• ikisini de kullanın ve senkronize olduklarından emin olun