Чем MongoDB лучше ElasticSearch?

Question

[Алексей Ямщиков]

Поставили задачу развернуть монгу в кластерном режиме. Почитал документацию на оффсайте монги. Поднял 2 ВМ с монгой. Нашёл статью про это всё дело на хабре и ещё эту.
Я не совсем понимаю зачем такие дикие танцы с бубном. У нас получается Конфиги на одном сервере, проксирование запросов на другом сервере, сами данные на третьем сервере.
Я конечно дико извиняюсь, но это полный отстой. После эластика это кажется каким то велосипедом.
Не вдаваясь в холливары объясните пожалуйста в двух словах чем MongoDB круче ElasticSearch.

Пояснение для тех кто не в курсе:
В эластике роль ноды настраивается в файле конфига. ВСЁ. В конфиге выставил, что нужно - 5 строк. Запустил ноду, запустил вторую. Открыл web морду плагина на любой из этих нод. И наблюдаешь как они собрались в кластер и раскидали шарды. (Я настраивал кластер с 4-мя нодами)

В монге нужно подкрутить mongos, нужно настроить сервер конфигураций, нужно запустить шард сервера.... Потом меня убила строчка в документации "Add each shard to the cluster using the sh.addShard() method,"
Чё ПРАВДА - руками добавлять? А где наблюдать работу кластера? В общем я пока не в восторге от монги.

Так что если кто то может высказать своё личное мнение исходящее из опыта управления и использования монги и эластика - с удовольствием выслушаю.

Comments

[un1t]

Подкинь статью как в эластике кластер работает. Количество шардов там автоматически выбирается и создается?

[Алексей Ямщиков]

un1t: нет, там руками задаёшь количество шардов. В конфиге. И количество реплик. Ставь эластик из репы их и конфиг там хорошо документирован - очень сложно не разобраться.
из плагинов сразу ставь kopf и HQ - самые оптимальные на наш взгляд.

[un1t]

Алексей Ямщиков: спасибо, посмотрю.

Answer 1

[Nikolai]

Согласен с un1t и с lega, но есть пара замечаний:
- elasticsearch: fulltext и комплексный поиск по проекциям (модель для чтения). как основное хранилище не очень советую, т.к. убить ноды это 2 случайных клика в веб морде.
- mongodb: основное хранилище (модель для записи), гибкая структура данных, скорость записи.

Посмотрите на mms.mongodb.com - система деплоя, мониторинга и бэкапа mongodb.

Comments

[Алексей Ямщиков]

Спасибо - коротко и ясно. Посмотрю на ММС. Там 8 серверов бесплатно вроде как.

Answer 2

[un1t]

Полнотекстовый поиск сравнивать тут конечно смысла нет.
А вот если мы рассматриваем Монгу и ЭластикСерч как БД, то вставка записей в монгу происходит гораздо быстрее.
И монговский шел гораздо удобнее чем курлом JSON-ы отправлять. Есть еще такая прикольная штука как bulk operations.
Эластик в качестве БД люди используют, но синтаксис для таких целей кажется монструозным.
Еще монга schemaless, в эластике надо указывать mappings.

Comments

[Алексей Ямщиков]

"Еще монга schemaless, в эластике надо указывать mappings."
Боюсь у вас тут заблуждение. mappings указывать далеко не обязательно, насколько я понял из документации. Эластик сам определяет типы. Да и вот (db-engines.com/en/system/Elasticsearch%3BMongoDB) нашёл сравнение, но там тоже shema-free

[un1t]

Алексей Ямщиков: не совсем так, эластиу можно не указывать схему, но он создает ее сам из присланных документов. Если у вас документы совершенно разные, то подозреваю будут проблемы. Есть примеры когда отправка документов может ломаться без схемы в зависимости от порядка отправления, т.к. там происходят неявные преобразования. https://orchestrate.io/blog/2014/09/30/improved-el...

[un1t]

Еще кажется, что в Эластик нельзя засунуть документ, чтобы поля не индексировались. Ведь нам не всегда на все поля нужен индекс.

Answer 3

[lega]

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

Comments

[Алексей Ямщиков]

В эластике при падении одной из нод все шарды распределятся по оставшимся - автоматически. Самая главная проблема - количество реплик шардов. Например у нас было так: 4 ноды. 1 реплика шарда. При падении 2-х нод из 4-х у нас велика вероятность того, что часть шардов окажется только на этих двух упавших нодах. В итоге так и случилось. Увеличили количество реплик и радуемся.

И в эластике всё практически автоматом. Там ничего сугубо серъёзного придумывать не требуется - только конфиг настроить.