Subsettings это ортогональная штука, она может работать как с p2c так и без.
Идея p2c очень проста, у тебя есть некоторый критерий худшести/лучшести. Ты случайно выбираешь два хоста и из них выбираешь тот, у которого критерий лучше (например, меньше коннекшинов или счетчик реквестов меньше или rtt, whatever you want). Есть paper где показывается, что это будет работать хорошо, при этом как ты понимаешь реализация очень легковесная, потому что O(1), а не O(N).
Ну а subsettings нужен просто для очень больших кластеров, да.
Да, это одна из идей. В sorted numeric dv существенная часть работы с тз процессорного времени это декомпрессия. Для часто читаемых данных размен памяти на ядра вроде классический трейдофф, если вы CPU bound.
Возможно, вам больше подходит более строгая модель "каталога", вместо поиска. То есть вы попадаете в каталог с определенными товарами в конкретной категории и потом просто уточняете запрос, пока вам не будет достаточно.
У всех маркетплейсов каталоги + фильтры плюс/минус есть.
Поиск это немного другая штука. Понятие релевантности не так просто оценивается разными людьми, как кажется, на первый взгляд. Безусловно, бывают явные промахи (типа показали стул, а искали тарелку), и с ними идет постоянная борьба.
Для того чтобы учтонить запрос, есть прекрасный инструмент фильтрации. Вы почему-то игнорируете его, при этом написали уже множество комментариев (совершенно не по теме статьи, кстати) о том, что вы считаете всех вокруг дураками, потому что они по вашему, выдают "не те результаты".
То что вы считаете другие модели iphone "левыми вещами" при запросе "iphone 13" с сортировкой по цене, это ваше право, но это не значит, что выше мнение является здесь экспертным или даже может быть обощено каким-то образом на большую группу людей.
Ну вы не передергивайте, да. Это довольно сомнительный прием в дискуссии. Я привел здесь примеры из других поисков, чтобы показать тот факт, что это довольно распрастенная практика. И вовсе не согласен с тем, что она плохая, даже если вы счиаете иначе :-)
Lucene как библиотека все еще очень хороший выбор. Написать свой поисковый движок с ноля возможно, но это примерно 1-2 года для команды из людей, которые уже точно знают что надо делать (уже работали с поиском, разбираются в SoTA поисковых технологиях и так далее).
У нас есть немалая экспертиза в java/JVM, но тогда, не было супер экспертизы в поиске, поэтому для нас Apache Lucene был вполне логичен.
Когда переходили на 20, 21-ой еще не было в GA. Сейчас переходим на 21. Дело в том, что как раз с 20 версии уже нормально заработала panama, которую мы используем (проект ANN поиска упоминается в статье).
Анализаторы у нас примерно также сделаны как в elastic search (и как в любом поисковом движке на базе lucene, да и не только в нем). Есть цепочка фильтров, среди которых замены, нормализация, синонимы, морфология/стемминг, выкидывание стоп слов и так далее. Тут нет какого-то rocket science, просто аккуратная кропотливая работа.
Привет. Примерно год. С этим можно жить, но есть некоторые неудобства, типа:
Сложности при изменении топологии
Ручная очистка pvc
Параллельность раскатки через костыли в виде множества маленьких sts
И так далее.
Но для нас это не является опцией (это необходимость), так как у нас большой индекс и мы очень сильно "сидим" на файловом кеше, поэтому диски нужны не сетевые и привязанные к инстансу.
Две копейки на счет RAFT. А вот твой коврумный протокол, он разве не больше генерируется сообщений чем RAFT в стейбл состоянии? Насколько я помню, когда выборы случились, хертбиты нужны только между лидером и фолловерами.
А у тебя между всеми нодами, если я правильно понял.
Имея RAFT можно также реализовать твой алгоритм. Например поверх ETCD (у которого внутри RAFT), я делал похожий алгоритм выбора лидера. ETCD обеспечивал atomic changes состояния (список нод), в лидером выбиралась нода с меньшам mod_revision. Liveness через leases.
С позиции «ветерана» стартапов:
Так имеет смысл работать только если ты находишься в компании, которая через год-два-три выйдет на IPO и у тебя есть пакет акций. Во остальных случаях, ты просто зря тратишь свое здоровье.
Спасибо, что сделал эту работу, а то люди регулярно этот вопрос задают :-)
Можно еще добавить с каждой новой версией jvm мы полчаем все новые оптимизации, которые есть в compiler/runtime для jvm.
Привет, а допускается ли в одной транзакции вставка или модификация записей более, чем в одном бакете и если да, то на бакетах, которые физически находятся на разных машинах?
Интересно! Получается что вы допускаете работу нескольких инстансов на одной машине. Но в случае винила, как тогда разграничить доступ к дискам? Через виртуализацию (контейнеры)?
Subsettings это ортогональная штука, она может работать как с p2c так и без.
Идея p2c очень проста, у тебя есть некоторый критерий худшести/лучшести. Ты случайно выбираешь два хоста и из них выбираешь тот, у которого критерий лучше (например, меньше коннекшинов или счетчик реквестов меньше или rtt, whatever you want). Есть paper где показывается, что это будет работать хорошо, при этом как ты понимаешь реализация очень легковесная, потому что O(1), а не O(N).
Ну а subsettings нужен просто для очень больших кластеров, да.
Привет. А мы в поиске Озона используем P2C алгоритм балансировки внутри каждого из отдельных кластеров.
И есть развитие идеи P2C: Aperture.
https://www.nginx.com/blog/nginx-power-of-two-choices-load-balancing-algorithm/
Да, это одна из идей. В sorted numeric dv существенная часть работы с тз процессорного времени это декомпрессия. Для часто читаемых данных размен памяти на ядра вроде классический трейдофф, если вы CPU bound.
Наконец-то вопросы вошли по теме!)
Я в цепях ничего не понимаю, но может быть вы покажите (на каком-то сервисе), как должна была бы выглядеть эталонная выдача по этому запросу?
Возможно, вам больше подходит более строгая модель "каталога", вместо поиска. То есть вы попадаете в каталог с определенными товарами в конкретной категории и потом просто уточняете запрос, пока вам не будет достаточно.
У всех маркетплейсов каталоги + фильтры плюс/минус есть.
Поиск это немного другая штука. Понятие релевантности не так просто оценивается разными людьми, как кажется, на первый взгляд. Безусловно, бывают явные промахи (типа показали стул, а искали тарелку), и с ними идет постоянная борьба.
А в говно лучше не наступать ;-)
Для того чтобы учтонить запрос, есть прекрасный инструмент фильтрации. Вы почему-то игнорируете его, при этом написали уже множество комментариев (совершенно не по теме статьи, кстати) о том, что вы считаете всех вокруг дураками, потому что они по вашему, выдают "не те результаты".
То что вы считаете другие модели iphone "левыми вещами" при запросе "iphone 13" с сортировкой по цене, это ваше право, но это не значит, что выше мнение является здесь экспертным или даже может быть обощено каким-то образом на большую группу людей.
Ну вы не передергивайте, да. Это довольно сомнительный прием в дискуссии. Я привел здесь примеры из других поисков, чтобы показать тот факт, что это довольно распрастенная практика. И вовсе не согласен с тем, что она плохая, даже если вы счиаете иначе :-)
У WB точно также.
Если вы зажмете конкретную модель слева, то результат будет именно тот, которвый вам нужен.
Разнообразие и сужение выдачи, это всегде некоторый trade off. Так не только у нас.
Мы даем вам инструмент суждения выдачи через фильтры, если он вам нужен.
Lucene как библиотека все еще очень хороший выбор. Написать свой поисковый движок с ноля возможно, но это примерно 1-2 года для команды из людей, которые уже точно знают что надо делать (уже работали с поиском, разбираются в SoTA поисковых технологиях и так далее).
У нас есть немалая экспертиза в java/JVM, но тогда, не было супер экспертизы в поиске, поэтому для нас Apache Lucene был вполне логичен.
Когда переходили на 20, 21-ой еще не было в GA. Сейчас переходим на 21. Дело в том, что как раз с 20 версии уже нормально заработала panama, которую мы используем (проект ANN поиска упоминается в статье).
Отвечу про анализаторы.
Анализаторы у нас примерно также сделаны как в elastic search (и как в любом поисковом движке на базе lucene, да и не только в нем). Есть цепочка фильтров, среди которых замены, нормализация, синонимы, морфология/стемминг, выкидывание стоп слов и так далее. Тут нет какого-то rocket science, просто аккуратная кропотливая работа.
Привет. Примерно год. С этим можно жить, но есть некоторые неудобства, типа:
Сложности при изменении топологии
Ручная очистка pvc
Параллельность раскатки через костыли в виде множества маленьких sts
И так далее.
Но для нас это не является опцией (это необходимость), так как у нас большой индекс и мы очень сильно "сидим" на файловом кеше, поэтому диски нужны не сетевые и привязанные к инстансу.
Сорри за орф. ошибки, писал с телефона.
Две копейки на счет RAFT. А вот твой коврумный протокол, он разве не больше генерируется сообщений чем RAFT в стейбл состоянии? Насколько я помню, когда выборы случились, хертбиты нужны только между лидером и фолловерами.
А у тебя между всеми нодами, если я правильно понял.
Имея RAFT можно также реализовать твой алгоритм. Например поверх ETCD (у которого внутри RAFT), я делал похожий алгоритм выбора лидера. ETCD обеспечивал atomic changes состояния (список нод), в лидером выбиралась нода с меньшам mod_revision. Liveness через leases.
Так имеет смысл работать только если ты находишься в компании, которая через год-два-три выйдет на IPO и у тебя есть пакет акций. Во остальных случаях, ты просто зря тратишь свое здоровье.
Случаем не утили для spark schema? )
Можно еще добавить с каждой новой версией jvm мы полчаем все новые оптимизации, которые есть в compiler/runtime для jvm.