Комментарии 21
Выглядит очень круто! А какая производительность у текущей реализации?
Если собирать в нативную архитектуру, то перф Summa бьется с графиками Tantivy Game: в два раза быстрее Lucene 8.10
Lucene 9 слегка быстрее предшественника, но общая картина не меняется.
Я делал еще подход и пытался провести сравнение с ES, но у меня экспертизы в ES немного. Скорость как индексации, так и поиска отличались на порядок. С одной стороны, я мог упустить нюансы в настройке ES, но вообще бывшие коллеги работали с ES и тоже видели, что он нереально медленный даже в сравнении с Lucene. Заготовки бенчмарка лежат тут, когда-нибудь я его допилю.
Бенчмаркать Summa, собраный для Wasm я не стал, так как сравнивать не с чем. Я не знаю больше поисковых индексов, которые можно собрать в эту архитектуру. Но перф полностью устраивает, 99% времени работы - это ожидание сети, быстрее для однопользовательской системы и не надо.
За счёт чего Tantivy в два раза обгоняет Lucene?
Могу предположить, что за счёт языка реализации. Lucene написан на Java, Tantivy — на Rust.
Короткий и провокационный ответ: Rust быстрее :)
Чуть больше можно узнать тут
В итерирование по постинг-листам в Tantivy вложено много усилий, а LLVM выдаёт код, в котором оптимизатор проделывает крутую работу по развертыванию циклов и удалению граничных проверок
Возможно JVM не дотягивает в этом месте, но круто если бы вы в О3 могли бы посмотреть на байт-код после прохода всех оптимизаторов в коде DocSet.seek и сказать так это или нет
Удивительно! В статье есть слово "децентрализованный", но нет слова "блокчейн"! Это в наше-то время, когда без блокчейна и яичницу не пожарить!
Редкий сейчас случай когда статья соответствует заголовку. К сожалению, не совсем моя тема и не могу оценить по достоинству, но выглядит интересно.
Человеческое спасибо за поднятую тему и предложения.
Я далёк от технической части, но как пользователь обеспокоен отсутствием децентрализованного веб-поисковика. Долгое время наблюдал за проектом YaCy. Пробежал глазами по тексту и не нашел обсуждения проблем, которые встали перед тем проектом.
Одна и, пожалуй, главнейшая проблема — ранжирование результатов. В YaCy ранжирования нет принципиально, что делает поиск непрактичным для обывателя. Как обстоят дела в предлагаемой системе? Пользователю нужно будет самому писать выражения на упомянутом в статье языке fasteval2?
Другая проблема — фильтрация контента. Не всё то, что у кого-то есть в индексе, должно попадать в выдачу другого пользователя. В противном случае злоумышленник будет способен прямыми руками и рандомайзером положить всю сеть целиком, забив её спамом и дизъинформацией. Иными словами, нужен механизм валидации, причём распределённый, то есть в общем случае у каждого пользователя своя политика фильтрации того, что попадает в его индекс ещё до того, как он что-то начинает искать.
Как подобные проблемы решаются в предлагаемой системе?
P.S. https://izihawa.github.io не существует — 404.
Не знаю что за ранжирование в YaCy, наверное все-таки какое-то есть. В библиотеке aiosumma (питонячий клиент для Summa) есть несколько классов и методов для расширения запросов, что сильно улучшает качество выдачи. Проблема в том, что это Python и я не хотел бы пихать в браузер и его тоже. Но в ближайших планах переписывание части методов из aiosumma на Rust, после чего они станут доступны внутри поискового движка. Поэтому ранжирование более качественное, чем BM25, будет.
На fasteval2 можно более тонко тюнить формулу ранжирования. Например, можно прикрутить пенальти для старых документов или добавить всякие пейджранки и все что вы насчитали у себя и сохранили в индекс. Это можно делать уже сейчас.
Общий концептуальный минус такого поисковика в том, что обратную связь от пользователя тут не получится использовать для тюнинга выдачи других пользователей, поэтому также круто, как в Гугле, сделать не получится. Но для качественной выдачи все возможности будут.
С фильтрацией немного мимо, в первую очередь эта архитектура для того, чтобы один агент создавал индекс, размазывая его по всей сети и делая неблокируемым. В такой постановке проблемы фильтрации нет, это ответственность одного агента (СМИ, поисковой системы, библиотеки - смотря кто будет пользоваться) и вы доверяете его авторитету.
P.S. Ссылку поправил, спасибо!
Не знаю что за ранжирование в YaCy, наверное все-таки какое-то есть.
Разрабы занимали принципиальную позицию, что пользователь может контролировать состав выдачи, но не порядок. В какой-то момент официальный ответ был таков: порядок определяется тем, кто из узлов сети ответит раньше.
один агент создавал индекс [...] ответственность одного агента и вы доверяете его авторитету.
Этот момент мне не до конца понятен. Допустим, в сети есть несколько агентов. Я становлюсь участником сети и хочу 1) уметь формировать выдачу на основе только тех агентов, которым я доверяю и 2) пополнять индекс своими данными, выступая в качестве агента по отношению к другим.
Как это делается? Что происходит, когда один из агентов оказывается скомпроментированным?
Или я постановку задачи неправильно понял? Потому что я исхожу из того, что искомый объект, будь то видео, картинка или даже текст, должны быть размечены (что видео по ООП, картинка с котиками) и только после этого добавлены в индекс, притом правильность разметки на совести агента. Ваш же ответ, как мне показалось, предполагает, что есть только один агент, с которым мы целевым образом взаимодействуем как с источником интересующих нас данных.
Во-первых, важно различать поиск и индексацию, это две разных задачи. Статья - о поиске, а индексация в таком поисковике может быть классической или какой-то иной, она за рамками статьи.
Второе, попробую ответить на ваш изначальный вопрос развернуто.
Сложные системы конструируются из более простых примитивов. Даже поисковик из моей статьи невозможно было сделать, если бы не существовало IPFS и WASM. Технологии оказались зрелыми, поэтому получилось на их основе построить более сложную систему - поисковик, для поиска в котором не требуется центральный сервер.
Вы задаете вопрос о системе еще более высокого порядка - поиске в группе поисковых систем, среди которых могут быть злонамеренные. Такую систему можно сконструировать из поисковиков Summa, но здесь не описано как это сделать.
Например, в libp2p есть примитивы для создания улея серверов (Swarm в оригинале, не уверен что так переводится). Поисковые системы разных агентов можно соединить в такой улей, подключать пользователя к улью и получать от каждого агента его поисковую базу, после чего выполнять поиск в каждой базе. Тогда самое простое решение фильтрации, какое мне приходит в голову - использовать ваш поведенческий фидбек и пенализировать базы, которые вы задизлайкали или пометили как ненадежные. Можно и дальше развить эту идею, например, публиковать фидбек для доступа других пользователей. Но я дальше уже боюсь предлагать что-то без тщательного обдумывания, потому что плаваю в механизмах консенсуса в общем, и в том, что libp2p предлагает в частности.
Много технических деталей и мало архитектурных. Ну и совсем нет понимания социальных проблем - как они будут решаться? А социальные проблемы - это главное. Именно они побуждают нас думать о децентрализации. Но стоит начать пилить, как сразу технические детали полностью захватывают. В эту ловушку попал и автор.
Коротко - имеем стороннюю распределённую файловую систему, в которую софт автора складывает некий индекс. Далее встают вопросы о доступе к этому индексу. Это взгляд с высоты.
Детали же требуют пояснения по каждому этапу обработки данных. Начинается всё с обхода сайтов. Кто это делает, как распределяется нагрузка, куда всё складывается, как складывается с точки зрения возможности искажений и надёжности хранения? Кто может вмешаться в процесс обхода сайтов? Кто может вмешаться в обработку данных с сайтов? Кто может вмешаться в сохранение? Кто может что-то менять после сохранения? Ну и кто разрабатывает алгоритмы индексации? Какие приоритеты он может задать, чем исказить выдачу? Это мы лишь начали копать первый этап - сбор информации. Потом будет потребление, когда опять по ходу процесса появится много вопросов из серии "кто?".
Все эти "кто" напоминают нам о первичности общества, а не техники. В существующем обществе нужно ответить на все вопросы про "кто", и ответить так, что бы гарантировать качество получаемой потребителями информации. Но как мы знаем, качество не бывает бесплатным. То есть нужно ещё ответить на вопрос - кто за это всё заплатит?
Желание начать двигаться в эту сторону правильное, хотя нужно понимать, что оно лишь фиксирует факт - мы не способны повлиять на тех, от кого собираемся прятаться. Поэтому сидим и думаем, как спрятаться получше, отвечая на вопросы про "кто". Стратегически это поражение. Рано или поздно уход в глухую оборону ведёт к проигрышу. Всегда.
Поэтому нужно думать о новом обществе. Только так можно на качественном уровне избавиться от вопроса "кто". Только так.
Автор, как далеки вы от вопросов об обществе?
Хорошая техническая статья должна обозначать конкретную проблему и решать ее. Предмет этой статьи обозначен во втором абзаце, в нем нет ни слова об индексации, обходе сайтов и прочем.
Поисковые системы - это не только обход сайтов и окошечко для ввода текста в Goolge, а в первую очередь инструмент для миллионов различных повседневных задач, от поиска в маркетплейсах и новостных сайтах до поиска раздач в торрент-трекерах.
Если хочется порассуждать о социальных проблемах - то пожалуйста, пишите и люди с удовольствием придут к вам комментировать. Жаловаться же на то, что в технической статье автор не изобретает очередную утопию, немного странно.
Интересно можно ли в качестве бекенда хранения прикрутить Storj (без IPFS), тоже децентрализовано и имеет лимит бесплатного хранения в 50 гб
Это решение как сделать поиск по сайту (базе данных) но вот как эту базу данных найти проблема не решена.
И ещё. После перезагрузки IPFS клиента он похоже забывает связь ipns ключа с ipfs хешем.
Это вопрос о том, как найти поисковик. Боюсь, тут бесконечная рекурсия получится :)
У IPFS и у других P2P сетей есть сеть DHT которая связывает хеш с адресом узла. В качестве хеша может выступать ключевое слово а узел кроме IP адреса в IPFS имеет ещё и публичный ключ к которому можно привязать либо саму базу данных либо информацию для подключения к ней.
Таким образом решается проблема поиска поисковика.
Да, про IPNS я вроде как писал в статье. Мне показалось, что комментарий был о проблеме более высокого порядка: мол, как тут среди кучи ваших хешей и технологий найти что-то нужное :)
С IPNS есть еще пара нерешенных проблем, например, отсутствуют заголовки кеширования в HTTP-гейтвее для путей /ipns/… или отсутствие удобных настроек в клиенте для политики кеширования разрезолвленных имен. Но в общем и целом все работает.
По поводу кеша можно перенаправлять IPNS на IPFS адрес и тогда будет кеширование.
Перенаправление на IPFS-адрес тоже ворох проблем несет.
IPFS-демон дополнительно делает перенаправление с адресов вида localhost:8080/ipfs/hash на hash.ipfs.localhost:8080. Из-за этого сайт, расположенный по этому адресу, может пользоваться только своим кешом, так как кеш ассоциируется с поддоменом. Может и можно было бы залезть в кеш корневого домена, но работа SharedBufferов в JS требует включенных cross-origin политик, запрещающих даже запросы к корневому домену.
Но я не настоящий JS-программист, возможно есть хаки, позволяющие таки лазить в кеш между разными поддоменами.
Точнее есть таймаут в 24 часа по умолчанию в течении которых желательно повторить публикацию.
Децентрализованный поиск для свободного веба