axdaily: Surrogate keys in AX 2012

[Logger]

Цитата:

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

В итоге - грошовое увеличение производительности (не везде и не всегда), при заметном усложнении внедрения и поддержки.

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

[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, для которого предназначена аксапта...

[Logger]

Цитата:

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

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

Именно !
Думаю в этом все дело.
Т.е. вопрос в том на какой рынок хотят вывести Аксапту. У меня складывается ощущение что MS хочет замахнуться на рынок SAP (плох солдат который не мечтает стать генералом. Нафига было вообще лезть на этот рынок, если не стремиться стать на нем лидером ?), т.е. для upper midmarket оставят Navision и может еще что, а Аксапту двинут на крупняк.

Мы с вами свои рассуждения строим для баз размером 10 - 100 - 1000 гигов. (А больше под аксаптой наверно и не бывает пока) А её возможно готовят для больших объемов баз. Тогда понятно желание ввести суррогатные ключи (читай сэкономить память БД и ускорить время работы с индексами).

Кстати, пример про 20 байт не очень удачный. Большинство ключей, по которым идет фильтрация и объединение таблиц являются наследниками EDT NUM, который имеет длину 20 символов, т.е. 40 байт в юникоде. Т.е. разница в 5 раз,а не в 2,5 раза.

[fed]

Цитата:

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

Именно !
Думаю в этом все дело.
Т.е. вопрос в том на какой рынок хотят вывести Аксапту. У меня складывается ощущение что MS хочет замахнуться на рынок SAP (плох солдат который не мечтает стать генералом.

Боюсь - для этого недостаточно введения поддержки суррогатных ключей, наследования таблиц и ивентинга
Для этого надо понимать как клиентский бизнес работает и от этого строить и маркетинг, и продажи, и разработку, и работу с партнерами.А вот в этом направлении движений не намечается. Присутствует наивная вера, что партнеры (у которых не так чтобы уж дофига денег), вдруг вложатся в разработку вертикальных решений и разовьют отраслевую эскпертизу. А раньше они, конечно-же, не хотели этого делать исключительно из за отсутствия суррогатных ключей в Аксапте
Опять улучшения из серии - "They are barking at the wrong tree"

[Logger]

Цитата:

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

Боюсь - для этого недостаточно введения поддержки суррогатных ключей, наследования таблиц и ивентинга ...

С этим не поспоришь

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

[fed]

Цитата:

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

Кстати, пример про 20 байт не очень удачный. Большинство ключей, по которым идет фильтрация и объединение таблиц являются наследниками EDT NUM, который имеет длину 20 символов, т.е. 40 байт в юникоде. Т.е. разница в 5 раз,а не в 2,5 раза.

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

[Logger]

Цитата:

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

...все равно в реальной жизни почти все данные в кэше, а при чтении из памяти, выигрыш из за экономии места для типичного объема данных - небольшой.

Это все верно.
Но я подумал о том что возможно Аксапту готовят для работы в более жестких условиях. Потому что извините - когда у вас полбазы влезает в оперативку сервера БД, то это тепличные условия. Можно вообще про оптимизации не думать, а ковырять в носу весь день.

[fed]

Цитата:

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

Это все верно.
Но я подумал о том что возможно Аксапту готовят для работы в более жестких условиях. Потому что извините - когда у вас полбазы влезает в оперативку сервера БД, то это тепличные условия. Можно вообще про оптимизации не думать, а ковырять в носу весь день.

Стоимость 4 гигов серверной памяти Kingston - порядка 120 евро. Стоимость работы специалиста по производительности (в Германии) - 120 евро за час
Вообще вся реляционная теория писалась в те времена когда годовая зарплата спеца была в районе 30000, а стоимость VAX средней руки - 500000. Память была дорогой, а диски медленными. Теперь вон, в новой версии Power Pivot (которая в Denali должна быть интегрирована в SQL Server), на полном серьезе собираются почти всю базу держать в оперативке в сжатом виде. Вообще - может оказаться что привычный B-Tree уже не эффективен для хранения данных, потому что данные храняться, как правило, не на диске, а в памяти, и принятое в B-Tree деление на страницы больше не актуально (поскольку чтение идет побайтно, а не постранично).
Это я к тому, что фундаментальные книжки про проектированию БД (Типа Дейта, которого я все равно уважаю), несколько устарели. Соответственно - молиться на все эти нормальные формы и суррогатные ключи - поздновато...

[Logger]

Цитата:

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

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

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

Кстати по поводу сжатия в SQL 2008 - если не ошибаюсь страницы с индексами он не жмет (в отличие от оракла). Т.е. сжатие не поможет в ускорении работы с индексами. Только сокращение длины ключа.

[fed]

Цитата:

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

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

Типичный прирост БД на типичном внедрении - гигабайт 20-25 в год. Типичный срок жизни внедренной системы (до перевнедрения на новой версии или замены системы) - 4-5 лет. Значит о террабайтных базах можно не особо напрягаться. Ну будет 100 Гигабайт, может 200. Все что выше - не особо типично. Кстати не следует думать что джойн больших таблиц легко происходит. Вполне возможно что тот же inventTrans за 5 лет в новой структуре будет много hash-joinов использовать, которые и память и процессорное время неплохо отъедают.

Цитата:

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

Кстати по поводу сжатия в SQL 2008 - если не ошибаюсь страницы с индексами он не жмет (в отличие от оракла). Т.е. сжатие не поможет в ускорении работы с индексами. Только сокращение длины ключа.

Жмёт-жмёт. Там есть два способа сжатия.
Первый полезен для таблиц в которых много пустых числовых полей (типа inventSum). Он просто в конкретном экземпляре записи динамически усекает все decimals-поля до минимально разумной длины. В результате время вставки и обновления почти такое же как для несжатых данных, а время чтения лучше процентов на 15-20 (но учитывая что с диска данные редко читаются, выигрыш для конкретных запросов не столь велик).
Второй способ - как раз таки традиционный Run Length Encoding, который в Microsoft FoxpPro использовался с 1989 года То есть - поскольку у нас с индексной странице данные отсортированы, то можно не записывать данные как "Иванов","Иванов","Иванов", "Ивановский", а записать "Иванов", 0x6,0x6,0x6"ский".Правда этот способ сжатия хорошо работает, только если у тебя ключи в индексе отсортированы так, что наиболее уникальные поля- в конце списка. Если у тебя индекс с recId начинается, большой выгоды от такого сжатия не будет. Замечу что такой способ сжатия позволяет сильно (типа процентов на 40-60) сэкономить на времени чтения (с диска), но время записи выростает процентов на 15-20, а нагрузка на проц во время записи - еще сильнее.