|
Aqwerty TiGОткуда вы взяли "фактически полный просмотр индекса" непонятно. Да это будет index range scan, даже для неизменяющихся идентификаторов, но не более того. Если данные не меняются очень часто, то обычно в отчетный диапазон редко для каких записей будет попадать много актуальных версий, чаще - немного либо вообще одна.
А просмотреть range scan'ом половину индекса - это не есть фактически полный просмотр индекса? TiG
При наличии индексов clients (id, stop_date, start_date) и products (id, stop_date, start_date) выборки из них вполне эффективны.
Естественно это будет немного медленнее, немного более сложные запросы, чем то что существует сейчас. Но это цена которую надо платить за поддержку версионности. Денормализация схемы для ускорения, предрасчитанные итоги или джойны тоже ведь не бесплатны - только там надо платить усложнением модели и дисковым пространством. В любом случае выбирать оптимальное решение для вашего случая - вам ;)
Приведенные Вами индексы оптимальны только в крайней случае - когда Вы делаете запросы за последние периоды. Если же делать запросы за самые старые периоды, то нужны индексы clients (id, start_date, stop_date) и products (id, start_date, stop_date), иначе по Вашим индексам надо будет просмотреть весь индекс, т.к. первое же условие stop_date > :BeginDate будет всегда истинным.
А если запросы делаются за периоды, находящиеся в посередине, то что один, что другой индесы потребуют чтения их половины. Что фактически же равносильно полному сканированию или вообще отказу от этого индекса. Утверждать наверняка без конкретного примера невозможно, но есть достаточно высокая вероятность того, что оптимизатор решить вообще индекс не использовать. Естественно, если делать запросы за вырожденный период [BeginDate;BeginDate), то вообще все хорошо становится. Но в общем случае невозможно гарантировать какую-то стабильную скорость ответа, она очень сильно будет зависеть не просто от длительности периода, но и от его месторасположения.
Я согласен, что обычно большая часть отчетов делается за последние периоды, однако все же следует учитывать и более старые периоды. К тому же если у Вас есть некоторая величина, например, потребление воды, газа, электроэнергии, количество осадков и т.п., о которой можно говорить, что это потребление непрерывно и есть необходимость найти величину этого потребления за указанный период при том, что реальные данные могут содержать любые периоды, то просто так просуммировать данные нельзя, нужно брать часть значения пропорционально периоду (выражение вида: value / (EndDate - StartDate) * (LEAST(EndDate, EndReportDate) - GREATEST(StartDate, StartReportDate)) ). Вот тут возникает еще целый пласт проблем.
В итоге я думаю, что все же следует идти по пути построения хранилища на базе схемы звезда/снежинка, поскольку в противном случае есть опасность нарваться на множество труднорешаемых проблем, в частности, проблему с производительностью.
У вас явно проблемы с пониманием что из себя представляют индексы, и когда и как они используются. В данном случае если вы делаете выборку по id - никакого "просмотра половины индекса" не будет (если конечно у вас на один единственный id на всю таблицу ;))), пофиг ему какие там даты, старые или новые, ничего от этого не меняется. Если отбор только по датам - есессно вам нужен индекс где даты будут ведущими столбцами. И никакой "сильной зависимости от месторасположения" не будет. С чего вы это взяли, вы вообще представляете как физически строятся древовидные индексы ?
В зависимости от размера/высоты индекса и кардинальности ведущих колонок у вас уже на первом уровне могут быть полные (вот где собака порылась!) ключи, что позволяет уже на первом уровне отсекать ветви содержащие не подходящие по всему списку колонок строки. Потому что поймите, если у вас ведущая колонка в индексе имеет всего 2 разных равновероятных значения (индекс хреновый конечно, но для примера сойдет), вторая колонка почти уникальна, а сама таблица содержит 10 миллионов строк, и индекс предположим получился 2-х уровневый, то какой смысл на 1ом уровне хранить только значения одной ведущей колонки, понятно ведь что он не селективный совершенно, и действительно будет приводить к "просмотру половины индекса". Поэтому в таком индексе уже на первом уровне будут храниться в качестве границ диапазонов ключей листовых блоков полные ключи и, соответственно, уже при скане блоков первого уровня индекса будет эффективно выделяться только нужный диапазон ключей с учетом значений второй колонки.
Короче решение о необходимости построения отдельного хранилища данных принимать следует явно не из посыла о "сканировании половины индекса". В первую очередь надо оценивать каков будет характер большинства отчетов, какую доп.нагрузку будет создавать на OLTP составляющую, насколько оперативные данные нужны в отчетной системе, каковы вообще будут требования к ней.
|
