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

Откуда: МО Электросталь
Сообщений: 5994
автор
MS SQL-ю можно указать сколько в процентах использовать места в страницах-листьях для кластерного индекса.
При вставке запись делается на страницу с близкими значениями кластерного ключа, если не хватает места, то страница разделяется на две и идет добавление на одну из них.

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

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

Спасибо за обьяснение. Получается основное отличие от ASA - у нас страница не будет расщепляться, просто если запись не входит по размерам на все подходящие страницы, она уйдет на другую или новую страницу. Ну и соотвествующе и FILL FACTOR в ASA из за этого в индексах не предусмотрено.

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
16 май 06, 15:35    [2669925]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
данные
148223,8125	148150,3125	H	13.01.2006 23:36:01
148223,8125	148194,5625	H	14.01.2006 23:36:00
> +44

20715,6875	20707,9375	H	13.01.2006 23:36:01
20715,6875	20712,375	H	14.01.2006 23:36:00
> +5

52531,5	51845,625	V	13.01.2006 23:36:01
52531,5	52242,0625	V	14.01.2006 23:36:00
> +397

310500	310115,8125	F	13.01.2006 23:36:01
311500	311230,125	F	14.01.2006 23:36:00
> +1115

H,V - индексы

итого, +1561Mb в сутки для 20 млн. записей, из них индексы занимают
446Mb

посчитаем: 446 / 20 = 22.3 байта на индекс
даже с учетом сжатия маловато вроде

теперь данные: 1115 / 20 = 55.75 байт на запись
и тоже вроде как маловато получается. хотя может
там одни числа?

может я что-то не так считаю?

С уважением. Сергей
16 май 06, 16:08    [2670106]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
MX -- ALEX
Guest
Sergei Obrastsov
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, который здесь так дружно
не любят. :)

С уважением. Сергей

может в ASA внутри MUMPS сидит :)

уж очень схема связей идентична
doubly-linked list

интересно про ASA почитать
16 май 06, 16:13    [2670132]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
может в ASA внутри MUMPS сидит :)

уж очень схема связей идентична
doubly-linked list

интересно про ASA почитать

Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;)

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
16 май 06, 16:15    [2670150]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ASCRUS
автор
может в ASA внутри MUMPS сидит :)

уж очень схема связей идентична
doubly-linked list

интересно про ASA почитать

Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;)

Да они хоть бы что-то читали... В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше.
16 май 06, 16:24    [2670203]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
Sergei Obrastsov
SiDen
данные
148223,8125	148150,3125	H	13.01.2006 23:36:01
148223,8125	148194,5625	H	14.01.2006 23:36:00
> +44

20715,6875	20707,9375	H	13.01.2006 23:36:01
20715,6875	20712,375	H	14.01.2006 23:36:00
> +5

52531,5	51845,625	V	13.01.2006 23:36:01
52531,5	52242,0625	V	14.01.2006 23:36:00
> +397

310500	310115,8125	F	13.01.2006 23:36:01
311500	311230,125	F	14.01.2006 23:36:00
> +1115

H,V - индексы

итого, +1561Mb в сутки для 20 млн. записей, из них индексы занимают
446Mb

посчитаем: 446 / 20 = 22.3 байта на индекс
даже с учетом сжатия маловато вроде

теперь данные: 1115 / 20 = 55.75 байт на запись
и тоже вроде как маловато получается. хотя может
там одни числа?

может я что-то не так считаю?

С уважением. Сергей


Народ когда такие сравнения делаете, пожалуйста сначала седала truncate log а потом dbcc shrink database. Результаты вас приятно удивят.

Во вторых страшен как размер индекса, так и высота дерева, которая используется при построении индекса.
16 май 06, 16:26    [2670214]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ЛП
Guest
SergSuper
В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше.

Судя по фразе автора топика ("... Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева...") некоторые думают, что как раз таки в кеше деревьев нет никаких, стал быть и перестраивать нечего. Или, быть может, думают, что дерево в кеше - волшебное, самоперестраивающееся.
16 май 06, 16:35    [2670261]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ЛП
SergSuper
В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше.

Судя по фразе автора топика ("... Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева...") некоторые думают, что как раз таки в кеше деревьев нет никаких, стал быть и перестраивать нечего. Или, быть может, думают, что дерево в кеше - волшебное, самоперестраивающееся.

некоторые думают, что Cache - это такая же колбаса, только в другой обертке, отсюда все непонимание. B-дерево, действительно, вещь тривиальная, не спорю, но ведь используют же. значит что-то в нем есть.
причем используют именно там "где рвется". я прав?

С уважением. Сергей
16 май 06, 17:05    [2670501]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
MX -- ALEX
Guest
SergSuper
ASCRUS
автор
может в ASA внутри MUMPS сидит :)

уж очень схема связей идентична
doubly-linked list

интересно про ASA почитать

Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;)

Да они хоть бы что-то читали... В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше.


