Форум пользователей MySQL

Почему использование fulltext - сомнительное занятие?
И в каком смысле поиск по прайс-листам, какие критерии поиска ожидаются?

Лучше всего сделать проект БД, запонить его сгенерированным правдоподобным контентом и потестировать. Если выбранное решение не соответствует нужным критериям, например скорости - искать другое решение или модифицировать существующее (оптимизация, денормализация, партиционирование и т.п.). А на этапе идеи (я так понимаю у вас именно этот этап) обсуждать инструменты как то рановато.

Например я не очень себе представляю зачем нужен полнотекстовый поиск по прайс-листам, обычно ищут по артикулу (LIKE '112-13%'), по названию модели(опять же левый лайк) или по разным там категориям и характеристикам (которые как правило хранятся в отдельных полях БД). А полнотекст зачем? Возможно у вас будут статьи, в которых будет нужен поиск названий моделей? А статей тоже будет миллионы?

Может быть fulltext вам действительно нужен, просто вы забыли рассказать про задачу поподробнее. Так что сомнительное занятие - это заниматься такой вот теорией.

Уважаемый Юрий. Убедительная просьба хоть как то аргументировать ваши высказывания

Использовать преславутую технологию поиска, в частности FULLTEXT для движков MyISAM - есть сомнительное занятие

основания так утверждать?

Может быть, кто-то из вас знает лучший подход (за исключением Sphinx)

почему кроме сфинкса?

использовать LIKE (на огромных данных не подходит)

почему не подходит?

специально для вас сделал табличку

В ней 80 млн строк, 40 сгенерированных, потом удвоена самокопированием, т.е. строки не уникальны


--> 19902 rows fetched (94 ms)


--> 2 rows fetched (0 ms)

в случае уникального ключа (а артикул должен быть именно таким) будет еще быстрее.

1000 таблиц - это ерунда, никаких проблем не будет, по сути проблемы возникнут только если количество файлов приблизится к сотням тысяч (для файловой системы это будет тяжело, не для mysql)

Но я бы в вашем случае думал про партиционирование - http://dev.mysql.com/doc/refman/5.1/en/ … oning.html

Ваше последнее сообщение равно первому по количеству информации о задаче. Теоретизировать (особенно без аргументов) можно сколько угодно. Когда попробуете что то и у вас не получится или будут проблемы с производительностью - приходите

Кстати, ко всему этому мне на одном форуме дали совет как использовать поиск по прайсам. Честно сказать я не совсем понял что хотел донести до меня разработчик. Может быть Вы, как опытный специалист более детальней разжуете мне саму идею... сказали что все это хорошо работает. Привожу цытаты его высказываний:

-----------------
"Надо понимать - что я все это писал про поиск по начальным символом а не LIKE'о-образный поиск по середине кода. С lik'ом при десятках миллионов ничего не поможет.
Так что имея первые 2 буквы - вы уже всегда на клиенте знаете в какую из таблиц полезть за результатами.

Например есть у Вас 10 млн. наименований вида(для примера):

RPLJ-04FGK_F10
A180-103

Вы перед вставкой думаете - ага, на A у меня начинается 835 536, а на B 143 654 наименований.
Делаете таблицы

AA AB AC .....

BA BB BC .....

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

Как работает LOCK на myIsam? Он открывает файл, и лочит его на уровне ФС. Так что каждое обращение будет открывать, допустим гигабайтный файл, что-то искать и закрывать - это само по себе очень долго т.к. файл при открытии перемещается в ОП.
На INNODB получше но забудьте про FULLTEXT.
Итак, на этом этапе у Вас есть допустим ~900 небольших таблиц которые лочатся при запросах отдельно.

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

Т.е. например вы дальше имея 900 таблиц строите по каждой hash-индексы по 1 букве.

Дальше пользователь начинает вводить например:
A18, система уже знает что из таблички(физического файла) "A1", ей надо отфильтровать только ту часть которая соответствует выборке по индексу "8" - и весь этот набор перегружается во временную таблицу(либо в зависимости от частоты система уже заранее построила вам hash-индекс по двум буквам 1A, 1B.... и если пользователь ввел всего не A18 а A184 то уже используется этот hash-индекс).

"

Отредактированно yuriy (20.10.2012 11:17:12)

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

Отредактированно yuriy (21.10.2012 23:13:30)

Спасибо за детальную интерпертацию... согласен с вами с тем что "геморно такие структуры поддерживать, там и кодировки могут всплыть, т.к. артикулы могут оказаться (внезапно) с русскими буквами и пр." - такой вариант не подходит!!!
Сейчас занимаюсь партиционированием таблиц для поиска по каталогу.
Суть в следующем.
Таблицы группируются, к примеру, по группе товара (запчастей) - создается 30 таблиц.
Каждый прайс будет загружаться в одну из этих таблиц, соответственно по тематике и соответствию номенклатуры запчасти которая относится к той или инной группе.
Затем каждую из этих 30 таблиц планируется разбить на секции (разделы) по критерию марки авто.
Исходя из всего этого мы сужуем диапазон поиска - сразу по двух критериях - группа запчасти и марка авто.
Если к примеру, пользователь выбирает Марку (ВАЗ) - Модель (21099) - Группа запчасти (Фильтры) - то система ищет соответственно в табл. которая относиться к группе (Фильтры) - затем находит подраздел в этой же таблице по марке ВАЗ - и выдает весь результат.
Думаю такой алгоритм будет быстро искать по каталогу не перегружая систему огромными таблицами (в десятки мил. строк).
Если будут какие-либо замечание - прошу высказываться... зарание всем спаибо за участие в проэктировании...

