Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 11   вперед  Ctrl      все
 Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
На обсуждение два предположения.


1. По SQL
Есть таблица которая хранит письма пользователей.

table mails (rowid bigint, userid bigint, mail nvarchar(max))
Так вот если на эту табличку навестить индекс (не важно какой) на поле userid, то система на SQL начнет загибатся причем сильно загибатся (при delete & insert), если число записей в таблице будет свыше 100 миллионов и ежедневно будет добавлятся 100 тысяч. Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева.
Я реально видел, как SQL (правдо старый) умирал при меньших нагрузках - по той же причине.

Прав ли я?

2. По Cache
Данна таблица

tovar(rowid bigint, tovar_id bigint, stoimost_edenitsi numeric(10,4), prodano int, data datetime)

Select *
from tovar
where tovar_id in (19,234,234523, 23523523 ,523321,12312,1314235)
OR stoimost_edenitsi*prodano int between 100.012 and 200.382
OR datetime between 'Mar 10, 2006 12:23:56' and 'Mar 30, 2006 01:23:17'


я специально написал мудреный запрос, чтобы использовать максимально не строковые значения в запросе. Полагаю, что Cache в таком запросе при 1 000 0000 сильно уступит SQL. Можно рассмотреть как вариант с индексом для таблицы так и просто Full Scan.

Прав ли я?
15 май 06, 08:57    [2662698]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Iura
1. По SQL
Есть таблица которая хранит письма пользователей.

table mails (rowid bigint, userid bigint, mail nvarchar(max))
Так вот если на эту табличку навестить индекс (не важно какой) на поле userid, то система на SQL начнет загибатся причем сильно загибатся (при delete & insert), если число записей в таблице будет свыше 100 миллионов и ежедневно будет добавлятся 100 тысяч. Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева.
Я реально видел, как SQL (правдо старый) умирал при меньших нагрузках - по той же причине.
Прав ли я?

насчет Cache ты прав - не поморщится. в последней базе, с которой я возился
и о которой писал, всасывается ежедневно от 100 до 200 тысяч записей в довольно развесистую структуру (9 индексов + штук 15 счетчиков).
для SQL в полный рост встанет проблема размера БД. и если для Cache я могу
оценить укладывание 90 млн. записей + (90 млн. * 8) индексов в 15.6Gb, то
для SQL я даже боюсь прикидывать.

Iura

2. По Cache
Данна таблица

tovar(rowid bigint, tovar_id bigint, stoimost_edenitsi numeric(10,4), prodano int, data datetime)

Select *
from tovar
where tovar_id in (19,234,234523, 23523523 ,523321,12312,1314235)
OR stoimost_edenitsi*prodano int between 100.012 and 200.382
OR datetime between 'Mar 10, 2006 12:23:56' and 'Mar 30, 2006 01:23:17'

я специально написал мудреный запрос, чтобы использовать максимально не строковые значения в запросе. Полагаю, что Cache в таком запросе при 1 000 0000 сильно уступит SQL. Можно рассмотреть как вариант с индексом для таблицы так и просто Full Scan.

Прав ли я?

ты упорно хочешь использовать Cache-SQL? :)
уф, при этом подходе - не знаю. при прямом доступе - никогда.
нет, может проиграть даже при прямом доступе, если в SQL используется
только одна таблица без индексов, где нет ни одного поля VARCHAR и результаты не сортируются/группируются/прочее, то есть максимально
быстрый выбор по базе. в этом случае точно проиграет. не сильно, но все же.
но это же несерьезно, ага

С уважением. Сергей
15 май 06, 16:39    [2665817]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Iura
Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева.

А как-будто в кэше нет индексного дерева?

Я вот у себя проверил - сделал табличку с парой индексов
create table #mails (rowid bigint identity, userid bigint, mail nvarchar(1000))
create index i on #mails(rowid)
create index ii on #mails(userid)
заполнил 2 млн записей лабуды (больше места у меня нет)
insert #mails select rand()*10000,convert(varchar(111), newid())

дык вот еще 200000 записей добавляются по одной за 40 сек
сделал таблику такую же, но без поля rowid и без индексов
записи по одной туда добавлялись 28 сек
из этой таблицу в первую все записи целиком добавились за 18 сек

