Elasticsearch против Кассандры против Elasticsearch с Кассандрой

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

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

В итоге у меня был короткий список: Cassandra and Elasticsearch

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

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