ViPRossphinx_mv Объем данных за месяц в одной из таблиц - 20 000 000 записей... Таких таблиц в системе пара десятков... Сказать, что запросы к ним (и с их участием) "летают" - не сказать ничего (данные обрабатываются в онлайн). Полегчало?
а объем даныых за одно итерацию 20 мильенов? не пробовал?
Распальцовка...
За "одну итерацию" у меня сколько "мильенов" записей точно не скажу, но в системе под пяток гигабайт "сырых" данных за каждые 5 минут обслуживается с импортом, группировками, тарификацией и прочей "шелухой"...

ViPRossphinx_mvС Вами - не о чем... На элементарных проблемах ноги ломаете...
послушай, исходников оптимизатора МССКЛ я не видел
И что с того? Я тоже их не видел. И мне это жить совершенно не мешает.
ViPRosно, все то что написано в БОЛ по оптимизации, всякие долбаные Кайты советы блоггеров применены

Когда не-долбаные спецы мешают в одну кучу рекомендации для разных по архитектуре серверов баз данных - это сильно...
Общие принципы, они, конечно, похожи... Но вот только дьявол кроется в деталях...
ViPRosпри большой интенсивности (запись удаление изменение) субд загибается

Ну, и сколько же транзакций в секунду ее "нагнуло"?
Или это была таки одна на все "100500 мульенов" записей?
Почему я не удивляюсь?
ViPRosв конце концов пришлось облегчить ей жизниь - использовать как хранилище
"Облегчили"... Не разобравшись с проблемой... И виновата в этом, естественно, СУБД... Ага...

ViPRossphinx_mv,

ладно, смотри
количество техпроцесов для одного изделия 100 000
некоторые процессы имеют альтернативы
каждый процесс требует определенный набор процессоров (станок,чек,инструмент и т.д.)
соответствующих наборов может быть много
в зависимости от выбранного ТП генерируются процессы хранения и перемещения
надо построить оптимальное расписание
это ОДНО изделие

Аж на ностальгию пробило!..
Правда, техпроцессов там было по-меньше... Да и объемы производства (в штуках) были не сильно впечатляющи...
Но сама ЗАДАЧА и, соответственно, ее СЛОЖНОСТЬ мне вполне знакомы...
ViPRosпосчитай количество записей сам
Измерять сложность задачи количеством записей - не "по-пацански"...

ViPRosда пофиг там кайт хендерсон или еще какой му**ло
а не удивляешься ты потому что не охватываешь масштаб
Нет у Вас никакого масштаба...
И рядом с Кайтом и Хендерсоном Вас даже мимо не проходило!..
ViPRosдело не в количество транзакция, а в том что, на одной и той же железке я это делаю на 1000 раз быстрее чем в лоб через скл сервер

Количество транзакций в секунду - один из основных показателей производительности серверов баз данных.
В совокупности с остальными показателями сервера дает более/менее объективные представления о реальной производительности сервера.
Про "одну и ту же железку" - такой бред даже комментировать не хочется...
ViPRosпри 8000 очередь дисковая 50
Любой студент, глянув на показатель дисковой очереди и посмотрев на рекомендуемые максимальные значения для этого параметра, понял бы, что данная дисковая подсистема НЕ ГОДИТСЯ под сервер с такой нагрузкой...
ViPRosна ноуте
Вот, собственно, Вы и озвучили МАСШТАБ Ваших задач... Ноутбук под сервер БД - это надо где-то отметить...

ViPRosблин
это просто означает что данный СУБД говно, потому что решение в обход СУБД никакие диски так не нагружает на том же ноуте
это тебе понятно?
У говняного специалиста и СУБД говно...

MasterZivOn 04/29/2012 09:13 PM, sphinx_mv wrote:
....
> Соответственно, причину, что "индексы не помогают", нужно искать не в базе
> данных, а где-то в другой части архитектуры приложения.

Именно это я и хотел подчеркнуть.
Конда индексы в принципе могут "помочь", они работают, и очень хорошо,
и на любых объёмах данных. Причём чем больше объём, тем сильнее эффект
использования индексов.

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