конечно между 2 и 100 млн разница есть, но разница между 40 сек и целым днём еще больше
попробуйте у себя проверить - я например не думаю что время вставки существенно вырастет
15 май 06, 18:35    [2666515]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
SergSuper
Iura
Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева.

А как-будто в кэше нет индексного дерева?

Я вот у себя проверил - сделал табличку с парой индексов
create table #mails (rowid bigint identity, userid bigint, mail nvarchar(1000))
create index i on #mails(rowid)
create index ii on #mails(userid)
заполнил 2 млн записей лабуды (больше места у меня нет)
insert #mails select rand()*10000,convert(varchar(111), newid())

дык вот еще 200000 записей добавляются по одной за 40 сек
сделал таблику такую же, но без поля rowid и без индексов
записи по одной туда добавлялись 28 сек
из этой таблицу в первую все записи целиком добавились за 18 сек

конечно между 2 и 100 млн разница есть, но разница между 40 сек и целым днём еще больше
попробуйте у себя проверить - я например не думаю что время вставки существенно вырастет



Ты сделай кластерный индекс по userid и закидай дачиком случайных числе и текст данные в таблицу. Накопи более 100 миллионов записей и посмотри как умирать начнет твой комп.
15 май 06, 20:43    [2666861]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Iura
На обсуждение два предположения.


1. По SQL
Есть таблица которая хранит письма пользователей.

table mails (rowid bigint, userid bigint, mail nvarchar(max))
Так вот если на эту табличку навестить индекс (не важно какой) на поле userid, то система на SQL начнет загибатся причем сильно загибатся (при delete & insert), если число записей в таблице будет свыше 100 миллионов и ежедневно будет добавлятся 100 тысяч. Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева.
Я реально видел, как SQL (правдо старый) умирал при меньших нагрузках - по той же причине.

Прав ли я?

Не прав.

Во-первых индекс очень даже важно какой. Древовидные индексы имеют разное заполнение, очень может повлиять на производительность. Еще они бывают кластерными, а бывают и вовсе хеш индексы. Все работает по-разному в смысле производительности в разных ситуациях.
Во-вторых есть еще, например, partishioned tables, там у каждой партиции может быть свой индекс и вообще без разницы сколько в таблице всего записей.

Тестировали как-то вставку сайбез АСА 8 на 6 млн, существенного замедления по сравнению со 100000 не наблюдалось, работало на пару процентов медленнее. Вряд ли на 100 млн. вылезут принципиально новые проблемы. Оборудование было не серверное, обычный десктоп с иде дисками.
15 май 06, 23:11    [2667039]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Iura

Ты сделай кластерный индекс по userid и закидай дачиком случайных числе и текст данные в таблицу. Накопи более 100 миллионов записей и посмотри как умирать начнет твой комп.

Убить при можно любую систему, дело только в наличии желания. Из хелпа по АСА9
CLUSTERED keyword
The CLUSTERED attribute causes table rows to be stored in an approximate key order corresponding to the index. While the server makes an attempt to preserve key order, total clustering is not guaranteed.
If a clustered index exists, the LOAD TABLE statement inserts rows into the table in the order of the index key, and the INSERT statement attempts to put new rows on the same table page as the one containing adjacent rows, as defined by the key order.

Это ж оно пыталось перестроить таблицу (не индекс, а именно таблицу) каждый раз при добавлении новой записи со случайным значением в индекированном поле. Ну может не каждой, но периодически перестраивало.
15 май 06, 23:26    [2667053]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
c127
Iura

Ты сделай кластерный индекс по userid и закидай дачиком случайных числе и текст данные в таблицу. Накопи более 100 миллионов записей и посмотри как умирать начнет твой комп.

Убить при можно любую систему, дело только в наличии желания. Из хелпа по АСА9
CLUSTERED keyword
The CLUSTERED attribute causes table rows to be stored in an approximate key order corresponding to the index. While the server makes an attempt to preserve key order, total clustering is not guaranteed.
If a clustered index exists, the LOAD TABLE statement inserts rows into the table in the order of the index key, and the INSERT statement attempts to put new rows on the same table page as the one containing adjacent rows, as defined by the key order.

