Итак, как автор одного из связанных ответов ( Elasticsearch против Cassandra против Elasticsearch с Cassandra ), я полагаю, что мне следует взвесить здесь.
эти предполагаемые потери возможно, это произошло из-за некоторых ошибок, которые были устранены в эти годы.
Это абсолютно верное утверждение. Ответ, который я написал, уже почти шесть лет, и ElasticSearch за это время вырос на 1011 * намного более надежный продукт. При этом, есть некоторые вещи, которые Cassandra может сделать, что ElasticSearch просто не был предназначен для (и наоборот).
какие дополнительные функции предлагает Cassandra ...
Я могу вспомнить некоторые из них, которые я суммирую здесь:
- Пропускная способность записи / производительность / задержка
ElasticSearch это поисковая система, основанная на проекте Lucene. Обработка больших объемов записи при низких задержках - это не то, для чего она предназначена; по крайней мере, не "из коробки". Есть способы настроить ElasticSearch, чтобы быть лучше в этом, как описано здесь: Методы достижения высокой производительности записи с ElasticSearch . Но с точки зрения создания нового кластера с минимальной конфигурацией, вы потратите меньше времени на разработку Cassandra, чтобы выполнить sh this.
"Иногда ElasticSearch теряет записи"
Да, я написал, что , Опять же, ElasticSearch улучшился. Много. Но я все еще вижу, что это происходит в условиях высокой пропускной способности записи. Если кластер спроектирован для определенного уровня пропускной способности, а приложение превышает , эти допуски приводят к перегрузке узла из-за обратного давления записи, запись будет потеряна.
Кассандра также не застрахована от этой проблемы. У него просто есть более высокая терпимость к этому. Если бы вы использовали их вместе, то было бы неплохо создать что-то наподобие Kafka для «регулирования» пропускной способности записи для каждого.
- Высокая доступность нескольких центров обработки данных (MDHA)
Имея возможность определять логические центры обработки данных и зоны доступности (стойки), Cassandra всегда умела реплицировать набор данных в нескольких регионах. Это проблематично c для ElasticSearch, так как у него нет концепции логического центра обработки данных, и его «главные» узлы не активны / активны.
- Одноранговые узлы и основанные на ролях узлы
В качестве продолжения моей точки MDHA ElasticSearch теперь позволяет узлам назначаться с "ролью" в кластере. Вы можете указать несколько узлов, которые будут выполнять роль «главной», отвечая за добавление и обновление индексов. Любой узел может направить трафик поиска c на узлы, которые работают под ролью «данные». Фактически, один из способов улучшить пропускную способность записи (моя первая тема для разговора) - назначить один или два узла ролью «ingest», которая может препятствовать трафику чтения и записи c мешать друг другу.
Это отличается от подхода Кассандры, где каждый узел является равноправным, и может обрабатывать операции чтения и записи. Возможность обрабатывать все узлы одинаково, упрощает обслуживание и администрирование. И «нет», несмотря на распространенное заблуждение, «начальный» узел не является чем-то особенным.
Для меня Это принципиальная разница между ними. Запрос не такой же, как поиск. Они могут показаться похожими, но они совершенно разные.
Извлечение данных путем сопоставления с шаблоном в одном или нескольких столбцах / свойствах поиск . Также с поиском, количество результатов заранее неизвестно. Конечно, Cassandra добавила некоторые функции в последние несколько лет, чтобы разрешить сопоставление с образцом на основе LIKE запросов (я не рекомендую его использовать). Но когда требуется «поиск» в наборе данных, Cassandra не может конкурировать с ElasticSearch.
Извлечение данных путем предоставления указанного значения c для указанного ключа c (столбца) составляет запросов . С запросом также легче иметь точные ожидания относительно количества результатов, которые будут возвращены. Если бы я создавал приложение и знал, что мне нужно только когда-либо получить данные, основанные на предварительно определенном запросе c с указанным ключом c, я бы выбрал Cassandra каждый раз.
С помощью Cassandra я также могу настроить согласованность запросов, требуя оперативного подтверждения от большего или меньшего количества реплик. Кроме того, я также могу направить эти операции в конкретный c geographi c регион, в зависимости от местоположения приложения.
... при использовании в сочетании с Elasticsearch?
Они хорошо дополняют друг друга. Кассандра хороша в некоторых вещах (подробно описано выше), которых нет в ElasicSearch (и наоборот ... много говорят). Требования к приложению могут потребовать и поиска и запроса. Иногда у вас есть приложение, которому нужен высокоскоростной поиск ключей «о, и мы также хотим поиск».
Summary, tl; dr;
Итак хотя я и написал здесь немало, основной момент, к которому я еще вернусь, - это выбор правильного инструмента для работы. Когда мне нужно искать , я выберу ElasticSearch. Когда мне понадобится запрос в сценарии с высокой доступностью и географической осведомленностью, я выберу Кассандру. Я все еще вижу, что приложения используют оба (в тандеме), поэтому оба имеют свои достоинства.