sandys

Рейтинг
1
Регистрация
08.06.2007

Кстати а что обычно инвесторы хотят взамен инвестиций?

Каковы шансы договорится без раздела долей собственности проекта, т.е. с обязательным выходом инвестора из проекта?

не надо для начала качать весь интернет.

А как тогда можно сделать полезным поиск - ведь но посто не будет полностью знать где что лежит. Пользователи не будут ходить - я например не пошел бы на такой поисковик - подождал бы когда вырастет база

Слава Шевцов:
Вы в это ещё верите? Ни доработками функционала, ни интерфейсом, ни алгоритмами, ни деньгами текущие поисковики не подвинуть. Для появления нового топ-поисковика нужно что-то радикальное + крупнейшие поисковики должны не иметь возможность реализации новых идей. В то, что они пропустят новинку и не смогут её оценить и захотеть вобрать всё лучшее, как-то не верится. Слишком хорошие команды в Яндексе и Гугле. Они всё новое и полезное спионерят и оставят новичка ни с чем.

Я тоже больше к этому склоняюсь.

Думаю что для того чтобы заинтеросовать инвестора нужно кардинально новые алгоритмы.

Удивительно что quintura, webalta заинтересовали инвесторов

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

А без этого занятие ощутимой доли рынка поиска мне не представляется реальным.

Andrey Ogarok

Вот я видел на вашем сайте бизнес план.

Скажите как нужно представлять проект поисковик чтобы было больше шансов заинтересовать инвестора. Что их интересует? Какова компетентность инвесторов которые интересуются вложением в поиск?

Как действовать с вашей точки зрения?

Кстати нету случайно статьи "J. Jobel, A. Moffat. Inverted Files for Text Search Engines, ACM Computing Surveys, Vol. 38, No. 2. (2006)"

скачать не получается ?

Затем для каждого уникального слова по очереди проходитесь по прямому индексу, составляете обратный индекс для этого слова, файл сбрасываете на диск. Таким образом, Вы можете индексировать базы любого размера. Правда количество проходов по прямому индексу получается равно количеству уникальных слов. Но это можно оптимизировать Самое узкое место - дисковая подсистема. Это уже лечится только добавлением памяти.

Тут я делаю проход по прямому индексу не для одного уникального слова а для определенного интервала - так меньше проходов требуется.

Разбиваете обратный индекс по словам. Для каждого слова свой файл с обратным индексом. Файлы хранятся на диске.

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

Но это мелочи - проблема не здесь.

Если требуется большая производительность и время чтения с диска критично, то кидаете часто используемые файлы в memcached.

Проблема в том что индекс "имен файлов" в оперативной памяти не умещается.

А как просто большой индекс делать:

допустим есть такие поля

int id //ключ

int offset //смещение в файле
void *gt, *lt; int bf; // для организации сбалансированного бинарного дерева

5*4 байта = 20 байт

Хотелось бы чтобы вся эта структура хранилась в памяти для быстрого определения смещения в файле по заданному ключу.

Но как это можно хранить в памяти если id несколько десятков миллионов (хотябы) - 20*50 000 000 = 1Гб

Или в таких ситуациях индекс раниться частично на диске ?

Lord Maverik:
Йоу... вы о чем?

Я говорю про создание поисковика не средствами СУБД.