Это ж оно пыталось перестроить таблицу (не индекс, а именно таблицу) каждый раз при добавлении новой записи со случайным значением в индекированном поле. Ну может не каждой, но периодически перестраивало.


Вот вот! Но и индекс тоже, чтобы хранить ссылку на страницу
16 май 06, 09:06    [2667470]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Iura
Ты сделай кластерный индекс по userid и закидай дачиком случайных числе и текст данные в таблицу. Накопи более 100 миллионов записей и посмотри как умирать начнет твой комп.

У меня нет возможности сделать такую большую базу. Если у Вас есть - попробуйте и выложите цифры.
Пока что есть только Ваши ощущения
И кстати: зачем делать именно кластерный индекс? Его применение далеко не всегда оправдано.
16 май 06, 10:54    [2668012]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iliker
Member

Откуда:
Сообщений: 21
c127
Убить при можно любую систему, дело только в наличии желания. Из хелпа по АСА9
CLUSTERED keyword
The CLUSTERED attribute causes table rows to be stored in an approximate key order corresponding to the index. While the server makes an attempt to preserve key order, total clustering is not guaranteed.
If a clustered index exists, the LOAD TABLE statement inserts rows into the table in the order of the index key, and the INSERT statement attempts to put new rows on the same table page as the one containing adjacent rows, as defined by the key order.

Это ж оно пыталось перестроить таблицу (не индекс, а именно таблицу) каждый раз при добавлении новой записи со случайным значением в индекированном поле. Ну может не каждой, но периодически перестраивало.

Обратите внимание While the server makes an attempt to preserve key order, total clustering is not guaranteed.
Не перестраивает asa каждый раз таблицу.Перестройка делается ручками при помощи reorganize table.
А MSSQL, похоже, перестраивает каждый раз.(маловато информации в MSDN)
MSDN 1
MSDN 2
16 май 06, 11:27    [2668241]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Что значит спокойнее жить? Или беспокойнее?
У нас ежедневно добавляется только 2 млн. записей (в mssql и такие же объемы в oracle).
Таблички вроде немаленькие, да и место нужно прогнозировать и индексы там имеются и все живет и не загибается.

ЗЫ: сусликофф видели? а они есть! :)
ЗЫЫ: очередной флэйм, вместо разведения которого не проще взять и поделать тесты? пусть далеко не идеальные, но на которых можно выяснить что нужно для себя под конкретные свои задачи.
16 май 06, 11:55    [2668403]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
Ценый совет и плюс в пользу MSSQL 2005
http://msdn.microsoft.com/SQL/default.aspx?pull=/library/en-us/dnsql90/html/sql2k5partition.asp&print=true
16 май 06, 12:08    [2668491]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
iliker
Не перестраивает asa каждый раз таблицу.Перестройка делается ручками при помощи reorganize table.
А MSSQL, похоже, перестраивает каждый раз.(маловато информации в MSDN)
MSDN 1
MSDN 2

При вставке записей ASA просто стремится ложить записи в конец не до конца заполненных страниц, которые по значениям кластерного ключа близки к вставляемым записям. При изменении записей сервер их оставляет на тех же страницах. В итоге получается этакая блоковая дефрагментация, где никто не гарантирует сортировки записей таблицы по кластерному ключу и страницы таблицы более менее содержат близкие по кластерному ключу записи, но не обязательно эти страницы идут одна за одной, что с моей точки зрения является вполне нормальным и оправданным демократичным подходом к организации кластерного ключа, где с одной стороны не тормозится скорость вставки новых записей, с другой стороны при выполнении запросов оптимизатор учитывает наличие кластерного ключа и получает более быстрое чтение записей засчет того, что они часто лежат в пределах одинаковых страниц. Для проведения физической полной онлайн дефрагментации таблицы по кластерному ключу (или PK eсли у теблицы нет кластерного ключа), используется оператор REORGINIZE TABLE, который во время работы не блокирует сессии и работает в фоновом режиме, незаметном для других сессий, действуя методом последовательного переноса записей в новые или пустые страницы, удаляя их с оригинальных, однако естественно реагируя на транзакции других сессий.

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

