Ну хорошо :) ну а на шаблоне типа "*" для поиска "бабушка" наверное будет еще хуже :) . Вы же всетаки что-то знаете о том, что ищите. Если плохо знаете - то уж
grep -i [regexp] везде
работать будет долго, но надежно. Окружающий мир все равно является поиском компромисов - хотим того или нет. Обычно можно (в 90%)сформулировать некоторые допустимые ограничения на синтаксис, дабы не терять производительность - например, построить 2 индекса, перевернув во втором слова. Полного решения не даст (и думаю в общем случае задача плохо выполнима)
Кстати, можно представить сколько мусора Вы соберете на многомиллионной базе слов по Вашей маске - разгребать дольше будете
Короче, я же написал - смотря что надо :) Кстати, 100 млн массив слов по 128 символов - это 1GB (в современных условиях в мозги влезет вместе с доп. информацией)
Ой-й-й-й, тут кажись граничные условия не ставили, а вдруг челу был нужен полноценный regexp - тады только перебор :). Если же просто найти все с произвольным окончанием - то задача для студента 2 курса. Главное городить самому особо ничего не надо, берем BerkeleyDB v.1.85 (она не коммерческая), строим BTREE. Для поиска используем установку курсора на первое соответствующее, далее перебором со сравнением на превышение. Таким образом еще в 1982 году работал SMTP агент, под названием IDA Sendmail (почти обычный сендмаил, но с использованием шаблонов для подмены адресов и прочими "дырявыми" бантиками) Легкий тормоз будет обнаружен на шаблонах типа "a*", в остальном - свистит как пулемет. :)
Если это то, что нада - готов получить свои $500 с фрагментом реализации из рамблера образца 1996г.
Я бы не "стал быть" ( :) ) столь категоричным - различные тиы моделей нейронных сетей _УЖЕ_ работают в жизни (например в экспериментальных РЛС для распознавания боевой самолет или гражданский, иль вообще НЛО :) ) Я сам кодировал году в 1994 фрагмент одной модели. Смысла не помню, но помню, упрощенно что "поджигали" край сети и смотрели в графике на реакцию - занимательные, надо сказать, картинки получались. Но... это просто модель 🚬
Андрюха, тема действительно уехала в ОФФ. А если вернуться к изначальному посту: может автор и вправду хочет создать _ВСЕ_ условия для разработки :) , а может не представляет, что это за условия, а может провокация на флейм.
Пойдем разрабатывать, а?
Прошу прощения за полуОФФ
Что существует понять несложно: объем базы - миллиарды документов с преспективой роста, время сложного поиска - в районе секунды, не больше, дополнительные бантики - у каждого свои, но есть и общие.
Т.е. в Вашем случае следует прежде всего приступить к постановке задачи - что должно получиться на выходе, какими свойствами обладать, что подается на вход и т.д. Потом поисследовать на практике аналоги, скорректировать постановку задачи...
Самообразование, или пытаться устроиться в реально работающую над подобными проблемами контору (маловероятно, но возможно, если покажете подготовленную базу и пр.) Понимаете, над этим работают коммерческие команды, и давно работают. Вероятность того, что ваши мысли самые прогрессивные есть, не стоит и такой шанс сбрасывать со счетов.
Именно так :) Однако если запрос без "кавычек" или еще какой-то другой - просто проигнорировать. Я вам больше скажу - запрос: user@domain должен восприниматься как одно слово, зачем мне документы, в которых есть user и domain, но в разных местах?
Кто сказал, что они войдут в память. Даже если допустить, что все документы состоят из "словарных" слов (пардон за каламбур), то как быть с другими языками (китайский, например 🚬 ), а с их морфологией? Просто присвоение уникальных ID для слов или их основ может сократить расход пространства хранилища (диска, например) для общего индекса. Предположим, что средняя длина слова 8 символов, предположим, что всего слов вместе с иероглифами будет не более 2 млрд. Тогда каждое слово можно представить 32 разрядами (4 символа). Подход упрощенный, но мысль, думаю, понятна.
Ну краулеры могут помечать, что был отсканирован документ с ID таким-то. На этапе слияния индекса с новой порцией в каждой итерации следует вычищать поднятые данные на предмет ID и сопутствующей ему информации. Это тоже упрощенно, не гарантирует, что вычистите все
Желаю удачи
1. Вы так и не сказали цели Ваших изысканий (построение супер-поисковика по неструктурированным документам, просто образование, решение корпоративной задачи и т.д.) В зависимости от посылок ответы совершенно разные.
2. По сути вопросов:
(a) обязательно читать Дональда Кнута (Вам будет интересен 3 том, но без остальных - никуда :)
(б) По поводу "кавычек" (почему именно кавычек? синтаксис запроса может быть любым... но однозначным) в индексе неструктурированных документов хранится и координатная информация, отнесенная к каждому термину. В процессе выполнения логических операций в этом же месте производится сравнение ближайшего расстояния. Для кавычек оно должно быть 1. Координатка может быть устроена совсем просто (типа номер вхождения), а может и сложно (типа номер абзаца-номер предложения-номер во фразе-позиция во фразе 🚬 )
(с) инверсный индекс организовать можно и так и так - все зависит от разработчика и задач. Надо помнить, что существует масса "несловарных" терминов типа КТ315, ММВБ, 666 (шайтан :) , многие авторы специально каверкают слова) и пр.
вы будете обязаны их по образу и подобию занести в свои листы знаний.
(д) как обновляется индекс - у каждого свое ноу-хау. Простейший прием - полное перестроение по сырым документам. Для большого интернет-енджина непреемлимо. Инкриментальность у каждого своя.
(е) подумайте - а оно Вам надо. Подход типа: расскажите мне, как сделать, а я уж напрограммирую - неприемлим т.к. рассказ - это 90% успеха (ничего личного)
Оставляя в покое "поиск по индексам нейросети" (я это не очень понимаю), позволю себе не согласиться с утверждением о простоте ранжирования. Взять к примеру преславутый гуглевский PageRank. Вы можете прикинуть затраты на его вычисления в классическом понимании. Имеем граф на N млрд. узлов и, кто его знает, сколько ребер. При этом он обязан быть связаным, чего в жизни нет. Стало быть, надо хотябы выделить сильно связанные компоненты, определить их соотношения. А далее (ой мама, не горюй) глубокая рекурсия по матрице NxN. Это не единственная компонента ранжирования и кто знает, какие еще методы предложит пытливый ум
Что касается нейронных сетей, то мой отец очень долго и серьезно этим занимался в академгородке Пущино, по его мнению (при встрече уточню), на практике их преспективно применять в распознавании образов (в нашем случае, по-моему, это авто-классификация). Кстати, проработав 20 лет над моделированием мозга, отец "плюнул" и ушел в монахи. Возможно это не имеет отношения к работе, однако - факт 🚬
Я скажу больше, в GNU реализации qsort и в реализации от BSD существуют существенные отличия в скорости в пользу Беркли - проверено электроникой :)
Все равно, мне кажется, что слишком многомерный вектор получится, и не понятно, как с координатами, как ориентировать и пр. Для этого, похоже, нужны мощности сильно превосходящие существующие. Хотя исключать этого нельзя. Простой пример из жизни: у меня сейчас в кармане лежит КПК, который превосходит по всем параметрам на порядок тот компьютер, на котором в 1996 году я сделал Rambler 🚬
В любом случае, для построения конкурентного поисковика надо иметь некие ноу-хау, которые можно реально дать пощупать пользователю, но скромно умолчать о том, как в деталях это работает
