Возник тут у нас небольшой спор: какой индекс (кластерный конечно) будет быстрее, построенный по колонке с типом BIGINT, или же по NVARCHAR(32) (GUID). Собственно я утверждаю что для системы, которая делает примерно 1000 вставок в час разница не будет заметна, а мой оппонент утверждает что вставка в BIGINT будет происходить быстрее, и быстрота будет обусловоена тем что быстрее будет перестраиваться индекс...
Вот собственно вопрос: кто прав? или кто правее из нас...
P.S.: каждую нось отрабатывает задача по перестройке всех индексов
P.P.S.: используем MS SQL Server 2005 Developer Edition
Здравствуйте, soljen, Вы писали:
s> Возник тут у нас небольшой спор: какой индекс (кластерный конечно) будет быстрее, построенный по колонке с типом BIGINT, или же по NVARCHAR(32) (GUID).
BIGINT
s> P.S.: каждую нось отрабатывает задача по перестройке всех индексов
Здравствуйте, soljen, Вы писали:
S>Возник тут у нас небольшой спор: какой индекс (кластерный конечно) будет быстрее, построенный по колонке с типом BIGINT, или же по NVARCHAR(32) (GUID). Собственно я утверждаю что для системы, которая делает примерно 1000 вставок в час разница не будет заметна, а мой оппонент утверждает что вставка в BIGINT будет происходить быстрее, и быстрота будет обусловоена тем что быстрее будет перестраиваться индекс...
bigint и обрабатывается быстрее при том же размере и сам его размер меньше, так что bigint победит.
Напишите небольшой тест и проверьте, заодно расскажете на сколько процентов что быстрее.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, vmpire, Вы писали:
V>>bigint и обрабатывается быстрее при том же размере и сам его размер меньше, так что bigint победит. L>Размер (в данном случае) не имеет значения, причина в другом. обрати внимание не то, что индекс — кластерный, это важо
Обратил. Поэтому и написал. Эта колонка будет целиком копироваться в страницы индекса, кроме конечных (где она будет по любому).
Если размер меньше, то и индекс будет меньше, то есть на одну страницу индекса влезет больше записей и средняя глубина индекса будет меньше.
Эффект невелик, но имеет место.
Здравствуйте, vmpire, Вы писали:
V>>>bigint и обрабатывается быстрее при том же размере и сам его размер меньше, так что bigint победит. L>>Размер (в данном случае) не имеет значения, причина в другом. обрати внимание не то, что индекс — кластерный, это важо V>Обратил. Поэтому и написал. Эта колонка будет целиком копироваться в страницы индекса, кроме конечных (где она будет по любому). V>Если размер меньше, то и индекс будет меньше, то есть на одну страницу индекса влезет больше записей и средняя глубина индекса будет меньше.
Это не является особенностью кластерного индекса.
V>Эффект невелик, но имеет место.
> V>>bigint и обрабатывается быстрее при том же размере и сам его размер > меньше, так что bigint победит. > L>Размер (в данном случае) не имеет значения, причина в другом. обрати > внимание не то, что индекс — кластерный, это важо > Обратил. Поэтому и написал. Эта колонка будет целиком копироваться в > страницы индекса, кроме конечных (где она будет по любому). > Если размер меньше, то и индекс будет меньше, то есть на одну страницу > индекса влезет больше записей и средняя глубина индекса будет меньше. > Эффект невелик, но имеет место.
1000 вставок в час?! Да можно забить полностью! Вообще, даже не
поднимать этот вопрос! А если бы кто-то в моей команде затеял такой
спор, я бы наверное заставил провести всестороннее измерение этого
аспекта на нескольких системах с подготовкой подробного отчета, и с
последующим представлением этого отчета всем коллегам. В нерабочее время!
Предпосылки такие. Разница в размерах BIGINT и nvarchar(32) 64 бита
против 512 бит (я бы посоветовал снизить до 256, просто заменив на
char(32)) — не такая, чтобы загрузить подсистему ввода-вывода
современных машин. Какое бы поле вы не выбрали при 1000 вставках в час
сервер будет простаивать практически все время.
Здравствуйте, soljen, Вы писали:
S>Возник тут у нас небольшой спор: какой индекс (кластерный конечно) будет быстрее, построенный по колонке с типом BIGINT, или же по NVARCHAR(32) (GUID). Собственно я утверждаю что для системы, которая делает примерно 1000 вставок в час разница не будет заметна, а мой оппонент утверждает что вставка в BIGINT будет происходить быстрее,
На 1000 вставках в час, разницу не увидите даже в микроскоп.
На практике, в достаточно нагруженных OLTP приложениях с миллионами записей в таблицах, разница между int и GUID для 2000 сиквела составляла порядка 15-20% в пользу int.
S>и быстрота будет обусловоена тем что быстрее будет перестраиваться индекс... S>P.S.: каждую нось отрабатывает задача по перестройке всех индексов
Как имеено перестраиваются индексы?
S>P.P.S.: используем MS SQL Server 2005 Developer Edition
В продакшене?
Здравствуйте, Other Sam, Вы писали:
OS>1000 вставок в час?! Да можно забить полностью! Вообще, даже не OS>поднимать этот вопрос! А если бы кто-то в моей команде затеял такой OS>спор, я бы наверное заставил провести всестороннее измерение этого OS>аспекта на нескольких системах с подготовкой подробного отчета, и с OS>последующим представлением этого отчета всем коллегам. В нерабочее время!
Сколько эмоций
Ну хочется людям порешать теоретический вопрос, что плохого-то? Они же не в вашей команде.
Кстати, Ваш метод борьбы с расходом времени на ерунду порочен: прослывёте среди команды нервным занудой.
Здравствуйте, Lloyd, Вы писали:
V>>Если размер меньше, то и индекс будет меньше, то есть на одну страницу индекса влезет больше записей и средняя глубина индекса будет меньше. L>Это не является особенностью кластерного индекса.
Я этого и не утверждал.
V>>Эффект невелик, но имеет место. L>Но речь не об этом.
Речь о скорости работы, нет?
Здравствуйте, soljen, Вы писали:
S>Собственно я утверждаю что для системы, которая делает примерно 1000 вставок в час разница не будет заметна
Правда S>а мой оппонент утверждает что вставка в BIGINT будет происходить быстрее, и быстрота будет обусловоена тем что быстрее будет перестраиваться индекс...
Тоже правда S>Вот собственно вопрос: кто прав? или кто правее из нас...
Оба правы. У вас нет спора, т.к. ваши утверждения касаются разных вещей (ну типа вы — это красная машина, он — нет она большая
Для СИСТЕМЫ которая делает примерно 1000 вставок в час разница не будет заметна, хотя ВСТАВКА в BIGINT будет происходить быстрее.
Здравствуйте, IB!
IB>На практике, в достаточно нагруженных OLTP приложениях с миллионами записей в таблицах, разница между int и GUID для 2000 сиквела составляла порядка 15-20% в пользу int.
Это для вставок или для выборок?
На тормоз-машине (cel 2.4|512 памяти) разрыв в select был в 25-40% (холодный старт) на 100k — оно даже из памяти не выпадало в теории.
Re[3]: какой индекс будет быстрее
От:
Аноним
Дата:
25.01.10 06:11
Оценка:
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IB!
IB>>На практике, в достаточно нагруженных OLTP приложениях с миллионами записей в таблицах, разница между int и GUID для 2000 сиквела составляла порядка 15-20% в пользу int.
S>Это для вставок или для выборок? S>На тормоз-машине (cel 2.4|512 памяти) разрыв в select был в 25-40% (холодный старт) на 100k — оно даже из памяти не выпадало в теории.
что то мне кажется 40% многовато на выборке
что за запрос конечно
Здравствуйте, Аноним:
А>что то мне кажется 40% многовато на выборке
Нормально — табличка из одного столбца. Если интересует, могу поискать скрипт.
А>что за запрос конечно
Я ж говорю: тормоз-машина: из 512 метров половина занята сторонними сервисами + касперским. Самое оно для тестирования на узкие места в экстремальных условиях.
Ну и 4 кросс-жойна слегка помогли
Здравствуйте, IB, Вы писали:
IB>На практике, в достаточно нагруженных OLTP приложениях с миллионами записей в таблицах, разница между int и GUID для 2000 сиквела составляла порядка 15-20% в пользу int.
На практике разрабатываемая система не будет настолько загружена...
S>>и быстрота будет обусловоена тем что быстрее будет перестраиваться индекс... S>>P.S.: каждую нось отрабатывает задача по перестройке всех индексов IB>Как имеено перестраиваются индексы?
Визардом создан Maintenance Plan, в подробности не вникал... Судя по отчётам, которые рассылаются — то время выполнения всех действия — меньше 5 минут, я предполагаю что практически ничего не перестраивается — нет в этом необходимости!
S>>P.P.S.: используем MS SQL Server 2005 Developer Edition IB>В продакшене?
Нет конечно! Это среда разработки. На продакшене у заказчика стоит Enterprise в кластере... сколько чего — информации нет.
Здравствуйте, Sinix, Вы писали:
S>Это для вставок или для выборок?
Для всего, смотрели типичные сценарии конкретного приложения, хотя вставка была не так критична. Железо, по тем временам, было довольно не плохое.
Здравствуйте, soljen, Вы писали:
S>Доброго времени суток!
S>Возник тут у нас небольшой спор: какой индекс (кластерный конечно) будет быстрее, построенный по колонке с типом BIGINT, или же по NVARCHAR(32) (GUID).
Ну так у слову: а зачем GUID в nvarchar(32)? Чем родной для гуида uniqueidetifier не угоден?
Мы уже победили, просто это еще не так заметно...