MSSQL насколько я помню, физически держит отсортированными по кластерному ключу записи и каждый раз их перестраивает, что с моей точки зрения (и видимо разработчиков ASA) не самый оптимальный вариант реализации кластерного ключа и, помимо уменьшения скорости вставки записей в таблицу с кластерным ключом, может приводить к различным нехорошим эффектам, таким, как например блокировка страниц.
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
16 май 06, 12:12    [2668511]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

Откуда:
Сообщений: 933
ASCRUS
MSSQL насколько я помню, физически держит отсортированными по кластерному ключу записи и каждый раз их перестраивает, что с моей точки зрения (и видимо разработчиков ASA) не самый оптимальный вариант реализации кластерного ключа и, помимо уменьшения скорости вставки записей в таблицу с кластерным ключом, может приводить к различным нехорошим эффектам, таким, как например блокировка страниц.

память подвела... ;)
в mssql2000 и далее есть такая штука, как fill factor, которая собственно и определяет, сколько свободного места резервировать на страницах нижнего уровня кластерного индекса.
т.е. идентично ASA
16 май 06, 12:20    [2668555]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
У нас ежедневно добавляется только 2 млн. записей (в mssql и такие же объемы в oracle).
Таблички вроде немаленькие, да и место нужно прогнозировать и индексы там имеются и все живет и не загибается.

интересно. а поконкретнее можно? сколько, например, это в мегабайтах (вместе с индексами, понятное дело)?

С уважением. Сергей
16 май 06, 12:21    [2668563]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
andy st
ASCRUS
MSSQL насколько я помню, физически держит отсортированными по кластерному ключу записи и каждый раз их перестраивает, что с моей точки зрения (и видимо разработчиков ASA) не самый оптимальный вариант реализации кластерного ключа и, помимо уменьшения скорости вставки записей в таблицу с кластерным ключом, может приводить к различным нехорошим эффектам, таким, как например блокировка страниц.

память подвела... ;)
в mssql2000 и далее есть такая штука, как fill factor, которая собственно и определяет, сколько свободного места резервировать на страницах нижнего уровня кластерного индекса.
т.е. идентично ASA

Да нет, по моему не подвела:
MSSQL BOL
Clustered tables are tables that have a clustered index.
The data rows are stored in order based on the clustered index key. The index is implemented as a B-tree index structure that supports fast retrieval of the rows based on their clustered index key values. The pages in each level of the index, including the data pages in the leaf level, are linked in a doubly-linked list, but navigation from one level to another is done using key values.

то есть записи, в отличие от ASA хранятся в порядке сортировки кластерного ключа, что по идее означает их физическое перестраивание на странице(ах). Причем тут FILL FACTOR честно говоря не понял, это просто процент резервирования на страницах свободного места для полей с плавающей длиной (во всяком случае в ASA именно так).
16 май 06, 12:32    [2668634]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

Откуда:
Сообщений: 933
ASCRUS
...

ну если есть BOL - может стоит посмотреть повнимательнее? ;)
Fill Factor
When you create a clustered index, the data in the table is stored in the data pages of the database according 
to the order of the values in the indexed columns. When new rows of data are inserted into the table or 
the values in the indexed columns are changed, Microsoft® SQL Server™ 2000 may have to reorganize the storage 
of the data in the table to make room for the new row and maintain the ordered storage of the data. 
This also applies to nonclustered indexes. When data is added or changed, SQL Server may have to reorganize 
the storage of the data in the nonclustered index pages. When a new row is added to a full index page, 
SQL Server moves approximately half the rows to a new page to make room for the new row. 
This reorganization is known as a page split. Page splitting can impair performance and fragment the storage 
of the data in a table. For more information, see Table and Index Architecture.

