Как стать автором
Обновить
392.4
Карма
0
Рейтинг
Andrew Aksyonoff @shodan

Пользователь

  • Подписчики 171
  • Подписки 45

А вот про Sphinx 3.0

Текущая ситуация вкратце — сижу вот в офисе Авито; пилим всякое в этот Сфинкс тут в составе группы лиц; не менее успешно его эксплуатируем; закапывать проект мы ни разу не собираемся; а вовсе даже и наоборот, есть некоторое громадьё технологических планов.

Вышло именно так ровно потому — что сколько-то серьёзный интерес к продолжению проекта проявила в нужный момент исключительно компания Авито, все остальные разговоры происходили практически буквально в стиле «срочно почини нам редкий спорадический баг неизвестной сложности в какой-то древней версии за гигантский бюджет в $200 на круг» или там например «сколько-сколько, целых $800 в мес за поддержку?! Не, это очень дорого для нашей маленькой компании на 1000+ человек» — и это, возможно, даже не самые угарные истории :)))

Поскольку пилим мы не только лишь один Сфинкс, а ещё и всю остальную инфраструктуру местного поиска, а толковых рук удаётся нанять не так много, как хотелось бы — то и получается не так быстро, как в Идеальном Мире хотелось бы. Плюс моё личное время на документацию, публичные релизы итп находится строго по остаточному принципу, увы; а каких-то ещё добровольцев помогать мне этим заниматься на данный момент нашлось отчего-то ровно 0 (ноль). Однако движемся явно вперед, ага. У нас тут вокруг всё интересно, и думаю, будет ещё интереснее :) что рано или поздно найдёт своё отражение и в релизах тоже, конечно.

А вот про Sphinx 3.0

Кто такие эти так называемые «простые смертные» и как их жизнь радикально поменяет наличие исходников, я не знаю.

А переходить, если хочется переходить, очевидно, что уже давно пора на Эластик. Собственно, см. первый же комментарий 4-летней давности :-) Нафига эти полумеры со странными форками сразу некоторым образом леворезьбовых (на данную минуту) проектов, бери текущий индустриальный стандарт.

А вот про Sphinx 3.0

Да меня в целом в текущей ситуации многое «смущает», в том числе и этот момент. Это не самая большая головная боль.

Увы, в моменте по ряду причин сейчас есть необходимость (или даже вообще обязанность) сделать именно вот так, все другие доступные варианты выглядят хуже.

Замечу ещё, что доступ к исходникам там, где можно и нужно, я тоже обеспечиваю и тоже уже сейчас.

А вот про Sphinx 3.0

Да у меня пока ещё нет желания тратить время на онлайн-драму и постить все пикантные и феерические подробности. Глобально-то история довольно банальная: начались разные проблемы, люди довольно некрасиво форкнулись, люди довольно некрасиво ушли, люди продолжают делать странные и некрасивые вещи, чем местами тупо мешают и проекту Сфинкс и лично мне.

Я лично пока таки предпочитаю разработкой Сфинкса заниматься, а не вынесением подобных дрязг в публичное пространство и прочим антипиаром. Надеюсь, уже совсем скоро публично покажу всякое интересное.

При этом погонять 3.0 можно прямо сейчас, нужно написать мне в почту и я выдам билд.

Андрей Карпов считает, что код проекта Manticore качественнее, чем код проекта Sphinx

У нас явно разные понятия «красоты» — это не красивая в моём личном понимании — это скучный и тупой off-by-one классический.

Последнюю именно «красивую» ошибку даже и не вспомню навскидку. Первое и последнее, что моментально приходит в голову — в итоге оказалось вообще не в C++ коде совсем :)

Андрей Карпов считает, что код проекта Manticore качественнее, чем код проекта Sphinx

отсутствие проверок на ошибочные данные было/стало скорее фичёй

Нет, это не совсем так.


Концепция всегда была (и есть) следующая:


  • Если можно "почти бесплатно" не падать на кривом входе, следует не падать.
  • Если это дорого, делаем утилиты для проверок (это и assert, и indextool, и т.д.), но сохраняем производительность.

