MSSQL2008 INT vs SMALLINT vs TINYINT & performance - Базы данных

Здравствуйте, Nonmanual Worker, Вы писали:

NW>Это говорил докладчик с официальной презентации SQL Server 2005 в России. К сожалении ссылки или записи нет.

Сам я прикладным программированием баз не занимаюсь, поэтому поверил им на слово.
Но сейчас все-же решил проверть это дело, дабы не быть голословным.
В инете нарыл несколько противоречивых данных, но всеже основоное
http://msdn.microsoft.com/en-us/library/bb508963(SQL.90).aspx
т.е. дело касается только numeric и decimal.
Только что проверил сам, поигравшись с тестовой таблицей и sp_estimated_rowsize_reduction_for_vardecimal.
Итоги:
1) Vardecimal Storage Format касается только numeric и decimal. Int и прочие — формат фиксированной длины (по крайней мере не документировано обратное и sp_estimated_rowsize_reduction_for_vardecimal считает размер таких полей фиксированным).
Появился Vardecimal Storage Format в SQL Server SP2.
2) В SQL Server 2008 это дело "is deprecated". Рекомендуют использовать сжатие на уровне базы данных.

Прошу прощения что ввел вас в заблуждение, хотя добросовестно заблуждался сам.

Здравствуйте, Nonmanual Worker, Вы писали:

NW>Здравствуйте, Tom, Вы писали:

Tom>>Всем привет, есть табличка с большим количеством записей. Несколько миллионов.
NW>Т.е. вы хотели сказать небольшая?

Tom>>В табличке есть поля int которые могут быть сконвертированы в SMALLINT | TINYINT. Внимание вопрос

имеет ли это смысл с точки зрения производительности

NW>В 2005 серваке даные места занимать меньше будут на дисках. В абсолюте в 4 раза.

А волосы будут на 67.5% шелковистее. Я гарантирую это.

Здравствуйте, Tom, Вы писали:

NW>>2) В SQL Server 2008 это дело "is deprecated". Рекомендуют использовать сжатие на уровне базы данных.
Tom>Можно ссылку на BOL?

http://msdn.microsoft.com/en-us/library/ms143729.aspx

P.S.
Гугл рулит.
http://www.google.com/search?hl=en&hs=fXh&q=Vardecimal+Storage+Format+SQL+Server+2008+is+deprecated&btnG=Search&aq=f&oq=&aqi=

Всем привет, есть табличка с большим количеством записей. Несколько миллионов. В табличке есть поля int которые могут быть сконвертированы в SMALLINT | TINYINT. Внимание вопрос

имеет ли это смысл с точки зрения производительности

Здравствуйте, Tom, Вы писали:

Tom>Всем привет, есть табличка с большим количеством записей. Несколько миллионов. В табличке есть поля int которые могут быть сконвертированы в SMALLINT | TINYINT. Внимание вопрос

имеет ли это смысл с точки зрения производительности.

Размер одной записи какой?

___>Размер одной записи какой?
Точно сейчас не скажу, как раз оптимизируем эту таблицу. Там несколько Nварчаров есть

Здравствуйте, Tom, Вы писали:

Tom>Всем привет, есть табличка с большим количеством записей. Несколько миллионов.
Т.е. вы хотели сказать небольшая?

Tom>В табличке есть поля int которые могут быть сконвертированы в SMALLINT | TINYINT. Внимание вопрос

имеет ли это смысл с точки зрения производительности

В 2005 серваке даные места занимать меньше будут на дисках. В абсолюте в 4 раза.

Здравствуйте, Tom, Вы писали:

___>>Размер одной записи какой?
Tom>Точно сейчас не скажу, как раз оптимизируем эту таблицу. Там несколько Nварчаров есть

Вобщем если запись, к примеру, 10 байт — то замена 1 int на smallint — +20% меньше места, 20% меньше супердорого дискового I/O.

имеет ли это смысл с точки зрения производительности

Индексы по ним есть?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, _d_m_, Вы писали:

___>А волосы будут на 67.5% шелковистее. Я гарантирую это.

