Кстати, вот еще что вспомнил, пардон что не сразу это было почти 10 лет назад, по поводу датапарка и хранения в базе. У них изначально был некий режим, вполне возможно, что это blob-mode, когда каждый инвертированный список хранился в блобе, так вот есть информация, что тогда были приличные проблемы с фрагментацией блобов. Может в современных версиях mysql-server все обстоит гораздо лучше. Господа, может это кто-нибудь прокомментировать?
А по поводу cache-mode: все-таки это как-то некошерно иметь две версии индекса, одна из которых занимает весьма много места. А много это что-то порядка 4-5 размеров текста.
сорри, посмотрел внимательно, действительно не обманывают. просто сниппет плохой выдают.
о, ну странно, я ненароком подумал, что эта кеше мода, когда сначала дампится в SQL, а потом уже в блоб. ну значит я неправ. ну а алгоритм ранжирования всегда малость подкрутить можно. см, кстати, предыдущий пост. ну а по части устанавливаемости и надежности тут слов нет, видимо, продукт добротный. и главное, что не заброшенный как аспсик. и поддержка разных языков оч хорошая.
Кстати, вопрос к знатокам dpSearh. Скачал версию, посмотрел create.txt практически то же, что и у mnogosearch. Но сайт http://www.43n39e.ru powered by dataparksearch пытается убедить, что у него есть опция поиска по близости!!!!! итак, следственный эксперимент. запрос test на первое место попадает сайт со словами drinking water подряд. ищем теперь по запросу Drinking Water и видим, что обманывают нас граждане насчет координатного поиска. Кстати, а если возможность настроить dpsearch чтобы он точные вхождения учитывал с большим весом. то, что это не сделано по дефолту наводит на грустные мысли.
PS: пардон не все тут так просто, там есть разные настройки по чему сортировать, использовать ли формы или нет, но все равно ранжирует ИМХО как-то не шибко хорошо.
Ок, сорри, я действительно не очень понял. Действительно, решения продавать намного выгоднее - это все-таки уникальная разработка. Хотя у меня и есть опыт негатива подобного рода. Я делал года четыре назад софт для одного каталога. Все очень мило было сделано средствами MySQL full text search + PHP + perl с поддержкой русской морфологии и подкруткой релевантности. До 100 тысяч страниц на хорошем железе вполне быстро работало. Очень быстро сделал за смешные деньги можно сказать бесплатно. в результате даже от этого бесплатно мне заплатили половину и продукт не внедрили. А каталог этот ищет до сих пор по вбиваемым руками ключевым словам. Так что востребованность даже такого сервиса дело довольно ненадежное. Хотя, если есть неплохоие заказчикИ, то нужно хвататься за это дело :-)
Ну это была лирика. Теперь давайте посмотрим на последнюю версию многосёрч (3.2.35) собственно таблица индекса:
CREATE TABLE dict (
url_id int(11) DEFAULT '0' NOT NULL,
word varchar(32) DEFAULT '' NOT NULL,
intag int(11) DEFAULT '0' NOT NULL,
KEY url_id (url_id),
KEY word_url (word)
);
легко видеть, что а) слово лежит в индексе (сикоко ж такой индекс места блин будет занимать???? б) в индексе нет координатной информации
я не знаю, может, конечно, они в поле word пихают, но вряд ли, это было бы ламерством каким-то. а координатный индекс вещь ОЧЕНЬ НУЖНАЯ и полезная. если страниц будет 200-300 тысяч некоординатный индекс дает низкую релевантность. цитаты опять-таки не найдешь.
Кстати, а Вы на nutch не смотрели?
но изначально все равно все в БД кладется?
если да, то это не очень хорошо. то есть это хорошо для специфических порталов, где неприемлема задержка между временем изменением страницы и отображением индекса. но где эти порталы? сейчас все уже давно привыкли и смирились с разрывом между обновлением и индексированием. тем более, если такой разрыв небольшой 1-2 часа вообще никто особо и не заметит.
я не советую, потому что не знаю объем легаси и Ваших возможностей копаться в коде аспсик. но мне аспсик показался более современным с точки зрения индекса. но есть большое НО, он давно не развивается. часть его создателей в яндексе, часть еще фиг знает где :-) может когда mnogosearch его и догонит когда, если откажется от идеи раскладывать индекс по реляционным табличкам.
ну ок, давайте по-другому. просто описанный выше продукт, который реально продавать 5 копий в месяц, даже люди очень хорошо понимающие в разработке поисковых машин и программировании вообще меньше чем за 2-5 (а реально я думаю где-то 10 человеко лет) не напишут. итого нужно для начала инвестировать в проект 240 тысяч баксов минимум (в России). легко посчитать, что чтобы просто отбить эти деньги понадобиться не один год, не говоря уже про такую маленькую проблемку, как начальные вложения. и это все при том раскладе, что замечательных программистов, которых Вы пригласите будут работать с большим энтузиазмом (понимая при этом, чтоб работа, собственно только на год) и их никто в это время не переманит. А если вы всех программистов решите оставить после запуска продаж, то это дополнительные большие расходы.
А потом продукт нужно постоянно обновлять фиксить, итд. за это время могут придти другие игроки и предложить продукт лучше (например потому что у них инвестиций больше). А вероятность этого очень велика, ведь посмотрите сколько разных поисковок уже наваяли. Короче, чтобы не тратить больше время: это очень и очень затратный, трудоемкий и рискованный бизнес. и в случае успеха бенефиты довольно скромные. Другое дело, если закрепиться на рекламном рынке. Он постоянно растет, там есть смежные проекты, можно делать портал итд итп. И свой продукт в результате можно не делать каким-то исключительным. Ведь при больших годовых оборотах это не очень важно сколько используется машин 100 или 1000. И не обязательно делать продукт идеального качества, потому как часть пользователей можно привлечь портальными сервисами.
Да, продолжая тему, на рынке можно что-либо получить, если только предложить какое-либо очень уникальное решение: быстрое, надежное, многоформатное, которое "держит", скажем, 10-20 миллионов документов при 10 запросах в секунду, имеет какой-нибудь простой язык для вкручивания разных там расширений типа SearchEngineScript :-) ну или прозрачный интерфейс для написания плагинов на джаве или плюсах,глубокую языковую поддержку всякую там синонимию, настраиваемость поиска, в частности хорошие возможности расширения запроса в случае, когда он мало результатов возвращает, а также хороший, самообучаемый спеллер.
Ну и многоплатформенность, ясен-пень, хотя бы на уровне разных *nixов.
Вот только тогда можно ломиться на рынок. Только посчитайте, сколько будет стоить такая разработка и насколько квалифицированные люди должны в ней участвовать. Их, прямо скажем, даже в одном месте собрать будет сложно.
Чем же он не сравнимо? по-моему, единственная загвозка с многосёрчем на таких объемах - это обработка pdf, rtf, doc. За 21 тысячу долларов, которую гугл хочет за двухюнитную машинку на 0.5 миллиона доков, вполне можно
а) купить двух процессорную машинку с 8 или более гигами памяти. многосёрчу этого хватит чтобы не тормозить на 1.5 миллионах (2-3тысячи)
б) нанять человека за несколько тысяч, который прикрутит внешний парсер за 2-3 месяца.
в) выкинуть многосёрч и поставить аспсик, он индексирует и ищет побыстрее
и еще деньги останутся.
2-4 тысячи долларов за инсталляцию, это не много. Сколько, например, можно делать этих инсталляций в России? Думаю штук пять-десять в месяц при самом удачном раскладе. А на такие деньги "белая" фирма проживет с трудом, выгоднее чем-нибудь другим заняться. А еще всякие там конкуренты: Многосёрчи, Аспсики, которые в некотором роде бесплатны.
