fed: Ledger Balance Data in DAX

[glibs]

Цитата:

Сообщение от fed

...
Ну насчет кластерных индексов - как раз сомнительно.
...

Не конкретно.

Цитата:

Сообщение от fed

...
Если у тебя стандартный индекс accountNum+dimension, а я ищу выборку по AccountNum+dimension[2], то индекс будет использоваться только для отбора всех проводок по счету. Фильтрация по аналитике будет делаться уже за счет данных, а не за счет индекса.
...

Верно. Но если индекса по AccountNum+dimension[2] нет и на LedgerTrans, а его там нет, то выборка по кластерному индексу приведет к эффекту сканирования фрагментов кластерного индекса на LedgerBalancesdimTrans. Т.е. произойдет а-ля сканирования таблицы на самом деле, но по отдельным кускам таблицы. Это оптимальный подход к выборке данных в данном случае. Да, фильтрация по данным будет.

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

Индекс некластерный эффективен при выборке одной или нескольких записей из большой таблицы.

Цитата:

Сообщение от fed

...
И если условие по dimension[2] высокоселективно, то надо по нему индекс строить (типа transDate+accountNum+dimension[2]) (независимо от того - ищем мы по ledgerTrans или ledgerBalancesDimTrans). Может заметно быстрее получиться - несмотря на лукап
...

Я говорил про стандартные индексы. На все случаи жизни индексов не настроишь. Индексирование — дело разумного компромисса.

Если бы индекс на LedgerBalancesdimTrans был не кластерным, то на выборе из огромной таблицы нескольких записей он бы дал большую скорость. Но при выборе очень большого количества записей большую скорость даст кластерный индекс.

Цитата:

Сообщение от fed

...
Кстати - длинный ключ кластерного индекса по ledgerBalances тут может негативную роль сыграть
...

О чем идет речь?

Блокировки? Скорость разноски на OLTP операциях?

Разумеется. OLTP оно такое. Должно учитывать интересы аналитических задач. Но при грамотной архитектуре БД тормоза OLTP пользователь не ощутит. При этом будет учтен интерес аналитических пользователей.