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

Откуда: СПб
Сообщений: 435
Andreww

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

А что тогда ?

Ссылочку на алгоритм приведёте. Интересно посмотреть....

Вы правы, именно оно, родимое, там и есть :-) Ссылочку поищу, если не найду, попробую своими словами.
17 май 06, 08:01    [2672077]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
LittleCat
Member

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

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

Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья)
17 май 06, 08:04    [2672083]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

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

Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья)

Спасибо, что не про РМД и (или) ООМД.
17 май 06, 08:47    [2672202]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
In SQL Server 2005, each file within a database can be reduced to remove unused pages. Although the Database Engine will reuse space effectively, there are times when a file no longer needs to be as large as it once was; shrinking the file may then become necessary. Both data and transaction log files can be reduced, or shrunk. The database files can be shrunk manually, either as a group or individually, or the database can be set to shrink automatically at specified intervals.

Files are always shrunk from the end. For example, if you have a 5-GB file and specify 4 GB as the target_size in a DBCC SHRINKDB statement, the Database Engine will free as much space as it can from the last 1 GB of the file. If there are used pages in the part of the file being released, the Database Engine first relocates the pages to the part being retained. You can only shrink a database to the point where it has no free space remaining. For example, if a 5-GB database has 4 GB of data and you specify 3 GB as the target_size of a DBCC SHRINKDATABASE statement, only 1 GB will be freed.
17 май 06, 09:03    [2672242]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
Допустим, что реальный размер данных в базе - 100 мегов на дату и 50 мегов лог.

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

1. Данные хранятся в 120 мегабайтном файле данный и 70 мегабайтном файле логов
2. Те же самые данные хранятся в 1 гигабайтном файле и 500 мегабайтном файле логов. Во втором случае база сами данные максимально разбросаны друг от друга по всему файлу.

То есть в 1 и 2 случае производительность будет одинакова (софт и хард одинаков)
17 май 06, 09:09    [2672256]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
MX -- ALEX
Guest
http://www.optim.su/cs/2005/4/cache/cache.asp

программы в CACHE
17 май 06, 09:47    [2672427]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
LittleCat
c127

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

Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья)


При чем тут "современные базы"? Уже в r-system были индексы для ускорения выполнения запросов. А то, что индексы имеют структуру B*-tree - так это самые удобные структуры. В м-технологии их тоже не от балды взяли.
17 май 06, 09:57    [2672477]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Самое сложное, что можно придумать в СУБД - это работа с ненаправленным/ненаправленным графом.(ИМХО конечно) Вот тут, именно на этой непростой задаче следовало бы проверить возможности и того и другого.
Одна из задач - найти кратчайший (можно оптимальный) путь между двумя узлами чисто средствами СУБД.
17 май 06, 10:34    [2672683]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Iura
...
1. Данные хранятся в 120 мегабайтном файле данный и 70 мегабайтном файле логов
...

В логе данные не храняться
А разница в производительности думаю будет небольшая(мое мнение, обосновать не могу - просто не с чего ей падать вроде)
17 май 06, 10:55    [2672811]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
LittleCat
c127

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

Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья)
А чем вы подкрепите это смелое утверждение? Просто первая публикация по B-деревьям их изобретателя Рудольфа Байера вообще датирована 1971 годом: Rudolf Bayer, Binary B-Trees for Virtual Memory, ACM-SIGFIDET Workshop 1971, San Diego, California, Session 5B, p. 219-235.

Никакими 60-ми тут и не пахнет.

На чем там внутри работала MUMPS с 1966 года неизвестно, говорится только про то, что она "incorporated a hierarchical database file system to standardize interaction with the data."
17 май 06, 11:39    [2673170]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

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

>>Вы правы, именно оно, родимое, там и есть :-) Ссылочку поищу, если не найду, попробую своими словами.

Можно своими, если там что-то интересное, будет сразу видно.
Пока что было заявление - "Вот именно, самоперестраивающееся. При вставке в любое место дерева изменяется максимум несколько блоков."

Говорит только о том, что либо в М(КАШЕ) какой-то НОВЫЙ и довольно сложный алгоритм, либо вы слабо владеете предметом, т.к. при вставке значительного числа элементов в B*дерево узлы будут быстро заполняться и часто требуется расшепление всех родительских вершин вплоть до корня,что в многопользовательской среде приводит к блокированию значительной части дерева (а никак не НЕСКОЛЬКИХ блоков), кроме того помимо расщепления есть ещё и слияние блоков (что бы не тратить зря место) тоже не самая быстрая операция.
других алгоритмов я не знаю, потому и прошу поделиться.

И кстати :) Индексы в виде B*-деревьев, существуют в Рел. системах от рождения (ещё от SYSTEM-R) :) Но это именно ИНДЕКСЫ, данные (как правило) хранятся в других структурах - почувствуйте разницу,все уже много лет как ушли от хранения ДАННЫХ в B*-дереве именно из-за того что поддерживать балланс в многопользовательской среде накладно и сложно,хотя для некоторых случаев можно и в B*-дереве хранить (в оракле например есть IOT про DB/2 MSSQL не знаю) и тут появляется М-технология и зовёт нас обратно в 70-е :)
Странно, не находите ?
17 май 06, 11:46    [2673227]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
SergSuper
Iura
...
1. Данные хранятся в 120 мегабайтном файле данный и 70 мегабайтном файле логов
...

В логе данные не храняться
А разница в производительности думаю будет небольшая(мое мнение, обосновать не могу - просто не с чего ей падать вроде)


Правильно. Это же журнал транзакций!

Так кто нибудь пусть ответит на мой вопрос.
Значит производительность никак не зависит от размера фалов и используемого пространства ?

Например если размер файла будет 100 GB (data и столько же log) и при этом used space будет 0.1%, = производительность такойже базы данных, но с файлами размера (100 MB) и usage space 100% ?
17 май 06, 13:43    [2674181]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
mir
Rudolf Bayer, Binary B-Trees for Virtual Memory, ACM-SIGFIDET Workshop 1971, San Diego, California, Session 5B, p. 219-235.


рыдалъ, спасиба
17 май 06, 13:50    [2674223]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
[quot Gluk (Kazan)рыдалъ, спасиба[/quot]?
17 май 06, 14:02    [2674306]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11383
Iura
Значит производительность никак не зависит от размера фалов и используемого пространства ?
Ответьте сами себе на вопрос, быстрее или медленнее вы будете работать с файлами, если у Вас HDD 1ГБ или 100ГБ ?
Ни разу не замечали, что проблемы с производительностью начинаются, когда на HDD остается мало места, а не когда на диске его полным-полно ? А почему ?
Может хватит фантазировать, а пора читать документацию и проводить эксперименты ? А то проект помрет не успев начаться или его отдадут другим :)
17 май 06, 14:31    [2674464]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
mir
[quot Gluk (Kazan)рыдалъ, спасиба
?[/quot]

B-деревья в 60-х годах :) порадовало
17 май 06, 14:53    [2674628]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Iura
SergSuper
Iura
...
1. Данные хранятся в 120 мегабайтном файле данный и 70 мегабайтном файле логов
...

В логе данные не храняться
А разница в производительности думаю будет небольшая(мое мнение, обосновать не могу - просто не с чего ей падать вроде)


Правильно. Это же журнал транзакций!

Так кто нибудь пусть ответит на мой вопрос.
Значит производительность никак не зависит от размера фалов и используемого пространства ?

Например если размер файла будет 100 GB (data и столько же log) и при этом used space будет 0.1%, = производительность такойже базы данных, но с файлами размера (100 MB) и usage space 100% ?


при 100% заполнении DML будeт работать гораздо медленнее чем при заполнении 0.1%
больше других зависимостей я не вижу

2 Andreww
в IOT не хранятся данные в В-дереве они храняться упорядоченно
полный аналог кластерного индекса в SQL Server в DB2 тоже есть подобная штука

2 all
кое что мне непонятно: насколько я знаю кашэ хранит данные в разреженных В-деревьях
идексы в рсубд тоже организованы в виде В-деревьев
причины торможения на больших обьемах данных кроются в размерах индексов - много времени уходит на их перестройку

однако в каше дерево судя по всему получается больше чем индекс и перестраивать его дольше

за счет чего кашэ быстрее или считается быстрее ?
объясните пожалуйста
17 май 06, 15:15    [2674763]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
ChA
Iura
Значит производительность никак не зависит от размера фалов и используемого пространства ?
Ответьте сами себе на вопрос, быстрее или медленнее вы будете работать с файлами, если у Вас HDD 1ГБ или 100ГБ ?
Ни разу не замечали, что проблемы с производительностью начинаются, когда на HDD остается мало места, а не когда на диске его полным-полно ? А почему ?
Может хватит фантазировать, а пора читать документацию и проводить эксперименты ? А то проект помрет не успев начаться или его отдадут другим :)



Вот именно почитай.

Любая информация занимает место. Не важно она полезная или нет. Важно другое, когда ты начинаешь искать то что тебе нужно, тебе приходится просматривать и ненужную инфо тоже. Причем тем чаще, чем длинее файл. Индекс тебе указывает номер страницы в которой находится нужная информация, но не конкретный row И не тем более конкретный физический адрес на hard disk. Сервак полностью просматривает страницу на которую указывает индекс.

Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию. Чтобы в самом индексе найти нужную конечну "ветку + лист" нужно немного потрудится. И чем длинее файл тем болеьше надо трудится. Ведь индекс в память полностью не загружается. Да возможно для того чтобы ему дойти до последней ветки нужно сделать не более 10-50 if, но эти же значения разбросанны на диске и причем не эффективно. Поэтому опять возникнет нагрузка на файл и диск. А если это многопользовательская система ? а если еще там isolations куча, тогда что.

Так, что думай.

Базы бывают разными и нагрузка на них бывает тоже разной. Если у тебя ьаза работает только на чтение, то сорри.
17 май 06, 15:31    [2674882]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
MX -- ALEX
Guest
pgres

