|
|
|
| Предполагается сделать поиск с учетом морфологии.
Поиск будет вестись по таблице в которой изначально предполагается >10000000 записей (сам поиск будет по текстовому полю ТЕХТ, и возможно по двум ФЛОАТ), в общем большой и постоянно растущей. На даном этапе используем СУБД MySQL, в будущем, возможно, что-то изменится (надеюсь :) ). Надо решить проблемму нагрузки на эту одну бедненькую табличку.
Может её разделить на несколько по каким-то критериям.
Например, если бы, текст в таблице состоял из одного-двух слов, можно разделить данные по первым двум символам, текст "икра кабачковая" состоял бы в двух таблицах "ik_table" (все записи где слово начинается на "ик"), "ka_table" (все записи где слово начинается на "ка"), т.е. запись дублируется в двух таблицах. Зато при поиске по запросу "икра кабачковая" не будет лопатится вся таблица с >10000000 записей, а всего две по 5000 зап. Но естественно такой вариант не проходит, т.к. в текстовом поле могу быть записи из 10-25 слов, и дублировать одну запись 25 раз невыгодно.
Вобщем посоветуйте что-то.
Может знаете литературу на эту тему. | |
|
|
|
|
автор: xx7 (11.01.2009 в 17:03) |
|
|
для: lonejan
(11.01.2009 в 11:32)
| | Если вся морфология только в том что учитываются начала слов , то индекс типа FULLTEXT неплохо-таки с этим справляется . ещё только не пробовал 10000000 записей , но примерно при 100000 записей при том что сами текстовые данные занимают где-то 274948 килобайт и индекс по ним примерно 118938 килобайт
, поиск слова получается довольно-таки шустрым , если без всяких лишних сортировок, и использую limit , штук по 20 записей
// сделал только три минимально-возможных буквы в слове для поиска , вместо четырёх по умолчанию | |
|
|
|
|
|
|
|
для: xx7
(11.01.2009 в 17:03)
| | Задача больше получается не на знание мускула, а на логику, разбить надо именно по каким то критериям. Причем не по смысловым критериям, а именно по каким-то критериям слов, как у меня в примере. | |
|
|
|