Топикстартер писал табличке есть поля int
Например. 10 полей = -30байт*10млн записей = примерно 300 мегабайт.
___меньше супердорого дискового I/O.
А также
-быстрее "сверхдолгий" бэкап
-меньше "сверхдорогих" носителей для бэкапов

А если в базе 1000 полей int?

И это простой сменой типа поля. Так что ничего смешного. Продолжайте увеличивать шелковистость ваших, скорее всего белых, волос

Кстати, я ошибся, это будет полезно на на серваках версий до 2005. В 2005-ом и далее хранение целых чисел оптимизировано на подобие varchar. Отсюда ответ топикстартеру — скорее всего тезультата не будет ни какого ни в размере ни в скорости для серваков 2005ых и выше.

Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, Tom, Вы писали:

___>>>Размер одной записи какой?
Tom>>Точно сейчас не скажу, как раз оптимизируем эту таблицу. Там несколько Nварчаров есть
Если маленькие нvarчары заменить на нчары, то тож может быть прирост в скорости, и меньше фрагментация при добавлении/удалении/изменении.

___>Вобщем если запись, к примеру, 10 байт — то замена 1 int на smallint — +20% меньше места, 20% меньше супердорого дискового I/O.
И больше скорость поиска по, возможно имеющему место быть, супер(не)кластерному индексу.

Ну и чуство суперсвежести на весь супердень. :)

Tom пишет:

> Всем привет, есть табличка с большим количеством записей. Несколько
> миллионов. В табличке есть поля int которые могут быть сконвертированы в
> SMALLINT | TINYINT. Внимание вопрос имеет ли это смысл с точки зрения
> производительности

Имеет. Особенно при очень больших таблицах.
Чем меньше поле, тем меньше его длина, меньше суммарная длина
записи, больше записей влезает на одну страницу, меньше страниц
надо читать, чтобы прочитать удельное кол-во записей,
и следовательно производительность растёт.

Но, естественно, нужно оценить процент уменьшения средней длины
записи при переходе. Если это изменение будет в килобайтной
записи, с INT (4 байта) на TINYINT (1 байт), разница будет
в 3 байта на килобайт, это будет почти незаметно.

Если же это, скажем, таблица связи с двумя идентификаторами
в PK, и всё -- прирост может быть в разы.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, MasterZiv, Вы писали:

MZ>Имеет. Особенно при очень больших таблицах.
MZ>Чем меньше поле, тем меньше его длина, меньше суммарная длина
MZ>записи, больше записей влезает на одну страницу, меньше страниц
MZ>надо читать, чтобы прочитать удельное кол-во записей,
MZ>и следовательно производительность растёт.

MZ>Но, естественно, нужно оценить процент уменьшения средней длины
MZ>записи при переходе. Если это изменение будет в килобайтной
MZ>записи, с INT (4 байта) на TINYINT (1 байт), разница будет
MZ>в 3 байта на килобайт, это будет почти незаметно.

MZ>Если же это, скажем, таблица связи с двумя идентификаторами
MZ>в PK, и всё -- прирост может быть в разы.

Я так понимаю, никто не читает предыдущие посты...
НЕ БУДЕТ ВЫИГРЫША
Я же ясно написал, что в 2005-ом и далее хранение целых чисел оптимизировано на подобие varchar. Если значени поля типа INT равно 100, то под него 2005 сервак отведет не 4 байта, а меньше. Отсюда ответ топикстартеру — скорее всего результата не будет ни какого ни в размере ни в скорости для серваков 2005ых и выше.

Здравствуйте, Nonmanual Worker, Вы писали:

NW>Я же ясно написал, что в 2005-ом и далее хранение целых чисел оптимизировано на подобие varchar. Если значени поля типа INT равно 100, то под него 2005 сервак отведет не 4 байта, а меньше.

Наверное стоит уточнить: если БД была обновлена с предыдущих версий посредством in-place upgrade, данные останутся в прежнем формате.

