Pull to refresh

Comments 36

Спасибо, буду иметь в виду. А есть киллер-фичи по сравнению с кибаной?
Kibana это несколько иное, как по способу установки, так и по паттернам использования. Мы используем и то и другое для разных задач.
Разговор идёт о всего-то 50к документов, а у вас навёрнуто столько… Толи и у вас индексов нет, толи вместо сервера raspberry pi. Тот же postgre, при самой простой настройке и грамотных запросах выдавал бы результаты за сотню миллисекунд, со встроенным полнотекстовым поиском. а написание обвязки на php без ларавела(можно было бы люмен взять или на симфони сделать микросервис) сэкономило бы ещё 150 миллисекунд. Короче, странно все это
Да и вообще, 300мс — я бы категорически не назвал высокой скоростью, а уж для простенького джойника по 50к «быстро» вообще должно быть где-то в диапазоне 5-15мс…
толи вместо сервера raspberry pi

Ты почти нас раскусил. Просто сейчас работаем «на минималках», скоро заказчик будет растить сервера, тогда и нагрузка подрастет, и результаты чуть адекватнее будут. А обвязку из-под фреймворка не стали выносить по ряд других причин.
я, возможно, повторюсь, но 50 тыс записей это семечки для эластика. На нормальной машине он способен выдавать и более объемные данные. Тем более структура у вас не то, чтобы сложная. К примеру частный случай использование эластика — хранение логов. Текстовой поиск по достаточно большому объему логов (около 2 Тб) занимает не так уж и много времени, учитывая, что мы используем кибану и по факту никто и никогда ничего не замерял(У нас редко когда вылазит ошибка кибаны о том, что реквест отвалился по таймауту в 300 ms).
50к это была своего рода вводная для проекта. Ждем когда набьется база, до 1-2 млн, там уже будет критично
50к это была своего рода вводная для проекта. Ждем когда набьется база, до 1-2 млн, там уже будет критично


Для современного железа и современного софта — это те же семечки.
При грамотном использовании этого софта.

Если бы речь шла о 1-2 миллиарда, а не миллиона — другой вопрос.
А миллионы — только звучит страшно…
я вас поправлю: на нормальном сервере не очень сложные запросы эластик нормально отрабатывает и на 25 террабайтах на сервер.

можно пойти и дальше) 25 Тб не предел. Я просто привел пример по логам. Очевидно, что Эластик используется и с большим объемом данных
Практически, это предел даже для логов. В ластике by-design есть требование — открытый индекс держит в памяти минимум 0,2% от объема индекса на диске. Причем это тот минимум когда отключены все фичи. Реально на практике меньше 0,5% я не видал.
Это приводит к тому что для 25ТБ индексов надо иметь ОЗУ 125 гиг только чтобы открыть эти индексы. Итого на серваке с 256 Гб ОЗУ все это работает в режиме «еле ворочается» — секунда на запрос. А если учесть насколько JAVA плохо работает с объемом HEAP за 32 гига, то приходиться изгаляться с кучей экземпляров…
И повторюсь, это для достаточно простых операций.

Выгружать/загружать индексы по требованию — тоже не решение: в момент загрузки индекса — кластер краснеет.

Я предлагал для elastic решение по «заморозке» индекса и их прозрачной загрузке выгрузке, но команда его разработки отказалась сказав «вам просто надо больше нод/памяти».
Это приводит к тому что для 25ТБ индексов надо иметь ОЗУ 125 гиг только чтобы открыть эти индексы. Итого на серваке с 256 Гб ОЗУ все это работает в режиме «еле ворочается» — секунда на запрос.


Ребята на конференции Highload утверждают, что как раз таки наоборот.
youtu.be/y5OJSIC5yE8

У них действительно была проблема с тем, что одиночный сервер должен быть очень жирным. В их случае — нереально жирным.

Но! Эта проблема была на Sphinx, который не поддерживает кластеризацию.

И они перешли на Elastic как раз именно потому, чтобы избавиться от ограничения огромных аппаратных требований на 1 машину. И размазать свою задачу по кластеру.

Да, они потеряли в производительности (ибо Sphinx быстрее). Это было осознано, так как они получили возможность масштабироваться и расти дальше.
Ребята на Хайлоад не нюхали жизни… Я как раз сейчас говорю про уже размазанную задачу. Я говорю про эээ метакластер на базе elasticsearch на 200+ серверов общим размеров 5 ПЕТАбайт. И кластер на 200 серверов рулится очень плохо, и я бы предпочел чтобы там было только 100 а лучше 50 серверов. Причем из этих 5 ПБ «горячими» являются только 50 ТБ… Т.е. для нормально работы по горячим данным мне хватило бы 500 Гиг ОЗУ на весь кластер, а приходится набивать 25 террабайт озу… только чтобы открыть эти индексы которые не нужны…
Ребята на Хайлоад не нюхали жизни…


Это вы про ivi-то? Ну-ну.

Я говорю про эээ метакластер на базе elasticsearch на 200+ серверов общим размеров 5 ПЕТАбайт.


Вот тут немножко не понял. Вы же раньше писали про другой порядок чисел? Вот же ваши слова:

Это приводит к тому что для 25ТБ индексов надо иметь ОЗУ 125 гиг только чтобы открыть эти индексы.


То ли я чего то не понял?

Ну а то, что при работе с 5 ПЕТАбайтами разработчик системы будет не простой пользователь/потребитель готовой СУБД, а было бы неплохо чтобы и разбирался досканально и проектировали архитектуру под задачу — совершенно естественно, имхо.
Это вы про ivi-то? Ну-ну.

Угу именно про ivi. Не спорю — ребята прошареные, только хайлоад бывает сильно по разному хай.

Вы же раньше писали про другой порядок чисел?

25ТБ индекса имелось в виду именно в пересчете на 1 сервер хранения конечно. Т.е. 25ТБ/сервер именно, из за того что Ластик довольно таки неплохо масштабируется. И именно потому что хайлоад. Смысл писать «у нас хайлоад, у нас миллион пользователей в сутки»? Вы пишите, а сколько при этом у вас железа. А то миллион пользователей в сутки на 1 сервер и на 100 серверов — абсолютно разные вещи даже по спектру возникающих задач, проблем и путей их решения.

Ну а то, что при работе с 5 ПЕТАбайтами разработчик системы будет не простой пользователь/потребитель готовой СУБД, а было бы неплохо чтобы и разбирался досканально и проектировали архитектуру под задачу — совершенно естественно, имхо.


На самом деле любая задача которая претендует на хайлоад уже требует «досконально разобраться». Решения «из коробки» типа elastic или postgres годны только так попробовать понюхать… И для более менее серьезного использования требуют анализа и допиливания в лучшем случае конфигов.

Говоря про 25 ТБ/сервер для эластика -я немного лукавлю. Порог был 5-10ТБ/сервер после которого я решил что проще будет «допилить» эластик…
но 10-25ТБ порог «а давайте рискнем с допиленным ластиком» не превзошел «давайте добавим оперативы».
И следующим порогом >25 ТБ/сервер стало — давайте уже напишем собственную «СУБД».
5 лет я был фанатом Elasticsearch и использовал его во всех проектах (и иногда совершенно невероятным образом). В текущем тоже начал использовать для suggest search, и снова начались грабли с синхронизацией данных базы и кластеров elastic + никуда не деть тот момент, что elastic это внешний сервис, и к нему нужно обратится, получить результат, а потом уже обратится к базе. В итоге я убрал elastic из текущего проекта полностью, переписав поиск на PosgreSQL + ts_vectors. В нужных моделях создал триггеры на уровне БД которые создают вектора, и по ним произвожу поиск. По бенчмаркам я выиграл в скорости в 4ре раза, а код стал проще и надежнее. Ну и не нужно платить за elastic! Может конечно это все зависит от объема БД, и когда нибудь производительность с elastic победит — но во-первых, не факт что БД этого проекта когда нибудь достигнет таких объемов, во-вторых — вернуть на проект его всегда можно (и довольно быстро). Короче говоря — я стал более аккуратно использовать elastic, и намного больше углубился в изучение родных возможностей Postgre.
О, интересно. Спасибо, буду иметь эту возможность в виду.
Вообще-то elasticsearch бесплатен. А так, наличие 2 БД это всегда архитектурная проблема, Эластик тут не при чем. Мы вот сделали наоборот 5 лет назад и весьма успешно для наших кейсов.
Он условно бесплатен. Функционал x-pack не бесплатен. Поддержание серверов не бесплатно. В production особенно. На одном проекте пользуемся их клаудом found.elastic.co и поверьте, он уж вообще совсем не бесплатен. И даже при этом мы через год встретились с переполнением памяти и отказами в запросах, что подняло цену еще в два раза…
Кластер, построенный на elasticsearch был и есть бесплатен. То что Вы докупили сервисов и поддержки, не делает ПО платным. Более того, elasticsearch еще и open source. Можете сами компилить и сервер, и плагины к нему.
Конечно могу. Но мое время, или время человека который все будет настраивать, также не бесплатно. Говоря о что то не нужно платить за elastic, я имел ввиду все в комплексе.
Вы ввели читателей в заблуждение, что нужно платить за elastic. Мы разобрались теперь.
Ну незнай, ваше время на
и намного больше углубился в изучение родных возможностей Postgre.
тоже не бесплатно.

По факту — какие то возможности лучше реализованы «из коробки» в ластике, для этих же фич к Постгресу необходимо ляпать жуткие костыли например партиционирование и федеративные запросы, с другой стороны некоторые банальнейшие задачи для Постгреса типа «проапдейтить поле по уникальному значению doc_id» — это костыли для ластика.

Как правило если у вас возникает выбор между Реляционный PostgreSQL или нереляционный FTS Elastic — вывод — как таковая транзакционность, нормализация и другие плюшки Postgres вам не нужны, а надо вам масштабирование, гибкая документоориентированная модель и полнотекстовый поиск.
А то что вы не можете склониться в сторону Ластика — значит что масштабы у вас так себе и пока еще справляется вертикальная модель, что документы ваши не настолько гибкие и структура понятна, а полнотекстовый поиск довольно ограничен. В итоге вы можете сделать как реализацию на постгресе так и на ластике, при этом в обоих случаях придется писать костыли.
Но мое время, или время человека который все будет настраивать, также не бесплатно. Говоря о что то не нужно платить за elastic, я имел ввиду все в комплексе.


Тогда вашу фразу можно отнести к вообще любому ПО.
Она попросту вводит в заблуждение.

Но мое время, или время человека который все будет настраивать, также не бесплатно.


А Postgres будет сам доплачивать за то, что с ним разбираются?
Все таки elastic бесплатен, а с недавних пор и некоторая часть x-pack по-тихоньку открывается
Каждый создатель велосипеда хвалит свой велосипед, но, когда доходит дело до расширения, внезапно обнаруживается, что документации по велосипеду нет, а его автор уволился. И тогда новый специалист принимает решение выкинуть и написать все на известной технологии, по которой есть и документация и на рынке специалистов потом найти легко.
Пишите статью, было бы интересно увидеть ваше решение.
Ну я бы не назвал это велосипедом. Это вполне себе задокументированный функционал (https://postgrespro.ru/docs/postgrespro/9.5/datatype-textsearch www.postgresql.org/docs/9.6/static/datatype-textsearch.html). Просто порог вхождения (для меня) был немного выше. В свое время для меня было гораздо проще настроить elastisearch чем ковырять SQL. Сейчас разобравшись я понимаю, что написание многоуровневых json запросов в elastic (по сложным много параметровым выборкам) было на самом то деле сложнее чем реализация на PostgreSQL. Я не говорю что elastic это плохо. Это хорошо и круто. Но не всегда нужно.
На самом деле термвектора в постгрессе это «недоэластик» и по сути весь FTS завязанный на обработке этих векторов приходиться писать самостоятельно… Те же токенизаторы, анализаторы. Да и алгоритмы выбора и ранжирования документов тоже… Но с другой это имеет право на жизнь если вам ничего кроме элементарного поиска не нужно, и гораздо более важна например задача целостности данных, или возможность апдейтов.
Так и есть. Я ведь и не призываю отказываться от elastic. Я просто привожу пример того, что иногда он не нужен. К сожалению, мой недостаток знаний в свое время привел к тому, что elastic я пихал везде, пока это не вылезло мне боком именно с целостностью данных. Если бы знал о альтернативах — я сэкономил бы много времени. В принципе это и был главный посыл моего комментария.
И да.Есть один проект на Ruby с частыми выборками из Elastic и он просто катасрофичен по затратам памяти. В продакшн съедает 1 Гб, и просит еще. Тот же функционал на Postgres снизил потребление до 256 Мб. А триггерный функционал на ресурсы базы SQL если и повлиял, то незаметно.
Все отлично и спасибо за статью.

P.S.:
Деготь такой:

Для подобной задачи ElasticSearch — избыточен.

1) Elastic написан на Java. Что вызывает некоторую, гм… требовательность к оперативной памяти.

2) В Elastic отлично реализована работа в кластере на множестве серверов. Завел кластер Elastic — и дальше индекс как-то там сам внутри распределяется и устойчиво работает.

Так вот — п. 2) нужен для серьезнейших и нагруженнейших решений. И благодаря великолепной работе в кластере Elastic'у можно простить п. 1).

Но для задачи:

Создать поиск на Elacsticsearch по базе из 50 000 документов минимум.
Обеспечить высокую скорость ответа на запросы – менее 300 мс.


Лучше подошел бы куда как более легковесный и куда как более шустрый SphinxSearch.
На самом деле странный выбор в пользу Ластика вместо постгресса.

30 тысяч записей для постгресса это не много, впрочем как и для ластика. Но при этом Слон предсказуем и по скорости и по расходу памяти.
Собственно сами когда-то делали выбор:
+ Постгрес предсказуем по расходу ОЗУ, который не зависит от объема БД.
— Ластик — тоже предсказуем — вынь да положь ему от 0,2 — 0,5% от объема индекса на диске даже если выключить все фичи причем это «work as designed» github.com/elastic/elasticsearch/issues/10869 в нашем случае это приводит к пределу 25 ТБ индекса на сервер из которых 24 ТБ — «холодные».
+ Ластик хорошо масштабируется ( раньше я сказал бы что шикарно, но сейчас только хорошо) 5-7 нод — смело. 20-40 нод с осторожностью… Больше 40 только если у вас мало индексов или они редко создаются — уничтожаются. Ибо синхронизация метаинформации между кандидатами в мастера для большого числа индексов (а точнее шардов) может занимать существенное время.
— Постгрес масштабируется от слова никак. Т.е. там есть механизмы master-slave чутка ущербный by-design но работает. Механизм multimaster находится в зачаточном состоянии (я про версию 9 говорю), но с помощью костылей и палок получается заставить работать кластер из 3 узлов в режиме мультимастера… но это хардкор.
+ Постгрес — это хорошая, взрослая, реляционная СУБД MVCC-типа. С транзакциями!
— Ластик в таком режиме — NoSQL система eventualy consistensy, если вам нужен «не точный поиск то оно вам самое то» а вот если вам понадобился поиск точный, да еще и например с сортировкой, да еще и с повторяющимися вариантами — подумайте дважды. Сделать можно, но местами ни разу не тривиально.

Ну и прочее, прочее прочее…
Мое мнение отталкиваться от производительности при выборе elastic/postgre ни разу не правильно.
И еще мы на тот момент поняли, что строить гигантские запросы в виде ассоциативных массивов на PHP это какая-то лютая наркомания. К тому же контроллеры становились абсолютно нечитаемыми, смотрите сами:


На своем проекте мы создавали репозитории + классы для каждого запроса и не было проблем с массивами для запросов.

ну и как то странно хранить запросы в контроллерах, все таки это не обязанность контроллера заниматься поиском в эластике.
Мы в самом начале не совсем понимали как это можно разрулить. Поэтому получался всякий разный костылесипед. Сейчас это уже утряслось.
Only those users with full accounts are able to leave comments. Log in, please.