When creating an index, you can specify a fill factor to leave extra gaps and reserve a percentage of free space 
on each leaf level page of the index to accommodate future expansion in the storage of the table's data 
and reduce the potential for page splits. The fill factor value is a percentage from 0 to 100 that specifies how 
much to fill the data pages after the index is created. A value of 100 means the pages will be full and will 
take the least amount of storage space. This setting should be used only when there will be no changes to the data, 
for example, on a read-only table. A lower value leaves more empty space on the data pages, which reduces the 
need to split data pages as indexes grow but requires more storage space. This setting is more appropriate when t
here will be changes to the data in the table.

The fill factor option is provided for fine-tuning performance. However, the server-wide default fill factor, specified 
using the sp_configure system stored procedure, is the best choice in the majority of situations. 



Note  Even for an application oriented for many insert and update operations, the number of database reads
 typically outnumber database writes by a factor of 5 to 10. Therefore, specifying a fill factor other than 
the default can degrade database read performance by an amount inversely proportional to the fill factor setting. 
For example, a fill factor value of 50 percent can cause database read performance to degrade by two times.


It is useful to set the fill factor option to another value only when a new index is created on a table with 
existing data, and then only when future changes in that data can be accurately predicted.

The fill factor is implemented only when the index is created; it is not maintained after the index is created as data 
is added, deleted, or updated in the table. Trying to maintain the extra space on the data pages would defeat 
the purpose of originally using the fill factor because SQL Server would have to perform page splits to maintain 
the percentage of free space, specified by the fill factor, on each page as data is entered. Therefore, if the data 
in the table is significantly modified and new data added, the empty space in the data pages can fill. 
In this situation, the index can be re-created and the fill factor specified again to redistribute the data.

16 май 06, 12:42    [2668694]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
вот некоторые таблички
68 млн записей, 29гиг данные, 16 - индекс
23 12 6
23 11 5,5
28 12,4 7
200 52 23
42 11 5
173 40 17
...
ширину считать лениво, но если оченно нужно, то могу посчитать
структуру по определенным причинам привести не могу, но вообщем-то и не в этом суть, не понимаю при чем тут объемы
если взять гис какую-нить, то там может быть мало записей, но вес... как впрочем и наоборот
16 май 06, 12:47    [2668723]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Не стоит думать что SQL Server будет перестраивать 100 000 000 записей при одном добавлении. Да они храняться упорядоченно но перестраивается при добавлении и т.п. только одна страница, в крайнем случае разбивается на 2. Это абсолютно не влияет на быстродействие.

Проблема не в отсортированности записей а в размере самого индекса. Кластерный он или нет не имеет значения.

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


--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
16 май 06, 12:52    [2668758]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11404
ASCRUS
то есть записи, в отличие от ASA хранятся в порядке сортировки кластерного ключа, что по идее означает их физическое перестраивание на странице(ах).
Внутри страницы записи не сортируются в порядке кластерного ключа. Почитайте, например, Kalen Delaney "Inside SQL Server", и не надо будет фантазировать.

P.S. Всегда восхищает способность людей - по капле воды догадаться о существовании океанов. На этом форуме, к сожалению, их особенно много :(
16 май 06, 13:36    [2669052]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
вот некоторые таблички
68 млн записей, 29гиг данные, 16 - индекс
23 12 6
23 11 5,5
28 12,4 7
200 52 23
42 11 5
173 40 17
...
ширину считать лениво, но если оченно нужно, то могу посчитать
структуру по определенным причинам привести не могу, но вообщем-то и не в этом суть, не понимаю при чем тут объемы
если взять гис какую-нить, то там может быть мало записей, но вес... как впрочем и наоборот

сам размеры таблиц меня как-то слабо интересуют, меня интересовал именно суточный прирост объемов

С уважением. Сергей
16 май 06, 14:00    [2669214]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
ChA
Внутри страницы записи не сортируются в порядке кластерного ключа. Почитайте, например, Kalen Delaney "Inside SQL Server", и не надо будет фантазировать.

К слову - на курсах (авторизованных, а как же иначе...) по mssql2000 авторизованный тренер (типа преподаватель) наверно с полчаса рассказывал что в кластерном ключе mssql2000 хранит записи всегда сортированными и во всем наборе записей. Меня потом долго клинило, что же произошло - он на самом деле так считает или был вынужден повторять неудачный перевод BOL. Или он доверился проверке на десятке записей и поверил переводу. Надолго запомнилось.
16 май 06, 14:01    [2669221]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ASCRUS
MSSQL BOL
Clustered tables are tables that have a clustered index.
The data rows are stored in order based on the clustered index key. The index is implemented as a B-tree index structure that supports fast retrieval of the rows based on their clustered index key values. The pages in each level of the index, including the data pages in the leaf level, are linked in a doubly-linked list, but navigation from one level to another is done using key values.

аж на душе потеплело, так все знакомо. именно так организованы
структуры в M, ну и соответственно в том Cache, который здесь так дружно
не любят. :)