NW>Я так понимаю, никто не читает предыдущие посты...
NW>НЕ БУДЕТ ВЫИГРЫША
NW>Я же ясно написал, что в 2005-ом и далее хранение целых чисел оптимизировано на подобие varchar. Если значени поля типа INT равно 100, то под него 2005 сервак отведет не 4 байта, а меньше. Отсюда ответ топикстартеру — скорее всего результата не будет ни какого ни в размере ни в скорости для серваков 2005ых и выше.

А можно ссылку на BOL или другой источник информации?

PS;
Планируем использовать MS SQL 2008

Здравствуйте, Tom, Вы писали:

Tom>А можно ссылку на BOL или другой источник информации?
Tom>Планируем использовать MS SQL 2008

Я тоже стал проверять и не нашел. Только тип numeric позволяет хранить значения разной длины в зависимости от точности.

Precision	Storage bytes
1-9	5
10-19	9
20-28	13
29-38	17

http://msdn.microsoft.com/en-us/library/ms187746.aspx

Но дискретность все равно достаточно большая. Я полагал, что SQL Server уже догнал основных конкурентов в плане компактности хранения чисел.

Здравствуйте, Tom, Вы писали:

NW>>Я так понимаю, никто не читает предыдущие посты...
NW>>НЕ БУДЕТ ВЫИГРЫША
NW>>Я же ясно написал, что в 2005-ом и далее хранение целых чисел оптимизировано на подобие varchar. Если значени поля типа INT равно 100, то под него 2005 сервак отведет не 4 байта, а меньше. Отсюда ответ топикстартеру — скорее всего результата не будет ни какого ни в размере ни в скорости для серваков 2005ых и выше.

Tom>А можно ссылку на BOL или другой источник информации?

Tom>PS;
Tom>Планируем использовать MS SQL 2008

Это говорил докладчик с официальной презентации SQL Server 2005 в России. К сожалении ссылки или записи нет.

Nonmanual Worker пишет:

> Я так понимаю, никто не читает предыдущие посты...
> НЕ БУДЕТ ВЫИГРЫША
> Я же ясно написал, что в 2005-ом и далее *хранение целых чисел
> оптимизировано* на подобие varchar.

Такое я не знал. Ну если так, и это работает, то да.

Posted via RSDN NNTP Server 2.1 beta

MZ>Такое я не знал. Ну если так, и это работает, то да.
Без подтверждения как то честно говоря слабо верится. Ибо сегодня число равно 100, а завтра 0xFFFF, а после завтра опять 100. И что она каждый раз новое место под хранение будет находить...

Здравствуйте, Tom, Вы писали:

MZ>>Такое я не знал. Ну если так, и это работает, то да.
Tom>Без подтверждения как то честно говоря слабо верится.

Ничто ведь не мешает вам проверить, верно? Думаю всем будет инетресно. У меня вот нет под рукой SQL Server.

Tom>Ибо сегодня число равно 100, а завтра 0xFFFF, а после завтра опять 100. И что она каждый раз новое место под хранение будет находить...

Конечно будет, также как и для [n]varchar.

Здравствуйте, Nonmanual Worker, Вы писали:

NW>Здравствуйте, _d_m_, Вы писали:

___>>А волосы будут на 67.5% шелковистее. Я гарантирую это.

NW>Топикстартер писал табличке есть поля int
NW>Например. 10 полей = -30байт*10млн записей = примерно 300 мегабайт.
NW>___меньше супердорого дискового I/O.
NW>А также
NW>-быстрее "сверхдолгий" бэкап
NW>-меньше "сверхдорогих" носителей для бэкапов

NW>А если в базе 1000 полей int?

NW>И это простой сменой типа поля. Так что ничего смешного.

Ну так ты ничего и не понял. Я вообще про 4 раза.

NW>Продолжайте увеличивать шелковистость ваших, скорее всего белых, волос

И снова пальцем в небо.

NW>Кстати, я ошибся, это будет полезно на на серваках версий до 2005. В 2005-ом и далее хранение целых чисел оптимизировано на подобие varchar. Отсюда ответ топикстартеру — скорее всего тезультата не будет ни какого ни в размере ни в скорости для серваков 2005ых и выше.