Причём про "вход" тут речь вообще-то в первую очередь скорее о данных индекса, чем пользовательском вводе. Пользовательскому как раз веры почти (почти) никакой, проверяем его что есть сил, где не забываем. Одно хорошо: что не вебсервер, и редко голым поротом в интернет смотрим, типично хотя бы в VPN.


Заодно замечу, что единственный опубликованный тут "уникальный" пример "ошибки" вообще не про это. Там честное кажущееся разыменование NULL, никак не связано ни с какими оптимизациями. При этом, насколько я помню, фактически словить именно в этой точке NULL как бы невозможно, тк. а) наличие элемента в хеше проверяется ранее в функции, и б) по уставу с хешем в этот момент должен работать только текущий тред, вот ровно эта функция, внезапно стереть оттуда элемент некому. Но все эти предположения могли сломаться за годы мутации кода, конечно, и в идеале лучше подложить соломки, хотя бы и ассертом. Подложу, если этот код вообще останется в живых по итогам :-)

А вот про Sphinx 3.0

Не, эти «люди» форкнулись по решительно другим причинам, настоящая история (в отличие от официальной) совершенно феерическая.

А ряд других людей уже успешно гоняет 3.0 в проде и тестах ;)

Встреча разработчиков про Sphinx, 18 июня (суббота)

Сниппеты в целом с документами до 200 мб должны успешно работать. Ну и для ветки когда-уже-3.0 сделали Solr-style кеш токенов и хранилку документов, штоп умело только заранее проиндексированные документы подсвечивать, зато быстро и без похода в базу. Пишите почту, выдам preview доступ, если интересно.

Встреча разработчиков про Sphinx, 18 июня (суббота)

и хватит ли пиццы!

Devconf 2016: Интервью с разработчиком SphinxSearch

Понятно. Есть пример в misc/suggest/ и собираемся когда-нибудь встроить автоматику в само двигло (начиная с определенного момента данных внутри индекса наконец хватает и это стало возможно).

Встреча разработчиков про Sphinx, 18 июня (суббота)

Ну какой-то shodan написал «ну и я тоже буду присутствовать, участвовать и состоять» — возможно, однофамилец!!!

Devconf 2016: Интервью с разработчиком SphinxSearch

uh, между чем и чем?

А вот про Sphinx 3.0

Мастер это 2.3 версия.

Ветку 3.0 откроем, как только переделку формата доведем хотя бы до альфы.

А вот про Sphinx 3.0

Упс, пропустил комментарий в горке почты.

Нету сроков. Конец в целом видно, конкретную дату не видно :(

А вот про Sphinx 3.0

Увы, разработка двигается вот так — небыстро.

А вот про Sphinx 3.0

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

2. Неожиданно, mysql -h0 -P9306, да.

3. Надо смотреть SHOW META и далее SHOW PLAN, подробности в документации есть.

Elasticsearch — сортируем выдачу руками

Ох. Речь вообще не про то, на чем что «надо» делать. Когнитивный диссонас вызывают математика и прилагательные!

Elasticsearch — сортируем выдачу руками

Реализации поиска в БД и их возможности это отдельный интересный разговор. Там сегодня не так все уже плохо, как ни странно. Но это совершенно нерелевантно. Выбор Эластика как первичного хранилища и вот эти вот вытекающие проблемы и решение — никто ведь не оспаривает (для этого в посте принципе недостаточно данных).

Меня удивляет другое: порядок 10М документов с намеками, что это как бы нечто неподъемное для РСУБД; отклик 1 msec, используемый для прикидок общего времени исполнения (?!!!); вот это все. Математика не сходится!

Elasticsearch — сортируем выдачу руками

Специально не стал раписывать подробнее слово «типа», ждал подобного комментария, и вот он прям сразу :)

Я отлично знаю, что latency может вообще никак быть не связана с bandwidth.

Однако во-первых, автор топика отчего-то использовал для своих расчетов именно эти самые 1 ms.

И во-вторых, что главнее, 1 ms латентности это тоже немало.

Elasticsearch — сортируем выдачу руками

Статья небезынтересная, но блин, вызывает мощнейший когнитивный диссонанс.

С одной стороны «хотите отсортировать выдачу по количеству просмотров документа», с другой «записывать каждый просмотр в 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: поправил опечатки.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность