FULLTEXT и большая база.

[Kelkos]

FULLTEXT и большая база.

Хм.. хочу на будущее избежать больших проблем. Создаю базу поиска по нескольким индексированным сайтам.. предполагается, что база будет гдето около 3гб (о размере ключей даже страшно подумать). Ессно FULLTEXT на поиске укапается. Но т.к. поиск будет только по страницам какого то одного сайта может разделить контент сайтов по разным таблицам? Намного ли добьёмся увеличение скорости поиска?

 

[Tor]

лучшей альтернативой этому будет дополнительное поле с названием сайта (или порядковым номером) и индексом по нему

 

[CCCP_MOCKBA]

а ты сам как думаеш ?
что быстрее поиск в двух записях или в одной записи?

-~{}~ 06.05.05 15:50:

лучшей альтернативой этому будет дополнительное поле с названием сайта (или порядковым номером) и индексом по нему

и поле с ссылкой на страницу.

 

[Kelkos]

Сорри.. ступил.. ессно у меня будет у каждой страницы id сайта. Но всётаки смущает меня размер такой таблицы.. Не глюкнет? Ктонить делал что то подобное?

 

[CCCP_MOCKBA]

-- Компания MySQL AB. использует MySQL для работы с несколькими базами данных, которые содержат 50 миллионов записей, кроме того, нам известны пользователи, использующие MySQL для работы с 60000 таблицами, включающими около 5000000000 строк.
[выдержка из мануала]

 

[Kelkos]

хех.. а вот случай из жизни: статистика прокси сервера записывалась в мускул.. админ её постоянно чистил и всё такое.. но однажды он уехал в отпуск на месяц и вместо него никто её не чистил.. и вот гдето в районе чуть больше 2-х гигов всё ёкнулось.. случайность или закономерность?

 

[CCCP_MOCKBA]

правильная структура, вот что ему помогло бы...

 

[Nimous]

Храни данные для поиска в файлах. А в таблице - только ссылки на них. Скорость будет повыше, а ресурсы - посвободнее.

Хранить всё в одной таблице, - слишком прожорливо,
а в разных - не слишком хорошо с точки зрения структуры БД.

 

[Kelkos]

Храни данные для поиска в файлах. А в таблице - только ссылки на них.

А поиск? поиск то как? Всё это ради этого несчастного поиска. Поиск в файлах будет ещё хуже чем поиск в таблице.. Да и удобнее использовать уже готовый поиск мускула, чем самому ещё мутить.

 

[Nimous]

А по твоему "готовый поик мускула" как-нибудь отличается от "готового поиска ПХП" в сторону удобства?
Те же реги и функции. И увязывать их в "ГОТОВЫЙ ПОИСК" придётся
тебе.

А вот добиться экономии ресурсов и гибкости можно будет меньшей кровью.

 

[Kelkos]

Автор оригинала: Nimous
А по твоему "готовый поик мускула" как-нибудь отличается от "готового поиска ПХП" в сторону удобства?

ага.. ещё как. + простота в использовании.

Те же реги и функции. И увязывать их в "ГОТОВЫЙ ПОИСК" придётся тебе.

Вот тот и оно.. либо делать медленную и тормознутую ситему долго и муторно.. либо взять готовое быстрое решение.

А вот добиться экономии ресурсов и гибкости можно будет меньшей кровью.

Я бы с этим поспорил. В конце концов сделаешь аналог fulltext поиска и чего ради? Экономии тут недобьёшься серьёзной.
Хм. а вот просто интересно стало.. рамблер или яндекс используют sql базы или файлы?

 

[Nimous]

Понимаешь, индекс нескольких сайтов, это, в принципе может быть ОЧЕНЬ большой объём информации.

Если даже распихать всё это по отдельным таблицам (кстати, только так!), пожирание, например, памяти, будет очень большое.

А файлы всё-таки надёжнее в экстремальных ситуациях.

Я сам пару раз сильно накалывался при обработке больших объёмов данных в MySQL, поэтому, возможно, это моё субъективное мнение,
что в данном случае файлы лучше.

Кстати, не знаю насчёт Рамблера и Яндекса, а вот Гугл точно на файлах(по крайней мере был до недавнего времени).
Да и не уверен я в том, что выборка у них происходит с помощью скриптов.

 

[fixxxer]

На базе в 2 гига вполне себе работает это FULLTEXT, проверено.
Но для таких объемов лучше использовать postgresql+tsearch2.

 

[Kelkos]

Мдя.. сделаю ка я тест базу на десяток гигов и посмотрю что получится.. А то прямо суета вокруг ещё неубитого медведя.

 

[Мутник]

Kelkos

ну так надо, наверное, сначала сделать, а потом спрашивать.. а еще хорошо иногда решать проблемы по мере их поступления!!!

P.S. интересно, как ты 2 гига текста генерить будешь! и как долго по времени!

 

[Kelkos]

да вот.. сгенерил..
Взял за основу 50кб текста и из него начал генерить страницы разной длины и набором случайных слов из основы.
Вообщем, нормально функционирует (время не более 30 секунд) при выборке из всей базы размером 500мб. Комп P4 2ггц -512мб под вин2000. Дальейшее время поиска прямопропорционально увеличению базы. Дождался 2-х гигов и плюнул.. и так ясно. Но вообщем мне этого более чем достаточно. У меня размер одной категории (сайта) не будет превышать 100мб. Запихнув всё в одну базу я ничего не теряю. Главное, чтобы размер одной из категорий не разбухал более 500мб и будет всё ок.
Всем спасибо за внимание. Извините, что побеспокоил. Сосбтвенно паук и поиск уже сделал.. щас тестирую.