- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Простите, если дурацкий вопрос, но всё же: как поисковые системы позволяют производить поиск с использованием спец. символов совпадения любых символов (поиск* запрос*)?
Если я правильно понимаю, это возможно при использовании суфиксных деревьев, и, в то же время, если я правильно понимаю, при поиске активно используется инвертированный индекс, который с суфиксными деревьями увязать сложновато...
Не полным же перебором всех слов это происходит (ht://Dig выполняет такой поиск именно таким образом и по признанию самой команды это _очень_ медленно)?
Заранее спасибо.
Наверное кроме как полным перебором никак не получится.
Т.е. по шаблону (поиск* запрос*) находятся все слова из словаря, затем для каждого слова извлекается постлист из индекса, после чего полученные постлисты объединяются по OR.
Какие-же тогда должны быть вычислительные/дисковые мощности для того, чтобы такое позволять делать... Ведь как-то же реализуется такое, или именно поэтому крупных поисковиков разрешающих такие запросы и нет?
Если кто-то будет задаваться таким же дурацким вопросом (как и я), то ответ на него можно найти в "классике" (документе об архитектуре Гугла): все (/большинство) имеющихся слов словаря держатся в оперативной памяти, доступ к которой не так уж и дорог даже при условии полного перебора.
Правильно ли я понимаю, что трудности вызывает именно применение шаблона (поиск*, поиск? и т.д.)?
Если так, то здесь все достаточно просто:
1. Получаем диапазон подходящих слов;
2. Объединяем соответствующие списки.
Время выполнения операции (1) пренебрежимо мало - одно обращение к словарю. Основное время операции (2) занимает чтение соответствующих списков, что также невелико.
Такие вещи реализовывались еще в поисковиках, работавших на 386-486 машинах, если кто помнит такие.
Так что проблемы, вроде, нет.
Правильно.
Вопрос в том, по какому принципу получить диапазон подходящих слов (если слова могут быть на разных языках и методы описанные на http://linguist.nm.ru/ и заточенные под один язык не подходят)?
Как я понимаю, в данном случае это возможно только полным перебором, который, впрочем, в оперативной памяти не так уж и дорог.
Мне кажется, что для этих задач также можно использовать суффиксные деревья...
В данном случае подойдет простой словарь словоформ без всяких "заточенных под язык" методов (любое дерево здесь подойдет). Вот тогда получение диапазона для шаблона превращается в тривиальную задачу.
Спасибо за справку!
В данном случае подойдет простой словарь словоформ без всяких "заточенных под язык" методов (любое дерево здесь подойдет). Вот тогда получение диапазона для шаблона превращается в тривиальную задачу.
тривиальную..
Дам $500 за реализацию такого алгоритма.
На любом языке, не обязательно си, но чтобы запустить проверить можно было, перл, питон или джава подойдут.
Нужен быстрый поиск с wildcards по словарю из примерно 100-150 миллионов слов.
Набор символов [\x21-\xFF], максимальная длина слова 128 байт, на разбивку на более простые и короткие слова по каким-то границам внутри слова (пробелы,запятые,...) расчитывать не стоит.
Найти нужно все слова в словаре, подходящие под шаблон, желательно (но не обязательно) в отсортированном порядке.
В словарь могут добавляться слова, удаляться не могут - нужно апдейтить индекс без перестройки его с нуля по всему словарю.
Размер индекса критичен, желательно уложиться не более чем еще один размер словаря, время создания индекса - не очень критично.
Очень критично - время поиска и "время поиска первых n результатов подходящих под шаблон"
За 3000 сделаю... За меньше лениво...
тривиальную..
Дам $500 за реализацию такого алгоритма.
На любом языке, не обязательно си, но чтобы запустить проверить можно было, перл, питон или джава подойдут.
...
Аналогично