axdaily: Surrogate keys in AX 2012

[fed]

Цитата:

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

Почему вы так уверены что будет грошовый прирост производительности ?
Думаю, что уверенно можно говорить только после теста на большом объеме данных. Или ранее уже пробовали ? Поделитесь результатами.

Не пробовал. Но соображения простые:
1. Суррогатный ключ позволят сделать индексные ключи более короткими. А при уменьшении размера ключа с 20 байт до 8 (допустим для custAccount), число индексных входов в странице вырастет в 2,5 раза, соответственно - время доступа упадет в log(x*2,5)/log(x) раз.
2. Аналогичным образом - нормализация. Типа можно сэкономить место на диске за счет снижения избыточности (вынесли, например, из inventTrans часть повторяющихся полей в отдельную табличку).
НО: Я на нескольких своих проектах экспериментировал с сжатием данных, которое появилось в SQL 2008. Так вот на практике, при сжатии популярных (и больших) таблиц, имеющих высокую избыточность и хороший коэфициент сжатия, результирующее время доступа для типичных запросов оставалось прежним (иногда чуть больше, иногда чуть меньше). При этом нагрузка на процессор заметно росла, а число физических чтений с диска падало, но не заначительно. Вывод из этого очень простой: В типичном современном сервере, памяти много (и ее легко добавить), дисковые массивы достаточно быстрые. Поэтому большая часть данных читается из кэша и от размера содержательной части данных зависит не очень сильно (ну конечно - при разумном уровне нормализации). Серьезный выигрыш от уменьшения размера хранимых данных может случиться только если идет запрос, который читает большой объем данных за большой период. Вполне могу поверить что в новой модели данных (или в скомпрессированных таблицах), отчет по inventTrans за 5 лет работает вполне быстрее чем в старой. Проблема в том, что такие запросы обычно гоняются через выделенную OLAP-систему. А в Аксапте наиболее типичный запрос - это джойн 2-3 таблиц, с максимум 50-100 записями в резульируюшей выборке. И если эти 2-3 таблицы, в результате нормализации или введения наследования, превратятся в 5-6, проигрыш от накладняков на джойны и компиляцию более сложного плана запроса заметно перекроют выигрыш от гипотетической экономии на чтении с диска/кэша.

Про EAV тут уже обсуждали, так что не буду повторяться.


Ну и могу заметить что, гм, пожелавшие остаться неназванными источники в Микрософте, рассказывали мне как разработчики ядра (скажем так - системного и ПРИКЛАДНОГО ядра) полировали глюкалу в промежуточных релизах 2012ой и пытались играть с параметрами и структурами данных, в надежде добиться хотя бы той же производительности некоторых операций (например работы с ГК) что и в старой версии. Вроде бы добились. Но любимая glibsом табличка с балансами теперь пересчитывается только по ночам, потому что в онлайне ее быстро обновлять не получается...

Уверен, что в пресс-релизах о выходе DAX2012 будет много сообщений о росте производительности в n раз. Вопрос в том, на какой выборке будет достигнута эта производительность и насколько типична эта выборка для того самого upper midmarket, для которого предназначена аксапта...