за счет чего кашэ быстрее или считается быстрее ?
объясните пожалуйста


теоретически - не должно

практически - возможно за счет более простого
механизма управления страницами
(то есть меньше "накладные расходы")

но разница не так уж велика
17 май 06, 15:32    [2674889]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 Iura
ChA
Вы браво продолжаете изрекать банальности, не считая откровенного, очень мягко говоря, непонимания. Будьте любезны ответить на более простые вопросы. Какой у Вас опыт работы с MS SQL Server-ом ? А вообще опыт работы с СУБД ?


присоединяюсь

Iura уволь сибя сам
какую траву ты куришь поделись

есть такой психологический тест "понимание при чтении"
так вот даже и не пробуй его сдавать
17 май 06, 15:59    [2675083]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

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

Поясните.

An Index-Organized Table (IOT) is a unique storage organization feature of the Oracle9i server that provides added value in performance, scalability, and availabili ty over conventional tables. The actual data for an index-organized table is stored in B-tree index leaves in sorted order based on the table's primary key so that changes to that data, such as adding, updating, or deleting rows, require an update t o the index only. This approach enables extremely fast access to table data for primary key based queries, making index-organized tables ideal for a wide variety of applications.


Особенно вот - The actual data for an index-organized table is stored in B-tree index leaves ....

Как это сочетается с "...в IOT не хранятся данные в В-дереве..."

Вот отсюда - http://www.oracle.com/technology/products/oracle9i/datasheets/iots/iot_ds.html
17 май 06, 16:05    [2675125]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Iura
Любая информация занимает место. Не важно она полезная или нет. Важно другое, когда ты начинаешь искать то что тебе нужно, тебе приходится просматривать и ненужную инфо тоже. Причем тем чаще, чем длинее файл. Индекс тебе указывает номер страницы в которой находится нужная информация, но не конкретный row И не тем более конкретный физический адрес на hard disk. Сервак полностью просматривает страницу на которую указывает индекс.

Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию. Чтобы в самом индексе найти нужную конечну "ветку + лист" нужно немного потрудится. И чем длинее файл тем болеьше надо трудится. Ведь индекс в память полностью не загружается. Да возможно для того чтобы ему дойти до последней ветки нужно сделать не более 10-50 if, но эти же значения разбросанны на диске и причем не эффективно. Поэтому опять возникнет нагрузка на файл и диск. А если это многопользовательская система ? а если еще там isolations куча, тогда что.
Уважаемый Iura. По вашему посту видно, что вы очень плохо знакомы с технологией организацией индексного поиска в БД. Советую некоторое время посвятить чтению.
17 май 06, 16:09    [2675152]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Andreww
2 pgres

Поясните.

An Index-Organized Table (IOT) is a unique storage organization feature of the Oracle9i server that provides added value in performance, scalability, and availabili ty over conventional tables. The actual data for an index-organized table is stored in B-tree index leaves in sorted order based on the table's primary key so that changes to that data, such as adding, updating, or deleting rows, require an update t o the index only. This approach enables extremely fast access to table data for primary key based queries, making index-organized tables ideal for a wide variety of applications.


Особенно вот - The actual data for an index-organized table is stored in B-tree index leaves ....

Как это сочетается с "...в IOT не хранятся данные в В-дереве..."

Вот отсюда - http://www.oracle.com/technology/products/oracle9i/datasheets/iots/iot_ds.html

Tom_Kyte

Блоки самого нижнего уровня в индексе, которые называют листовыми вершинами,
содержат все проиндексированные ключи и идентификаторы строк (rid на схеме), ссы-
лающиеся на соответствующие строки. Промежуточные блоки над листовыми верши-
нами называют блоками ветвления. Они используются для переходов по структуре.
Например, если необходимо найти в индексе значение 42, надо начать с вершины дере-
ва и двигаться вправо. При проверке этого блока оказывается, что необходимо перейти
к блоку в диапазоне "от 40 до 50". Этот блок оказывается листовым и ссылается на стро-
ки, содержащие число 42. Интересно отметить, что листовые блоки фактически образу-
ют двухсвязный список. Как только найдено "начало" среди листовых вершин, т.е. пер-
вое значение, очень легко просматривать значения по порядку (это называют также
просмотром диапазона по индексу, index range scan). Проходить по структуре индекса боль-
ше не нужно; мы просто переходим по листовым вершинам. Это существенно упрощает
поиск строк но условиям следующего вида:
where x between 20 and 30


просто сами индексы на основе В-дерева в листовых вершинах имеют не по одному значению
17 май 06, 16:11    [2675164]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
предыдущий слишком рано отправил

перефразируя: только листы дерева хранят данные

в этом разница с класическим В-деревом, где каждая вершина даже корневая хранит данные

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

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

Понятно что не по одному и понятно что отсортированные.

Но в случае IOT где же ДАННЫЕ (ACTUAL DATA ) храняться как не в листовых вершинах (index leave) B*-дерева ?

По OTN выходит там, по вашему - "...в IOT не хранятся данные в В-дереве..." ?
17 май 06, 16:17    [2675181]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить