один большой запрос или несколько мелких?

Arhat109
Дата: 14.12.2012 13:20:55
Собственно вопрос в сабже.

История: делаю автопарсер товарных строк. Собственно пока ничего сложного нет, алгоритм:

1. Бьем строку на отдельные символы и подаем в Мускуль как таблицу отдельных символов (SELECT "f" UNION SELECT "a" ...).
2. Мускуль по моим правилам о разделителях собирает из них слова (первый подзапрос) - получаем табличку слов с примененными правилами.
3. Слова джойним со словарем слева и получаем описание слова, если оно есть (второй подзапрос)
4. Результат джойним с табличкой известных слов и ещё с табличкой применимых контекстов. (третий и четвертый подзапросы) Получаем описания товарных позиций в рамках прайса фирмы
5. Результат джойним с табличкой страниц портала - получаем куда воткнуть ту или иную товарную строку прайса.

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

Вариант 2: сделать это всё силами ЯП (ПХП) поочередно выполняя запросы.

Пока из замеров: 1,2,3 - подзапросы выполняются как по отдельности так и совместно примерно за 0.35сек... П.5 тоже дает время выполнения около 0.2сек (проверял только отдельно).

Сейчас готовы уже таблички для п.3. и п.4. ... вот и засел думать... как лучше? интегрировать всё в один пирог... или таки разделить его по отдельности... смущает опыт разделения 1-3 стадий... каждая исполняется практически столько же сколько все вместе.

Насчет использовать на части этапов ЯП (в частности regexp) - не надо. Пробовал. Оно получается не быстрее. Несущественно (5-10%) но стабильно. И не совсем то, что хочется. В частности разбивка на слова - около 160мсек. для 250 символов (regexp) против 150-180мсек у Мускуля (которые эффективно втягиваются в следующий над запрос!).

Требуется совет профи... как обычно - вчера. :)
Akina
Дата: 14.12.2012 13:33:22
Если не требуется для реализации этого многоэтажного безобразия использовать итеративные структуры MySQL (курсоры там и протчая) - несомненно следует всё отдать мускулю на откуп. Возможно, местами вручную подтюнить - зафорсить там использование либо неиспользование индексов или около того... но в любом случае он выполнит обработку массива эффективнее, чем алгоритмический язык. Да и на пересылках опять же экономия.
miksoft
Дата: 14.12.2012 13:39:41
Arhat109
В частности разбивка на слова - около 160мсек. для 250 символов (regexp)
Это что ж за язык такой? Я бы выкинул регэкспы и делал нормальными строковыми функциями, имхо, было б на порядки быстрее.
Arhat109
Дата: 14.12.2012 14:54:25
miksoft, "дедушка повой волком!" ?!? "дедушка, а ты когда последний раз бабку того?" У-у-у... :)

Это не язык. Это ПХП. У-у-у... :(

Если серъезно, то это пока модель. Будет перетаскиваться на С(++)... и там Мускуль лучше и по другой причине: мне надо правила разбивки брать в зависимости от контексту, который в табличках у него же ... но мне нужно, чтобы оно уже сейчас начало работать... конкретно с понедельника...