Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Вопрос относительно хранения данных при clustered index
|
|||
|---|---|---|---|
|
#18+
Во всех виденных мною местах (и в Book Online тоже) написано, что "При наличии кластерного индекса, страницы в базе данных и строки внутри них размещаются в ключевой последовательности кластерного индекса. Все вставки выполняются по ключевому значению с сохранением последовательности ключей." Я это трактую, как последовательное расположение данных таблицы в файле. Возникает вопрос. Я добавляю в таблицу n записей, согласно установленному кластерному индексу они должны находиться в начале таблицы. Сервер что, раздвигает остальные страницы с данными и запиивает новую страницу(цы) в середину? Если да, то как он справляется с такой нагрузкой -двигать сотни гигабайт? Если нет, то как на самом деле? Приветствуются ссылки на документацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2001, 12:41 |
|
||
|
Вопрос относительно хранения данных при clustered index
|
|||
|---|---|---|---|
|
#18+
Документация - BOL: \SQL Server Architecture\Database Architecture\Physical Database Architecture\Table and Index Architecture\Clustered Indexes Кратко - речь идёт о логических блоках (страницах). При вставке в начало записи вставляются в дырки, если их нет, добавляется страница, если нет - экстент. Наверное, так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2001, 13:18 |
|
||
|
Вопрос относительно хранения данных при clustered index
|
|||
|---|---|---|---|
|
#18+
Сотни гигабайт не двигаются, сколько данных приходится перемещать зависит от заполненности страниц, см. в BOL - Clustered indexes -> fill factor ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2001, 13:33 |
|
||
|
Вопрос относительно хранения данных при clustered index
|
|||
|---|---|---|---|
|
#18+
>Если да, то как он справляется с такой нагрузкой - двигать сотни гигабайт Не знаю как насчет сотен гигабайт и как там что двигается, но вот личные наблюдения. База ~100 000 000 записей, ~30Gb добавление 10 000 000 записей - при наличии "непраильного" кластерного индекса - 6-7 часов(~100 000 записей должны попасть в середину таблиц) - при наличии "правильного" кластерного индекса - 1-1.5 часов Transaction log при наличии кластерного индекса то же растет до 8-10Gb. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2001, 13:40 |
|
||
|
Вопрос относительно хранения данных при clustered index
|
|||
|---|---|---|---|
|
#18+
Данные в базе данных хранятся в виде B-дерева. Структура B-дерева как раз расчитана на то, чтобы при логической упорядоченности данных физические их передвижки свести к минимуму. В общем и целом наличие кластерного индекса приводит к дополнительным потерям на перемещение данных, однако их бОльшая часть происходит лишь в пределах одной страницы данных. Наличие индексов вообще (и некластерных в том числе) замедляет выполнение команд Update и Insert, хотя ускоряет выполнение команды select (да и то не всегда). На то и голова программистам, чтобы думать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2001, 18:09 |
|
||
|
Вопрос относительно хранения данных при clustered index
|
|||
|---|---|---|---|
|
#18+
Насчет сотен гигабайт это я конечно прогорячился, на 3 порядка. Сотни мегабайт конечно же. И еще добавлю, что интересует mssql 6.5. Вставка в "дырки" внутри страниц это понятно, а вот нет дырок - добавляем страницу. Где физически будет расположена эта страница? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2001, 04:41 |
|
||
|
Вопрос относительно хранения данных при clustered index
|
|||
|---|---|---|---|
|
#18+
Если нет "дырок" то выполняется операция, назывемая page split, т.е. создается еще одна страница половина данных остается на старой, а вторая половина переносится на новую. В образовавшуюся "дырку" будут занесены данные. Если размер вставляемых данных больше полученной "дырки", то page split повторяется. Физически новая страница будет в другом месте, а логически в соответствии с clustered index. Получается фрагментация данных. Потому Microsoft рекомендует время от времени перестраивать clustered index'ы для дефрагментации. Более того при update, если размер новых данных не помещается в место используемое записью (например при использоании varchar), то в реальности происходит delete и insert с page split. Самый плохой случай, когда используется неуникальный Clustered Index. Clustered Index существенно замедляет скорость модификации данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2001, 05:54 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32016051&tid=1825190]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 357ms |

| 0 / 0 |