Пальцем в небо.

NW>2) В SQL Server 2008 это дело "is deprecated". Рекомендуют использовать сжатие на уровне базы данных.
Можно ссылку на BOL?

Здравствуйте, Ziaw, Вы писали:

Tom>>Всем привет, есть табличка с большим количеством записей. Несколько миллионов. В табличке есть поля int которые могут быть сконвертированы в SMALLINT | TINYINT. Внимание вопрос

имеет ли это смысл с точки зрения производительности

Z>Индексы по ним есть?

Жаль, что я не услышал ответа на вопрос. Поясню почему он задан. Размер индексов напрямую зависит от размера полей,
и в отличии от данных, индексы читаются гораздо чаще (я про случаи когда индексы действительно нужны). Нередки случаи
когда для получения результата запроса достаточно одних индексов.

Поскольку количество записей превышает 1М, я преполагаю, что выборка идет малыми частями или агрегатами, соответственно
размер полей тут играет роль менее значимую, чем размер используемых в запросах индексов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Ziaw, Вы писали:

Z>Жаль, что я не услышал ответа на вопрос. Поясню почему он задан. Размер индексов напрямую зависит от размера полей,
Z>и в отличии от данных, индексы читаются гораздо чаще (я про случаи когда индексы действительно нужны). Нередки случаи
Z>когда для получения результата запроса достаточно одних индексов.

Ну если исходить из того что мы выяснили про механизм хранения int и подобных, а также
[msdn]
The only reason to use vardecimal storage format is to reduce the size of the table and thereby of the database. Reducing the size of the database has benefits other than the obvious savings of disk space. A smaller database leads to fewer I/Os, reduces memory pressure on the buffer pool (you can fit more information in the buffer pool), and reduces the size of a backup and thereby the time required to back up a database.

To test table scans, in a very extreme test case, a table with 20 decimal (38, 0) columns was used. After 10 million rows were inserted with only the value '0' in all columns, the table used about 450,000 pages on disk. After activating the new vardecimal format, the table used only about 14,000 pages—roughly 30 times less. The same factor was then measured for a simple sequential scan, which was also about 30 times faster after vardecimal storage format was enabled. No doubt that is a "best case" scenario that might never happen in a real-life application. But it is certain that I/O-bound scans are faster if there is a significant reduction in space due to the vardecimal storage format.
[/msdn]

то результат должен быть положительный.

Z>Поскольку количество записей превышает 1М, я преполагаю, что выборка идет малыми частями или агрегатами, соответственно
Z>размер полей тут играет роль менее значимую, чем размер используемых в запросах индексов.
Прелагаю вам проверить и написать о результатах, благо делов там на полчаса.

Здравствуйте, Nonmanual Worker, Вы писали:

Z>>Жаль, что я не услышал ответа на вопрос. Поясню почему он задан. Размер индексов напрямую зависит от размера полей,
Z>>и в отличии от данных, индексы читаются гораздо чаще (я про случаи когда индексы действительно нужны). Нередки случаи
Z>>когда для получения результата запроса достаточно одних индексов.

NW>Ну если исходить из того что мы выяснили про механизм хранения int и подобных, а также
NW>[msdn]
NW>The only reason to use vardecimal storage format is to reduce the size of the table and thereby of the database. Reducing the size of the database has benefits other than the obvious savings of disk space. A smaller database leads to fewer I/Os, reduces memory pressure on the buffer pool (you can fit more information in the buffer pool), and reduces the size of a backup and thereby the time required to back up a database.

NW>To test table scans, in a very extreme test case, a table with 20 decimal (38, 0) columns was used. After 10 million rows were inserted with only the value '0' in all columns, the table used about 450,000 pages on disk. After activating the new vardecimal format, the table used only about 14,000 pages—roughly 30 times less. The same factor was then measured for a simple sequential scan, which was also about 30 times faster after vardecimal storage format was enabled. No doubt that is a "best case" scenario that might never happen in a real-life application. But it is certain that I/O-bound scans are faster if there is a significant reduction in space due to the vardecimal storage format.
NW>[/msdn]

