Эластичный поиск против Кассандры против Эластичный поиск с Кассандры

Question

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

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

Я закончил с коротким списком: Cassandra and Elasticsearch

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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