Но вот организовать поиск по артиклу (коду товара) по такой структуре пока неясно!!! Хочеться создать одновременно и поиск по каталогу и поиск по коду товара.
Я пока не тестировал поиск по LIKE% - как будут каие-то результаты сообщу вам.

Значит так:
Создал таблицу на сервере и на локальной машине для тестирования из трех полей:

------------------------------------
id  |  namezapch  | numberkatalog  |
------------------------------------
Напхал туда 4 имл. строк и с помощью лайк сделал выборку:

SELECT * FROM pric WHERE numberkatalog LIKE  '038253010C';

На сервере показало: Отображает строки 0 - 29 ( 2,595 всего, Запрос занял 0.04 сек.)
На локальной машине: 3498 rows in set (0.56 sec)
Судя по показателем неплохо!!! На сервере даже быстрей выполняется нежели на локальной машине)))
Правда если туда добавить 100 мил. строк, может быть время составит порядка 1-2 сек.

Получаеться, что всю информацию можно хранить в одной огромной таблице (размером порядка 100-200 мил. строк) и LIKE-ом производить поиск товаров.
Кстати поле по LIKE нужно проиндексировать?
Кроме этого весь этот запрос можно написать в хранимых процедурах, так оно еще быстрей будет искать? Верно?


Судя из проведенных тестов партиционирование не нужно теперь!

Отредактированно yuriy (22.10.2012 19:58:10)

Таблица получается очень большая, поэтому есть желание ее разбить. Скжите, как ведет себя LIKE когда таблица разделена на секции (подтаблицы - партиционирование)?

Отредактированно yuriy (23.10.2012 10:03:04)

yuriy написал:

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

А какая разница откуда делать эти несколько запросов - из скрипта php, хранимой процедуры или удаленного терминала?

yuriy написал:

откомпилированый код на самом сервере выполняется намного быстрее нежжели из рнр-сценария создавать несколько запросов!!!

Это вы о чем? Что такое "откомпилированый код"? Prepared statement? Так, во-первых, не намного быстрее, а, во-вторых, живут они в течении сессии, и какая разница что за сессия - скрипта php, хранимой процедуры или удаленного терминала?

Shopen написал:

1. В данном случае вы хоть и написали LIKE, но по сути ваш запрос равен такому:

SELECT * FROM pric WHERE numberkatalog =  '038253010C'

проверяйте лучше именно по LIKE '03825%' если конечно поиск по части артикула у вас будет вообще. Если только точный поиск, то бинго

2. Судя по количеству возвращенных строк - у вас не особо артикулы уникальны (2500 позиций  с артикулом "038253010C" плохо похоже на реальность).

3. А у вас запрос выше работает без индекса на поле `numberkatalog` с такой скоростью?? Индекс безусловно нужен. Он нужен по всем полям упоминающихся во WHERE при наличии достаточной селективности.

4. Процедуры в данном случае - это экономия на спичках

----------------------------------------
Иксать у меня будет по коду товара - строгое совпадение:
SELECT * FROM pric WHERE numberkatalog =  '038105264J';
По названию с выражением LIKE%
SELECT * FROM pric WHERE namezapch LIKE  'бампер%';

1. Вы правы, количество возвращенных строк по артикулах не уникальны, потому что одни и те же товары (их коды и название) в разных прайсах одинаковы. Продавцы загружают прайсы в которых продают одни и те же товары (они совпадают). Как здесь быть? Наверное никак...!!!
2. Индексы проставил по названиях и по их коду.
Делаю запрос по названию товара на сервере в phpMyAdmin - кол-во строк 4 мил. записей:

Результат:
Отображает строки 0 - 29 ( 49,287 всего, Запрос занял 0.0004 сек.)
Время сдесь сомнительное - поэтому по моим наблюдением запрос выполняется где-то около 1-2 сек.

3. Есть идея следущего характера:
Разбить огромную таблицу на разделы, по критерию марки автомобилей.
При этом, диапазон выборки значительно уменьшится. Предположим, пользователь ищет бампер (при этом он должен обязательно укзать марку авто).
MySQL будет в таком случае искать название товара не по всей огромной табл. а по раздулу марки к которой относиться данный товар.
Как Вы считаете такой подход будет оправданным или нет?
Спасибо!

Отредактированно yuriy (23.10.2012 16:46:56)

Спасибо за консультацию!!!!