Комментарии 16
Статья небезынтересная, но блин, вызывает мощнейший когнитивный диссонанс.
С одной стороны «хотите отсортировать выдачу по количеству просмотров документа», с другой «записывать каждый просмотр в Elasticsearch». Эээ, что?! Окей, быстрых обновлений атрибутивки нету, это тоскливо, когда её таки надо обновлять. Но сырые неагрегированные данные-то совать в поиск, которому нужны только подокументные агрегаты — ууух, по-моему, такое не должно возникать даже в формате заведомо нерабочей идеи :)
С одной стороны «десятки миллионов документов», с другой «большие масштабы» и как бы противопоставление реляционным СУБД. Эээ, что?! Извините, но уж 10M веб-документов отлично поместятся что в MySQL, что Postgres на 1 (одном) умеренно толстом сервере. Собственно, даже 100M при среднем размере 5K/документ можно полностью в 512 GB памяти запихать, и всё ещё на одном сервере. Да, конечно, встроенный поиск у них типично будет дрянной, но это другая история. Причем, полагаю, с простенькими выборкам по отдельным ключевикам должен более-менее справиться и он.
С одной стороны «очень быстрое хранилище Redis», с другой 1 ms на запрос, то есть типа 1K rps. Эээ, что?! Даже РСУБД, не говоря уже о специализированных KV хранилках типа memcached, давно пробили 100K rps с одного сервера, а в лабораторных условиях 1M rps. Вот, первый результат в гугле, 400K rps и это 5 лет назад: yoshinorimatsunobu.blogspot.ru/2010/10/using-mysql-as-nosql-story-for.html
В общем, или каких-то важных ключевых чисел про мега-масштабы в статье решительно не хватает, или они, числа, действительно не сходятся.
upd: поправил опечатки.
С одной стороны «хотите отсортировать выдачу по количеству просмотров документа», с другой «записывать каждый просмотр в Elasticsearch». Эээ, что?! Окей, быстрых обновлений атрибутивки нету, это тоскливо, когда её таки надо обновлять. Но сырые неагрегированные данные-то совать в поиск, которому нужны только подокументные агрегаты — ууух, по-моему, такое не должно возникать даже в формате заведомо нерабочей идеи :)
С одной стороны «десятки миллионов документов», с другой «большие масштабы» и как бы противопоставление реляционным СУБД. Эээ, что?! Извините, но уж 10M веб-документов отлично поместятся что в MySQL, что Postgres на 1 (одном) умеренно толстом сервере. Собственно, даже 100M при среднем размере 5K/документ можно полностью в 512 GB памяти запихать, и всё ещё на одном сервере. Да, конечно, встроенный поиск у них типично будет дрянной, но это другая история. Причем, полагаю, с простенькими выборкам по отдельным ключевикам должен более-менее справиться и он.
С одной стороны «очень быстрое хранилище Redis», с другой 1 ms на запрос, то есть типа 1K rps. Эээ, что?! Даже РСУБД, не говоря уже о специализированных KV хранилках типа memcached, давно пробили 100K rps с одного сервера, а в лабораторных условиях 1M rps. Вот, первый результат в гугле, 400K rps и это 5 лет назад: yoshinorimatsunobu.blogspot.ru/2010/10/using-mysql-as-nosql-story-for.html
В общем, или каких-то важных ключевых чисел про мега-масштабы в статье решительно не хватает, или они, числа, действительно не сходятся.
upd: поправил опечатки.
связь между временем ожидания ответа (1ms) и количеством rps (посчитанная как 1к) работает не так, как вы думает
поддерживаю. «100K rps с одного сервера» — redis стоит не на тех же машинах где и ElasticSearch. И плагин custom score работает по одному документу последовательно
Специально не стал раписывать подробнее слово «типа», ждал подобного комментария, и вот он прям сразу :)
Я отлично знаю, что latency может вообще никак быть не связана с bandwidth.
Однако во-первых, автор топика отчего-то использовал для своих расчетов именно эти самые 1 ms.
И во-вторых, что главнее, 1 ms латентности это тоже немало.
Я отлично знаю, что latency может вообще никак быть не связана с bandwidth.
Однако во-первых, автор топика отчего-то использовал для своих расчетов именно эти самые 1 ms.
И во-вторых, что главнее, 1 ms латентности это тоже немало.
Судя по всему вам не хватает понимания, что elastic изначально был заточен под full text search и все с этим связанное. А любая реляционная бд этого либо не поддерживает, либо работает все через одно место.
да, речь идет именно о этом. Чтобы делать описанные вещи надо чтобы поисковый функционал лежал в основе приложения, а не наоборот — притянули за уши ElasticSearch потому что модно
Реализации поиска в БД и их возможности это отдельный интересный разговор. Там сегодня не так все уже плохо, как ни странно. Но это совершенно нерелевантно. Выбор Эластика как первичного хранилища и вот эти вот вытекающие проблемы и решение — никто ведь не оспаривает (для этого в посте принципе недостаточно данных).
Меня удивляет другое: порядок 10М документов с намеками, что это как бы нечто неподъемное для РСУБД; отклик 1 msec, используемый для прикидок общего времени исполнения (?!!!); вот это все. Математика не сходится!
Меня удивляет другое: порядок 10М документов с намеками, что это как бы нечто неподъемное для РСУБД; отклик 1 msec, используемый для прикидок общего времени исполнения (?!!!); вот это все. Математика не сходится!
не надо делать HabraHabr на ElasticSearch. Речь идет именно о задачах когда поиск лежит в основе функционала. Примеров когда врезаться в стандартную формулу подсчета _score множество. И все эти примеры делятся на 2 категории:
смотря какие задачи. Аггергационный фреймоврк позволяет например такой подход — писать буквально каждый пук в ES (просмотры, голосования, все отдельными записями), потом быстро считать суммы. Но опять же «быстро» будет относительно.
- вы в начале запроса получаете данные и используете их для изменения _score документов, например вывести вверху список товаров просмотренных пользователем и совпадающих с поисковым запросом (быстро и просто)
- для каждого документа надо подтянуть какие-то внешние данные которые хранить в ES нельзя. Речь не только о просмотрах или голосованиях. Представьте вы AliExpress и хотите немного менять поисковую выдачу для разных регионов. Например, вы знаете что по запросу «Сапоги» в Москве покупают сапоги для стриптиза, а в Барнауле резиновые )
Но сырые неагрегированные данные-то совать в поиск, которому нужны только подокументные агрегаты — ууух, по-моему, такое не должно возникать даже в формате заведомо нерабочей идеи :)
смотря какие задачи. Аггергационный фреймоврк позволяет например такой подход — писать буквально каждый пук в ES (просмотры, голосования, все отдельными записями), потом быстро считать суммы. Но опять же «быстро» будет относительно.
Есть ощущение что задачу теоретически можно также решить через DocValues
shaierera.blogspot.com/2014/04/updatable-docvalues-under-hood.html
shaierera.blogspot.com/2014/04/updatable-docvalues-under-hood.html
Гугление показало что в Solr кто-то решал
github.com/safarijv/ifpress-solr-plugin/blob/master/src/main/java/com/ifactory/press/db/solr/processor/UpdateDocValuesProcessor.java
github.com/safarijv/ifpress-solr-plugin/blob/master/src/main/java/com/ifactory/press/db/solr/processor/UpdateDocValuesProcessor.java
А эта, как же Tarantool ?)
У меня был похожий кейс на одном из проектов. Требовалось сохранить 10+ миллиардов туристических предложений. В качестве основного хранилища был выбран Solr. Почему именно он — вопрос второй. Суть в том, что помимо сохранения информации, нужно было вести историю изменения цен (редкие апдейты) и актуализировать наличие авиарейсов по каждому из миллиардов предложений в момент запроса для фильтрации и аналитики.
В итоге, апдейты цен с историей делались через самописанный модуль к Solr. Операция была тяжёлая из-за append-only архитектуры, но требования позволяли. Актуализация авиарейсов — это был крайне интересный хардкор. Рейсы хранились в кластере Redis. Информация по наличию мест и их количеству обновлялась практически в реалтайме. Чтобы это всё жило, я запилил несколько кастомных типов данных, которые использовались в схеме и просчитывались в реалтайме. При старте нод Solr делался прогрев внутреннего кеша инфой из Редиса. Памяти было много, можно было себе позволить.
Особый треш был в том, что всё это должно было работать на 100 шардах помноженных на коэффициент репликации. Плюс круглосуточный входной поток данных.
В итоге, апдейты цен с историей делались через самописанный модуль к Solr. Операция была тяжёлая из-за append-only архитектуры, но требования позволяли. Актуализация авиарейсов — это был крайне интересный хардкор. Рейсы хранились в кластере Redis. Информация по наличию мест и их количеству обновлялась практически в реалтайме. Чтобы это всё жило, я запилил несколько кастомных типов данных, которые использовались в схеме и просчитывались в реалтайме. При старте нод Solr делался прогрев внутреннего кеша инфой из Редиса. Памяти было много, можно было себе позволить.
Особый треш был в том, что всё это должно было работать на 100 шардах помноженных на коэффициент репликации. Плюс круглосуточный входной поток данных.
Однако есть довольно сложные техники, когда можно считать score батчами, и делать запрос в redis не на каждый документ, а формируя пакеты, например, по 1000 документов.
Какие?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Elasticsearch — сортируем выдачу руками