Как правильно организовать базу?

Не бывает самой релевантной страницы сайта Например, вы вводите, слово, которое на главной странице отсутствует. Более того, оно отсутствует на страницах, ссылающихся на эту страницу. И в эпсилон-окрестности также нет слов, форм-слова и его синонимов. Как эта главная страница может быть вообще релевантной?

Я имею ввиду сделать с надписью "Еще с сайта (33687)", а показывать одну.

Главная страница - это просто url сайта, а все второстепенные = главная + какие-то дополнения (для того, чтобы при хранении места меньше занимали, и чтобы было понятно, что все они принадлежат одному сайту).

А аннотацию Вы тоже с этой главной страницы будете делать?

при такой экономии и при указанных вами объемах выигрыш будет в пару десятков килобайт, но при этом вы затратите больше процессорного времени и скорее всего будете делать большее количество обращений к базе данных, смысл?

Для itman: нет, аннотация с той страницы, которая релевантна.

Для ЗодчийТеней: Согласен, экономии мало. Может тогда просто дополнительное поле ввести (id_group), которое будет говорить, что страницы находятся на одном сайте? Не сравнивать же каждый раз url-и...

А как Вы собираетесь устанавливать позицию слова, если оно будет встречаться в документе десятки раз? ;)

1 вариант будет десяток записей

2 можно собрать эти записи в один блоб, но в действительности выигрыш от такого объединения может быть иллюзорным. все от базы зависит. в оракле, например, блобы лежат в отдельных файлах, поэтому на каждую такую запись будет создаваться 4 или 8 килобайтный файл!!! в mysql блобы вроде хранятся в теле таблицы, но если постоянно происходят обновления, удаления, и прочая, то таблица с записью перменного размера может сильно фрагментироваться и производительность опять-таки упадет. то же самое будет, если хранить не блобы, а варчары.

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

любая база данных это всего лишь набор файлов, а сама «база» лишь интерфейс доступа к ним, блобы, варчары, какую размерность поля вы зададите для варчара? Пять, десять, сто символов? А как индекс по ним? Чем больше размерность поля, тем больше места будет занимать индекс, а в большинстве случаев он будет избыточен. Тупик? Разрабатывать свой интерфейс доступа к данным?

З.ы. по объемам и производительности на мускуле, мускуль прекрасно работает с базами до терабайта, другой вопрос если вы начнете сегментировать базу тогда он уходит, но точно также тут пасует и оракакел, что остается, db2? Или все же своя база данных? или просто файловая система?

Думаю что все будет зависить от поставленных задач и их окупаемости.

1) Отнюдь не любая база данных - это набор файлов, как это в mysql. Некоторые базы умеют с сырыми дисками работать, так там файлов нет вообще. Возвращаясь к ораклу. У него данные хранятся в экстентах, а экстенты в дата файлах. Дата-файлы составляют табличное пространство. Так вот, когда в таблицу заносятся всякие варчары и инты, то под них выделяется место прям-таки в этих экстентах из табличного пространства. Когда там хранится блоб, то реально вместо блоба хранится только блоб-локатор. А сам блоб хранится в другом месте. Ну может не в отдельном файле, но в отдельном экстенте размером 4 к минимум.

В mysql это не так. Там блобы укладываются прям-таки в табличное пространство. Это означает, что вместо записией постоянного размера, там появляются записи сильно переменного размера. Что по-моему и не только по-моему опыту работы сильно сказывается на производительности. Не в лучшую сторону.

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

По поводу держания мускулом террабайта? Это в каком виде он его держит? В виде одной таблицы? Какой тип таблиц? MyISAM не потяент, потому что свалится на блокировках. А, вообще, повторюсь, что SQL решение в 100 раз медленнее, чем статический файл. Особенно печально происходит там индексация.

PS: по моему опыту, у мускульных поисковиков проблемы начинаются отнюдь не с террабайтов, а с десятка гигабайт. то есть на десятке гигабайт полный ПPЕВEД.

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

терабайт в одной таблице? интересно db2 с этим справится? интересно будет попробовать. Для примера моя рабочая база хранится в мускуле и занимает 360 Гб, пользуется правда только во внутренней сети, это всего полтора десятка пользователей, но комп на котором она висит древний, семпрон 2500 кажется, тормозов нет никаких.