Spark-Cassandra против Spark-Elasticsearch

Я использую Elasticsearch уже довольно давно и у меня мало опыта использования Cassandra.

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

Что касается коннектора, у Cassandra и Elasticsearch теперь есть хороший коннектор для загрузки данных, так что это не будет решающим фактором.

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

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

Спасибо


apache-spark spark-cassandra-connector cassandra-2.0 elasticsearch elasticsearch-hadoop
person Adetiloye Philip Kehinde    schedule 28.08.2015    source источник
comment
В чем вопрос?   -  person eliasah    schedule 29.08.2015
comment
Да, это зависит от рабочей нагрузки по извлечению данных. Cassandra очень хороша для извлечения частичных данных по ключу, из spark вы можете сбросить фильтры только по первичному и кластерному ключу, в противном случае это не так хорошо для полного сканирования таблицы ( select * from table ). Подробно опишите нам свой вариант использования, потому что и cassandra, и elasticsearch — очень вертикальные СУБД.   -  person axlpado - Agile Lab    schedule 31.08.2015
comment
Мой вариант использования довольно прост, мне нужно каждый день создавать отчеты для разных пользователей (1 миллион+) с помощью Spark. Прямо сейчас мне нужно загрузить все мои пользовательские данные из Cassandra или Elasticsearch в Spark, и нет смысла запускать и Cassandra, и Elasticsearch.   -  person Adetiloye Philip Kehinde    schedule 31.08.2015

Ответы (2)


arrow_upward
3
arrow_downward

Короткий точный ответ: «это зависит», в основном от размеров кластера =)

Я бы не стал выбирать Elastisearch в качестве основного источника данных, потому что он хорош для поиска. Поиск — это очень специфическая задача, и она требует очень специфического подхода, который в этом случае использует инвертированный индекс для хранения фактических данных. Каждое поле в основном входит в отдельный индекс, поэтому индексы очень компактны. Хотя можно хранить в индексе полные объекты, такой индекс вряд ли получит какую-либо выгоду от сжатия. Это требует гораздо больше места на диске для хранения индексов и гораздо больше тактов процессора, вращающихся дисков для их обработки.

Cassandra, с другой стороны, довольно хорошо умеет хранить и извлекать данные.

Без каких-либо более или менее конкретных требований я бы сказал, что Cassandra хороша в качестве основного хранилища (и предоставляет довольно простые сценарии поиска), а ES хороша в поиске.

person evgenii    schedule 28.08.2015

arrow_upward
2
arrow_downward

Я опровергну ответ Евгения о том, что ES хорош только в поиске. YES ES превышает текстовый поиск, но это не означает, что он не может выполнять данные.

На самом деле вы можете относиться к нему так, как если бы это была документация в стиле «Монго», и запускать «фильтрующие» запросы к ней, чтобы получить быстрые результаты выборки. ОДНАКО теперь возникает вопрос: насколько быстро вам нужно чтение/запись и нужны ли вам какие-либо дистрибутивы? Чего не хватает ES, так это распространения. Да, ES может выполнять сегментирование, но у него есть проблемы с распределением по нескольким регионам и надежностью репликации ваших данных.

Если вам нужна гибкость/надежность ваших данных, я бы обратился к Cassanda. Кроме того, поскольку вы имеете дело с туберкулезом, Cassandra тоже может стать победителем, потому что она приспособлена для экстремальной громкости.

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

person azngunit81    schedule 30.07.2016