NW>то результат должен быть положительный.

Результат чего?

Z>>Поскольку количество записей превышает 1М, я преполагаю, что выборка идет малыми частями или агрегатами, соответственно
Z>>размер полей тут играет роль менее значимую, чем размер используемых в запросах индексов.
NW>Прелагаю вам проверить и написать о результатах, благо делов там на полчаса.

Проверить что? То, что в запросах при которых читается только индекс важен размер индкеса?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Ziaw, Вы писали:

NW>>то результат должен быть положительный.

Z>Результат чего?
Замена int на tinyint\smallint (см. пост №1) в результате положительно скажется на производительности.

Z>Проверить что? То, что в запросах при которых читается только индекс важен размер индкеса?
Заменить (см. пост №1) и проверить верность рассуждений.

Здравствуйте, Nonmanual Worker, Вы писали:

NW>Заменить (см. пост №1) и проверить верность рассуждений.

Я уже делал подобные тесты в ветке GUID vs INT.

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Ziaw, Вы писали:

Z>Я уже делал подобные тесты в ветке GUID vs INT.
И как результат?
Какая методика проведения тестов была?

Здравствуйте, Nonmanual Worker, Вы писали:

Z>>Я уже делал подобные тесты в ветке GUID vs INT.
NW>И как результат?

Если бы он был вам действительно инетересен вы бы нашли. Зависимость от размера заметная.

NW>Какая методика проведения тестов была?

Какие методики проведения тестов ресурсоемкости запросов вы знаете?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Nonmanual Worker, Вы писали:
Z>Если бы он был вам действительно инетересен вы бы нашли. Зависимость от размера заметная.
Что-то я не нашел вас в той ветке... как и результатов...

NW>>Какая методика проведения тестов была?
Z>Какие методики проведения тестов ресурсоемкости запросов вы знаете?

Таки почемю ви всегда отвечаите вопгосом на вопгос?

Здравствуйте, Nonmanual Worker, Вы писали:

NW>Что-то я не нашел вас в той ветке... как и результатов...

Я неудачно указал критерии для поиска

вот резульаты теста:
http://rsdn.ru/forum/db/2992150.1.aspx

NW>>>Какая методика проведения тестов была?
Z>>Какие методики проведения тестов ресурсоемкости запросов вы знаете?

NW>Таки почемю ви всегда отвечаите вопгосом на вопгос?

Ну а что еще можно ответить на такой шикарный вопрос?
Методики проведения тестов. Как будто я научную работу опубликовал с сотнями измерений по
различным общепринятым или не очень (но стандартизированным) методикам.
Умное лицо еще не признак ума, господа. (с)

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Ziaw, Вы писали:

Z>Ну а что еще можно ответить на такой шикарный вопрос?
Z>Методики проведения тестов. Как будто я научную работу опубликовал с сотнями измерений по
Z>различным общепринятым или не очень (но стандартизированным) методикам.
Z>Умное лицо еще не признак ума, господа. (с)

методики, методики...
да ты мудри, ты пальцем покажи

вот резульаты теста:
Z>http://rsdn.ru/forum/db/2992150.1.aspx
Вот теперь другое дело. Спасибо. Вопрос про как замеряли снят.

	От:	Nonmanual Worker
	Дата:	02.10.09 12:04
	Оценка:	8 (2)

	От:	_d_m_
	Дата:	01.10.09 08:42
	Оценка:

	От:	Nonmanual Worker
	Дата:	06.10.09 04:36
	Оценка:	8 (1)

От:	Tom	http://www.RSDN.ru
Дата:	01.10.09 06:25
Оценка:

	От:	_d_m_
	Дата:	01.10.09 06:34
	Оценка:

От:	ZAMUNDA	для жалоб и предложений
Дата:	01.10.09 12:09
Оценка:

	От:	Ziaw
	Дата:	05.10.09 08:23
	Оценка:

	От:	Ziaw
	Дата:	05.10.09 12:15
	Оценка: