Правда сие строго под виндой. Но ничего не мешает поствить рядом сервачек под виндой. С такими десткими объемами он справится легко. А его стоимость вряд ли более 110 баксов в месяц будет.
Причем данное решение в корне отличается от остальных -- благодаря поиску документов похъожих по содержанию. Можно искать сракзу и по абзацу и по странице и т.д.
А заодно отсеивать дубли при наполнении базы.
а в том что касается библиотек -- тоже опыт есть -- читайте здесь
Кому интересно работа в динамично растущей компании и реального лидера в поисковых технологиях в СНГ -- пишите лично мне.
Толковые программисты меня очень интересуют.
Центр разработок и соответственно весь development team находится в Минске, а в Москве у нас сэйловый офис -- куда тоже кстати велкам только уже не программистов а менеджеров.
Приниципы работы у нас западные включая stock options для сотрудников которые ценны для компании.
Возникла потребность+желание разработать что-то полезное для информационного поиска.
..........
Буду очень благодарен за все предложения и полезные ссылки на открытые для исследования темы, как-то близкие с описанным.
AiK: Интересно, а чём плох вариант сравнения количества употреблений N самых частовстречающихся слов в документе? Гугль очень похоже, что именно так и поступает, а потому документы с малым количеством текста у него в supplemental results попадают.
Только тем что он в принципе не работает как впрочем и все чисто частотные алгоритмы. надо отслеживать еще порядок слов и многое другое. И даже если применять статистику то нельзя наиболее часто встречающиеся слова в документе -- как правило это будут общеупотребительные слова.
EvM: Предполагается создать полнотекстовый поисковый сервис на массиве из 20 000 000 документов (0.5 терабайта). Сервис должен поддерживать поиск с учетом морфологии (русской и английской)
проекта.
...............
Скорость поиска должна быть < 3 сек. Приложение должно работать под нагрузкой ~ 100 000 запросов в сутки, ~ 20 000 новых документов в день.
Скорость поиска на таком маленьком объеме как полтера у нас будет несколько уникальных запросов в секунду, ну а если запросы будут повтряющиеся то сработает кэш -- там вообще мгновенно.
Скорость индексайии от 10 до 30 гиг в час.
На такие объемы и задачи даже с учетом тюнинга под Ваши нужды в суммы менее 100К с нами точно впишетесь и запустим вам думаю все под ключ за срок от 1 недели до 2 месяцев, если все основные требования вы в посте изложили
Kryukov: где и как тестировались заявленные на сайте цифры
Базы «11.1», «21.85», «41.17», «83.22» – это англоязычные патенты в формате HTML. Документы физически хранятся в архивных файлах формата ZIP по 5000 – 10000 файлов в одном архиве.
База «132.26» кроме патентов в HTML на «83.22» Гб также содержит информацию из тестовых баз форматов (DOC, RTF, PDF) и тексты «10.7».
Кстати средний размер html не 30 кб а 10 кб. Но естественно на 'fnfgt индескирования это уже все в зипе например по 5000 файлов.
С прикладной точки зрения ничего не мешает пауку после скачивания страницы ложить ее в архив.
Заявленные скорости безусловно подразумевают средне-нормальные условия. А если довести дло обсурда, то можно создать 100 миллионов файлов по 10 байт (по одному слову в файле) так там только винда эти файлы бцдет сканировать часа 3, хотя инфы то всег 1 гиг
Только сие же уже относится не к индескированию а к кривым рукам прикладного программиста который такое утворил.
walker: Вот, кстати, по всей этой впечатляющей скорости вопросы:
1. обработка "миллионов" файлов идет по одному или все ставится в один поток/пакет?
Про что вопрос? И причем в скорости поиска обработка файлов?
walker:
2. морфология "локальна" - для каждого вхождения, где можно пытаться снимать неоднозначность - либо "глобальна" (можно вообще без морфологии - хранить только словоформы исходных текстов - и разбирать только запрос)
У нас можно искать и с морфодлогие и без -- еслти загрузить прогу то это становится сразу видно
http://www.searchinform.com/site/ru/index.htm
Правда сие строго под виндой. Но ничего не мешает поствить рядом сервачек под виндой. С такими десткими объемами он справится легко. А его стоимость вряд ли более 110 баксов в месяц будет.
Причем данное решение в корне отличается от остальных -- благодаря поиску документов похъожих по содержанию. Можно искать сракзу и по абзацу и по странице и т.д.
А заодно отсеивать дубли при наполнении базы.
а в том что касается библиотек -- тоже опыт есть -- читайте здесь
http://www.searchinform.com/site/ru/main/search-inform-projects-biblioinform.htm
Кому интересно работа в динамично растущей компании и реального лидера в поисковых технологиях в СНГ -- пишите лично мне.
Толковые программисты меня очень интересуют.
Центр разработок и соответственно весь development team находится в Минске, а в Москве у нас сэйловый офис -- куда тоже кстати велкам только уже не программистов а менеджеров.
Приниципы работы у нас западные включая stock options для сотрудников которые ценны для компании.
http://www.searchinform.com/site/ru/index.htm
Чего о нас пишут в бумажной прессе найти легко через инет.
Мое мыло leo собака softinform точка com
Возникла потребность+желание разработать что-то полезное для информационного поиска.
..........
Буду очень благодарен за все предложения и полезные ссылки на открытые для исследования темы, как-то близкие с описанным.
http://www.searchinform.com/site/ru/index.htm
Также с радостью прочту Ваше резюме и информацию о том что и как вам удалось сделать. Пишите на leo собака softinform точка com
Интересно, а чём плох вариант сравнения количества употреблений N самых частовстречающихся слов в документе? Гугль очень похоже, что именно так и поступает, а потому документы с малым количеством текста у него в supplemental results попадают.
Только тем что он в принципе не работает как впрочем и все чисто частотные алгоритмы. надо отслеживать еще порядок слов и многое другое. И даже если применять статистику то нельзя наиболее часто встречающиеся слова в документе -- как правило это будут общеупотребительные слова.
Вообще говоря интеллектуальное решение данной проблемы уже есть и успешно работает в корпоративном секкторе -- http://www.searchinform.com/site/ru/index.htm
Предполагается создать полнотекстовый поисковый сервис на массиве из 20 000 000 документов (0.5 терабайта). Сервис должен поддерживать поиск с учетом морфологии (русской и английской)
проекта.
...............
Скорость поиска должна быть < 3 сек. Приложение должно работать под нагрузкой ~ 100 000 запросов в сутки, ~ 20 000 новых документов в день.
http://www.searchinform.com/site/ru/index.htm
Пишите лично мне leo собака softinform точка com
Скорость поиска на таком маленьком объеме как полтера у нас будет несколько уникальных запросов в секунду, ну а если запросы будут повтряющиеся то сработает кэш -- там вообще мгновенно.
Скорость индексайии от 10 до 30 гиг в час.
На такие объемы и задачи даже с учетом тюнинга под Ваши нужды в суммы менее 100К с нами точно впишетесь и запустим вам думаю все под ключ за срок от 1 недели до 2 месяцев, если все основные требования вы в посте изложили
где и как тестировались заявленные на сайте цифры
Базы «11.1», «21.85», «41.17», «83.22» – это англоязычные патенты в формате HTML. Документы физически хранятся в архивных файлах формата ZIP по 5000 – 10000 файлов в одном архиве.
База «132.26» кроме патентов в HTML на «83.22» Гб также содержит информацию из тестовых баз форматов (DOC, RTF, PDF) и тексты «10.7».
Не буду грузить конфу копией всего описания -- оно доступно на сайте и вот прямая ссылка http://www.searchinform.com/site/ru/main/search-inform-indexing-speed-tests.htm
Кстати средний размер html не 30 кб а 10 кб. Но естественно на 'fnfgt индескирования это уже все в зипе например по 5000 файлов.
С прикладной точки зрения ничего не мешает пауку после скачивания страницы ложить ее в архив.
Заявленные скорости безусловно подразумевают средне-нормальные условия. А если довести дло обсурда, то можно создать 100 миллионов файлов по 10 байт (по одному слову в файле) так там только винда эти файлы бцдет сканировать часа 3, хотя инфы то всег 1 гиг
Только сие же уже относится не к индескированию а к кривым рукам прикладного программиста который такое утворил.
http://www.searchinform.com/site/ru/index.htm
http://www.searchinform.com/site/ru/index.htm
Если ищете не бесплатное, то данное решение будет для вас оптимальным
Господа у кого в Москве трафик в инет неоплачиваемый -- типа стрима?
Я бы накачал гиг 300 в архиве на свое серваке в америке и дал бы линки скачать а потом бы с удовольствием приехал в гости с винтом на 300 гиг
Качать планирую из инет -- например все софт директории или все бибьлиотеки и т.д., а далее архивировать и только htm без графики
Реально 300 гиг архивов это будет более полутра терра если разорхивировано инфы и порядка 300-500 млн страниц.
Очень хочу прогнать такой тест чтобы испытать на прочность -- потом готов запостить сюда результаты.
Кто готов помочь -- пишите
leo собака softinform точка com
http://www.searchinform.com/site/ru/index.htm
Тесты уже выложены на сайт.
http://www.searchinform.com/site/ru/main/search-inform-indexing-speed-tests.htm
Leo
---------------
http://www.searchinform.com/site/ru/index.htm
Вот, кстати, по всей этой впечатляющей скорости вопросы:
1. обработка "миллионов" файлов идет по одному или все ставится в один поток/пакет?
Про что вопрос? И причем в скорости поиска обработка файлов?
2. морфология "локальна" - для каждого вхождения, где можно пытаться снимать неоднозначность - либо "глобальна" (можно вообще без морфологии - хранить только словоформы исходных текстов - и разбирать только запрос)
У нас можно искать и с морфодлогие и без -- еслти загрузить прогу то это становится сразу видно
Leo
--------
http://www.searchinform.com/site/ru/index.htm