Elasticsearch против Cassandra против Elasticsearch с Cassandra

Я изучаю NoSQL и ищу различные варианты для одного из требований моего клиента. Я просмотрел различные ресурсы, прежде чем задать этот вопрос (человек с небольшим знанием NoSQL)

• Мне нужно быстрее хранить данные и читать данные.
• Полностью отказоустойчивый и легко масштабируемый.
• Возможность поиска данных для аналитики.

В итоге я получил короткий список: Cassandra and Elasticsearch

Что я действительно понимаю, так это то, что Cassandra - идеальное решение для хранения данных NoSQL для меня, поскольку я могу записывать и читать данные с помощью индексов. Где он не работает или может потерпеть неудачу, находится в Analytics. В будущем, если я захочу получать данные from_date to to_dateили другие способы получения данных для аналитики, если я не буду проектировать модель данных должным образом или не буду следить за долгосрочными перспективами, что может быть довольно сложно в постоянно меняющемся мире.

Пока Elastic Searchлучше всего индексируется (поддерживается Lucene) и может искать данные случайным образом, выбрасывая случайный текст. Но работает ли он так же, даже если я хочу получить данные from_date to to_date(я полагаю, что это может быть). Но настоящий вопрос в том, это поисковая система или идеальное хранилище данных NoSQL, такое как Cassandra? Если да, то зачем нам еще нужна Кассандра?

Если они оба находятся в разных мирах, пожалуйста, объясните это! Как их объединить, чтобы получить более эффективное решение?

Одно из наших приложений использует данные, которые хранятся как в Cassandra, так и в ElasticSearch. Мы используем Cassandra для доступа к этим записям всякий раз, когда можем, и дублируем данные в таблицы запросов, предназначенные для соответствия конкретным запросам на стороне приложения. ElasticSearch отлично справляется с этой функцией для более свободного поиска, чем могут позволить наши таблицы запросов.

Мы задали тот же вопрос (себе) ... "Почему бы нам просто не получить все от ElastsicSearch?"

Ответ заключается в том, что ElasticSearch был разработан как поисковая система, а не как постоянное хранилище данных. Иногда ElasticSearch теряет запись. В ElasticSearch сложно изменить схему, не удалив все и не перезагрузив. Для этой цели я написал задания, которые предназначены для обеспечения синхронизации ElasticSearch с нашим кластером Cassandra. На Quora также было довольно недавнее обсуждение этой темы , в результате которого были получены аналогичные результаты.

Это , как говорится, ElasticSearch работает большой в качестве поисковой системы. А Cassandra отлично работает как масштабируемое высокопроизводительное хранилище данных. Но запрос данных отличается от поиска данных. Бывают случаи, когда нам нужен один или другой, и их комбинация хорошо работает для нашего приложения. Это может (а может и не работать) хорошо для вас.

Что касается аналитики, мне удалось использовать коннектор Cassandra Spark для обслуживания более сложных запросов OLAP. Надеюсь, это поможет.

Изменить 20200421

Я написал более свежий ответ на аналогичный вопрос:

ElasticSearch против ElasticSearch + Cassandra

Cassandra + Lucene - отличный вариант. Есть разные инициативы по этому поводу, например:

• Stratio Cassandra Lucene Index - производный от Stratio Cassandra, это плагин для Apache Cassandra, который расширяет функциональность индекса. ( https://github.com/Stratio/cassandra-lucene-index )
• Stratio Cassandra, это нативная интеграция с Apache Lucene, это очень интересно. ( https://github.com/Stratio/stratio-cassandra ) - ДАННЫЙ ПРОЕКТ ПРЕКРАЩЕН В ЗАВЕРШЕНИЕ ИНДЕКСА Stratio Cassandra Lucene
• Tuplejump Каллиопа, это как Stratio Cassandra, только менее активный. ( https://github.com/tuplejump/stargate-core )
• Поиск DSE по Datastax. Он позволяет использовать Cassandra с Apache Solr, но это проприетарный вариант. ( Http://www.datastax.com/what-we-offer/products-services/datastax-enterprise )

После самостоятельной работы над этой проблемой я понял, что базы данных NoSQL, такие как casandra, хороши, когда вы хотите убедиться, что вы сохраняете свою схему данных с надежной операцией записи, и не хотите пользоваться преимуществами операций индексирования, которые предлагает elasticsearch. Если вы хотите сохранить некоторые данные индексов, то elasticsearch подойдет, если вы доверяете своей схеме и собираетесь выполнять гораздо больше операций чтения, чем записи.

В моем случае была аналитика данных. Поэтому я сохранил большую часть своих Latices в эластичном поиске, так как позже я захотел много просматривать данные, чтобы увидеть, каким должен быть мой следующий шаг. Я бы использовал casandra, если бы хотел внести много изменений в схему данных в моих аналитических строчках.

Также есть много хороших инструментов представления, таких как кибана, которые вы можете использовать для представления ваших данных с хорошей графикой. Может, я и ленив, но они очень хорошо выглядят и мне помогли.

Хранение данных в комбинации Cassandra и ElasticSearch дает вам наибольшую функциональность. Он позволяет вам искать таблицы "ключ-значение", а также позволяет искать данные в индексах.

Комбинация дает вам большую гибкость, идеально подходящую для вашего приложения.

Elassandra - это комбинированное решение Cassandra + Elastic search, оно использует Elastic search для индексации данных и Cassandra в качестве хранилища данных, я не уверен в производительности, но, согласно этой статье , его производительность хорошая.
Если вашему приложению нужна функция поиска, то Elassandra - лучший вариант с открытым исходным кодом. Поиск DSE доступен, но стоит дорого.

Мы разработали приложение, в котором использовали Elasticsearch и Cassandra. Подобные данные хранились в Cassandra и индексировались в Elasticsearch.

Пользовательский интерфейс нашего приложения имел такие функции, как поиск, агрегирование, экспорт данных и т. Д. Внутренние микросервисы постоянно получали огромные данные (по темам Kafka) и сохраняли их в Cassandra. После того, как данные будут сохранены в Cassandra, сервисы обеспечат индексацию данных в Elasticsearch.

Кассандра была «Источником истины» для Elasticsearch. В тех случаях, когда требовалась переиндексация индекса ES, мы запрашивали Cassandra и повторно индексировали данные в ES.

Это решение помогло нам, поскольку его было очень легко масштабировать, а поиск и агрегирование выполнялись намного быстрее.

• Поскольку elasticsearch построен на индексе Lucene, и если вы хотите сохранить индексирование в elasticsearch, он лучше всего работает по сравнению с индексированием в самой Cassandra для извлечения данных.
• Если ваши требования не связаны с поиском в реальном времени, вы также можете использовать elasticsearch в качестве базы данных NoSQL, есть мысли, что ElasticSearch теряет записи, а изменения схемы затруднены, но если ваш объем данных не слишком велик. Вы можете легко получить elasticsearch в качестве поисковой системы с лучшей индексацией вместе с elasticsearch в качестве базы данных NoSQL. Есть несколько способов предотвратить это. Я работал над изменениями схемы в elasticsearch, если ваша структура данных согласована, это создаст какие-либо проблемы.
• Являясь сторонником ElasticSearch или SOlr. Я работал с обеими поисковыми системами, и я убедился, что обе поисковые системы можно использовать плавно, если вы правильно их настроите.
• Единственные минусы, о которых я могу думать, если вы нацелены на результат в реальном времени и не можете компенсировать миллисекундную задержку в своем ответе. Тогда лучше воспользоваться помощью других баз данных NoSQL, таких как cassandra или couchbase.
• Кассандра с solr, лучше работает Кассандра с elasticSearch.

Кассандра отлично подходит для получения данных по идентификатору . Я мало знаю о производительности вторичного индекса, но сомневаюсь, что он так же быстр, как Elasticsearch. Безусловно, Elasticsearch выигрывает, когда речь идет о функциях полнотекстового поиска ( анализ текста , оценка релевантности и т. Д.).

Кассандра также выигрывает по производительности обновлений . Elasticsearch поддерживает обновления, но на самом деле обновление - это переиндексирование + мягкое удаление в атомарной операции.

У Cassandra очень хорошая модель репликации (если вам нужно быть особо отказоустойчивым). Elasticsearch тоже в порядке, я не сторонник того, что ES особенно ненадежен (у него иногда возникают проблемы, как и у любого программного обеспечения).

Elasticsearch также имеет агрегаты для аналитики в реальном времени. А поскольку поиск выполняется так быстро, аналитика по подмножеству данных тоже будет быстрой .

Если ваши требования достаточно хорошо удовлетворяются одним из них (например, здесь кажется, что ES будет работать хорошо), я бы просто использовал один. Если у вас есть требования из обоих миров, вы можете:

• воспользуйтесь одним из них и постарайтесь обойти недостатки. Например, вы можете обрабатывать много обновлений с помощью Elasticsearch, но с большим количеством сегментов и большим количеством оборудования.
• используйте оба и убедитесь, что они синхронизированы