А дерево где -
в моем посте нет про дерево
.................

..мальчики кровавые в глазах
16 май 06, 17:11    [2670538]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
мясник
Guest
Sergei Obrastsov
........
некоторые думают, что Cache - это такая же колбаса, только в другой обертке, отсюда все непонимание. .......



Сергей, с интересом слежу за обсуждением. Слово "колбаса" впервые встретилось в Вашем посте. Есля я не прав, приведите ссылку, кто думает, что Cache - это колбаса.
16 май 06, 17:11    [2670540]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
мясник
Sergei Obrastsov
........
некоторые думают, что Cache - это такая же колбаса, только в другой обертке, отсюда все непонимание. .......


Сергей, с интересом слежу за обсуждением. Слово "колбаса" впервые встретилось в Вашем посте. Есля я не прав, приведите ссылку, кто думает, что Cache - это колбаса.

впервые. но оно не главная значимая часть этого предложения, главная -
"такая же" :)

С уважением. Сергей

P.S. ну что, блин, за детство?
16 май 06, 17:33    [2670683]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Сергей, речь не о 20, а о 2 млн, внимательнее плз
To lura: 1. лог приведен отдельно (опять же внимательнее), 2. вы пробовали шринкать полутеррабайтные базы на системах 24х7? Занимательное однако занятие :)
16 май 06, 17:36    [2670702]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
Сергей, речь не о 20, а о 2 млн, внимательнее плз
To lura: 1. лог приведен отдельно (опять же внимательнее), 2. вы пробовали шринкать полутеррабайтные базы на системах 24х7? Занимательное однако занятие :)

а действительно. прошу прощения
теперь верю

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

Откуда:
Сообщений: 138
SiDen
Сергей, речь не о 20, а о 2 млн, внимательнее плз
To lura: 1. лог приведен отдельно (опять же внимательнее), 2. вы пробовали шринкать полутеррабайтные базы на системах 24х7? Занимательное однако занятие :)


В таких случаях полгаюа делают shrink file. А кол-во файлов там наверняка больше чем 2. Не разумно в таком случае в одном файле хранить всю инфо :)

В зависиомост от модели базы данных MSSQL FULL or Simple, shrink приводит к совершенно разным результатм.

А шринкать в случае FULL обязательно надо, а то база будет разрастаться, не только от инсерт но и от delet & update.
16 май 06, 18:48    [2671098]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
ЛП
Или, быть может, думают, что дерево в кеше - волшебное, самоперестраивающееся.

Вот именно, самоперестраивающееся. При вставке в любое место дерева изменяется максимум несколько блоков.
16 май 06, 19:24    [2671239]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
Iura
В зависиомост от модели базы данных MSSQL FULL or Simple, shrink приводит к совершенно разным результатм.
Что значит "совершенно разные результаты" ? Можно подробнее ?
Iura
А шринкать в случае FULL обязательно надо, а то база будет разрастаться, не только от инсерт но и от delet & update.
База будет "разрастаться" от delete ? Вы подразумеваете транзакционный лог ? А зачем "шринкать" ? Чтобы потом сервер опять корячился снова выделяя место под тот же самый лог ? В принципе, есть еще и другие способы создавать проблемы серверу и его пользователям.
16 май 06, 19:25    [2671248]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 LittleCat


>>Вот именно, самоперестраивающееся. При вставке в любое место дерева изменяется максимум несколько блоков.

Так там не В*-дерево ?

А что тогда ?

Ссылочку на алгоритм приведёте. Интересно посмотреть....
16 май 06, 19:59    [2671362]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
ChA
Iura
В зависиомост от модели базы данных MSSQL FULL or Simple, shrink приводит к совершенно разным результатм.
Что значит "совершенно разные результаты" ? Можно подробнее ?
Iura
А шринкать в случае FULL обязательно надо, а то база будет разрастаться, не только от инсерт но и от delet & update.
База будет "разрастаться" от delete ? Вы подразумеваете транзакционный лог ? А зачем "шринкать" ? Чтобы потом сервер опять корячился снова выделяя место под тот же самый лог ? В принципе, есть еще и другие способы создавать проблемы серверу и его пользователям.


На самом деле зависит от логики сервера. Как часто происходит delete & update & insert. Если очень часто, то помимо того, что у тебя лог файл разрастется и файл данных, когда ты будешь делать любые операции - у тебя в такой базе число операций поиска и чтения страниц с диска увеличится. Ведь на диске не все последоавтельно находится, и нужна инфа не в одной странице находится.

А чтобы, сервер не мучался, ты делаешь shrink до задоного предела. Ты должен расчитать, сколько тебе нужно места в запасе на неделю и столько места хранить. А все лишнее чистить.
16 май 06, 22:31    [2671586]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
Iura
На самом деле зависит от логики сервера. Как часто происходит delete & update & insert. Если очень часто, то помимо того, что у тебя лог файл разрастется и файл данных, когда ты будешь делать любые операции - у тебя в такой базе число операций поиска и чтения страниц с диска увеличится. Ведь на диске не все последоавтельно находится, и нужна инфа не в одной странице находится.

