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

110

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

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

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

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

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

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

Reddy
источник
2
Вы также должны рассмотреть DSE Search = Cassandra + solr Integrated = лучшее из обоих миров: масштабируемая база данных для хранилища, управляемая поисковой мощностью Solr.
Беренг
1
@Bereng, я думаю, DSE является коммерческой, и мы не занимаемся коммерческим ПО.
Reddy
3
Если вы стартап с чистой выручкой менее 2 миллионов долларов (США), они позволят вам использовать DSE бесплатно (как минимум в течение года или двух).
Аарон

Ответы:

150

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

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

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

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

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

Изменить 20200421

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

ElasticSearch против ElasticSearch + Cassandra

Аарон
источник
24
Может ли кто-нибудь пояснить разницу между запросом и поиском данных?
Dror
21
@dror, например, если вы знаете идентификатор (а) ваших данных, вы просто запрашиваете его (кассандра), и если вы не знаете идентификатор (а) ваших данных, вы ищете его / их (эластичный поиск).
Арсеник
2
@Gladwell: все зависит от размера ваших данных и сложности ваших запросов. Теоретически Elastic может все. Тем не менее, я бы доверил Cassandra лучше справиться с масштабированием для поддержки большого набора данных (для запросов), чем Elastic, особенно если вы поддерживаете многорегиональный / DC.
Аарон
1
@Aaron ... масштабирование для поддержки большого набора данных - вот что хорошо умеют оба этих движка. Наша организация использует эластичный поиск в качестве основной базы данных, механизма оповещения, инструмента аналитики, и теперь, когда xpack поддерживает машинное обучение; он также предоставляет бизнес-статистику по нашему периферийному IOT.
AnthonyJClink 03
1
@Dror Задаю настоящий вопрос!
Майк Эззати
32

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

Альваро Агеа
источник
Следует иметь в виду одну вещь: в 2.1 теперь вы можете «добавить» специальный индексатор ... так, например, вы можете имитировать то, что Statio делает с их вилкой C *, но не с основной C *. Мне не известно о каких-либо широко распространенных попытках сделать это, но я сам планирую перенести индексы Lucene в C *. Для получения дополнительной информации: issues.apache.org/jira/browse/CASSANDRA-8717
evanv
8

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

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

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

М.Рез
источник
4

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

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


источник
4

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

Anavaras Lamurep
источник
1

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

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

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

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

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

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

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

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

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

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

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