Comments 36
В ES нет натуральной сортировки. Доберетесь до нее — вот плагин для форка. Будете админить кластер(ы) — вот кроссплатформенный десктопный клиент.
Разговор идёт о всего-то 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 Гб ОЗУ все это работает в режиме «еле ворочается» — секунда на запрос. А если учесть насколько 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. Мы разобрались теперь.
Ну незнай, ваше время на
По факту — какие то возможности лучше реализованы «из коробки» в ластике, для этих же фич к Постгресу необходимо ляпать жуткие костыли например партиционирование и федеративные запросы, с другой стороны некоторые банальнейшие задачи для Постгреса типа «проапдейтить поле по уникальному значению doc_id» — это костыли для ластика.
Как правило если у вас возникает выбор между Реляционный PostgreSQL или нереляционный FTS Elastic — вывод — как таковая транзакционность, нормализация и другие плюшки Postgres вам не нужны, а надо вам масштабирование, гибкая документоориентированная модель и полнотекстовый поиск.
А то что вы не можете склониться в сторону Ластика — значит что масштабы у вас так себе и пока еще справляется вертикальная модель, что документы ваши не настолько гибкие и структура понятна, а полнотекстовый поиск довольно ограничен. В итоге вы можете сделать как реализацию на постгресе так и на ластике, при этом в обоих случаях придется писать костыли.
и намного больше углубился в изучение родных возможностей 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).
Но для задачи:
Лучше подошел бы куда как более легковесный и куда как более шустрый SphinxSearch.
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 ни разу не правильно.
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 это какая-то лютая наркомания. К тому же контроллеры становились абсолютно нечитаемыми, смотрите сами:
На своем проекте мы создавали репозитории + классы для каждого запроса и не было проблем с массивами для запросов.
ну и как то странно хранить запросы в контроллерах, все таки это не обязанность контроллера заниматься поиском в эластике.
Sign up to leave a comment.
Неполнотекстовый поиск: специфичные возможности Elasticsearch для сложных задач