С уважением. Сергей
16 май 06, 14:03    [2669237]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
данные
148223,8125	148150,3125	H	13.01.2006 23:36:01
20715,6875	20707,9375	H	13.01.2006 23:36:01
52531,5	51845,625	V	13.01.2006 23:36:01
310500	310115,8125	F	13.01.2006 23:36:01
1000	1000	F	13.01.2006 23:36:01
лог
5042,125	307,320312	I	13.01.2006 23:36:01

данные
148223,8125	148194,5625	H	14.01.2006 23:36:00
20715,6875	20712,375	H	14.01.2006 23:36:00
52531,5	52242,0625	V	14.01.2006 23:36:00
311500	311230,125	F	14.01.2006 23:36:00
1000	1000	F	14.01.2006 23:36:00
лог
5546,375	5406,828125	I	14.01.2006 23:36:00

H,V - индексы
16 май 06, 14:42    [2669498]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
зы: данные в Мб, первый столбец - общий объем, второй - используемый
16 май 06, 14:45    [2669525]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
ASCRUS
то есть записи, в отличие от ASA хранятся в порядке сортировки кластерного ключа, что по идее означает их физическое перестраивание на странице(ах). Причем тут FILL FACTOR честно говоря не понял, это просто процент резервирования на страницах свободного места для полей с плавающей длиной (во всяком случае в ASA именно так).

FILLFACTOR = fillfactor

Specifies a percentage that indicates how full SQL Server should make the leaf level of each index page during index creation. When an index page fills up, SQL Server must take time to split the index page to make room for new rows, which is quite expensive. For update-intensive tables, a properly chosen FILLFACTOR value yields better update performance than an improper FILLFACTOR value. The value of the original FILLFACTOR is stored with the index in sysindexes.

When FILLFACTOR is specified, SQL Server rounds up the number of rows to be placed on each page. For example, issuing CREATE CLUSTERED INDEX ... FILLFACTOR = 33 creates a clustered index with a FILLFACTOR of 33 percent. Assume that SQL Server calculates that 5.2 rows is 33 percent of the space on a page. SQL Server rounds so that six rows are placed on each page.

MS SQL-ю можно указать сколько в процентах использовать места в страницах-листьях для кластерного индекса.
При вставке запись делается на страницу с близкими значениями кластерного ключа, если не хватает места, то страница разделяется на две и идет добавление на одну из них.

внутри страницы судя по BOL физической пересортировки не делается.

ИТОГ: перестройка таблицы с кластерным индексом идет только тогда, когда запись не влезает на страницу. при этом происходит расщепление страницы и соответствующая перестройка индекса.

Сравниваем:
ASCRUS
При вставке записей ASA просто стремится ложить записи в конец не до конца заполненных страниц, которые по значениям кластерного ключа близки к вставляемым записям. При изменении записей сервер их оставляет на тех же страницах. В итоге получается этакая блоковая дефрагментация, где никто не гарантирует сортировки записей таблицы по кластерному ключу и страницы таблицы более менее содержат близкие по кластерному ключу записи, но не обязательно эти страницы идут одна за одной, что с моей точки зрения является вполне нормальным и оправданным демократичным подходом к организации кластерного ключа, где с одной стороны не тормозится скорость вставки новых записей, с другой стороны при выполнении запросов оптимизатор учитывает наличие кластерного ключа и получает более быстрое чтение записей засчет того, что они часто лежат в пределах одинаковых страниц.

ЗЫ извиняюсь за некоторую сумбурность
16 май 06, 14:46    [2669532]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить