AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.03.2008, 12:37   #1  
Tarrash is offline
Tarrash
Участник
 
41 / 11 (1) +
Регистрация: 03.08.2005
CustInvoiceTrans кластерный индекс
Всем доброго времени суток!

Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId? Не приведет ли это к снижению производительности при массовой обработки накладных в заказах?
Ведь в тройке индекс не был кластерным.
Заранее спасибо за пояснения.
Старый 24.03.2008, 12:38   #2  
Tarrash is offline
Tarrash
Участник
 
41 / 11 (1) +
Регистрация: 03.08.2005
Кластерный индекс на таблице CustInvoiceTrans
Старый 24.03.2008, 12:52   #3  
AvrDen is offline
AvrDen
Участник
 
134 / 26 (1) +++
Регистрация: 04.08.2005
Адрес: Усть-Каменогорск
Создание кластерных индексов на крупных таблицах, вряд ли оправдано
Старый 24.03.2008, 12:59   #4  
konopello is offline
konopello
SAP
SAP
 
628 / 76 (4) ++++
Регистрация: 08.11.2005
Адрес: Минск
Цитата:
Кто нибудь, подскажет, зачем в DAX4 понадобилось создавать кластерный индекс по RecId?
ну если подумать что recId теперь состоит с 64-бит и выделяется инкрементно, то проводки физически будет расположены в порядке их создания.
За это сообщение автора поблагодарили: Tarrash (1).
Старый 24.03.2008, 13:09   #5  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Создание кластерных индексов на крупных таблицах, вряд ли оправдано
Каким образом кластерность индекса зависит от размера таблицы и почему ?
Старый 24.03.2008, 13:14   #6  
Tarrash is offline
Tarrash
Участник
 
41 / 11 (1) +
Регистрация: 03.08.2005
А не может быть такой ситуации (пока теоретически).

Допустим первая обработка зарезервировала несколько десятков тысяч значений RecId.

В это время другая обработка вставляет уже другие записи (RecId резервируется позднее).

После этого вставляются с записи из первой обработки.
Причем значения RecId будут меньше, чем из второй обработки.
В результате перестроение кластерного индекса.

Ведь резервирование RecId осуществляется средствами DAX-а а не SQL
Старый 24.03.2008, 13:20   #7  
Tarrash is offline
Tarrash
Участник
 
41 / 11 (1) +
Регистрация: 03.08.2005
Андре, дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц (это в основном справочники). И konopello абсолютно прав, если записи вставляются в СТРОГОМ порядке возрастания RecId то обновление кластерного индекса по RecId не приводит к большим затратам по производительности. Но вопрос, всегда ли записи будут вставляться СТРОГО по возрастанию RecId?
Старый 24.03.2008, 13:20   #8  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Не приведет ли это к снижению производительности при массовой обработки накладных в заказах?
Если для вас это важный вопрос - я бы поднял копию базы и погонял бы типичные сценарии работы с обоими вариантами индекса.
Старый 24.03.2008, 13:29   #9  
Tarrash is offline
Tarrash
Участник
 
41 / 11 (1) +
Регистрация: 03.08.2005
Спасибо за совет, Андре. Мы конечно погоняем тесты в разных варинатах, проанализируем планы выполнения запросов и т. п. и примем решение.

Но все равно интересно, почему именно для этой таблицы CustInvoiceTrans нужно было создавать кластерный индекс (прошу извинения за излишнюю дотошность). По InventTrans, например, нет кластерного индекса.
Старый 24.03.2008, 13:34   #10  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от Tarrash Посмотреть сообщение
дело в том что кластерные индексы оправданы в основном для редко изменяемых таблиц
Простите, а на чем основывается подобное заявление?
Старый 24.03.2008, 13:38   #11  
Tarrash is offline
Tarrash
Участник
 
41 / 11 (1) +
Регистрация: 03.08.2005
Yprit, примерно что-то подобное уже обсуждалось

Посмотрите, пожалуйста,

Кластерный индекс на InventTrans в AX 4.0
Старый 24.03.2008, 13:42   #12  
Tarrash is offline
Tarrash
Участник
 
41 / 11 (1) +
Регистрация: 03.08.2005
Yprit, вернее было бы сказать, индекс оправдан для, таблиц для которых значение ключа кластерного индекса монотонно возрастает/убывает или вставка записей в данную таблицу происходит достаточно редко. Прошу извинения, если не четко формулирую проблему. Но вопрос в другом: насколько ОПРАВДАН кластерный индекс ИМЕННО на таблице CustInvoiceTrans?
Старый 24.03.2008, 13:51   #13  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Tarrash, если ответить прямо на Ваш вопрос - потому что по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс. В 4-ке попытались приблизиться к этому стандарту, правда не всегда обдуманно и удачно. В случае с CustInvoiceTrans - наверное, это не лучший выход, но ничего старшного в этом я тоже не вижу.
За это сообщение автора поблагодарили: Tarrash (1).
Старый 24.03.2008, 14:01   #14  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
по BP максимально возможное число (если не все) таблицы в БД должны иметь кластерный индекс
BP здесь не первоисточник. Например, таблицы без кластерных индексов не подвержены не экстентовой дефрагментации, ни внутренней. И в случае массовой вставки/обновления/удаления - неиспользуемое пространство будет лишь дырами в страницах. И проблема будет даже не в разрастании БД, а в том, что для того, чтобы выполнить скан такой таблицы необходимо прочитать на порядок больше страниц, нежели необходимо.
Старый 24.03.2008, 14:08   #15  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от Андре Посмотреть сообщение
BP здесь не первоисточник.
Ну, когда следование конкретному правилу BP в 90% случаях действительно является оправданным, то я обычно ссылаюсь на BP Можно обсудить, конечно, и преимущества куч перед кластреными индесами, и конкретные случаи выигрыша без использования кластерных индексов. Но это, скорее, для sql.ru уже. Поэтому я просто с Вами соглашусь Ну и ссылочку для комплекта

http://www.microsoft.com/technet/pro.../clusivsh.mspx
Старый 24.03.2008, 14:20   #16  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
Цитата:
Можно обсудить, конечно, и преимущества куч перед кластреными индесами, и конкретные случаи выигрыша без использования кластерных индексов.
На всякий случай - мое сообщение выше - как раз наоборот: преимущества кластерных индексов. Дабы не ввести никого в заблуждение.
Старый 24.03.2008, 15:23   #17  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5717 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
А единственный (и основной) минус кластерного индекса состоит в том, что во всех некластерных индексах, вместо RowId хранится ключ кластерного индекса. Поэтому при выборке по некластерному индексу, фактически делается две выборки: Сначала выбираются значения ключей кластерного индекса из обычного индекса, затем по значениям этих ключей, выбираются записи из кластерного индекса. Так что я вот к рекомендации BP отношусь достаточно настороженно; Кластерный индекс однозначно лучше только в том случае, если процентов 70 выборок делается ТОЛЬКО по нему, а все остальные индексы используются только в каких-то экстремальных случаях.
Старый 24.03.2008, 15:32   #18  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от fed Посмотреть сообщение
А единственный (и основной) минус кластерного индекса состоит в том, что во всех некластерных индексах, вместо RowId хранится ключ кластерного индекса
Ну и отлично, ведь кластерный индекс - это сами данные и есть
Старый 24.03.2008, 15:41   #19  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5717 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Yprit Посмотреть сообщение
Ну и отлично, ведь кластерный индекс - это сами данные и есть
Не совсем. В кластерном индексе тоже может быть несколько уровней у дерева. То есть - если у нас все индексы обычные, мы после сканирования получили список rowid и на доступ к каждой записи по rowid нам требуется ОДНО обращение к диску. В случае наличия кластерного индекса, если мы отсканировали обычный индекс, мы получили список ключей кластерного индекса. И потом для поиска каждой такой записи нам нужно минимум ДВА доступа к диску (вырожденный случай, когда у нас вся таблица влезла в одну страницу не рассматриваем). А если записей нас много - то и уровней в кластерном индексе может быть 3-4-5. Соответственно - поиск по обычному индексу занял 3 доступа к диску, а потом еще поиск по кластерному индексу занял 3 доступа к диску. Время поиска выросло почти в два раза...
Старый 24.03.2008, 16:22   #20  
Yprit is offline
Yprit
Злыдни
Аватар для Yprit
Злыдни
 
419 / 93 (4) ++++
Регистрация: 22.02.2004
Адрес: СПб
Цитата:
Сообщение от fed Посмотреть сообщение
после сканирования получили список rowid
или список ключей кластерного индекса ДЛЯ СТРОК. Плюс не будем забывать о всяких хитрых алгоритмах read-ahead, которые работают только на кластерах. Плюс "метание" по страницам. И т.п.
Теги
ax4.0

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Кластерный индекс на InventTrans в AX 4.0 Ivanhoe DAX: Администрирование 42 23.03.2016 16:42
Создание CustInvoiceJour, CustInvoiceSalesLink, CustInvoiceTrans from X++ DmitrySincerity DAX: Программирование 12 15.12.2008 18:40
Не работает индекс в отчете dreamer DAX: Программирование 8 10.07.2008 16:00
Уникальный индекс по Dimension DreamCreator DAX: Программирование 5 26.05.2006 12:57
Кластерный индекс DreamCreator DAX: Программирование 2 05.10.2005 10:06
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:43.