А чтобы, сервер не мучался, ты делаешь shrink до задоного предела. Ты должен расчитать, сколько тебе нужно места в запасе на неделю и столько места хранить. А все лишнее чистить.
Если Вы считате, что ответили на прямо поставленные вопросы, то вынужден огорчить, это не так. Вы браво продолжаете изрекать банальности, не считая откровенного, очень мягко говоря, непонимания. Будьте любезны ответить на более простые вопросы. Какой у Вас опыт работы с MS SQL Server-ом ? А вообще опыт работы с СУБД ?
16 май 06, 23:12    [2671643]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
SergSuper
ASCRUS
автор
может в ASA внутри MUMPS сидит :)

уж очень схема связей идентична
doubly-linked list

интересно про ASA почитать

Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;)

Да они хоть бы что-то читали... В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше.

Это понятно, когда ничего кроме кеша не знаешь, то кажется что все что есть в мире - взято из кеша.


iliker
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


А где я сказал, что ПЕРЕСТРАИВАЕТ каждый раз?

А какое отношение МСДН имет к АСА?


Iura
c127

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


Вот вот! Но и индекс тоже, чтобы хранить ссылку на страницу

Уважаемый товарищ, перестроить индекс это совсем не то же самое что перестроить таблицу.

Кластерный индекс в данной ситуации совершенно не подходит, организовав кластерный индекс Вы сделали откровенную глупость. В этом нет ничего страшного, Вы же не администратор СКЛ серверов, но вот только нужно не выкручиваться, а признать это.
16 май 06, 23:20    [2671660]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Iura

На самом деле зависит от логики сервера. Как часто происходит delete & update & insert. Если очень часто, то помимо того, что у тебя лог файл разрастется и файл данных, когда ты будешь делать любые операции - у тебя в такой базе число операций поиска и чтения страниц с диска увеличится.

Бред какой-то. Физически СКЛ сервер записи не удаляет, это неэффективно, только помечает как удаленные, поэтому размер базы при делитах не меняется. Я удивлюсь, если в КЕШ-е не аналогично.

Если был делит, потом инсерт, то запись может попасть на место удаленной, размер базы не изменится. Поэтому файл не обязательно разрастается.

Лог растет, но на то он и лог, туда пишется большинство операций и ничего само по себе не удаляется по определению. Правда не все операции пишутся в лог, truncate table, например, в АСА не пишется. Если Вы так озабочены размером лога, то его можно отключить, но делать это по понятным причинам не рекомендуется.

Iura

А чтобы, сервер не мучался, ты делаешь shrink до задоного предела. Ты должен расчитать, сколько тебе нужно места в запасе на неделю и столько места хранить. А все лишнее чистить.

Чушь.
Во-первых скорость работы сервера от размера файлов БД не зависит, поскольку, как Вы правильно сказали, информация на современных дисках хранится не последовательно. Поэтому ужимать файлы БД не обязательно, если есть место на диске. В утилитах АСА шринка по-моему вообще нет, по крайней мере у меня ни разу в жизни не возникала необходимость его использовать, при обычной работе пустых мест в файле БД не так много.

Во-вторых база с необходимостью растет только при инсертах и отсутствии пустых мест в таблицах. Чудес же не бывает, нужно где-то хранить информацию. Или может КЕШ способен все на свете засунуть в пространство фиксированного размера, например в один байт?
17 май 06, 00:22    [2671785]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
Кластерный индекс в данной ситуации совершенно не подходит, организовав кластерный индекс Вы сделали откровенную глупость. В этом нет ничего страшного, Вы же не администратор СКЛ серверов, но вот только нужно не выкручиваться, а признать это.

вот я уж точно не администратор СКЛ серверов, а потому просто спрошу: может Вы мне подскажете как обойтись без организации "кластерных
индексов" в таблице типа

A B C D E F,

где при выборке на любое поле может придти условие вида

1. VAL = x1,x2,x3...

или

2. x1<VAL<x2

при количестве записей в таблице ~90 млн.
17 май 06, 03:06    [2671942]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 Sergei Obrastsov
При чем здесь кластерные индексы?
Вы вообще понимаете о чем говорите?
17 май 06, 03:33    [2671950]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
2 Sergei Obrastsov
При чем здесь кластерные индексы?
Вы вообще понимаете о чем говорите?

свихнешься тут с вами, все перепутал, sorry :)
вопрос снимается
17 май 06, 04:18    [2671961]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Sergei Obrastsov
свихнешься тут с вами

Ну вот, мы еще и виноваты :)

Sergei Obrastsov
все перепутал, sorry :)

Ничего, приходите еще :)
17 май 06, 04:21    [2671962]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить