Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10 11      [все]
 Слабые стороны 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]     Ответить | Цитировать Сообщить модератору
 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

Откуда: Москва
Сообщений: 11404
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

Откуда: Москва
Сообщений: 11404
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]     Ответить | Цитировать Сообщить модератору
 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

Откуда: Москва
Сообщений: 11404
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]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ChA
Member

Откуда: Москва
Сообщений: 11404
Iura
Вот именно почитай.
Читаю, Вы продолжаете нести бред, смешивая в кучу умные слова. Может пора остановиться и заняться делом ?

Удачи.
17 май 06, 16:18    [2675185]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

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

Такая структура (данные только в листах) называется B+ или B* деревом, и именно она используется на практике, почему-то часто этот * или + опускают (я кстати стараюсь не опускать) видимо считая, что практически Bдерево может быть реализованно только как B+ :).

Читайте внимательнее мой изначальный пост к lura (https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=293038&pg=3#2673227) я в нём говорю про B*, а вы уже отвечаете про "...в IOT не хранятся данные в В-дереве...".
17 май 06, 16:29    [2675248]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

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

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



http://msdn2.microsoft.com/en-us/library/ms190969(d=ide).aspx
http://msdn2.microsoft.com/en-us/library/ms188270(d=ide).aspx
http://msdn2.microsoft.com/en-us/library/ms177443(d=ide).aspx
http://msdn2.microsoft.com/en-us/library/ms177484(d=ide).aspx
17 май 06, 16:37    [2675303]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

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

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

есть такой психологический тест "понимание при чтении"
так вот даже и не пробуй его сдавать

Это все еще актуально

2 Andreww
Я прошу прощения. буду знать

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

Откуда:
Сообщений: 518
To lura:
имхо вы несколько заблуждаетесь, например, есть первая страница хранения индекса, в конце нее стоит линк на следующую страницу, и так далее (при чем список двунаправлен), читать левые(чужие, пустые) страницы никто не будет вне зависимости от того сколько там их пустых.
такая же штука с данными + имеются страницы, где хранится информация о том какие страницы свободны, а какие нет, на сколько заполнены эти страницы в дискретном процентном соотношении (0-50,51-80,81-95,96-100)
вероятно такие фичи как упреждающее чтение и прочее влияют на процесс чтения при близком расположении нужных страниц, но это нужно тестировать.
17 май 06, 17:22    [2675698]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
Перечитал доку по новой.

Признаю, в чем-то был не прав.
17 май 06, 17:59    [2675969]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

ну вот, например, физическая реализация хранения некоего двухуровневого
массива ^X(i1,i2)
блок указателей (пусть #50)
^X(1,1)=100 -> ссылка на блок данных
^X(300,10)=101
^X(555,500)=102

блок данных #100
^X(1,1)=... -> ссылка и данное при узле
^X(1,2)=...
...
(ссылка на блок #101)

блок данных #101
^X(300,10)=...
^X(300,11)=...
...
^X(555,499)=...
(ссылка на блок #102)

блок данных #102
^X(555,500)=...
...
команда
set ^X(300,10.5)=...
порождающая создание узла ^X(300,10.5) в лучшем случае приведет к смещение ссылок внутри блока #101 (для сохранения сортировки), в худшем (когда блок заполнен) к созданию нового блока (пусть #300) и помещения выпавших после сдвига ссылок в него с изменением ссылки блока #101 (со #102 на #300) и добавлением нового указателя в блок #50, который в этом случае приобретет вид:

блок указателей #50
^X(1,1)=100
^X(300,10)=101
^X(555,499)=300
^X(555,500)=102
это немножко утрированное описание, конечно, там есть свои нюансы
разбиения заполненного блока и переноса части его содержимого, но
принцип вообще-то такой.

как мы видим, изменением затрагивается либо один блок, либо два блока +
блок указателей. есть, конечно, вариант с уже полным блоком указателей.
в этом случае процедура обработки нового блока повторяется на уровне указателей (намного реже чем для данных).
при этом естественно происходит блокировка именно этих (и только этих
блоков) модулем работы с БД. задачи работающие с ^X(555,500) или
^X(1) могут ожидать только освобождения блока #50, если уж они сами
породили в процессе своей работы новый блок данных.


И кстати :) Индексы в виде B*-деревьев, существуют в Рел. системах от рождения (ещё от SYSTEM-R) :) Но это именно ИНДЕКСЫ, данные (как правило) хранятся в других структурах - почувствуйте разницу,все уже много лет как ушли от хранения ДАННЫХ в B*-дереве именно из-за того что поддерживать балланс в многопользовательской среде накладно и сложно,хотя для некоторых случаев можно и в B*-дереве хранить (в оракле например есть IOT про DB/2 MSSQL не знаю) и тут появляется М-технология и зовёт нас обратно в 70-е :)
Странно, не находите ?

будьте так добры, напомните мне систему, в которой данные ранее хранились вместе с индексами, а потом, следуя оптимальным теориям были перемещены в отдельную структуру. я вообще-то вижу нечто обратное. вот тот же IOT, например.
17 май 06, 18:12    [2676057]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Andreww
Такая структура (данные только в листах) называется B+ или B* деревом
Не "или", а просто B+. Причём в B+дереве листья ещё и связаны между собой.
B* дерево - следующая модификация. Его особенность в улучшенном алгоритме вставки за счёт использования идеи "переливания" и сокращении количества делений узлов.
17 май 06, 18:29    [2676142]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

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

Конечно так, просто недоговорил.

Хотел обратить внимание на то, что данные в листах в В+ ИЛИ В* деревьях, вроде нигде не говорил, что это одно и то же :( у В*, перелив иной, это факт и вроде как у В* листья тоже связаны.
17 май 06, 18:38    [2676183]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
задачи работающие с ^X(555,500) или
^X(1) могут ожидать только освобождения блока #50, если уж они сами
породили в процессе своей работы новый блок данных.
А если не породили, то не должны ждать?
Что они будут делать, если в процессе работы других задач произойдёт деление блока #50 и увеличение уровня дерева?
Разделяемая блокировка должна накладываться в любом случае. Кто-то кого-то да должен подождать :-)
17 май 06, 18:44    [2676222]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Sergei Obrastsov
задачи работающие с ^X(555,500) или
^X(1) могут ожидать только освобождения блока #50, если уж они сами
породили в процессе своей работы новый блок данных.
А если не породили, то не должны ждать?
Что они будут делать, если в процессе работы других задач произойдёт деление блока #50 и увеличение уровня дерева?
Разделяемая блокировка должна накладываться в любом случае. Кто-то кого-то да должен подождать :-)

а кто спорит? только блокировка накладывается на затронутые изменением блоки, а не на все блоки подряд.
когда изменится блок указателей, то его разблокировки будут ждать все те задачи, которые получают доступ к узлам, указанным в нем, но не к узлам, указанным в предыдущем или последующем блоке указателей.
17 май 06, 18:52    [2676255]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

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

Уффф. А надо ли комментировать...... Дерево с одним уровнем.

Посмотрите внимательнее, блок указателей у вас "бесконечный" т.к. данных мноооого или мало, но это СПИСОК указателей ведь тоже надо хранить и скорее всего на диске (т.к. вы сами заранее разбили всё хранилище на блоки) ?

Если вы настаиваете на блоке указателей ФИКСИРОВАННОГО размера (который растёт когда появляются новые блоки), то тогда БЛОКИ ДАННЫХ у вас быстро превращяются в связанные списки (т.к. вы сами заранее разбили всё хранилище на блоки) и, опять же, если данных мнооого списки будут длинююющие и поиск в них небыстрый (хотя в сортированных списках конечно искать легче, но при вставке придётся двигать).

И чего вы добились, сохранив указатели в одном списке, а данные разбросав по блокам? Уменьшили время поиска в столько раз, сколько указателей помещается в список ?

B*дерево решает проблемы поиска совсем по-другом (там размер блока фиксированный и число уровней переменное, но за это приходится платить расщеплением и слиянием).

>>будьте так добры, напомните мне систему, в которой данные ранее хранились вместе с индексами, а потом, следуя оптимальным теориям были перемещены в отдельную структуру

D3 от Rainingdata (ровесник МУ-МУ). Данные сначала хранились В ТОЧНОСТИ КАК ВЫ ОПИСАЛИ, даже размер списка указателей требует при создании ФАЙЛА, спустя некоторое время (не так давно) было добавленно отдельно живущее и автоматически поддерживаемое B*(или B+ не помню точно) дерево.
17 май 06, 19:12    [2676329]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
LittleCat
Member

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

Уффф. А надо ли комментировать...... Дерево с одним уровнем.

Ну зря Вы так, Сергей же просто пример привел, при разрастании дерева в М системах строится несколько уровней указателей. Размер блока указателей (да и вообще блока базы данных, с которым ведется операция как на диске, так и в кэше) является фиксированным (как впрочем и блока в котором хранятся данные). В ранних М системах этот размер был фиксированным (например в DSM-11 это был килобайт). С размером блока были связаны ограничений как на длину полной ссылки, так и на длину отдельного узла данных. С ростом потребностей (ну неудобно иметь длину локальной переменной в 32 кБ, а глобальной всего 511 байт или около того, сейчас не помню) разные производители внесли соответствующуе улучшения (в Cache блок базы сделали 8 кБ, в GT.M вообще этот параметр для базы сделали настраиваемым, можно для разных баз задать разный размер блока базы). Так что насчет уровней, торопиться не надо, тем более число индексов может быть до 63...
PS. Блоки делятся на: Блок главного каталога, Блок указателей, Блок указателей на нижний уровень (т.е. на блоки данных), и собственно блоки данных. Ну это если вкратце...
17 май 06, 20:26    [2676502]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
буржуй
Guest
все РСУБД-шники - необразованные демагоги, это факт. Просто куда ни ткни. Очередной яркий пример от Andreww:

И кстати :) Индексы в виде B*-деревьев, существуют в Рел. системах от рождения (ещё от SYSTEM-R) :) Но это именно ИНДЕКСЫ, данные (как правило) хранятся в других структурах - почувствуйте разницу,все уже много лет как ушли от хранения ДАННЫХ в B*-дереве именно из-за того что поддерживать балланс в многопользовательской среде накладно и сложно,хотя для некоторых случаев можно и в B*-дереве хранить (в оракле например есть IOT про DB/2 MSSQL не знаю) и тут появляется М-технология и зовёт нас обратно в 70-е :)
Странно, не находите ?

>>будьте так добры, напомните мне систему, в которой данные ранее хранились вместе с индексами, а потом, следуя оптимальным теориям были перемещены в отдельную структуру

D3 от Rainingdata (ровесник МУ-МУ). Данные сначала хранились В ТОЧНОСТИ КАК ВЫ ОПИСАЛИ, даже размер списка указателей требует при создании ФАЙЛА, спустя некоторое время (не так давно) было добавленно отдельно живущее и автоматически поддерживаемое B*(или B+ не помню точно) дерево.

------------

Оказывается "все" это D3, и конечно же, ничего общего с mumps у D3 нет и не было (а если и есть, то то же самое общее, что и с Oracle и т.п.).
17 май 06, 20:33    [2676520]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Andreww

Уффф. А надо ли комментировать...... Дерево с одним уровнем.

не надо торопиться с выводами. во-первых, с двумя.
во-вторых, дерево вида ^X(i1,i2,i3,i4,i5,i6,i7) ложится в такую же структуру
блок указателей #50
^X(1,2,3,4,5,1,"xxx")=100
^X(1,2,3,4,5,555,"yyy")=101
^X("X","Y","Z",6,7,8,"kkk")=102
...

и что это я все сбалансированные деревья рисую? вот так нагляднее?

блок указателей #50
^X = 101
^X(100,255)=102
^X(160,100,400)=103
^X(500,400)=104
^X(600,101,202,303,405,7)=105
...


Посмотрите внимательнее, блок указателей у вас "бесконечный" т.к. данных мноооого или мало, но это СПИСОК указателей ведь тоже надо хранить и скорее всего на диске (т.к. вы сами заранее разбили всё хранилище на блоки) ?

а разве я не упоминал про возможность заполнения блока указателей?
конечно блок фиксирован размером, какой же это был бы иначе блок?
сейчас, скажем, 8Kb (как и блок данных и прочие другие блоки).


Если вы настаиваете на блоке указателей ФИКСИРОВАННОГО размера (который растёт когда появляются новые блоки), то тогда БЛОКИ ДАННЫХ у вас быстро превращяются в связанные списки (т.к. вы сами заранее разбили всё хранилище на блоки) и, опять же, если данных мнооого списки будут длинююющие и поиск в них небыстрый (хотя в сортированных списках конечно искать легче, но при вставке придётся двигать).

а ведь очевидно, что поиск идет через блоки указателей, а не через
всю цепочку блоков данных. или нет? блоки указателей тоже растут
по мере роста блоков данных, хоть и не так быстро. вот скажем массив
с 162 млн. узлов занимает 366,061 блоков данных, 515 блоков указателей 2-го уровня и один блок указателей 1-го уровня. (ага, все тот же, из сравнения)


И чего вы добились, сохранив указатели в одном списке, а данные разбросав по блокам? Уменьшили время поиска в столько раз, сколько указателей помещается в список ?

я вообще-то ничего не добивался, я просто показал как хранятся данные.
в ответ на соответствующий вопрос. время поиска сокращается очень значительно, иначе бы эти структуры не использовались.
и не только в M, ага. :)


B*дерево решает проблемы поиска совсем по-другом (там размер блока фиксированный и число уровней переменное, но за это приходится платить расщеплением и слиянием).

вот странно, а все полагают, что это оно и есть.


D3 от Rainingdata (ровесник МУ-МУ). Данные сначала хранились В ТОЧНОСТИ КАК ВЫ ОПИСАЛИ, даже размер списка указателей требует при создании ФАЙЛА, спустя некоторое время (не так давно) было добавленно отдельно живущее и автоматически поддерживаемое B*(или B+ не помню точно) дерево.

данные там и сейчас хранятся так же как и раньше, в итемах и файлах.
и откуда, интересно, информация про "В ТОЧНОСТИ ТАК..."?
раньше использовали hash-indexing, потом добавили
B-tree, молодцы, растут.
17 май 06, 20:38    [2676532]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

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

>>не надо торопиться с выводами. во-первых, с двумя.

Определение уровня у вас своё ? Корень дерева имеет уровень 0, любой другой узел имеет уровень на 1 больше потомка (определение всех остальных людей).

У вас в примере который вы привели (УКАЗАТЕЛИ) -> (БЛОКИ ДАННЫХ), сл-но глубина вашего дерева равна 1 и список указателей всегда показывает на данные, сл-но дерево у вас с 1 уровнем.

>>конечно блок фиксирован размером, какой же это был бы иначе блок?

мало-ли какой, вон уровень у вас "не как у людей" :)

>>сейчас, скажем, 8Kb (как и блок данных и прочие другие блоки).

Хммм. А менять размер можно ? Для указателей 8к может и нормально (хотя надо учитывать что при вставке\удалении указатели двигать надо), но для данных перебор.

>>а ведь очевидно, что поиск идет через блоки указателей, а не через всю цепочку блоков данных. или нет? блоки указателей тоже растут

Пару минут назад я думал что "блок фиксирован размером, какой же это был бы иначе блок" теперь выясняем, что "растут подлецы" :)

А указатель-то на блок данных в списке указателей надо найти ? Или как ?

Вот ваш же пример

блок указателей #50
^X = 101
^X(100,255)=102
^X(160,100,400)=103
^X(500,400)=104
^X(600,101,202,303,405,7)=105
....... и далее

Как мне найти номер блока данных для ^X(230,67,22,3,87,11,55,3,223) ? Есть он вообше в 8 килобайтах блока #50 или блок #50 уже вырос или .... ?

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

>>массив 162 млн. узлов занимает 366,061 блоков данных, 515 блоков указателей 2-го уровня и один блок указателей 1-го уровня.

Стоп-стоп. В исходном примере у вас блок указателей показывал только на данные, теперь оказывается есть ещё уровень указателей, т.е. дерево всё-таки глубины 2 или может 3 или всё же не ограничено ?
Обясните.

>>время поиска сокращается очень значительно, иначе бы эти структуры не использовались.и не только в M, ага. :)

Так дело в том что "не только в М" у дерева глубина произвольная и поиск потому эффективнее.

>>вот странно, а все полагают, что это оно и есть.

Не знаю кто "все", но в Б*дереве глубина не ограничена 2 уровнями. Несогласны ?

>>раньше использовали hash-indexing,

Вообще-то ХЭШ-СПИСОК, ну да ладно, смысл от этого не меняется, сначала находим указатель на СПИСОК (по хэшу) (из списка указателей) потом последовательным перебором этого списка находим нужный нам элемент.

Как и у вас - 1 уровень (кстати убыстрен за счёт ХЭША, а как у вас пока не понятно) второй уровень- последовательный перебор списка до нужного элемента (ИТЕМА как вы говорите).

Файл с 40 милионнами "ИТЕМОВ" умирает, т.к. хэш-функция есс-но неполная то скорость выборки пропорциональна размеру файла.


2 буржуй

Просили напомнить, я напомнил, а если нечего сказать лучше жевать. рябчиков например.

2 LittleCat

>>Ну зря Вы так, Сергей же просто пример привел, при разрастании дерева в М системах строится несколько уровней указателей.

Несколько это 2,3,5 ? Может я горячусь и там разумное ограничение эдак в 100-200 уровней ?
Почему никто не может объяснить ?
Зачем вообще это ограничивать 2 или 3 уровнями ? Нормальное Б*дерево всегда будет эффективнее для поиска,
а 3 или 5 уровней вызовут все те же проблемы расщепления-слияния (блокировка блоков указателей до корня) про которые уже всё рассказали.


>>Размер блока указателей (да и вообще блока базы данных, с которым ведется операция как на диске, так и в кэше)
>>С размером блока были связаны ограничений как на длину полной ссылки, так и на длину отдельного узла данных.


Вы очевидную вешь "блока базы данных, с которым ведется операция как на диске, так и в кэше" полагаете чем то особенным именно для М-систем ?
Если нет зачем про это писать ?
У кого работа с блоками ведётся по-другому ?

>>С ростом потребностей (ну неудобно иметь длину локальной переменной в 32 кБ, а глобальной всего 511 байт или около того, сейчас не помню) разные производители внесли соответствующуе улучшения (в Cache блок базы сделали 8 кБ, в GT.M вообще этот параметр для базы сделали настраиваемым, можно для разных баз задать разный размер блока базы).

Вы всерьёз полагаете простое увеличение "улучшением" ?
Кто-то тут говорил какая КАШЕ супре экономная и вдруг такое улучшение :(
А GT.M давно появилась ? Почему только там догадались сделать параметр настраиваемым ?


>> Так что насчет уровней, торопиться не надо, тем более число индексов может быть до 63...

Как связано число уровней в Б*дереве и число индексов ?
17 май 06, 22:39    [2676682]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
LittleCat
c127

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

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

Деревья не изобретение КЕШ-а. Запатентуйте еще блок питания и постоянный ток.
Данные в РСУБД (по-видимому это они понимаются под именем "современные базы данных") хранятся в таблицах, которые есть отношения. Как было у Кодда в самом начале, так и осталось, никто никуда не пришел. А индексы - это средство, вопрос удобства и вряд ли их взяли из КЕШ-а.



Iura

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

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

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

Iura

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

Отвечаю: не зависит никак. Связи размера файла БД современного СКЛ сервера с производительностью нет.

К тому же, повторяю еще раз, при обычной работе файлы растут не так быстро.

Iura

Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию.

Не кучу, гораздо меньше чем данные, но безусловно занимают. А что, в КЕШ-е индексы места вообще не занимают? Иерархия деревьев в КЕШ-е тоже сложная.

Мы выяснили в соседнем топике что в М, например, индексы отсутсвуют в принципе. Вместо них предлагается ДУБЛИРОВАТЬ ДАННЫЕ в деревья подходящей структуры. Вот это действительно КУЧА места. Место под индексы по сравнению с этим - детские шалости.

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

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

Iura
но эти же значения разбросанны на диске и причем не эффективно.

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

Не упорствуйте, чем дольше Вы пытаетесь выкрутиться, тем глубже закапываетесь и тем комичнее это выглядит. Признайте что ошиблись.
18 май 06, 00:22    [2676822]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Andreww
Определение уровня у вас своё ? Корень дерева имеет уровень 0, любой другой узел имеет уровень на 1 больше потомка (определение всех остальных людей).
У вас в примере который вы привели (УКАЗАТЕЛИ) -> (БЛОКИ ДАННЫХ), сл-но глубина вашего дерева равна 1 и список указателей всегда показывает на данные, сл-но дерево у вас с 1 уровнем.

корнем для блока указателей является блок каталога, ну да ладно

Andreww

>>сейчас, скажем, 8Kb (как и блок данных и прочие другие блоки).
Хммм. А менять размер можно ? Для указателей 8к может и нормально (хотя надо учитывать что при вставке\удалении указатели двигать надо), но для данных перебор.

на длинных данных используются какие-то свои хитрости, я пока не ковырялся,
но понятие big-string у них существует. наверное указатель


>>а ведь очевидно, что поиск идет через блоки указателей, а не через всю цепочку блоков данных. или нет? блоки указателей тоже растут
Пару минут назад я думал что "блок фиксирован размером, какой же это был бы иначе блок" теперь выясняем, что "растут подлецы" :)

"растут" не в размерах, а в количестве.


А указатель-то на блок данных в списке указателей надо найти ? Или как ?
Вот ваш же пример

блок указателей #50
^X = 101
^X(100,255)=102
^X(160,100,400)=103
^X(500,400)=104
^X(600,101,202,303,405,7)=105
....... и далее

Как мне найти номер блока данных для ^X(230,67,22,3,87,11,55,3,223) ? Есть он вообше в 8 килобайтах блока #50 или блок #50 уже вырос или .... ?

а вот насчет поиска - это уже не ко мне. алгоритмы бывают разные, а
система вовсе не Open Source. понятно, что блоки указателей тоже
выстраиваются в цепочку. когда она становится слишком большой,
добавляется уровень указателей выше. добавится ли новый уровень,
когда и тот заполнится - не знаю, у меня нет БД такого большого объема.


>>массив 162 млн. узлов занимает 366,061 блоков данных, 515 блоков указателей 2-го уровня и один блок указателей 1-го уровня.
Стоп-стоп. В исходном примере у вас блок указателей показывал только на данные, теперь оказывается есть ещё уровень указателей, т.е. дерево всё-таки глубины 2 или может 3 или всё же не ограничено ?
Обясните.

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


>>время поиска сокращается очень значительно, иначе бы эти структуры не использовались.и не только в M, ага. :)
Так дело в том что "не только в М" у дерева глубина произвольная и поиск потому эффективнее.

а разве я спорю? B-деревья - вещь удобная. и B-деревья вовсе
не изобретение M-технологии, как пытаются за нас утверждать некоторые.


>>вот странно, а все полагают, что это оно и есть.
Не знаю кто "все", но в Б*дереве глубина не ограничена 2 уровнями. Несогласны ?

а разве я писал про ограничения?


>>раньше использовали hash-indexing,
Вообще-то ХЭШ-СПИСОК, ну да ладно, смысл от этого не меняется, сначала находим указатель на СПИСОК (по хэшу) (из списка указателей) потом последовательным перебором этого списка находим нужный нам элемент.
Как и у вас - 1 уровень (кстати убыстрен за счёт ХЭША, а как у вас пока не понятно) второй уровень- последовательный перебор списка до нужного элемента (ИТЕМА как вы говорите).

вполне может быть, есть там несколько непонятных байт. на всех уровнях,
кстати, если это оно и есть - я не удивлюсь.


>>Ну зря Вы так, Сергей же просто пример привел, при разрастании дерева в М системах строится несколько уровней указателей.
Несколько это 2,3,5 ? Может я горячусь и там разумное ограничение эдак в 100-200 уровней ?
Почему никто не может объяснить ?

послушайте, может Вы можете нам объяснить как это будет выглядить
в IOT на террабайте данных? я с удовольствием послушаю. а то как-то
некрасиво получается, что Вам не скажи - все мало.

может и нет там ограничений вовсе? нет, ограничение конечно есть - 32Tb
на размер БД, то есть блок в БД адресуется 4-мя байтами. и все это
укладывается в 3 уровня (2 уровня указателей и уровень данных).


Зачем вообще это ограничивать 2 или 3 уровнями ? Нормальное Б*дерево всегда будет эффективнее для поиска,
а 3 или 5 уровней вызовут все те же проблемы расщепления-слияния (блокировка блоков указателей до корня) про которые уже всё рассказали.

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


Вы всерьёз полагаете простое увеличение "улучшением" ?
Кто-то тут говорил какая КАШЕ супре экономная и вдруг такое улучшение :(
А GT.M давно появилась ? Почему только там догадались сделать параметр настраиваемым ?

в Cache он тоже настраиваемый (в своем роде, 2Kb или 8Kb). вот потому и
"экономная", что долго тянули с этим выбором. или нужно объяснять чем
невыгоден большой разбер блока на небольших данных?


>> Так что насчет уровней, торопиться не надо, тем более число индексов может быть до 63...
Как связано число уровней в Б*дереве и число индексов ?

а никак. связано только количество узлов с данными.

я вот вижу, что B-дерево увидели только в способе хранения.
а то, что хранится тоже дерево - нет.
18 май 06, 03:30    [2676930]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
Деревья не изобретение КЕШ-а. Запатентуйте еще блок питания и постоянный ток.
Данные в РСУБД (по-видимому это они понимаются под именем "современные базы данных") хранятся в таблицах, которые есть отношения. Как было у Кодда в самом начале, так и осталось, никто никуда не пришел. А индексы - это средство, вопрос удобства и вряд ли их взяли из КЕШ-а.

Cache здесь, честно говоря, вообще не причем. речь идет о M-технологии.
ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как
видим, они оказались дальновидны. а ведь все очень просто, с большими
объемами данных первыми столкнулись именно они.


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

приходится. над физическое размещение файла наложена его логическая
структура, которая ну никак в секторы по 512 байт не укладывается.
об этом Вам и говорят. вот тот же блок в 8Kb, например.


Iura

Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию.

Не кучу, гораздо меньше чем данные, но безусловно занимают. А что, в КЕШ-е индексы места вообще не занимают? Иерархия деревьев в КЕШ-е тоже сложная.
Мы выяснили в соседнем топике что в М, например, индексы отсутсвуют в принципе. Вместо них предлагается ДУБЛИРОВАТЬ ДАННЫЕ в деревья подходящей структуры. Вот это действительно КУЧА места. Место под индексы по сравнению с этим - детские шалости.

как мы уже заметили в "соседнем топике", наличие этого дублирования
почему-то не занимает КУЧУ места, а занимает объем гораздо меньший,
чем прекрасно организованные индексы в SQL. можем повторить опыт,
если есть желание. :)


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

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

ну да, головки ведь у дисков мгновенного действия, позиционирования нынче
не существует, индексный файл прекрасно влезает в память...


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

"операционной системе" пофигу сколько времени нужно задаче на собирание
вместе кусков файла БД. а вот задаче - нет. дефрагментация всегда давала
выигрыш в скорости, дает и сейчас, даже при наличии "супер-файловых" систем.
18 май 06, 03:58    [2676944]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
to Andreww & c127
Ребята, вы что-то заговариваться стали...

to Sergei Obrastsov
может и нет там ограничений вовсе? нет, ограничение конечно есть - 32Tb
на размер БД, то есть блок в БД адресуется 4-мя байтами. и все это
укладывается в 3 уровня (2 уровня указателей и уровень данных).

Никак не может такого быть. Страница 8К, следовательно порядок дерева около 500 (реально возможно и меньше). Дерево такого порядка при размере 32Т будет, как минимум, 4-х уровневое. А то и пяти...
я вот вижу, что B-дерево увидели только в способе хранения.
а то, что хранится тоже дерево - нет.
В-дереву по барабану что в нём хранят :-) Точно такой же индекс можно и в реляционке организовать.
18 май 06, 13:05    [2678634]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp

to Sergei Obrastsov
может и нет там ограничений вовсе? нет, ограничение конечно есть - 32Tb
на размер БД, то есть блок в БД адресуется 4-мя байтами. и все это
укладывается в 3 уровня (2 уровня указателей и уровень данных).

Никак не может такого быть. Страница 8К, следовательно порядок дерева около 500 (реально возможно и меньше). Дерево такого порядка при размере 32Т будет, как минимум, 4-х уровневое. А то и пяти...

нет фактических типов промежуточных блоков указателей, только TOP и
BOTTOM. впрочем, может они ими извращаются? не знаю, как только найду
такую базу - сразу посмотрю.

pavelvp

я вот вижу, что B-дерево увидели только в способе хранения.
а то, что хранится тоже дерево - нет.
В-дереву по барабану что в нём хранят :-) Точно такой же индекс можно и в реляционке организовать.

правильно, по барабану. но мне-то нет. :)
это не индекс, это ВСЯ структура.

C уважением. Сергей
18 май 06, 13:35    [2678868]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Andreww
Member [заблокирован]

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

>> Ребята, вы что-то заговариваться стали...

Полагаете пора ликбез закончить ? Пожалуй.

2 Sergei Obrastsov

>>корнем для блока указателей является блок каталога, ну да ладно

:( Вы читаете что вам пишут или нет ?

Ещё раз : Корень дерева имеет уровень 0, любой другой узел имеет уровень на 1 больше потомка (определение всех остальных людей).

Корень ВАШЕГО дерева, это и есть "самый первый" блок указателей.


>>"растут" не в размерах, а в количестве.

Я про это и говорю.


>>а вот насчет поиска - это уже не ко мне. алгоритмы бывают разные, а
>>система вовсе не Open Source. понятно, что блоки указателей тоже
>>выстраиваются в цепочку. когда она становится слишком большой,
>>добавляется уровень указателей выше. добавится ли новый уровень,
>.когда и тот заполнится - не знаю, у меня нет БД такого большого объема.

Ну я про то и говорю, и в этом списке (8 килобайтном) надо найти элемент. Если у вас 2-х уровневое дерево, надо пробежать 2 * 8 = 16 кб элементов для поиска каждого значения, в сортированном списке это сделать проще конечно :)


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

Сейчас сейчас всё будет.


>>а разве я спорю? B-деревья - вещь удобная. и B-деревья вовсе
>>не изобретение M-технологии, как пытаются за нас утверждать некоторые.

И кстати говоря не единственное, у оракла, например, индексы бывают :

B*tree indexes
B*tree cluster indexes
hash cluster indexes
reverse key indexes
bitmap indexes


>>а разве я писал про ограничения?

А то как же ?


>>послушайте, может Вы можете нам объяснить как это будет выглядить в IOT на террабайте данных? я с удовольствием послушаю. а то как-то
некрасиво получается, что Вам не скажи - все мало.

Нету в обычных базах IOT-ов на террабайты, о чём я и пытаюсь вам сказать, исключения бывают, но это не мой случай :)

Вот кусочек с металинка :

B*Tree Balancing
~~~~~~~~~~~~~~~~
Oracle indexes are implemented as B* Trees which are always balanced.

In an Oracle B*tree the root of the tree is at level 0. In a very small B*tree
the root block can also be a Leaf block.

In most cases, blocks on levels 0 through N-2 (where N is the height of the
tree) are Branch blocks. Branch blocks do not contain data, they simply contain
separators which are used to navigate from the root block to the the Leaf
blocks.

All Leaf blocks are at level N-1 in Oracle B*trees. All data stored in a B*tree
is stored in the Leaf blocks.

The definition of a 'Balanced Tree' is that all the data is on the same level.
Which means that the path to all data in the tree is the same length. Since all
the data is stored in Leaf blocks and all the Leaf blocks are on the same level
the B*trees are always balanced. There is no way to unbalance a B* tree.

Про ограничение на N не нашел, вполне может быть что плохо искал.

Вам раз 5 уже повторили, что при большом количестве данных и значительной глубине, механизм блокировок узлов, довольно затратный, потому террабайты и не хранят в деревьях.


По этому вопросу, работ немало - http://www.cs.wisc.edu/~cs764-1/blink.pdf, посмотрите как там его (дерево разнесчастное) крутят, и дополнительные связи вводят
и Красно-чёрные деревья добавляют и т.д. и т.п.

С того же металинка :


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The reason for doing this is that, when data is inserted into a Leaf block, and
there is no room for the insert, a very expensive operation called a split
occurs. The split creates a new Leaf block and possibly new Branch blocks as
well to maintain the balance of the tree. The split operation is by far the
most expensive operation that is done in the maintenance of B* trees so we go
to great lengths to avoid them. By not collapsing the now unused levels out of
the B*Trees after large deletes these levels (with splits) do not have to be
recreated during future inserts.


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

Ну вот, что это как не ОГРАНИЧЕНИЕ, то оно есть, то его нету ....




>> Так что насчет уровней, торопиться не надо, тем более число индексов может быть до 63...
Как связано число уровней в Б*дереве и число индексов ?

а никак. связано только количество узлов с данными.

А зачем тогда вспоминать про число индексов ?
18 май 06, 14:20    [2679236]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
нет фактических типов промежуточных блоков указателей, только TOP и
BOTTOM. впрочем, может они ими извращаются?
Да причём тут типы. Их то как раз два - узлы и листья :-)
С 8-ми килобайтной страницей никак такое дерево не влезет в три уровня...

Sergei Obrastsov
правильно, по барабану. но мне-то нет. :)
это не индекс, это ВСЯ структура.
Да какая разница!? Точно такую же логическую структуру хранения данных в виде дерева, или как вы их назваете красиво - многомерные разреженные массивы :-), можно хранить и в реляционке (в любой РСУБД). Физически будет отличаться только тем, что данные в узлах лежат отдельно от индексов. Логически - ничем абсолютно.
18 май 06, 14:29    [2679318]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
А вот кстати вопрос кешевцам.

Как уже вами не раз упомяналось типизации нет, числа хранятся строчками и следовательно "2" будет больше чем "111".

Значит ли это что фактически для чисел можно использовать только запросы где есть точное сравнение? Т.е. запросы типа i between 2 and 111 или просто i>2 использовать нельзя
Если я не прав то объясните как это решается

Имеется ввиду конечно использование индексного поиска
18 май 06, 16:01    [2679908]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
А вот кстати вопрос кешевцам.

Как уже вами не раз упомяналось типизации нет, числа хранятся строчками и следовательно "2" будет больше чем "111".

нет, если речь идет об индексе. если его можно интерпретировать в число
без потери символов, то он и запишется как число. это для правильной
сортировки, то есть цифровой, она же дефолтная. чтобы было наоборот
нужно указывать "строковую" сортировку для массива.


Значит ли это что фактически для чисел можно использовать только запросы где есть точное сравнение? Т.е. запросы типа i between 2 and 111 или просто i>2 использовать нельзя
Если я не прав то объясните как это решается
Имеется ввиду конечно использование индексного поиска

надо полагать вопрос к народу, занимающемуся Cache-SQL? я работаю
с массивами напрямую.
18 май 06, 16:16    [2679990]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
надо полагать вопрос к народу, занимающемуся Cache-SQL? я работаю
с массивами напрямую.
причём здесь SQL...
18 май 06, 16:22    [2680015]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
SergSuper
Как уже вами не раз упомяналось типизации нет, числа хранятся строчками и следовательно "2" будет больше чем "111".


По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111". Имплементации мампса могут поддерживать (дополнительно) задание других соглашений, в частности строковой безотносительно содержания. В ней "2" пойдет после "111".

По умолчанию сортировка индексная.
USER>s a("2")=""
USER>s a("111")=""
USER>w
a(2)=""
a(111)=""
Если значения - числа то сравниваются как числа. Если не числа то сравниваются как строки по установленному для глобали / процесса коллейшена. Если сравнивается число и не число, то числа всегда меньше нечисел. Исключение - пустая строка, она сортируется перед числами.

SergSuper
Значит ли это что фактически для чисел можно использовать только запросы где есть точное сравнение? Т.е. запросы типа i between 2 and 111 или просто i>2 использовать нельзя
Если я не прав то объясните как это решается

Имеется ввиду конечно использование индексного поиска


s i=2 f  s i=$o(a(i)) q:(i="")!'(111]]i)  w i,!
Начальное значение итератора 2. В цикле берем следующее значение индекса после итератора. Прекращаем цикл если итератор пуст (данные кончились) или если 111 не сортируется после итератора. В цикле пишем в текущий девайс значение индекса и перевод строки. Например:
USER>w
a(2)=""
a(3)=""
a(34)=""
a(111)=""

USER>s i=2 f  s i=$o(a(i)) q:(i="")!'(111]]i)  w i,!
3
34
18 май 06, 16:27    [2680048]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

а причем тут "запросы типа i between 2 and 111 или просто i>2"?
впрочем ладно, может я просто неправильно воспринимаю.
но я все-равно ответил, числа отсортируются правильно.
18 май 06, 16:33    [2680096]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ну я
USER>s i=2 f s i=$o(a(i)) q:(i="")!'(111]]i) w i,!
3
34
[/src]

а зачем так мудрить "'(111]i)"? не проще написать i>111, все-равно ведь известно, что там числа? :)

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

Откуда: Москва
Сообщений: 1277
Sergei Obrastsov
ну я
USER>s i=2 f s i=$o(a(i)) q:(i="")!'(111]]i) w i,!
3
34
[/src]

а зачем так мудрить "'(111]i)"? не проще написать i>111, все-равно ведь известно, что там числа? :)

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

Инерция мышления. Привычка работать только с параметрами как таковыми.
Кстати, условие выхода i>111 пустит в цикл также и 111, то есть нужно i'<111.
18 май 06, 17:16    [2680394]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?
Если типизации нет, и все хранится как строки, то как он отличает строку "111" от строкового представления числа 111? Или никак не отличает, а просто сортирует строки "неправильно"?
18 май 06, 17:23    [2680443]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Т.е. если есть набор строк:
111
111-ый нах
2
2-ой нах
Вася
Петя
то в каком порядке все эти строки в кешовом "индексе" расположатся? В таком:
2
111
111-ый нах
2-ой нах
Вася
Петя
?
18 май 06, 17:37    [2680552]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
Пьяный Лох
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?

Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом.
Пьяный Лох
Если типизации нет, и все хранится как строки, то как он отличает строку "111" от строкового представления числа 111? Или никак не отличает, а просто сортирует строки "неправильно"?

Есть детальное описание (в стандарте) того, что называется каноническим представлением числа. Полное определение довольно длинное, не буду приводить. Например "2" это число, а "2.00" или "2." это уже строки. Речь идет именно о каноническом представлении чисел для индексной сортировки, ни о чем другом. Если работать с мампсом, то путаницы обычно ни у кого не возникает более одного раза ))).
Выяснить что из себя есть каноническое и неканоническое представление можно через операцию +: значение переменной str есть каноническое представление числа если +str=str. Исключения и нюансы - с плавающей точкой.
18 май 06, 17:48    [2680614]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
Т.е. если есть набор строк:
111
111-ый нах
2
2-ой нах
Вася
Петя
то в каком порядке все эти строки в кешовом "индексе" расположатся? В таком:
2
111
111-ый нах
2-ой нах
Вася
Петя
?

при числовой сортировке именно так. есть правда маленькая деталь,
а нафига совать в индекс разные логические типы данных?
там где нужны числа у меня будут числа, а там где строки - строки

С уважением. Сергей
18 май 06, 17:52    [2680639]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 ну я
Пьяный Лох
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?

Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом.

Оп-ля... Это как это - "приписать пробел"? У меня строка безо всякого пробела в начале, однако. С какой радости я её модифицировать должен?

-----------

2 Sergei Obrastsov
при числовой сортировке именно так. есть правда маленькая деталь,
а нафига совать в индекс разные логические типы данных?
там где нужны числа у меня будут числа, а там где строки - строки

Нафига? Не знаю... А нафига отсутствие типизации сделали? Значит это кому-нибудь нужно? Если это кому-нибудь нужно - наверное и работать с этим кому-нибудь приходится?

Были бы типы данных - не было бы таких вопросов. Поле числового типа сортировалось бы как набор чисел, и строку туда нельзя было бы записать, а в поле строкового типа можно было бы записать любую строку (хоть бы даже и содержащую "каноническое представление числа"), и сортировалось бы это как набор строк.

А так получается, что я могу записать в одно и то же поле и "строки", и "числа" (и это действительно иногда нужно). И если "строковое" подмножество содержит что-то, по несчастливой случайности совпадающее по внешнему виду с "каноническим представлением числа" - то отсортировать корректно полученное множество уже никак не получится, патамушта либо часть "строк" уедет в область "чисел" (при "числовой" сортировке), либо "числа" будут сортироваться как "строки" (при выставленном ascii collation'е для глобали).
18 май 06, 18:08    [2680755]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
Пьяный Лох
2 ну я
Пьяный Лох
ну я
По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111".

Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться?

Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом.

Оп-ля... Это как это - "приписать пробел"? У меня строка безо всякого пробела в начале, однако. С какой радости я её модифицировать должен?

Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь. А про радость не могу ничего сказать - это нетехнический вопрос. Пока не вижу чего тут пугаться или радоваться - соглашение о правиле индексной сортировке на редкость практичное. Если бы в мампсе была типизация - то мы бы зашились с этими типами. Есть куча систем которые должны быть по своему устройству (как следствие их назначения) непрерывно изменяемы. В первую очередь бизнес-ориентированные. Если нам еще и типами заниматься - зашились бы точно.
18 май 06, 18:23    [2680833]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
Были бы типы данных - не было бы таких вопросов. Поле числового типа сортировалось бы как набор чисел, и строку туда нельзя было бы записать, а в поле строкового типа можно было бы записать любую строку (хоть бы даже и содержащую "каноническое представление числа"), и сортировалось бы это как набор строк.

интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :)
и зачем вот это "нельзя записать"? я сам строю БД и решаю куда что писать.


А так получается, что я могу записать в одно и то же поле и "строки", и "числа" (и это действительно иногда нужно). И если "строковое" подмножество содержит что-то, по несчастливой случайности совпадающее по внешнему виду с "каноническим представлением числа" - то отсортировать корректно полученное множество уже никак не получится, патамушта либо часть "строк" уедет в область "чисел" (при "числовой" сортировке), либо "числа" будут сортироваться как "строки" (при выставленном ascii collation'е для глобали).

можно пример такой необходимости, что-то я навскидку ничего представить
не могу?
ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются
на принцип "str=+str", как справедливо заметил "ну я".
только это не операция на уровне "послать запрос 2<i<111 и получить список"
это несколько другой уровень абстракции

С уважением. Сергей
18 май 06, 18:37    [2680900]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 ну я
Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь.

Т.е. все строки - с пробелом в начале? И тогда уж не "первый символ отбрасываешь", а "первый символ анализируешь, если пробел - отбрасываешь"?

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

Да ладно Вам. Я даже не буду спорить с тем, что иногда сильная типизация хуже, чем слабая (но только иногда, имхо). Речь не про то. Если уж система расчитана на слабую типизацию - кто мешает факт наличия этой самой слабой типизации унутре себя учесть? Хранили бы в месте со значением переменной еще один байт - "тип", не имели бы проблем с определением этого самого типа. Собственно предложенное решение ("при записи конкатенируешь с пробелом, при чтении пробел выкидываешь") и есть та самая информация о типе значения. Тока почему-то не на уровне системы, а ручками делать.
18 май 06, 18:39    [2680905]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 Sergei Obrastsov

интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :)

Кто мешает-то? В чем проблема отсортировать по разному? По-моему проблемы с сортировкой нет, более того, в вашем М именно по разному и сортируется - числа одним способом, строки другим, между собой еще как-то. Только у вас проблема с невозможностью определения типа для некоторых значений.

можно пример такой необходимости, что-то я навскидку ничего представить не могу?

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

ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я".

Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. Так что не четко проверяются. Можно лишь четко определить случай, когда строка НЕ является строковым представлением числа.
18 май 06, 18:51    [2680968]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
Пьяный Лох
2 ну я
Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь.

Т.е. все строки - с пробелом в начале? И тогда уж не "первый символ отбрасываешь", а "первый символ анализируешь, если пробел - отбрасываешь"?

)))
Я, конечно, понимаю, что хочется повыделываться, но это неверное правило. Если вам придется работать с мампсом, вы сами себя переубедите, на простых контрольных примерах. А если не придется - то не берите в голову.
18 май 06, 18:54    [2680990]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
это неверное правило.

Тогда какое верное?
Не всем строкам пробел спереди приписывать? А каким?
18 май 06, 18:58    [2681006]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Если вам придется работать с мампсом

не дай бог :)
18 май 06, 18:58    [2681014]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

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

Гнать не нужно. Никто вам ничего не должен, не выдумывайте. И криков никаких нет и лагеря никакого нет.

Пьяный Лох
Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111.

А зачем это может понадобиться?
USER>w "111"+"111"
222
USER>w 111+"111"
222
USER>w "111"+111
222
USER>w 111
111
USER>w "111"
111
USER>w +"111"
111
Хотя мне известны способы как различить, но хотелось бы услышать законченную мысль: Не отличить строку от представления числа, что безусловно необходимо для ....
Вот для чего это необходимо, хотелось бы понять.
18 май 06, 19:04    [2681046]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
Пьяный Лох
ну я
это неверное правило.

Тогда какое верное?
Не всем строкам пробел спереди приписывать? А каким?

Быстрый вопрос - проявление нежелания подумать даже немного.
18 май 06, 19:07    [2681062]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Пьяный Лох
2 Sergei Obrastsov

интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :)

Кто мешает-то? В чем проблема отсортировать по разному? По-моему проблемы с сортировкой нет, более того, в вашем М именно по разному и сортируется - числа одним способом, строки другим, между собой еще как-то. Только у вас проблема с невозможностью определения типа для некоторых значений.

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


можно пример такой необходимости, что-то я навскидку ничего представить не могу?

Это мумпсисты должны примеры приводить, когда необходимо в одном поле хранить разнотипные переменные.

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


ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я".

Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. Так что не четко проверяются. Можно лишь четко определить случай, когда строка НЕ является строковым представлением числа.

я прошу прощения, конечно, но я не вижу разницы между 111 и "111":
111+2=113
"111"+2=113
для чего оно мне понадобится? чтобы "строково сортировалось"? ну, я это
учту при выводе, раз уж так кому-то захотелось.
18 май 06, 19:10    [2681073]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
Пьяный Лох
Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111.

А зачем это может понадобиться?
USER>w "111"+"111"
222

А что, такого не может быть:
USER>w "111"+"111"
111111
USER>w "111"+111
111111
USER>w 111+"111"
111111
USER>w 111+111
222
???
18 май 06, 19:10    [2681074]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.
18 май 06, 19:14    [2681100]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
Пьяный Лох
ну я
Пьяный Лох
Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111.

А зачем это может понадобиться?
USER>w "111"+"111"
222

А что, такого не может быть:
USER>w "111"+"111"
111111
USER>w "111"+111
111111
USER>w 111+"111"
111111
USER>w 111+111
222
???

Нет, первых три случая не может быть. Четвертый должен быть.
Если нужна конкатенация - то ее и нужно использовать. Обозначается подчеркиванием.
18 май 06, 19:17    [2681110]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
Нет, первых три случая не может быть. Четвертый должен быть. Если нужна конкатенация - то ее и нужно использовать. Обозначается подчеркиванием.

Ок. Это, видимо, вопрос синтаксиса.

Что вернется в результате такой операции:
USER>w "abc"+"def"
?
Т.е. операция "+" перегружена (в зависимости от типов операндов), или четко и строго является арифметическим сложением двух чисел (и ничем другим являться не может)?
Я, пардон, синтаксиса мумпса не знаю, потому и спрашиваю. Можно в какой-нибудь онлайн хелп послать, не обижусь.
18 май 06, 20:25    [2681265]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
Пьяный Лох
Что вернется в результате такой операции:
USER>w "abc"+"def"
?
Т.е. операция "+" перегружена (в зависимости от типов операндов), или четко и строго является арифметическим сложением двух чисел (и ничем другим являться не может)?

+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0.
USER>w +"abc"
0
USER>w +"123abc"
123
USER>w +"123e3abc"
123000
USER>w +"123.98abc"
123.98
USER>w +"++--+-123"
-123
Документация ставится при установке, также есть онлайн
тынц
18 май 06, 21:12    [2681365]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
ну я
+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0.
USER>w +"abc"
0
USER>w +"123abc"
123
USER>w +"123e3abc"
123000
USER>w +"123.98abc"
123.98
USER>w +"++--+-123"
-123

USER>w +"123"
USER>w +"0123"
USER>w +"00000123"
выдадут одинаковый результат?
если да, то считаются ли эти строки ("123", "0123" и "00000123") равными? в частности при записи в эту... как её... в глобаль?

Документация ставится при установке, также есть онлайн
тынц

сенкс, на досуге поизучаю.
18 май 06, 21:26    [2681382]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1277
Пьяный Лох
ну я
+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0.
USER>w +"abc"
0
USER>w +"123abc"
123
USER>w +"123e3abc"
123000
USER>w +"123.98abc"
123.98
USER>w +"++--+-123"
-123

USER>w +"123"
USER>w +"0123"
USER>w +"00000123"
выдадут одинаковый результат?

Да.

Пьяный Лох
если да, то считаются ли эти строки ("123", "0123" и "00000123") равными? в частности при записи в эту... как её... в глобаль?

Нет, лидирующий ноль - неканоничен.
18 май 06, 22:43    [2681579]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Пьяный Лох
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.

А ведь есть еще даты.
19 май 06, 00:29    [2681858]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
c127
Пьяный Лох
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное.
не видите разницу между "111" и 111 - говорить наверное больше не о чем.

А ведь есть еще даты.

не будем о грустном
19 май 06, 00:40    [2681897]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

А ведь есть еще даты.

не будем о грустном

а что с ними такого страшного? нет, конечно, можно и хранить их в виде
dd.mm.gggg, но это неудобно. обычно пользуются их машинным
форматом, т.е. 19.05.2006 = 60404. аналогично для времени
19 май 06, 01:13    [2681985]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Sergei Obrastsov
c127
Деревья не изобретение КЕШ-а. Запатентуйте еще блок питания и постоянный ток.
Данные в РСУБД (по-видимому это они понимаются под именем "современные базы данных") хранятся в таблицах, которые есть отношения. Как было у Кодда в самом начале, так и осталось, никто никуда не пришел. А индексы - это средство, вопрос удобства и вряд ли их взяли из КЕШ-а.

Cache здесь, честно говоря, вообще не причем. речь идет о M-технологии.

Речь идет как раз о КЕШ-е, которая, если не ошибаюсь, построена на М.

Sergei Obrastsov

ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как
видим, они оказались дальновидны. а ведь все очень просто, с большими
объемами данных первыми столкнулись именно они.

Как же, знаем, они также первыми высадились на берега Америки, еще до викингов. А ссылочку не приведете на большие объемы данных?


Sergei Obrastsov


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

приходится. над физическое размещение файла наложена его логическая
структура, которая ну никак в секторы по 512 байт не укладывается.
об этом Вам и говорят. вот тот же блок в 8Kb, например.

Что Вы знаете о физической структуре файла данных СКЛ сервера? Наверняка же ничего не знаете. Я тоже почти ничего не знаю, но это же совершенно очевидно, что файл подряд с самого начала каждый раз не читается. Сервер знает где у него лежат таблицы, где индексы, если нужен индекс читается только он и то не целиком, таблица тоже, только то что нужно, остальное не читается. Ну какая разница, сколько занимает файл? Абсолютно то же самое, как если бы все индексы и таблицы были сложены в отдельные файлы. Кстати так тоже можно, но никто этого не делает, потому что никакого выигрыша в скорости нет.

Sergei Obrastsov


Iura

Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию.

Не кучу, гораздо меньше чем данные, но безусловно занимают. А что, в КЕШ-е индексы места вообще не занимают? Иерархия деревьев в КЕШ-е тоже сложная.
Мы выяснили в соседнем топике что в М, например, индексы отсутсвуют в принципе. Вместо них предлагается ДУБЛИРОВАТЬ ДАННЫЕ в деревья подходящей структуры. Вот это действительно КУЧА места. Место под индексы по сравнению с этим - детские шалости.

как мы уже заметили в "соседнем топике", наличие этого дублирования
почему-то не занимает КУЧУ места, а занимает объем гораздо меньший,
чем прекрасно организованные индексы в SQL. можем повторить опыт,
если есть желание. :)

Мы этого к сожалению не заметили. Приведите ссылку, где это обсуждалось и где выяснилось, что так называемые индексы в М не занимают кучу места.

Дублирование данных (индексирование по-Вашему) обсуждалось тут:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070
от слов "В предположении, что индекса по пассажирам нет" и дальше по топику

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

Sergei Obrastsov

ну да, головки ведь у дисков мгновенного действия, позиционирования нынче
не существует, индексный файл прекрасно влезает в память...

К Вашему сведению позиционирование головки от размера файла никак не зависит. Диск крутится все время, ОС елозит головками по диску все время, поэтому совершенно неизвестно где окажется головка по отношению к следующему запрашиваемому сектору.


Sergei Obrastsov

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

Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся.
А, вот нашел, оказывается есть дефрагментатор для ext2, но:
"ext2fs is somewhat resilient against fragmentation, and more importantly is not severely affected by it when it does happen.
This is quite different from the "MS-DOS experience," where fragmentation has significant deleterious effects on system performance."
http://cbbrowne.com/info/defrag.html
Но при чем тут дефрагментация?

Ну ладно, хотите чтобы зависело, пусть зависит. Но повторяю в третий раз: РАЗМЕР БД ПРИ ОБЫЧНОЙ РАБОТЕ (не специальные тесты) РАСТЕТ НЕ БЫСТРО И ПУСТЫХ МЕСТ ТАМ ОБЫЧНО НЕ СИЛЬНО МНОГО. Объяснял почему, можно еще книжки почитать для разнообразия. Это закрывает вопрос о больших файлах, даже в том случае, если скорость на них и падает.
19 май 06, 01:45    [2681993]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
интересно...
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?
2. Если для всех математических вычислений приходится производить конвертацию каждого аргумента к числовому виду (если это возможно, конечно), то вряд ли можно получить выигрыш по скорости.
3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных?
19 май 06, 02:22    [2682010]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
AAron
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?

.3333333333333333333
так и хранится, как строка. если тебя интересует как это обрабатывает
модуль вычислений - понятия не имею.


2. Если для всех математических вычислений приходится производить конвертацию каждого аргумента к числовому виду (если это возможно, конечно), то вряд ли можно получить выигрыш по скорости.

по сравнению с компилятором? конечно же нет. а никто и не утверждал
обратного.


3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных?

в 3.
нет. но упаковывать можно, если уж так хочется, есть соответствующие функции.
может в базах данных хранятся, в основном, не числа?

С уважением. Сергей
19 май 06, 02:33    [2682014]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Sergei Obrastsov
AAron
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?

.3333333333333333333
так и хранится, как строка. если тебя интересует как это обрабатывает
модуль вычислений - понятия не имею.

гм... и сколько знаков? SQL Server способен в типе данных float занимая 8 байт хранить следующее (msdn)
Floating precision number data with the following valid values: -1.79E + 308 through -2.23E - 308, 0 and 2.23E + 308 through 1.79E + 308.


Sergei Obrastsov


3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных?

в 3.
нет. но упаковывать можно, если уж так хочется, есть соответствующие функции.
может в базах данных хранятся, в основном, не числа?

"в 3." - не понял, это к третьему пункту или в три раза? Мне вообще не хочется хранить упакованные или неупакованные числа в виде строк.
А в базах данных числа в том числе хранятся.
Например, банк заключает сделки на бирже. типичный набор полей таблицы (trade_id int, asset_id int, currency_id int, deal_date datetime, price float, quantity float). Итого - ни одной строки, но масса чисел.

Другой пример. Телеком. Информация о звонках в системе. Таблица (call_date datetime, circuit_id int, prefix_id int, client_id int, host_id int, seconds_1 int, seconds_2 int, amount_1 int, amount_2 int) ну и т.д.
Таблицы разумеется более сложно структуры, но суть отражают. Количество записей - для банков (россии) это сотни тысяч, для телекома - миллионы.
19 май 06, 03:01    [2682027]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186

в 3.
нет. но упаковывать можно, если уж так хочется, есть соответствующие функции.
может в базах данных хранятся, в основном, не числа?

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


А что по вашему в основном храниться в БД строки ? Большенство баз в мире имеет отношение к финансовой и производственной деятельности. В них храняться показатели данных сфер деятельности (деньги, количество). Имено с ними и приходиться выполнять такие операции как например суммирование или сложение и вычитание. При больших объемах данных перевод строк в числа и обратно процедура настолько затратная что обещание фантастических скоростей при использовании MUMPS сомнительно. Что в общем то и подтвердилось у нас. Скорость расчетов на M ситеме оказалась намного меньше чем в том же ORACLE. Чудес не бывает. Не может тот же PHP (который так же использует нетипизированные пременные и является как и MUMPS интерпритатором обогнать в скорости вычислений программу на С). Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз.
19 май 06, 03:15    [2682031]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584

Sergei Obrastsov

ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как
видим, они оказались дальновидны. а ведь все очень просто, с большими
объемами данных первыми столкнулись именно они.

Как же, знаем, они также первыми высадились на берега Америки, еще до викингов. А ссылочку не приведете на большие объемы данных?

а сами объемы не нужно привести? Mumps создавался для системы здравоохранения, по-моему можно прикинуть количество данных,
которые там крутятся
(если честно, я притомился искать в инете конкретные цифры)


Что Вы знаете о физической структуре файла данных СКЛ сервера? Наверняка же ничего не знаете. Я тоже почти ничего не знаю, но это же совершенно очевидно, что файл подряд с самого начала каждый раз не читается. Сервер знает где у него лежат таблицы, где индексы, если нужен индекс читается только он и то не целиком, таблица тоже, только то что нужно, остальное не читается. Ну какая разница, сколько занимает файл? Абсолютно то же самое, как если бы все индексы и таблицы были сложены в отдельные файлы. Кстати так тоже можно, но никто этого не делает, потому что никакого выигрыша в скорости нет.

а разве я говорил про полное чтение файла? речь, скажем, о чтении индексного дерева, которое явно читается не по секторам.



как мы уже заметили в "соседнем топике", наличие этого дублирования
почему-то не занимает КУЧУ места, а занимает объем гораздо меньший,
чем прекрасно организованные индексы в SQL. можем повторить опыт,
если есть желание. :)

Мы этого к сожалению не заметили. Приведите ссылку, где это обсуждалось и где выяснилось, что так называемые индексы в М не занимают кучу места.

Дублирование данных (индексирование по-Вашему) обсуждалось тут:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12#2406070
от слов "В предположении, что индекса по пассажирам нет" и дальше по топику


https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383
еще раз скажу, что сравнивалась SQL (MySQL, MSSQL) таблица с одним индексом и Cache-структура с 9-ю.


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

я только ЗА. ссылки приведены.


Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся.

я бы рад избавиться, но пока приходится дефрагментировать. не часто и все же. про ext2 ничего не скажу, мне приходится работать под Windows
19 май 06, 03:51    [2682041]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
AAron
Sergei Obrastsov
AAron
математика на нетипизированных значениях (типа все строки).
1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится?

.3333333333333333333
так и хранится, как строка. если тебя интересует как это обрабатывает
модуль вычислений - понятия не имею.

гм... и сколько знаков? SQL Server способен в типе данных float занимая 8 байт хранить следующее (msdn)
Floating precision number data with the following valid values: -1.79E + 308 through -2.23E - 308, 0 and 2.23E + 308 through 1.79E + 308.

18
впечатляет. но пока хватает и 18.


"в 3." - не понял, это к третьему пункту или в три раза? Мне вообще не хочется хранить упакованные или неупакованные числа в виде строк.
А в базах данных числа в том числе хранятся.
Например, банк заключает сделки на бирже. типичный набор полей таблицы (trade_id int, asset_id int, currency_id int, deal_date datetime, price float, quantity float). Итого - ни одной строки, но масса чисел.

Другой пример. Телеком. Информация о звонках в системе. Таблица (call_date datetime, circuit_id int, prefix_id int, client_id int, host_id int, seconds_1 int, seconds_2 int, amount_1 int, amount_2 int) ну и т.д.
Таблицы разумеется более сложно структуры, но суть отражают. Количество записей - для банков (россии) это сотни тысяч, для телекома - миллионы.

в 3 раза, я думал, что понятно, sorry.
да, конечно, я тоже вот вспомнил последнюю базу по телефонным звонкам -
одни числа. и все же, разница в объемах есть. а когда в дело вступают индексы, то разница становится очень большой.
19 май 06, 04:09    [2682047]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
А что по вашему в основном храниться в БД строки ? Большенство баз в мире имеет отношение к финансовой и производственной деятельности. В них храняться показатели данных сфер деятельности (деньги, количество). Имено с ними и приходиться выполнять такие операции как например суммирование или сложение и вычитание. При больших объемах данных перевод строк в числа и обратно процедура настолько затратная что обещание фантастических скоростей при использовании MUMPS сомнительно.
Что в общем то и подтвердилось у нас. Скорость расчетов на M ситеме оказалась намного меньше чем в том же ORACLE.

красиво звучит, но хотелось бы увидеть конкретные цифры.
затраты есть, спорить не буду. в больших математических расчетах
M проигрывает специализированным приложениям. но не
проиграет СУБД, которые под это дело тоже не заточены. значит речь
о другом. о неправильной организации данных, о неумелых выборках
и прочем. я ведь могу залить в бак "болида" воду и сказать "херня эта ваша
гоночная машина, мой велосипед быстрее!" :)


Чудес не бывает. Не может тот же PHP (который так же использует нетипизированные пременные и является как и MUMPS интерпритатором обогнать в скорости вычислений программу на С).

однозначно не может. а он что, пытался?


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

я просто привык верить собственным глазам и рукам, так что знаю о чем говорю.
19 май 06, 04:20    [2682052]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186

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

я просто привык верить собственным глазам и рукам, так что знаю о чем говорю.[/quot]

Я понимаю когда человек глазам верит (хотя иногда бывает обман зрения), Но чтоб он рукам верил это уже что-то интересное. Ну да ладно это ваши личные проблемы. Вот вам задача конкретная давайте на ней тестировать

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)
Вот вам реальный пример. В начале месяца нагрузка увеличивается раза в 2 так как необходимо выдать немеренное кол- отчетности в том числе и аналитической. И все работает никто особо не жалуется. Одновременно выпоолняются сложные отчеты, заливаются новые данные (в день более 1 млн. записе), расчитывается стоимость разговора и т д. В 2001 году перешли на Оракл потому что система на М просто не справлялась. Жду от вас результатов тестирования на подобном обеме. Тесты на таблице из 100 записей не состоятельны для серьезных систем. Видимо поэтому ни одна из М систем не представлена независимых тестах TCP.
19 май 06, 09:04    [2682266]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

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

в больших математических расчетах
M проигрывает специализированным приложениям. но не
проиграет СУБД, которые под это дело тоже не заточены.

Так во-первых, чаще всего СУБД именно заточены для работы с разными языками (БД в общем случае предназначена для многих приложений и стало быть на разных языках). И потому в паре в такими языками имеют преимущество перед языком М по обоими направлениям. По вычислениям специализрованные приложения, по хранению и обработке СУБД тоже как спекциализированная на БД. Во-вторых, для некоторых специализированных приложений, например, ОЛАП и Датамайнинг СУБД могут иметь дополнительные специализированные возможности (в виде дополнительных опций) - поддерживать Движки для соответсвующих вычислений , напрмер, прогнозирования, распределения и проч.
Я уже пытался сказать об этом. Вы теперь сами почти пришли к этому - кооперация из специализированных часто лучше чего-то одного универсального.
19 май 06, 09:35    [2682375]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные
...
Оракл потому что система на М просто не справлялась. Жду от вас результатов тестирования на подобном обеме. Тесты на таблице из 100 записей не состоятельны для серьезных систем. Видимо поэтому ни одна из М систем не представлена независимых тестах TCP.

хороший тест. а про "железо" можно что-нибудь услышать, чтобы я имел
представление с чем идет сравнение?
19 май 06, 10:22    [2682628]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AI
Member

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

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)


Не надо еще забывать, что в оракле числа хранятся в своем внутреннем, а не в процессорном виде.
19 май 06, 12:16    [2683515]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Sergei Obrastsov

да, конечно, я тоже вот вспомнил последнюю базу по телефонным звонкам -
одни числа. и все же, разница в объемах есть. а когда в дело вступают индексы, то разница становится очень большой.


И все-таки, я не понимаю, как индексы могут помочь уменьшить объем фактических данных. Если есть такие факты: "Маша", "Даша", "Саша", "Паша", "Глаша" и т.п. как не строй индекс - все равно эти строки останутся. Точно так же и в том же телекоме - если есть продолжительность звонка, то никуда от нее не избавится. Да еще если хранить эту продолжительность в виде строки.
19 май 06, 12:51    [2683743]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

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

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

Есть ли еще что нибудь в каше изза чего на него стоит смотреть?

Пока видны такие минусы:
- специалистов по каше мало и они малоподвижы
- распростанена система слабо поэтому найти работу с применением знаний по каше будет сложно, похожих применяемых систем я тоже не знаю, так что нельзя как в рсубд - знаешь sql знаешь как работает версионник а как блокировочник и все на любом движке можно работать
- строгой математической теории, такой как под рсубд без белых пятен и простым решением любой проблемы, под каше нету
(только не надо заваливать ссылками, я же сказал без белых пятен, где ясно абсолютно все)
- по скорости работает также как и все остальное


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

Откуда: Магадан
Сообщений: 584
Joker_Ya
Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

еще один вопрос: а эти данные нужно получить на всей таблице или только
на выборке за 1 месяц?
19 май 06, 12:54    [2683772]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
AAron
И все-таки, я не понимаю, как индексы могут помочь уменьшить объем фактических данных. Если есть такие факты: "Маша", "Даша", "Саша", "Паша", "Глаша" и т.п. как не строй индекс - все равно эти строки останутся. Точно так же и в том же телекоме - если есть продолжительность звонка, то никуда от нее не избавится. Да еще если хранить эту продолжительность в виде строки.

вот ведь. разве я такое говорил? конечно, меньший объем вряд ли получится,
только за счет сжатия данных, а это чревато нагрузкой при выборке.
но вот объем БД вместе с индексами будет меньше чем у других СУБД на
этих же данных и с такой же индексацией.
19 май 06, 13:00    [2683809]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

было бы интересно посмотреть на результаты "того же самого можно добиться".

pgres

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

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

pgres

Есть ли еще что нибудь в каше изза чего на него стоит смотреть?
Пока видны такие минусы:
- специалистов по каше мало и они малоподвижы

yeees! правильно, но они уже есть. через год их будет больше.

pgres

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

true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да
работают.

pgres

- по скорости работает также как и все остальное

я бы не стал так говорить, не имея на руках результатов сравнений.
впрочем, я так понимаю, что даже имея такие результаты, вы их
все-равно опротестуете
19 май 06, 13:19    [2683917]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
можно посравнивать для разнообразия, что бы было не голословно
http://msdn2.microsoft.com/en-us/library/ms178085.aspx
http://msdn2.microsoft.com/en-us/library/ms190620.aspx
19 май 06, 13:20    [2683927]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 Sergei Obrastsov
Да что Вы заладили каше - большие объемы данных / данные растут в геометрической прогрессии
до боли напоминает рекламные с программированием ассоциаций
наверное это на тренингах по каше как мантру повторяют

лично у меня с большими объемами данных ассоциируется оракл и дб2

да откройте наконец секрет какие у Вас например объемы и почему так остро стоит проблема дискового пространства

автор

yeees! правильно, но они уже есть. через год их будет больше.


а специалистов по рсубд будет еще больше и прибавляться они будут гораздо быстрее
автор

true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да
работают.

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

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

да к тому же Вам ведь предложили провести сравнение
Joker_Ya

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)

если прочитаете 5 пункт то увидите что данные надо выбирать за месяц

с нетерпением жду результатов

ЗЫ: если результаты будут такими которые легко опротестовать то зачем эти результаты
19 май 06, 14:01    [2684239]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Joker_Ya
[quot ]
т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.


Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных.

>>1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
"простейший инкримент" он и в Африке такой же.. КАШЕ написан на C, как и Оракл, поэтому время увеличения счётчика в оперативной памяти скорее всего будет одинаковым. А если считать записи по мере прохода по всему массиву, так это получится выдуманный пример.. в реальной задаче нужные счётчики скорее всего будут меняться при записи или удалении данных (по крайней мере для проекта на Каше, это естественно)

>>2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
вот тоже самое.. не будет программист на Каше делить на 3600. Там есть встроенные функции преобразования количества секунд во время формата ЧЧ:ММ:СС .. они входят в сам язык, поэтому реализованы на C.

>>3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
вот это сравнение может что нибудь и даст..

4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
с такими объёмами Каше работает.. что подразумевается под умением - не понятно

5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
опять не выйдет сравнение.. в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу.
19 май 06, 14:21    [2684408]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 yww@escape.ru

ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать

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

Откуда: Магадан
Сообщений: 584
pgres
Да что Вы заладили каше - большие объемы данных / данные растут в геометрической прогрессии
до боли напоминает рекламные с программированием ассоциаций
наверное это на тренингах по каше как мантру повторяют

понятия не имею, я там никогда не был.

pgres

лично у меня с большими объемами данных ассоциируется оракл и дб2
да откройте наконец секрет какие у Вас например объемы и почему так остро стоит проблема дискового пространства

диск небольшой, а MSSQL много кушает.
~300 млн. записей, а ведь индексировать еще нужно. если мне сейчас скажут,
что это все ерунда и без индексов SQL выберет все, что нужно за минуту,
я не поверю.

pgres

автор

true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да
работают.

это говорит в пользу рсубд

"на безрыбье..." :)

pgres

если прочитаете 5 пункт то увидите что данные надо выбирать за месяц

я не слепой. а мат.операции делались на этой выборке или на всей базе?

pgres

с нетерпением жду результатов
ЗЫ: если результаты будут такими которые легко опротестовать то зачем эти результаты

как только Joker ответит
еще кстати не хило бы спросить: а выбранные данные куда-то складывались,
пересылались или как?
19 май 06, 14:41    [2684589]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
pgres
2 yww@escape.ru

ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)



Не понял вопрос.. возможно вы с кем то обсуждали эту тему.. но не со мной.
О какой гордости идет речь?
19 май 06, 14:50    [2684674]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

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

диск небольшой, а MSSQL много кушает.
~300 млн. записей, а ведь индексировать еще нужно. если мне сейчас скажут,
что это все ерунда и без индексов SQL выберет все, что нужно за минуту,
я не поверю.

и это послужило причиной перехода с mssql на cache ? в таком случае Вы просто фанатик
300 млн. - ну пусть это 300 Гб ну пусть еще 150 Гб на индексы
да сейчас люди домой для фильмов такие диски покупают(не плохо былоб если б Вы указывали иногда и физический размер, все таки диски со строками не работают)


автор
как только Joker ответит
еще кстати не хило бы спросить: а выбранные данные куда-то складывались,
пересылались или как?

я вас умоляю скоьлко там данных - за три года 1096 строк
автор
"на безрыбье..." :)

опять не в пользу каше

PS так почему Вы замалчиваете ответ про TPC :)

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

Откуда: Харьков
Сообщений: 140
yww@escape.ru
pgres
2 yww@escape.ru

ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать




Не понял вопрос.. возможно вы с кем то обсуждали эту тему.. но не со мной.
О какой гордости идет речь?


простите, действительно tpc не с вами

но по поводу вашего поста о целесообрзности тестов скажу что в оракле тоже не все так просто работает как вы думаете однако никто не заявляет что нет смысла в тестах так как cost based optimizer & materialized views

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

Откуда: Магадан
Сообщений: 584
yww@escape.ru

Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных.

да не только поэтому. во-первых, надо проверять на одном оборудовании,
во-вторых, при одинаковой нагрузке. ну будет у меня быстрее, а мне
скажут - фигня, это у тебя 40 пользователей не работали. а будет медленнее,
я скажу - извините, господа, у меня простенький комп на 1.8Ghz/1Gb с IDE.


>>2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
вот тоже самое.. не будет программист на Каше делить на 3600. Там есть встроенные функции преобразования количества секунд во время формата ЧЧ:ММ:СС .. они входят в сам язык, поэтому реализованы на C.

ну-ну, чего это он не будет? может стандартная функция возьмет значение
часа более 23? :)


>>3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
вот это сравнение может что нибудь и даст..

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


5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
опять не выйдет сравнение.. в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу.

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

С уважением. Сергей
19 май 06, 15:11    [2684832]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>конечно же не так. я, например, буду организовывать индекс по дате, так правильнее, вдруг выборка будет за неделю.

если вы уже на этапе постановки задачи знаете что вам портебуются выборки по датам, то и данные можно хранить в узлах, организованных на $h... а здесь уже всё равно - по месяцу, по неделе, по году - принцип то один и тот же.. становитесь на начало периода и двигаетесь до конца.. дополнительные индексы здесь могут и не понадобиться. ИМХО, конечно..
19 май 06, 15:27    [2684969]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

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

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

да мудро. эти данные и так аплодятся по порядку через append это же udr
так что за оракл не волнуйтесь он возьмет только нужные блоки
--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
19 май 06, 15:28    [2684977]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
Sergei Obrastsov

диск небольшой, а MSSQL много кушает.
~300 млн. записей, а ведь индексировать еще нужно. если мне сейчас скажут,
что это все ерунда и без индексов SQL выберет все, что нужно за минуту,
я не поверю.

и это послужило причиной перехода с mssql на cache ? в таком случае Вы просто фанатик
300 млн. - ну пусть это 300 Гб ну пусть еще 150 Гб на индексы
да сейчас люди домой для фильмов такие диски покупают(не плохо былоб если б Вы указывали иногда и физический размер, все таки диски со строками не работают)

записи-то? 156 байт в plain-файле. а вот насчет дисков проблема, 80Gb - все,
что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :)


я вас умоляю скоьлко там данных - за три года 1096 строк

5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)


я, видимо, совсем не умею читать?


PS так почему Вы замалчиваете ответ про TPC :)

а я-то здесь при чем? я что-ли разработчик и продавец Cache? есть сайт
InterSystems - у них и спрашивайте. насколько я слышал, Cache туда не
берут поскольку она не RDBMS. может и врут.
19 май 06, 15:33    [2685015]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Сергей, я же привел ссылки по подсчету размеров индексов, давайте сравним.
19 май 06, 16:30    [2685353]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
Сергей, я же привел ссылки по подсчету размеров индексов, давайте сравним.

я прочитал. а что с чем будем сравнивать-то?

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

Откуда:
Сообщений: 518
с вашей табличкой с индексами, где ~300млн.
19 май 06, 16:40    [2685402]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
с вашей табличкой с индексами, где ~300млн.

дык сравнивайте. все данные для этого есть здесь

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383

если я неправильно использовал индексирование в SQL и на самом
деле индекс по дате займет гораздо меньше места, то самое время
мне об этом сказать. а то как-то все промолчали.

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

Откуда:
Сообщений: 518
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным
19 май 06, 16:48    [2685442]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

не могу, вроде как формул не описано, тем более они жмутся по префиксам.
я привел конкретные данные, полученные до и после полной индексации по 9 полям.
не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью.

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

Откуда:
Сообщений: 518
Я и не сомневаюсь что не врете:
итого, что вышло, по той таблице что Вы приводили с 19-ю столбцами, при 18047848 записях и кластерным индексом по date
при расчетах таблица у меня была 18 столбцов, date и time я считал за один (8 байт)
данные занимают 237472 страницы по 8192 байта (1855.25 мб)
кластерный индекс: размер - 20 байт (исходя из того что 1 поле - 8 байт)
на странице умещается - 368 строк
считаем по уровням: level0 = 237472/368=646
level1=646/368=2
level2=1
итого: кол-во занимаемых страниц - 649 по 8192 байта.

ЗЫ: fill factor = 100%
ЗЫЫ: меня еще смутил несколько int(3), но для теоритических рассчетов это не актуально, на порядок не влияет :)
ЗЫЫ: для рассчета индекса некластерного нужно знать размерность кластерного (он будет больше)
19 май 06, 17:29    [2685680]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov
SiDen
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным

не могу, вроде как формул не описано, тем более они жмутся по префиксам.
я привел конкретные данные, полученные до и после полной индексации по 9 полям.
не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью.

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


1.15Gb это те самые 300млн строк ?
чувак это не объем у тебя ж памяти гиг
19 май 06, 17:38    [2685726]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Сергей, еще было бы не безинтересно посмотреть на размер без сжатия.
19 май 06, 17:48    [2685779]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov

дык сравнивайте. все данные для этого есть здесь

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383

если я неправильно использовал индексирование в SQL и на самом
деле индекс по дате займет гораздо меньше места, то самое время
мне об этом сказать. а то как-то все промолчали.


Про измерение индексов в MySQL на FAT32 улыбнуло
коментировать как то более развернуто не до сук

P.S. не серьезно это
19 май 06, 17:53    [2685814]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen

данные занимают 237472 страницы по 8192 байта (1855.25 мб)

очень близко к реальности

SiDen

кластерный индекс: размер - 20 байт (исходя из того что 1 поле - 8 байт)
на странице умещается - 368 строк
считаем по уровням: level0 = 237472/368=646
level1=646/368=2
level2=1
итого: кол-во занимаемых страниц - 649 по 8192 байта.

подумаем. 5Mb? интересно. перепроверил, все правильно.
очень впечатляет.


ЗЫЫ: для рассчета индекса некластерного нужно знать размерность кластерного (он будет больше)

насколько больше? мне ведь их еще 8 нужно.
и что это тогда был за индекс, который так хорошо убил базу в моем
примере?

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

Откуда: Магадан
Сообщений: 584
pgres
Sergei Obrastsov
SiDen
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным

не могу, вроде как формул не описано, тем более они жмутся по префиксам.
я привел конкретные данные, полученные до и после полной индексации по 9 полям.
не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью.
С уважением. Сергей

1.15Gb это те самые 300млн строк ?
чувак это не объем у тебя ж памяти гиг

а внимательнее читать по ссылке не получается? там ведь прямо сказано,
что тестируется база из 18 млн. записей
19 май 06, 18:09    [2685884]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
Сергей, еще было бы не безинтересно посмотреть на размер без сжатия.

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

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

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Про измерение индексов в MySQL на FAT32 улыбнуло
коментировать как то более развернуто не до сук
P.S. не серьезно это

верю. я потому и ждал каких-либо серьезных замечаний.
вроде как "а у меня в DB2" или там "а мой MSDE", или уж "а вот Oracle"...
делов-то на полчаса.
нет ничего. ну и какие ко мне претензии тогда?
вот человек откликнулся, спасибо ему. надеюсь, все-таки
доведем эту тему до логического завершения.
19 май 06, 18:16    [2685920]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Без ручного конечно.
Встроенное незачем трогать да и "никак" :)
19 май 06, 18:26    [2685950]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
Без ручного конечно.
Встроенное незачем трогать да и "никак" :)

можно и так прикинуть. если брать по-максимуму, то добавится 16 символов
на каждую запись. итого ~289 Mb, если еще грубее, с учетом увеличения
число блоков БД, то 300.

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

P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :)
19 май 06, 18:38    [2685987]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
На мой взгляд, Вы пока еще не начали понимать про MUMPS, pgres.
Именно в РСУБД "теория" вся в белых пятнах. Очередной пример - горячо обсуждаемые "индексы".
"Индексы" - это банальный пример денормализации для повышения производительности. В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные. Это в бОльшей степени данные, чем так называемые метаданные (словари данных). Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ? Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД. Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных.
И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД. Специалистов по MUMPS намного меньше, и распространены системы на MUMPS меньше, чем на РСУБД. Это факт. В любой области есть попса, и есть альтернативные направления для "высоколобых", "идиотов", "интеллектуалов", "маргиналов" (кому как больше нравится).
19 май 06, 21:08    [2686404]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Sergei Obrastsov

P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :)
А вот еще вопрос: чего Вы периодически всё про разделители упоминаете? Они как-то суются в данные? Просто странно как-то, я единственно когда про разделители думал - ну разве что при экспорте текстовых файлов
19 май 06, 23:57    [2686800]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
yww@escape.ru

Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных.

Ага, придумали новый отмазон. Да какая разница как они там данные организованы, мы же и не собираемся сравнивать способ организации данных, мы собираемся сравнивать производительность. Производительность тоже принципиально разная? Ее что нельзя измерить в секундах на запрос, а секунды что, разные для всех серверов?

yww@escape.ru

>>1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
"простейший инкримент" он и в Африке такой же.. КАШЕ написан на C, как и Оракл, поэтому время увеличения счётчика в оперативной памяти скорее всего будет одинаковым.
>>2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
вот тоже самое.. не будет программист на Каше делить на 3600. Там есть встроенные функции преобразования количества секунд во время формата ЧЧ:ММ:СС .. они входят в сам язык, поэтому реализованы на C.

Магическое слово "С". А конвертация строки, в которой хранится число и дата в КЕШ-е, в число ничего не занимает? Говорили уже - занимает, даже если это все реализовано на на страшном и ужасном С.

yww@escape.ru

5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
опять не выйдет сравнение.. в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу.

А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве.

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





Sergei Obrastsov

Sergei Obrastsov

ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как
видим, они оказались дальновидны. а ведь все очень просто, с большими
объемами данных первыми столкнулись именно они.

Как же, знаем, они также первыми высадились на берега Америки, еще до викингов. А ссылочку не приведете на большие объемы данных?

а сами объемы не нужно привести?

Приведите.

Sergei Obrastsov

(если честно, я притомился искать в инете конкретные цифры)

В таком случае воздержитесь от утверждений типа что КЕШ первый работал с такими объемами.

Sergei Obrastsov

а разве я говорил про полное чтение файла? речь, скажем, о чтении индексного дерева, которое явно читается не по секторам.

А как же оно читается? По другому железо читать не умеет.

Sergei Obrastsov

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383
еще раз скажу, что сравнивалась SQL (MySQL, MSSQL) таблица с одним индексом и Cache-структура с 9-ю.

Хорошо, смотрю.

Sergei Obrastsov

я только ЗА. ссылки приведены.

Это теперь, после напоминания они приведены.

Sergei Obrastsov


Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся.

я бы рад избавиться, но пока приходится дефрагментировать. не часто и все же. про ext2 ничего не скажу, мне приходится работать под Windows

Неправда, Вы уже сказали: "дефрагментация всегда давала выигрыш в скорости, дает и сейчас, даже при наличии "супер-файловых" систем."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=293038&pg=4#2676944
По-моему лучше остерегаться подобных обобщений до появления соответствующего опыта с супер файловыми системами, хотя бы с NTFS.

Sergei Obrastsov

а вот насчет дисков проблема, 80Gb - все,
что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :)

Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb.

Нужно ведь быть немного резонным. Никто же не спорит, что можно найти задачу, где преимущества КЕШ-а будут очевидными. Например поставить условия, что данные внутри сервера должны храниться в виде строк. Зачем - неизвестно, нужно и все. Но ведь это несерьезно, мы же обсуждаем СУБД общего назначения, которые работают на человеческом железе.

Sergei Obrastsov

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

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

Пусть запись в некоторой таблице занимает N байт, а база L байт.
Добавили одну запись, получили (примерно) L+N байт,
добавили две записи - получили L+2*N байт,
сто записей - L+100*N байт
и т.д.
Это арифметическая прогрессия. Индекс растет еще медленнее. И где тут можно увидеть геометрическую прогрессию? Ткните пальцем, а то моей фантазии не хватает.

Хотя нет, понял. Недооценил оказывается свою фантазию. Вспомнил, что говорю с КЕШ-истом, так вот по КЕШ-овым революционным правилам действительно получается нечто очень похожее на геометрическую прогрессию:
L+N
(L+2)*N
...
(L+100)*N
...

И все бы хорошо, но вот только к реальному росту БД эта прогрессия никакого отношения не имеет.
20 май 06, 00:34    [2686866]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Чернышев Андрей Леонидович

"Индексы" - это банальный пример денормализации для повышения производительности.

Особенно к денормализации индексы имеют отношение. Еще бы в нормализованной схеме индексов не может быть никогда? Если канечно это реальный ЧАЛ, а не разводка на флейм.

Чернышев Андрей Леонидович

В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные.

Не иначе - выдержавшие проверку временем. От того и такие настоящие.

Чернышев Андрей Леонидович

Это в бОльшей степени данные, чем так называемые метаданные (словари данных).

Совсем похоже на разводку.

Чернышев Андрей Леонидович

Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ?

Ко всему что хранится в отношениях можно писать запросы на SQL (это ни какой-нибудь там МУМПС). А к якобы данным ("индексам") писать запросы ломает. Они лучше для другого подходят.

Чернышев Андрей Леонидович

Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД.

Забыли ЧАЛа спросить. Вот от того все и происходит.

Чернышев Андрей Леонидович

Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных.

Смотря кому. Некоторые, может, наконец через несколько лет пребывания на форуме и узнают разницу между "логическим уровнем" и физическим.

Чернышев Андрей Леонидович

И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД.

Чтобы писать циклы вместо нормального запроса "подвижность специалиста", наверное, понадобится какая-то особенная. Да и "теория" для обоснования такого подхода тоже нужно придумать особенную. Не иначе.
20 май 06, 00:42    [2686873]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
Sergei Obrastsov

P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :)
А вот еще вопрос: чего Вы периодически всё про разделители упоминаете? Они как-то суются в данные? Просто странно как-то, я единственно когда про разделители думал - ну разве что при экспорте текстовых файлов

правильно думали, поскольку здесь сходная ситуация. в M нет фиксированного
задания полей для структур, поскольку и сами структуры тоже не заданы.
поэтому есть только один тип данного - строка. и есть возможность
указать в строке символы-разделители, чтобы получить "виртуальные" поля
данных.
строка данных:
а,b*,c:,d*,e
5 полей через разделитель ","
3 поля - через "*"
2 поля через ":"
если их нет, то их надо создать:
set ^dft(v5,"idx",idx)=tr_"*"_cat_"*"_pha_"*"_phb_"*"...
в результате данные выглядят так:
1*10*51123*76543*...*700*100*650*1
2*10*612341231123*4111323176543*...*700*101**
1*10*643423*676543*...****
берутся они функцией, которая для этого и сделана:
set f1=$piece(data,"*",1)
...
set f5=$piece(data,"*",5)
и пишутся ей же, то есть нет смысла пересобирать строку данных:
1*10*51123*76543*...*700*100*650*1

set $piece(data,"*",2)=13

1*13*51123*76543*...*700*100*650*1

это, конечно, не единственный вариант хранения данных в M. я часто встречаю
такой:
^table(idx,1)=field1
^table(idx,2)=field2
...
^table(idx,N)=fieldN
тоже, конечно, вариант. imho, не оптимальный.

про "проблему концевых разделителей" можно посмотреть здесь:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=17#2655401

С уважением. Сергей
20 май 06, 01:54    [2686926]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Sergei Obrastsov

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383
еще раз скажу, что сравнивалась SQL (MySQL, MSSQL) таблица с одним индексом и Cache-структура с 9-ю.

Посмотрел. Пока увидел, что сравнивался на самом деле не MySQL-MSSQL, а только MySQL. Каким образом сделан вывод, что "впрочем, MS SQL 15 млн. записей с индексацией по дате в 3.5 Gb тоже не запишет. :))" пока непонятно. МССКЛ мелькал только как рабочая база, сравнивать ее с тестовой не совсем корректно, тем более что имели место многочисленные неточности. Никто не может поручиться, что о рабочей базе не забыли упомянуть какую-нибудь деталь. К тому же неизвестно что случится, например, с размером файла данных КЕШ-а, если он поработает несколько месяцев, как МССКЛ. Крчать что ничего не случиться не нужно, нужно поставить базы в одинаковые условия и проверить.


https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383
Sergei Obrastsov

эти вещи просьба мне в вину не ставить, SQL пакует числа, так
что нечего тут,

СКЛ числа не пакует.

Идем дальше.

На данных без индексов выигрыш КЕШ-а по объему аж 30% (1.970 гиг в МуСКЛ - 1.155 гиг в КЕШ-е). Обсуждать смешно.
С индексами - не понимаю кешового синтаксиса, хорошо бы пояснить. Также хорошо бы привести скрипт для создания индекса в МУСКЛ-е и параметры сервера, например сколько fillfactor, или как он там называется в МуСКЛ-е. Пока вижу что разница аж на те же 30-40%, игнорируя количество индексов. Тоже нечего обсуждать, это не разница. Что же касается разных индексов, то зачем об этом постоянно говорить, проще уберать лишние из кеша, либо добавить необходимые в МуСКЛ, тогда можно сравнить.

Так что пока ничего существенного. Можете поставить в заслугу КЕШ-у выигрыш в 50% по размеру файлов. По-видимому это выдающееся достижение, но из-за экономии места в пол-файла я, например, на КЕШ не перейду.




Еще приведите время создания индекса кешем и МуСКЛ-ем. Хоть это и не типичная операция, но интересно.

Что касается необходимости индекса, то в РСУБД действительно не всегда нужно индексировать все подряд. Например если в запросе участвует индексированное поле, которое выдаст небольшое количество записей (порядка 20 в случае обычного индекса), скажем фамилия, то остальные поля можно не индексировать, все равно прямой перебор по этому множеству будет быстрее. Кроме того существуют составные индексы, в некоторых случаях по подмножествам полей индекс заводить уже не обязательно. Так что то что в КЕШ-е делается девятью индексами, в РСУБД может быть сделано меньшим (или большим) числом индеков. Есил выложите типичные запросы, то можно пообсуждать необходимые индексы.
20 май 06, 02:05    [2686934]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
yww@escape.ru

Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных.

Ага, придумали новый отмазон. Да какая разница как они там данные организованы, мы же и не собираемся сравнивать способ организации данных, мы собираемся сравнивать производительность. Производительность тоже принципиально разная? Ее что нельзя измерить в секундах на запрос, а секунды что, разные для всех серверов?

это он поторопился.


А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве.

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

вот ведь забавно. сколько раз уже объясняли, что при необходимости ввести
новый индекс он просто создается и все. и в SQL его надо создавать, и в M
его надо создавать. в SQL это менее затратно? согласен. за удобство
работы с данными нужно платить.


Sergei Obrastsov

а вот насчет дисков проблема, 80Gb - все,
что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :)

Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb.

ну, не все живут красиво. а еще меня можно попрекнуть зарплатой.
это тоже хороший критерий, сразу видно, кто чего стоит.


Нужно ведь быть немного резонным. Никто же не спорит, что можно найти задачу, где преимущества КЕШ-а будут очевидными. Например поставить условия, что данные внутри сервера должны храниться в виде строк. Зачем - неизвестно, нужно и все. Но ведь это несерьезно, мы же обсуждаем СУБД общего назначения, которые работают на человеческом железе.

а ведь мне лучше было бы работать на связке Clarion+SQL, чем на
Clarion+Cache, меньше возни с интерфейсом.
так что я не пытался засунуть "вшивый КЕШ" в очередную дырку, вопреки
всем правилам и традициям.


Sergei Obrastsov

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

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

кол-во зарегистрированных сотовых телефонов в городе по годам:
2003  2004  2005-2006
0      1000   150000
как там будет выглядеть рост кол-ва звонков по ним?


Хотя нет, понял. Недооценил оказывается свою фантазию. Вспомнил, что говорю с КЕШ-истом, так вот по КЕШ-овым революционным правилам действительно получается нечто очень похожее на геометрическую прогрессию:
И все бы хорошо, но вот только к реальному росту БД эта прогрессия никакого отношения не имеет.

я понимаю, что хочется "погнуть пальцы и постучать копытами". но может
лучше это делать не здесь?
20 май 06, 02:45    [2686945]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127

Посмотрел. Пока увидел, что сравнивался на самом деле не MySQL-MSSQL, а только MySQL. Каким образом сделан вывод, что "впрочем, MS SQL 15 млн. записей с индексацией по дате в 3.5 Gb тоже не запишет. :))" пока непонятно.

первая попытка была с MSSQL. данные за 2 месяца заняли именно такой объем.
это меня и напугало.


МССКЛ мелькал только как рабочая база, сравнивать ее с тестовой не совсем корректно, тем более что имели место многочисленные неточности. Никто не может поручиться, что о рабочей базе не забыли упомянуть какую-нибудь деталь.

а я и не спорю. если есть во что ткнуть меня носом - я буду только рад.
как я уже сказал в предыдущем письме, связка Clarion+SQL для меня
предпочтительнее связки Clarion+Cache.


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

работает, посматриваю. пока все нормально.


Sergei Obrastsov

эти вещи просьба мне в вину не ставить, SQL пакует числа, так
что нечего тут,

СКЛ числа не пакует.

пакует. в 2 байта, в 4 байта... для меня это упаковка.


На данных без индексов выигрыш КЕШ-а по объему аж 30% (1.970 гиг в МуСКЛ - 1.155 гиг в КЕШ-е). Обсуждать смешно.

это не совсем так. я надеялся, что кто-нибудь захочет вникнуть и заметит
подвох. :) в M структура не существует без индексов, поэтому 1.155Gb
это уже с индексом по v5. но вот вчера мне показали, что "кластерный
индекс" занимает очень мало места и этот выигрыш просто пропадает.
ну, что тут скажешь, сегодня посмотрю.


С индексами - не понимаю кешового синтаксиса, хорошо бы пояснить. Также хорошо бы привести скрипт для создания индекса в МУСКЛ-е и параметры сервера, например сколько fillfactor, или как он там называется в МуСКЛ-е. Пока вижу что разница аж на те же 30-40%, игнорируя количество индексов. Тоже нечего обсуждать, это не разница. Что же касается разных индексов, то зачем об этом постоянно говорить, проще уберать лишние из кеша, либо добавить необходимые в МуСКЛ, тогда можно сравнить.

индексы и есть индексы. насчет fillfactor посмотрю. 30-40% это действительно
не разница. я бы убрал лишние, если бы они не были нужны. как было сказано
ранее, время обработки данных критично. а добавить необходимые в MySQL
не могу, размер скачет. сегодня попробую кластерный по дате-время, может
это облегчит жизнь.


Так что пока ничего существенного. Можете поставить в заслугу КЕШ-у выигрыш в 50% по размеру файлов. По-видимому это выдающееся достижение, но из-за экономии места в пол-файла я, например, на КЕШ не перейду.

а никто никого и не зовет. 50% на 100Gb - существенная разница.


Еще приведите время создания индекса кешем и МуСКЛ-ем. Хоть это и не типичная операция, но интересно.

MySQL быстрее, что, впрочем, не удивительно. там ведь был только один индекс, а не 9 как в Cache. и импорт быстрее на порядок, Cache плохо
работает с последовательными файлами.


Что касается необходимости индекса, то в РСУБД действительно не всегда нужно индексировать все подряд. Например если в запросе участвует индексированное поле, которое выдаст небольшое количество записей (порядка 20 в случае обычного индекса), скажем фамилия, то остальные поля можно не индексировать, все равно прямой перебор по этому множеству будет быстрее. Кроме того существуют составные индексы, в некоторых случаях по подмножествам полей индекс заводить уже не обязательно. Так что то что в КЕШ-е делается девятью индексами, в РСУБД может быть сделано меньшим (или большим) числом индеков. Есил выложите типичные запросы, то можно пообсуждать необходимые индексы.

буду только рад. итак для таблицы:
v1 - tinyint
v2 - int(3)
v3 - varchar(16)
v4 - varchar(16)
v5 - data
v6 - time
v7 - int(6)
v8 - int(8)
v9 - int(2)
v10 - int(2)
v11 - tinyint
v12 - tinyint
v13 - int(4)
v14 - int(4)
v15 - tinyint
v16 - int(4)
v17 - int(4)
v18 - int(4)
v19 - int(4)

необходимы выборки по полям:
v1 - заданное значение
v2 - заданное значение
v3 - префиксный выбор из заданного списка
v4 - префиксный выбор из заданного списка
v5 - диапазон
v6 - диапазон
v7 - диапазон, значение
v8 - диапазон, значение
v9-v12 - значение
v13 - заданный список
v14 - заданный список
v16-v17 - заданный список
v18-v19 - заданный список
как я уже упоминал, время обработки данных - серьезный критерий.
минимальный объем данных ~80 млн. записей, максимальный - ~300.

"префиксный выбор..." это когда задан список в виде:

413
22522
4412
8787890201

и нужно найти записи, где данное в этом поле начинается с указанного
в списке значения (sorry, если говорю банальные вещи)
списки не фиксированы размером.

размер запросов не лимитирован, т.е. могут быть заданы все условия одновременно.
20 май 06, 03:24    [2686954]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

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

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

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


Я понимаю когда человек глазам верит (хотя иногда бывает обман зрения), Но чтоб он рукам верил это уже что-то интересное. Ну да ладно это ваши личные проблемы. Вот вам задача конкретная давайте на ней тестировать

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)
Вот вам реальный пример. В начале месяца нагрузка увеличивается раза в 2 так как необходимо выдать немеренное кол- отчетности в том числе и аналитической. И все работает никто особо не жалуется. Одновременно выпоолняются сложные отчеты, заливаются новые данные (в день более 1 млн. записе), расчитывается стоимость разговора и т д. В 2001 году перешли на Оракл потому что система на М просто не справлялась. Жду от вас результатов тестирования на подобном обеме. Тесты на таблице из 100 записей не состоятельны для серьезных систем. Видимо поэтому ни одна из М систем не представлена независимых тестах TCP.[/quot]


Пожалуйста, если есть возможность провести тест - искуственно увеличь рамеры файлов базы данных (раза в два) и через неделю, попробуй провести анналогичный тест. Посмотри изменится ли производительность ? А после теста уменьш файлы азы до минимально возможного значения и повтори тест.
Сообщи нам результаты!
20 май 06, 09:52    [2687019]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
c127
А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель)


Что ж вы так горячитесь? Не помещайте данные по месяцам в узлы - поместите их в узлы по дате.. все вопросы с неделями снимутся... как и, впрочем, с часами и минутами.. $h - хранит и дату и время одновременно.

Что касается других выборок - постройте для них подходящие индексы.

И не думайте, пожалуйста, что лично вас кто то пытается обмануть
20 май 06, 13:40    [2687245]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
автор
Ага, придумали новый отмазон. Да какая разница как они там данные организованы, мы же и не собираемся сравнивать способ организации данных, мы собираемся сравнивать производительность.


Если очень хочется сравнить самостоятельно - сравнивайте...

А можете и просто посмотреть :
"Начисление всем абонентам повременка 1 286 093 109 (записей) 12 часов 25 мин
Справка по доходам 1 час 13 мин
Сортировка всех абонентов по адресам для печати квитанций 2 часа 50 мин 43 сек"

Вот здесь это находится http://www.asr.orel.ru/news/tenmillion.htm
20 май 06, 14:46    [2687306]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
yww@escape.ru

А можете и просто посмотреть :
"Начисление всем абонентам повременка 1 286 093 109 (записей) 12 часов 25 мин
Справка по доходам 1 час 13 мин
Сортировка всех абонентов по адресам для печати квитанций 2 часа 50 мин 43 сек"

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

С уважением. Сергей
20 май 06, 15:36    [2687360]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Но ведь там ещё "3000 процессов с выполнением фонового задания формирования отчетных данных." .. хотя, может и не очень быстро.. судить не берусь.. для других систем тесты такого объёма ведь не проводились.. на 10 миллионов абонентов - в России это единственная сертифицированная система
20 май 06, 16:02    [2687389]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Dimonana
Guest
Отцы, да НАПЛЕВАТЬ сколько база занимает

https://www-132.ibm.com/webapp/wcs/stores/servlet/ConfiguratorDisplay?storeId=1&catalogId=-840&langId=-1&site_type=public&oiId=null¤cy=USD&base=17002RD&x=8&y=13

Следующий конфиг:

IBM Total Storage DS400 - Dual Controller

1. 146GB X 14 штук
(Gen 3) Hot-Swap 3.5" 15K RPM Ultra 320 SCSI HDD ( $649.00 )

2. IBM SMB 2-Gbps Fibre Channel HBA ( $549.00 ) X 4 штуки

3. IBM TotalStorage Storage Switch Model L10 (Loop Switch) ( $1,845.00 ) X 1 штука - на всякий случай :)

4. 1GB PC2700 ECC DDR SDRAM DRAM ( $619.00 ) X 2 штуки

5. Кабель IBM 5m LC-LC Fibre Channel Cable ( $129.00 ) X 4 штуки

6. 3000XHV Uninterruptible Power Supplies ( $1,439.20 ) X 1 штука

Итого:

Объем 2 ТБ (можно в максимуме расширить до 12 ТБ)

Цена $28,310.20

Производительность 2% присутствующих могут представить

Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО
21 май 06, 00:51    [2688220]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
на 10 миллионов абонентов - в России это единственная сертифицированная система

Гыыыы...
"на 10 миллионов абонентов" - это что значит?
Сколько абонентов прямо или косвенно пользуется этой системой в действительности? 10000000 телефонных абонентов в Орле? Та хде вы их там нашли, в Орле людей в двадцать раз меньше, при этом половина в своей жизни телефона не видала.

Или речь идет о максимальном (предельном) размере справочника абонентов? Типа с (максимум) десятимиллионным справочником каша способна работать, и её на это сертифицировали, а с пятнадцатимиллионным справочником - уже ой, не сертифицировали?

Или под фразой "предназначена для обслуживания сети емкостью 10000000 абонентов" понимается тот и только тот факт, что всего лишь в системе номера являются семизначными?

Писец рекламные клоуны нах.
21 май 06, 00:54    [2688226]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает

Гыыы... Очередной тупой му**к.
Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов.
В случае фуллскана, разумеется. В случае не фуллскана - надо более другие вещи смотреть, но завязанные опять таки на объем этих самых более других вещей.

Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО

Вывод - иногда лучше жевать, чем говорить. Если после "жевать" возникло желание "говорить" - предварительно почитать учебники.
21 май 06, 00:59    [2688230]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

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

Отцы, да НАПЛЕВАТЬ сколько база занимает

Не скажите. Например, если одна и та же табла с одной и той же инфой занимает разный объем на диске, то на той которая меньше меньше болков считывать надо. А это имеет значение для скорости выполнения запросов в общем случае.
21 май 06, 01:02    [2688239]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Dimonana
Guest
Пьяный Лох
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает

Гыыы... Очередной тупой му**к.
Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов.
В случае фуллскана, разумеется. В случае не фуллскана - надо более другие вещи смотреть, но завязанные опять таки на объем этих самых более других вещей.

Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО

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


Нда, ну от ника странно ожидать чего-то другого.

Специально для пьяных и тупых лохов попытаюсь разжевать:

Разница даже в 2 раза несущественно при нынешнмх производительных и дешевых системах.
21 май 06, 01:10    [2688248]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Dimonana
Специально для пьяных и тупых лохов попытаюсь разжевать:

Разница даже в 2 раза несущественно при нынешнмх производительных и дешевых системах.

[удалено модератором]
21 май 06, 01:15    [2688250]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@mail.ru
Guest
Пьяный Лох
yww@escape.ru
на 10 миллионов абонентов - в России это единственная сертифицированная система

Гыыыы...
Писец рекламные клоуны нах.


Никакой рекламы.. Боже упаси меня от такого занятия.
Уточните, пожалуйста, про клоунов. К кому возглас то направлен?

По ссылке было показано то, что "АСР ОРЕЛ-М получила Сертификат соответствия № ОС/1-СТ-76 как универсальная тиражируемая автоматизированная система расчётов высшего уровня" и "В ноябре 2002г прошли испытания системы в рамках инспекционного контроля на базе, смоделированной на платформе Cache'и предназначенной для обслуживания сети емкостью 10 000 000 и более абонентов".

Эта ссылка предложена в качестве альтернативы самостоятельным проверкам производительности Каше.

В Орле действительно нет 10 миллионов абонентов.. их нет ни в одном городе России.. только речь то идёт о других цифрах. Был вопрос - справится ли Каше с 50 миллионами записей? Вот в Орле есть ответ (для 1 286 093 109). Если есть желание, проверьте это лично.
21 май 06, 10:51    [2688409]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 yww@mail.ru
Никакой рекламы.. Боже упаси меня от такого занятия.
Уточните, пожалуйста, про клоунов. К кому возглас то направлен?

Большей частью оно было в сторону авторов штатьи, на которую Вы ссылку привели. Может они и не совсем рекламные, но смеяццо можно над многими кусками штатьи.
К Вам по прежнему вопрос - что значит "сертифицирована на 10 миллионов абонентов"? На 500 тысяч - не сертифицирована? Или на 15 миллионов?
Что вообще означает термин "сертификация на определенное количество абонентов"?

По ссылке было ... предназначенной для обслуживания сети емкостью 10 000 000 и более абонентов"

Т.е. на 10000000 - предназначена, на более - предназначена. А на менее, чем 10 миллионов? Если да, то это фраза из серии "до 16 и старше". Что-то сказали, цифру красивую засветили, информации ноль.

Эта ссылка предложена в качестве альтернативы самостоятельным проверкам производительности Каше.

Нет уж, лучше самостоятельно, чем по такой штатье.
21 май 06, 17:48    [2688868]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
Что вообще означает термин "сертификация на определенное количество абонентов"?

Я, пожалуй, соглашусь, что рекламная составляющая в той статье есть.

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

Организация, выдавшая сертификат, должна иметь некоторый "законный авторитет" в той области, для которой проводит испытания.. Для связистов это Ленинградский институт связи. То есть, если сертификация проведена, значит есть подтверждение качеств продукта.

Смысл 10 миллионов абонентов можно (при желании) увидеть в таком примере:
- для 10 миллионов абонентов можно вычислить ожидаемое количество разговоров в сутки (у связистов есть методики)
- биллинговая система должна успевать провести расчет стоимости (или хотя бы выгрузку данных со станции) суточного массива за время менее 24 часов. Если она не успевает это сделать, то значит не пригодна для обслуживания биллинга 10 миллионов абонентов.

Пример, конечно, искуственный, но вполне возможно что похожее требование может присутсвовать в программе сертификации.

Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет.
21 май 06, 18:44    [2688914]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
guest_20040621
Guest
> DS400

2 Тб (и 12 Тб) можно найти по гораздо более привлекательной цене при сопоставимой производительности, надежности и масштабируемости.

Dimonana, Вы напрасно в этом треде упомянули СХД. ;) Здесь кодеры (язык не поворачивается назвать их разработчиками) заняты любимым делом: сравнением длины пиписек. О популярности этого занятия Вы можете судить по длине обсуждения. ;)) О глубине - по фразе "Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов". ;))
21 май 06, 18:50    [2688919]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 yww@escape.ru
Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет.

Так вот, откуда Вы взяли факт сертификации на 10 млн.?
В штатье по ссылке есть следующие факты:
- система как-то кем-то сертифицирована "для обслуживания сети электросвязи ёмкостью до 500 000 номеров"
- система еще как-то кем-то сертифицирована, но без указания кол-ва абонентов
- система тестировалась для "обслуживания сети емкостью 10 000 000 и более абонентов". Как я уже указывал, сказать "10000000 и более" - это значит не сказать ничего, тока циферки красивые засветить.

Я уж не говорю о том, что тестирование само по себе не много значит, если оно стоит в одном абзаце с государственной сертификацией.
Ну тестировали чего-то там в Орле, ну получили какой-то результат. Например тот результат, что список абонентов сортировался по адресам в течение почти трех (!) часов. Это, пардон, пузырьковой сортировкой надо было сортировать.. на 286-ом компе..
21 май 06, 19:40    [2688992]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
2 yww@escape.ru
Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет.

Так вот, откуда Вы взяли факт сертификации на 10 млн.?
В штатье по ссылке есть следующие факты:
- система как-то кем-то сертифицирована "для обслуживания сети электросвязи ёмкостью до 500 000 номеров"
- система еще как-то кем-то сертифицирована, но без указания кол-ва абонентов
- система тестировалась для "обслуживания сети емкостью 10 000 000 и более абонентов". Как я уже указывал, сказать "10000000 и более" - это значит не сказать ничего, тока циферки красивые засветить.

Я уж не говорю о том, что тестирование само по себе не много значит, если оно стоит в одном абзаце с государственной сертификацией.
Ну тестировали чего-то там в Орле, ну получили какой-то результат. Например тот результат, что список абонентов сортировался по адресам в течение почти трех (!) часов. Это, пардон, пузырьковой сортировкой надо было сортировать.. на 286-ом компе..


Да нет.. зачем придумывать? Статья устарела уже, но всё там правда. Я разговаривал с одним из разработчиком этой системы. Сертифицировал её ЛНИИС (Ленинградский НИИ связи). И не сортировку сертифицировали а весь комплекс. У меня нет причин не доверять тем людям.
21 май 06, 20:18    [2689052]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31636
Ну сертифицирующая контора вааще-то называецца ЛОНИИС
21 май 06, 20:31    [2689078]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Что какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс). Там больше параметров используется. Один из них - длина квитанции. Печать то производится не на рулонную бумагу, а на (жаргонно) листинг. Поэтому нужно знать как сформатировать квитанции, что бы доставщики смогли их быстро и просто разделить. Вот вычисление длины квитанции и занимает много времени. Там не только счета к оплате, но и извещения и реклама, и еще какие либо тексты присутсвуют. Причем для каждого клиента свой набор.
21 май 06, 20:35    [2689086]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Изопропил
Ну сертифицирующая контора вааще-то называецца ЛОНИИС


Ну пусть и так.. что с того? Чем хуже ЛНИИСА?
21 май 06, 20:37    [2689093]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 yww@escape.ru
Да нет.. зачем придумывать?

Хммм... То ли я не по-русски говорю, то ли Вы не по-русски понимаете.
Еще раз. Откуда взялось утверждение о сертификации на 10 млн, если в статье приведены только факты о сертификации на "до 500 тысяч абонентов"? Я вот Вас и спрашиваю - зачем придумывать?

Статья устарела уже, но всё там правда.

Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД.
Точно-точно. Все правда.
Только вот почему-то абонентов по адресу сортировали три часа. Наверное забыли включить опцию "беспрецедентной производительности".

Я разговаривал с одним из разработчиком этой системы. Сертифицировал её ЛНИИС (Ленинградский НИИ связи).

Да по мне хоть бы её Карабас Барабас сертифицировал. Вы на знакомых не кивайте, лучше ответьте на вопрос - откуда взялась сертификация на 10 млн.? Это Вы сами выдумали, или Ваш знакомый разработчик?

У меня нет причин не доверять тем людям.

А у меня нет причин им доверять.
Пока что общедоступные факты - это сертификация на обслуживание сетей емкостью до 500000 номеров. Зачем Вы это число в двадцать раз увеличили - непонятно.
21 май 06, 20:39    [2689097]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
Что какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс).

В статье вижу слова:
"... Сортировка всех абонентов по адресам для печати квитанций... "
Вы пытаетесь утверждать, что это не сортировка по адресам.
ЛОЛ.
21 май 06, 20:41    [2689102]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
yww@escape.ru
Что какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс).

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


Именно это я и утверждаю.

>>>Да по мне хоть бы её Карабас Барабас сертифицировал.

А зачем тогда вообще разговор вести? Предвзятость - ана и в Африке предвзятость.
21 май 06, 20:46    [2689109]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
>>>Да по мне хоть бы её Карабас Барабас сертифицировал.

А зачем тогда вообще разговор вести? Предвзятость - ана и в Африке предвзятость.

А зачем тогда ссылку на штатью было приводить?
Так бы и заявили сразу, мол одна бабка сказала, что на 10 миллионов (и более), но слова бабки ничем подтвердить не можете.
21 май 06, 20:48    [2689113]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД.

???
А это то здесь причем?
21 май 06, 20:49    [2689118]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД.

???
А это то здесь причем?

А это из штатьи, однако. В которой все правда.
21 май 06, 20:50    [2689124]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
yww@escape.ru
>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД.

???
А это то здесь причем?

А это из штатьи, однако. В которой все правда.


аа.. да.. есть там такое.. перебор с рекламоу..
Но всё равно не пойму я вас что то..

Что Вы хотите сказать? Можете в паре абзацев изложить?
21 май 06, 20:54    [2689138]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Но всё равно не пойму я вас что то..

Фсе, это финиш...
Товарисч, сколько раз Вам нужно повторить вопрос, прежде чем Вы его поймете?

Вопрос:
Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов?

Если в вопросе Вам какое-то слово не понятно - откройте словарь живого великорусского языка Владимира Даля. Если все равно не понятно - это будет Вашим домашним заданием.
21 май 06, 20:59    [2689152]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31636
Сертификация - дело серьёзное.
Нет в природе такой сертифицирующей конторы -ЛНИИС.

Следовательно можно писать всё что угодно.
21 май 06, 21:00    [2689156]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
Но всё равно не пойму я вас что то..

Фсе, это финиш...
Товарисч, сколько раз Вам нужно повторить вопрос, прежде чем Вы его поймете?

Вопрос:
Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов?

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


Товарисч, спуститесь с небес. Мания величия - симптом.

>>Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов?

Информация взята со слов разработчиков. Документальным подтверждением не располагаю.
21 май 06, 21:01    [2689157]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Изопропил
Сертификация - дело серьёзное.
Нет в природе такой сертифицирующей конторы -ЛНИИС.

Следовательно можно писать всё что угодно.


ЛОНИИС конечно.. я неправильно назвал его раньше.
ЛОНИИС - Ленинградский Отраслевой Научно-исследовательский институт связи
21 май 06, 21:03    [2689159]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
Информация взята со слов разработчиков. Документальным подтверждением не располагаю.

И почему я не удивлен?
Наверное потому, что уже не первый раз на этом форуме фанаты какой-то СУБД толкают какие-то слухи, документально ничем не подтверждаемые.

То Interbase в танках Абрамсь используют, то вся NASA переходит на MySQL, то пенсионный фонд во всех регионах РФ на мумпсе работает, то кашовые системы сертифицируются на шесть с половиной миллиардов абонентов...
21 май 06, 21:06    [2689165]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
yww@escape.ru
Информация взята со слов разработчиков. Документальным подтверждением не располагаю.

И почему я не удивлен?
Наверное потому, что уже не первый раз на этом форуме фанаты какой-то СУБД толкают какие-то слухи, документально ничем не подтверждаемые.

То Interbase в танках Абрамсь используют, то вся NASA переходит на MySQL, то пенсионный фонд во всех регионах РФ на мумпсе работает, то кашовые системы сертифицируются на шесть с половиной миллиардов абонентов...


Какие слухи то?
Вот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан..
Проверяйте на здоровье.
21 май 06, 21:19    [2689189]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
yww@escape.ru
Вот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан..
Проверяйте на здоровье.


Скажу по секрету - туда постить может все кому не лень - можно даже запостить что Орловская ГТС отказалась от использования Каше.



Пришли новость не от Инфосис
22 май 06, 08:05    [2689596]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
http://rusmetall.orel.ru
22 май 06, 09:23    [2689706]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Lepsik
yww@escape.ru
Вот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан..
Проверяйте на здоровье.


Скажу по секрету - туда постить может все кому не лень - можно даже запостить что Орловская ГТС отказалась от использования Каше.



А кроме Вас, это кому нибудь надо?
Вот ещё ссылки. Пофантазируйте про них.

http://www.connect.ru/article.asp?id=6341

http://www.pcweek.ru/?ID=294287&4Print=1
http://www.it-daily.ru/?ID=174340&Year=2003&Month=6&Day=17

А вот база сертификатов
http://svcons.ru/cgi-bin/sert2006/sert_cnt.cgi?acs=&nomcat=0&date=All&poisk=%CE%D0%C5%CB-%CC
22 май 06, 10:09    [2689874]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает
Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО


А это :
"Серверный комплекс, на котором тестировалась АСР CBOSS, включал в себя 72 процессора – в испытаниях системы Орловского филиала ОАО «ЦентрТелеком» их было 2."
смешно? (Отсюда взято : http://www.connect.ru/article.asp?id=6341 )
22 май 06, 11:36    [2690417]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Если действительно все правда об испытаниях на 50 млн, то разработчики просто молодцы. Снимаю шляпу.

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

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

Точно так же то что на каше создан супер удачный биллинг не дает возможности утверждать что каше 20 раз быстрее чем любой рдбмс.

да и выигрыш по размеру базы в 2 раза это не слишком много. если б хотыя бы в 5. а так ну купишь себе в 2 раза больше винтов, слава богу с этим нет проблемы

так что давайте кашисты не изворачивайтесь а делайте придложенный тест

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
22 май 06, 12:24    [2690726]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>>Однако, тесты системы и тесты движка базы данных не одно и то же.

Трудно не согласиться

>>>так что давайте кашисты не изворачивайтесь а делайте придложенный тест

Смысл в таких действиях может быть только в случае, когда тестеру нужно принять решение о выборе СУБД.. вот пусть автор топика и тестирует. Остальным - вряд ли это нужно.
22 май 06, 12:50    [2690894]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Dimonana
Guest
yww@escape.ru
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает
Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО


А это :
"Серверный комплекс, на котором тестировалась АСР CBOSS, включал в себя 72 процессора – в испытаниях системы Орловского филиала ОАО «ЦентрТелеком» их было 2."
смешно? (Отсюда взято : http://www.connect.ru/article.asp?id=6341 )


Если это правда, то я только радуюсь. По крайней мере есть ориентиры на скорость топовых решений.

А относительно оборудования - ну реально было 12, но их логи фиксировали что только на 2х была работа. Ок. Если так строится беседа, то СБОСС может написать - да у нас из 72 процов ваще только один чуть чуть юзался.

Не серьезно. Взяли бы двухпроцессорный Зеон и задали бы жару. А так...

А за

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


надо назначать изнасилование в особо извращенной форме :)
22 май 06, 13:18    [2691121]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 Чернышев Андрей Леонидович
Сам дурак.

Чернышев Андрей Леонидович
На мой взгляд, Вы пока еще не начали понимать про MUMPS, pgres.
Именно в РСУБД "теория" вся в белых пятнах. Очередной пример - горячо обсуждаемые "индексы".
"Индексы" - это банальный пример денормализации для повышения производительности. В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные. Это в бОльшей степени данные, чем так называемые метаданные (словари данных). Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ? Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД. Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных.


1. хорошо известно в каких случаях индексы надо использовать а в каких нет. 2. они отлично вписываются в модель: меньше нормализации - больше скорость и наоборот.
3. таким образом индексы это материализованные представления данных 4. отношения индексов дублируют отношения таблиц т.к дублируют данные.
5. индексы не храняться в отдельной субд и запросы на индексы могут быть составлены разработчиком.

можно так и дальше, но видно Ваши белые пятна в понимании рдбмс невосполнимы изначально

автор

И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД.

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



автор
Специалистов по MUMPS намного меньше, и распространены системы на MUMPS меньше, чем на РСУБД. Это факт. В любой области есть попса, и есть альтернативные направления для "высоколобых", "идиотов", "интеллектуалов", "маргиналов" (кому как больше нравится).

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

Откуда: Магадан
Сообщений: 584
pgres
так что давайте кашисты не изворачивайтесь а делайте придложенный тест

хорошо, привожу результаты тестирования.
в связи с тем, что заказчик теста не указал размер записи, тестировались 2
структуры:
a)
^table(date,idx)=$random(1000)

b)
^table(date,idx)=$random(1000)*$random(86400)
где date - "дата звонка" в 5-значном "внутреннем" формате, idx - 1-1300000,
$random(1000) - "продолжительность звонка" в секундах и $random(86400) -"время звонка" во внутреннем 5-значном формате.
с учетом пожеланий заказчика было выбрано такое кол-во записей на сутки,
чтобы за 31 день получить выборку в 40 млн. записей.

размер БД - 261.3 млн. записей/узлов (3.7Gb), больше не позволяет FAT32.
спешу заверить и заказчика, и оппонентов, что тестирование доказало
независимость скорости выборки и обработки данных от количества записей
в БД.

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.
вычислялись следующие значения:
1. число выбранных записей
2. сумма "продолжительности звонков" в часах за сутки
3. средняя "продолжительность звонка" за сутки
4. время, затраченное на обработку суточной выборки
5. время, затраченное на весь тест

результаты тестирования по структурам:
a) 87-90 секунд, независимо от даты начала выборки.
b) 126-129 секунд, независимо от даты начала выборки.

"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

главный вывод: это, как я уже говорил, несерьезный тест. ни оборудование,
ни загруженность СУБД, ни размерность записей не уравнены. разве можно делать какие-то серьезные выводы?

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

Откуда: Харьков
Сообщений: 140
автор
"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.


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

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

Откуда: Магадан
Сообщений: 584
pgres
автор
"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.


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

"почем", "почему" или "по чем"? видимо, третье. :)
конечно, я создавал его по дате. я уверен, что у заказчика записи аналогичным образом по дате
проиндексированы. какие там, интересно, могут быть предрасчеты?
или проблема в том, что я строго зафиксировал количество записей на дату?
ну и что? что система переберет 40 млн. записей с разным количеством
записей на дату, что с одинаковым - один фиг, 40 млн. и будет.

С уважением. Сергей
22 май 06, 17:47    [2692761]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

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

Откуда: Магадан
Сообщений: 584
pgres
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

прокомментируйте плз

а ведь все банально просто - структура индексирована, следовательно
поиска дат по всей таблице не происходит, во время выборки снимаются
нужные значения сразу "под" нужной датой. и причем тут физика?

а вот "размер данного" - это да, система дольше читает.

С уважением. Сергей
22 май 06, 17:57    [2692818]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
pgres
так что давайте кашисты не изворачивайтесь а делайте придложенный тест

хорошо, привожу результаты тестирования.
в связи с тем, что заказчик теста не указал размер записи, тестировались 2
структуры:
a)
^table(date,idx)=$random(1000)

b)
^table(date,idx)=$random(1000)*$random(86400)
где date - "дата звонка" в 5-значном "внутреннем" формате, idx - 1-1300000,
$random(1000) - "продолжительность звонка" в секундах и $random(86400) -"время звонка" во внутреннем 5-значном формате.
с учетом пожеланий заказчика было выбрано такое кол-во записей на сутки,
чтобы за 31 день получить выборку в 40 млн. записей.

размер БД - 261.3 млн. записей/узлов (3.7Gb), больше не позволяет FAT32.
спешу заверить и заказчика, и оппонентов, что тестирование доказало
независимость скорости выборки и обработки данных от количества записей
в БД.

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.
вычислялись следующие значения:
1. число выбранных записей
2. сумма "продолжительности звонков" в часах за сутки
3. средняя "продолжительность звонка" за сутки
4. время, затраченное на обработку суточной выборки
5. время, затраченное на весь тест

результаты тестирования по структурам:
a) 87-90 секунд, независимо от даты начала выборки.
b) 126-129 секунд, независимо от даты начала выборки.

"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

главный вывод: это, как я уже говорил, несерьезный тест. ни оборудование,
ни загруженность СУБД, ни размерность записей не уравнены. разве можно делать какие-то серьезные выводы?

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


Вот хоть что-то конкретное. Тест конечно не совсем корректный т.к. структура данных совсем упрощена вследствии чего объем данных совсем маленький. 3.7 Gb это не серьезно (Кстати очеь большой объем для 2 то полей)
Вот примерная структура таблицы на которой я тестировал
CREATE TABLE "TTALKS"
( "PHONE_NUMBER" VARCHAR2(15),
"PHONE_CALL" VARCHAR2(15),
"DATE_CONNECT" DATE,
"MNEMONIC_IN" VARCHAR2(3),
"MNEMONIC_OUT" VARCHAR2(3),
"OVERTIME" CHAR(1),
"LENTALK" NUMBER(6),
"FILIAL_ID" NUMBER(3),
"SCHEMA" VARCHAR2(9),
"ID" NUMBER(10),
"ID_CALL" NUMBER(10),
"TYPE_CONNECT" CHAR(1),
"LENTALK_MINUTES" NUMBER(4),
"LENTALK_ACCRUAL" NUMBER(4),
"TARIFF" NUMBER(10, 2),
"TARIFF_ID" NUMBER(4),
"SUMTALK" NUMBER(20, 5),
"NDS_SUMTALK" NUMBER(20, 5),
"DATE_OF_COUNT" DATE,
"REASON_OTSEV" NUMBER(2),
"SERVICE" VARCHAR2(4),
"AOP_ID" NUMBER(3),
"AOP_ID_CALL" NUMBER(3),
"ID_PAY" NUMBER(10),
"PHONE_FULL_A" VARCHAR2(15)
)
Если считать что все записи строки то примерно 217 байт на запись (поля типа дата\время я посчитал по 20 байт) что составляет в вашем случае 217*261300000 = 56702100000 байт = 53 Гб.
Это без индексов. А индексы нужны практически по всем полям (кроме тех что хранят количественные показатели). Даже на таком сильно урезаном тесте в однопользовательском варианте (у меня на сервере еще более сотни человек работало выполняло запросы и вставку данных) производительность у вас всего примерно в 2 раза выше. Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД? Если добавить в тест условие что необходимо обеспечить выборки данных с условиями по многим полям то результат я думаю будет еще хуже.
Мне для выборки всех данных потребовалось написать 1 запрос (привожу ниже). Если не секрет поделитесь своим кодом.

select to_char(t.date_connect, 'mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'mm.yyyy')

Результат выполнения запроса 1 строка с данными за 1 месяц (что-то типа такого):

03.2005 41714548 1636542.161 2.353915705

Время выполнения - 94,7 с. Вы видимо сделали группировку за месяц.
В первый раз я имел ввиду запрос с группировками по дням

select to_char(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'dd.mm.yyyy')

В результате возвращается выборка из 31 записа с результатами на каждый день. Что-то типа этого:
01.03.0005 1460834 57702.9437222222 2.37550710512518
02.03.0005 1662122 65709.9997222222 2.37272681051328
......
22.03.0005 1373366 51959.0136666666 2.27656501779704
........

Я тут немного поэксперементировал и получил время работы запроса 105 с.
Чтоб не говорили что увидев ваш результат я быстро подделал свой привожу пример того запроса который работает примерно 200 - 230 с.

select to_date(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_date(t.date_connect, 'dd.mm.yyyy')

Так что при условии оптимизации запросов я получил результат не хуже вашего на гораздо больших объемах и большей нагрузке на систему. Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).
23 май 06, 03:48    [2693681]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Вот хоть что-то конкретное. Тест конечно не совсем корректный т.к. структура данных совсем упрощена вследствии чего объем данных совсем маленький. 3.7 Gb это не серьезно

а я и говорю, что тест несерьезный. надо было сразу показывать свою структуру. впрочем, речь шла, как я понимаю, о кол-ве записей, а не о
их размере, так что мне пришлось поджаться, размещая нужное кол-во
в 4Gb.


(Кстати очеь большой объем для 2 то полей)

не стоит забывать, что это таблица + индекс по дате


Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД? Если добавить в тест условие что необходимо обеспечить выборки данных с условиями по многим полям то результат я думаю будет еще хуже.

я бы сказал, что измерение производительности СУБД на последовательном
переборе данных не есть правильное тестирование.


Мне для выборки всех данных потребовалось написать 1 запрос (привожу ниже). Если не секрет поделитесь своим кодом.

пожалуйста, если Вам это что-нибудь даст. как видите, общего - 0.
 s t=$p($h,",",2)
 s d1=$zdh("11/04/2005",4)
 s d=d1-1 f  s d=$o(^table(d)) q:d=""!(d>(d1+30))  d  ;
 . s cnt=0,len=0,t2=$p($h,",",2)
 . i $d(^(d,0))
 . s idx="" f  s idx=$o(^(idx)) q:idx=""  s a=^(idx),len=len+a,cnt=cnt+1
 . w !,$tr($zd(d,4),"/",".")," ",cnt," ",len/3600," ",len/cnt/60," = ",$p($h,",",2)-t2
 w !,$p($h,",",2)-t


select to_char(t.date_connect, 'mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
^^^^^^^^^^^^^

а вот такие вещи надо уточнять. я, как умная Маша, высчитываю
продолжительность в часах по КАЖДОЙ записи.
так что я, конечно, пересчитаю по-Вашему, а Вам советую сделать
по-моему и сравнить, ага. :)


Время выполнения - 94,7 с. Вы видимо сделали группировку за месяц.
В первый раз я имел ввиду запрос с группировками по дням

нет, я делал по дням.


В результате возвращается выборка из 31 записа с результатами на каждый день. Что-то типа этого:
01.03.0005 1460834 57702.9437222222 2.37550710512518
02.03.0005 1662122 65709.9997222222 2.37272681051328
......
22.03.0005 1373366 51959.0136666666 2.27656501779704
........

пожалуйста
11.04.2005 1300000 180413.7811111111111 8.326789897435897437 = 2
12.04.2005 1300000 180278.2861111111111 8.320536282051282052 = 2
13.04.2005 1300000 180449.9947222222222 8.328461294871794872 = 2
14.04.2005 1300000 180339.4480555555556 8.323359141025641025 = 2
...
08.05.2005 1300000 180375.9941666666667 8.325045884615384615 = 1
09.05.2005 1300000 180382.6883333333333 8.325354846153846153 = 2
10.05.2005 1300000 180405.1225 8.32639026923076923 = 2
11.05.2005 1300000 180471.1494444444444 8.329437666666666667 = 2
61


Я тут немного поэксперементировал и получил время работы запроса 105 с.

убрав вычисление часов по КАЖДОЙ записи, я тоже оптимизировал выборку - 60-62 с.


Так что при условии оптимизации запросов я получил результат не хуже вашего на гораздо больших объемах и большей нагрузке на систему. Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).

отсюда можно сделать только один правильный вывод: сравнивать можно
только в одинаковых производственных условиях и на одинаковом оборудовании. и не только на последовательном переборе.
23 май 06, 08:26    [2693832]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
Joker_Ya
Sergei Obrastsov
pgres
так что давайте кашисты не изворачивайтесь а делайте придложенный тест

хорошо, привожу результаты тестирования.
в связи с тем, что заказчик теста не указал размер записи, тестировались 2
структуры:
a)
^table(date,idx)=$random(1000)

b)
^table(date,idx)=$random(1000)*$random(86400)
где date - "дата звонка" в 5-значном "внутреннем" формате, idx - 1-1300000,
$random(1000) - "продолжительность звонка" в секундах и $random(86400) -"время звонка" во внутреннем 5-значном формате.
с учетом пожеланий заказчика было выбрано такое кол-во записей на сутки,
чтобы за 31 день получить выборку в 40 млн. записей.

размер БД - 261.3 млн. записей/узлов (3.7Gb), больше не позволяет FAT32.
спешу заверить и заказчика, и оппонентов, что тестирование доказало
независимость скорости выборки и обработки данных от количества записей
в БД.

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.
вычислялись следующие значения:
1. число выбранных записей
2. сумма "продолжительности звонков" в часах за сутки
3. средняя "продолжительность звонка" за сутки
4. время, затраченное на обработку суточной выборки
5. время, затраченное на весь тест

результаты тестирования по структурам:
a) 87-90 секунд, независимо от даты начала выборки.
b) 126-129 секунд, независимо от даты начала выборки.

"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

главный вывод: это, как я уже говорил, несерьезный тест. ни оборудование,
ни загруженность СУБД, ни размерность записей не уравнены. разве можно делать какие-то серьезные выводы?

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


Вот хоть что-то конкретное. Тест конечно не совсем корректный т.к. структура данных совсем упрощена вследствии чего объем данных совсем маленький. 3.7 Gb это не серьезно (Кстати очеь большой объем для 2 то полей)
Вот примерная структура таблицы на которой я тестировал
CREATE TABLE "TTALKS"
( "PHONE_NUMBER" VARCHAR2(15),
"PHONE_CALL" VARCHAR2(15),
"DATE_CONNECT" DATE,
"MNEMONIC_IN" VARCHAR2(3),
"MNEMONIC_OUT" VARCHAR2(3),
"OVERTIME" CHAR(1),
"LENTALK" NUMBER(6),
"FILIAL_ID" NUMBER(3),
"SCHEMA" VARCHAR2(9),
"ID" NUMBER(10),
"ID_CALL" NUMBER(10),
"TYPE_CONNECT" CHAR(1),
"LENTALK_MINUTES" NUMBER(4),
"LENTALK_ACCRUAL" NUMBER(4),
"TARIFF" NUMBER(10, 2),
"TARIFF_ID" NUMBER(4),
"SUMTALK" NUMBER(20, 5),
"NDS_SUMTALK" NUMBER(20, 5),
"DATE_OF_COUNT" DATE,
"REASON_OTSEV" NUMBER(2),
"SERVICE" VARCHAR2(4),
"AOP_ID" NUMBER(3),
"AOP_ID_CALL" NUMBER(3),
"ID_PAY" NUMBER(10),
"PHONE_FULL_A" VARCHAR2(15)
)
Если считать что все записи строки то примерно 217 байт на запись (поля типа дата\время я посчитал по 20 байт) что составляет в вашем случае 217*261300000 = 56702100000 байт = 53 Гб.
Это без индексов. А индексы нужны практически по всем полям (кроме тех что хранят количественные показатели). Даже на таком сильно урезаном тесте в однопользовательском варианте (у меня на сервере еще более сотни человек работало выполняло запросы и вставку данных) производительность у вас всего примерно в 2 раза выше. Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД? Если добавить в тест условие что необходимо обеспечить выборки данных с условиями по многим полям то результат я думаю будет еще хуже.
Мне для выборки всех данных потребовалось написать 1 запрос (привожу ниже). Если не секрет поделитесь своим кодом.

select to_char(t.date_connect, 'mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'mm.yyyy')

Результат выполнения запроса 1 строка с данными за 1 месяц (что-то типа такого):

03.2005 41714548 1636542.161 2.353915705

Время выполнения - 94,7 с. Вы видимо сделали группировку за месяц.
В первый раз я имел ввиду запрос с группировками по дням

select to_char(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'dd.mm.yyyy')

В результате возвращается выборка из 31 записа с результатами на каждый день. Что-то типа этого:
01.03.0005 1460834 57702.9437222222 2.37550710512518
02.03.0005 1662122 65709.9997222222 2.37272681051328
......
22.03.0005 1373366 51959.0136666666 2.27656501779704
........

Я тут немного поэксперементировал и получил время работы запроса 105 с.
Чтоб не говорили что увидев ваш результат я быстро подделал свой привожу пример того запроса который работает примерно 200 - 230 с.

select to_date(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_date(t.date_connect, 'dd.mm.yyyy')

Так что при условии оптимизации запросов я получил результат не хуже вашего на гораздо больших объемах и большей нагрузке на систему. Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).


Переведи поля даты к типу datetime bповтори запрос. Я уверен что у тебя и база будет меньше занимать места и выигрыш в скорости запроса будет больше
23 май 06, 08:34    [2693847]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

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

Переведи поля даты к типу datetime bповтори запрос. Я уверен что у тебя и база будет меньше занимать места и выигрыш в скорости запроса будет больше


select trunc(t.date_connect) as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from talks.ttalks_local_2005 t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by trunc(t.date_connect)

при таком запросе стало 85 с.
Я думаю если еще подумать то можно и до 60 с довести. Просто лень если честно. Если создать таблицу аналогичную той что использовал Sergei Obrastsov с 2 полями то время будет значительно менише 60 с. т.к. её объем будет меньше раз в 10 как минимум. Причет я использую запросы которые выполняет ядро базы. А он использует интерпритатор который гоняет цикл, что не сильно быстро как мы увидили. И все зяаявления Кашистов о беспрецедентной скорости работы рассыпались в прах. Я уж молчу о том как не удобно работать с их системой. Надо постояно продумывать структуру под запросы иначе только полный просмотр. А продумать все запросы которые понадобятся пользователям невозможно. Мне же достаточно добавить индекс и впринципе все работает. Пусть даже чуть чуть медленнее (превосходства в 5 раз никто не заметил).
23 май 06, 09:14    [2693911]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
LittleCat
Member

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

хорошо, привожу результаты тестирования.
.....

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.
.....


Вот хоть что-то конкретное. Даже на таком сильно урезаном тесте в однопользовательском варианте (у меня на сервере еще более сотни человек работало выполняло запросы и вставку данных) производительность у вас всего примерно в 2 раза выше. Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД?
....
Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).

Не могли бы Вы привести конфигурацию оборудования, на котором производилось тестирование ? В примере, который привел Сергей, она присутствует. Мне кажется, выводы можно начать делать, когда мы ее сравним с Вашей. А пока они преждевременны :-)
23 май 06, 10:07    [2694087]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov
pgres
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

прокомментируйте плз

а ведь все банально просто - структура индексирована, следовательно
поиска дат по всей таблице не происходит, во время выборки снимаются
нужные значения сразу "под" нужной датой. и причем тут физика?

а вот "размер данного" - это да, система дольше читает.

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


я не совсем правильно понял
думал что время вычисления за день не зависит от количества записей за день
23 май 06, 10:17    [2694137]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

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

Не могли бы Вы привести конфигурацию оборудования, на котором производилось тестирование ? В примере, который привел Сергей, она присутствует. Мне кажется, выводы можно начать делать, когда мы ее сравним с Вашей. А пока они преждевременны :-)


Пожалуйста.

4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb доступно 2,5 так как остальное забирается под их хитрый райд массив и горячую подмену (Объемы очень большие так ак надо хранить все данные минимум за 3 года). Память 4 Гб. На этом железе работает примерно 100 чел. В пики до 160. Выполняется куча аналитической отчетности.
23 май 06, 10:22    [2694156]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

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

Не могли бы Вы привести конфигурацию оборудования, на котором производилось тестирование ? В примере, который привел Сергей, она присутствует. Мне кажется, выводы можно начать делать, когда мы ее сравним с Вашей. А пока они преждевременны :-)


Пожалуйста.

4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb доступно 2,5 так как остальное забирается под их хитрый райд массив и горячую подмену (Объемы очень большие так ак надо хранить все данные минимум за 3 года). Память 4 Гб. На этом железе работает примерно 100 чел. В пики до 160. Выполняется куча аналитической отчетности.


Забыл БД Oracle 10.1.0.5 работает в режите Archivelog,
так же включена опция flashback что не очень помогает быстродействию так как пишется куча журналов. Объем журналов за 1 день составляет 19-28 Гб.
23 май 06, 10:36    [2694225]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200
=
4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb 
Память 4 Гб. 

Что сравнивается в таких разных условиях, не понял. Хотя интересно было-бы узнать.
23 май 06, 10:39    [2694246]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
iscrafm
AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200
=
4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb 
Память 4 Гб. 

Что сравнивается в таких разных условиях, не понял. Хотя интересно было-бы узнать.


Ну так и нагрузка разная слегка не заметили. Там 1 чел. сидит а у меня 100. У него при более выгодных условиях (с базой работает 1 чел. Практически больша никаких задач не выполняется, объем значительно меньше и т д.) скорость работы не сильно выше. Это говорит о многом в том числе о том что при многопользовательской работе и на реальных данных все работать будет гораздо медленнее. Конечно усиление железа немного спасет ситуацию но вы никогда не получите 3-5 кратного превосходства над тем же Ораклом. В общем то я хотел показать имено это. Так что не поддавайтесь на рекламу о чудо постреляционных СУБД придуманных в 60-70 гг. прошлого века.
И еще сравните код на SQL и на М. Интересно в каком коде быстрее разберется человек. Если на SQL надо написать 1 команду то на М надо целую программу. Достаточно приличного объема. Я конечно понимаю что поклонники М хитрят и не пишут операторы полностью чтоб хоть как то визуально приблизить свое творение к размерам SQL запроса. Пусть это будет на их совести. Кстати SQL можно вообще не писать есть куча графических построителей запросов. Ну это к слову. Не хочу обидеть стороников М систем. Просто мне надоело что постояно говорят о том что М может сделать любую РСУБД в несколько раз. А как доходит до реальных примеров ничего доказать не могут. Причем этим страдают не только программисты но и сама Intersystems.
23 май 06, 10:54    [2694346]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.
23 май 06, 11:31    [2694561]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Joker_Ya
И еще сравните код на SQL и на М. Интересно в каком коде быстрее разберется человек.

Насчет кода конечно Вы правы.
23 май 06, 11:33    [2694585]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
iscrafm
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.

не был бы. обратите внимание, что идет последовательный перебор.

С уважением. Сергей
23 май 06, 11:34    [2694587]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Sergei Obrastsov
обратите внимание, что идет последовательный перебор.


А не могли бы Вы попробовать выполнить во эту программку?

автор


; Формирование теcтового массива
k ^Table
k ^SPhoneIndex
k ^DateTimeIndex
s StartDate=+$h ; массив будет формироваться начиная с сегодняшнего дня


w !,"формируем массив"
w !,"Начало формирования - ",$ZDT($h)," "
f i=1:1:10000000 d ; количество (нужно менять при испытании)
.s DeltaDate=$r(365) ; случайный день
.s date=StartDate+DeltaDate ; дата разговора для тестирования
.s time=$r(86400) ; случайное время для даты разговора
.s DateTime=+(date_"."_time) ; в таком формате будем хранить дату и время
.s SPhone=+$r(9999999) ; случайный номер телефона-источнка
.s RPhone=+$r(9999999) ; случайный номер телефона-приёмника
.s Length=$r(3600) ; случайная продолжительность разговора
.s Сortege=$LB(DateTime,Phone,Length,RPhone) ; кортеж данных
.s ^Table(i)=Сortege ; массив данных
.s ^SPhoneIndex(SPhone,DateTime)=i ; Индекс по номеру телефона-источника
.s ^DateTimeIndex(DateTime,SPhone)=i ; Индекс по дате
.i i#100000=0 w !,i," ",$ZT($p($h,",",2))
w !,"Конец формирования - ",$ZDT($h)," ",!!

; Выборки
;----------
w !,"проход по всему массиву и подсчет количества записей"
s i="" s count=0
w !,"Начало - ",$ZDT($h)," "
f s i=$O(^Table(i)) q:i="" s count=count+1
w "Конец - ",$ZDT($h)," ",!
w " количество = ",count,!!


Мне интересно время выплнения на вашем компьютере.
23 май 06, 12:14    [2694929]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
yww@escape.ru
Sergei Obrastsov



Если возьмётесь, исправьте одну строчку.. ошибся я.. нужно так

автор

.s Сortege=$LB(DateTime,SPhone,Length,RPhone) ; кортеж данных


Если не возьмётесь - я не обижусь
23 май 06, 12:17    [2694963]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov
iscrafm
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.

не был бы. обратите внимание, что идет последовательный перебор.

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


а что Вы предлагаете
23 май 06, 12:40    [2695171]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

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

а что Вы предлагаете

Выслать тест на TPC и попросить их прокомментировать или хотя бы посмотреть на их реакцию. Что же еще?
23 май 06, 13:12    [2695508]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

Microsoft SQL Server 2000 - 8.00.194 (Intel X86) Aug 6 2000 00:57:48 Copyright (c) 1988-2000 Microsoft Corporation Personal Edition on Windows NT 5.1 (Build 2600: Service Pack 2)


create table ttalks(
  starttime datetime not null,
  duration int not null
)
go

create clustered index ttalks_idx1 on ttalks(starttime)
go


количество записей за месяц ~43млн
по дням распределены неравномерно
в таблице немного больше но при существовании индекса это неважно
размер базы 1.7Гб

не самый лучший запрос

select day(starttime), count(*), sum(cast(duration as numeric(18,0)))/3600, avg(cast(duration as numeric(18,0)))/3600
from ttalks 
where starttime between '1-Jan-1900' and '31-Jan-1900' 
group by day(starttime)
order by day(starttime)

120 сек

не вижу обещаного превосходства каше в 5 раз
(ну или хотя бы в 2)

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

Откуда: Магадан
Сообщений: 584
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше


select day(starttime), count(*), sum(cast(duration as numeric(18,0)))/3600, avg(cast(duration as numeric(18,0)))/3600
from ttalks 
where starttime between '1-Jan-1900' and '31-Jan-1900' 
group by day(starttime)
order by day(starttime)
120 сек

может кто-нибудь все-таки проверит сколько времени займет
sum(cast(duration as numeric(18,0))/3600)


не вижу обещаного превосходства каше в 5 раз
(ну или хотя бы в 2)

в 2 и есть. :)
24 май 06, 01:06    [2698586]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
iscrafm
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.


За процессорами не следил в этот раз но до этого специально мониторил систему. Загрузка в рабочее время в среднем составляет 30-40%. К сведению для вас 100 подключений даже неактивных требуют довольно боольших ресурсов системы сами по себе. Это прежде всего память (около 1 М если ничего не делали на процесс, у меня в среднем 2-5). Это время процессора так как постояно проверяется активно ли соеденение. Вообще внутри системы происходит значительное кол-во телодвижений для поддержания пула соеденений, для обеспечения целостности транзакций как читающих так и пишущих. Кстати у меня запрос был в рамках 1 транзакции, т. е. все данные были полученвы на момент начала транзакции. В приведенном тесте на М о транзакциях не слова и если данные необходимые для выборки были изменены после начала обработки то уже измененные данные попадут у них в выборку. Я же получу те данные которые были на момент начала транзакции даже если после начала выполнения запроса кто либо изменил данные. Поддержка транзакция весьма ресурсоемкая вещ. Так что тест в принципе показал что никакого особого приемущества М системы не дают. Железо у них было послабее. Так и работала в однопользовательском режиме без поддержки транзакций на сильно урезанных данных (у меня кол-во записей в таблице порядка 500 млн. у них всего 261 кроме того у меня длина записи почти в 15 раз больше). И при всех этих условиях скорость выполнения у них всего в 1.5 - 2 раза выше. Если добавить в их тест еще пару работающих человек, уравнять структуры хранения добавить транзакции то результат будет не сильно лучше.
Тут Сергей постояно говорит:
обратите внимание, что идет последовательный перебор

И что это проблемы Каше и других М систем. Сделайте аналогичный SQL запрос если вам перебор не нравиться. Я думаю там вообще результат будет хуже раза в 2. В одном из топиков кто-то делал сравнение SQL в Оракле и Каше. Результат был не в пользу Каше раза в 1.5.

Еще раз повторюсь я не против Каше. Просто при практически одинаковой стоимости лицензий на Каше и Оракл вы получите конструктор сделай сам все на языке похожем на курсовую работу студента филолагического факультета (так как с математикой очень плохо у них было приоретета операций нет) с криво пределаным SQL производительность которого не блещет а синтаксис застыл на уровне 90 годов, с жесткими ограничениями на кол-во подключений (у оракла нет никаких ограничений. Только совесть клиента и если например в какой то момент ононеожидано превысит кол-во лицензий купленных то ничего страшного все будет работать дальше. А вы можете спокойно докупить лицензии), с практически полным отсутствием литературы на русском, с отсутствием нормальной бесплатной версии (практически у всех РСУБД они есть с определенными ограничениями, по объему и количеству процессоров которые позволяют спокойно работать). Есть еще много минусов. Плюсов я например от приверженцев Каше так и не дождался. Одни обещают беспрецидентной производительности раз в 5 больше чем у РСУБД но этого нет как мы видим на реальных тестах. Другие говорят об удобстве хранения данных в деревьях, но его тоже нет так как под очередной запрос надо структуру данных подгонять. В общем сплошной гемморой за нехилые бабки.
24 май 06, 02:47    [2698621]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
yww@escape.ru
c127
А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель)


Что ж вы так горячитесь? Не помещайте данные по месяцам в узлы - поместите их в узлы по дате.. все вопросы с неделями снимутся... как и, впрочем, с часами и минутами.. $h - хранит и дату и время одновременно.

А я ничего никуда не помещаю, это Вы их туда помещаете:
"в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=293038&pg=6#2684408

yww@escape.ru
Что касается других выборок - постройте для них подходящие индексы.

Ну да, как же, только что нам втюхивали что индексы могут не потребоваться:
"если вы уже на этапе постановки задачи знаете что вам портебуются выборки по датам, то и данные можно хранить в узлах, организованных на $h... а здесь уже всё равно - по месяцу, по неделе, по году - принцип то один и тот же.. становитесь на начало периода и двигаетесь до конца.. дополнительные индексы здесь могут и не понадобиться. ИМХО, конечно.."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=293038&pg=8#2687245

Я же об этом и говорю, что стоит немного поменять постановку задачи, а это по-моему происходит всегда, все достоинства КЕШ-а пропадают, остаются давно всем хорошо известные недостатки иерархических БД.

yww@escape.ru

И не думайте, пожалуйста, что лично вас кто то пытается обмануть

Расслабтесь, я так не думаю. Но даже если и пытаются, это меня не беспокоит, не должно беспокоить и Вас. Хотя имете право беспокоиться разумеется.
24 май 06, 03:31    [2698631]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Тут Сергей постояно говорит:
обратите внимание, что идет последовательный перебор

И что это проблемы Каше и других М систем. Сделайте аналогичный SQL запрос если вам перебор не нравиться. Я думаю там вообще результат будет хуже раза в 2. В одном из топиков кто-то делал сравнение SQL в Оракле и Каше. Результат был не в пользу Каше раза в 1.5.

а вот не надо утверждать за меня, ладно? не надо путать "последовательный
перебор записей" и "работу с последовательными файлами". Cache действительно сильно подсаживает систему при работе с обычным файлом,
по крайней мере так в 5.0.11
перебор записей, лежащих в БД подряд,
в РСУБД будет быстрее, это однозначно.
с таким же успехом я могу утверждать, что простенькая программка на C круче обеих тестируемых СУБД, поскольку сделает все то же с обычным файлом намного быстрее. :)
24 май 06, 04:13    [2698635]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
Sergei Obrastsov
c127

А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве.

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

вот ведь забавно. сколько раз уже объясняли, что при необходимости ввести
новый индекс он просто создается и все. и в SQL его надо создавать, и в M
его надо создавать. в SQL это менее затратно? согласен. за удобство
работы с данными нужно платить.

В который раз спрашиваю: в чем именно состоит удобство работы с данными? В том что программы в 3 раза длиннее? Так это скорее неудобство.

Потом индексы в КЕШ-е создаются медленнее, получается если создать-посмотреть аналитику-убить, то может получиться что займет больше времени. Правда и места больше.

Насколько быстрее МуСКЛ создает индекс? Не могли бы Вы привести цифры, у Вас же они оба на одной машине. А то по размерам файлов, где КЕШ выигрывает приводятся конкретные цифры, а по созданию индекса, где КЕШ проигрывает - только признание, что таки медленнее. Двойные стандарты получаются.


Sergei Obrastsov

c127

Sergei Obrastsov

а вот насчет дисков проблема, 80Gb - все,
что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :)

Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb.

ну, не все живут красиво. а еще меня можно попрекнуть зарплатой.
это тоже хороший критерий, сразу видно, кто чего стоит.

Не нужно выжимать из меня слезу, мы не в церкви. Вы систему на 10 млн пользователей на этих дисках сертифицировали, или может предлагаете своим клиентам хранить работать с промышленными базами на 80Гб ИДЕ дисках с фат32? Так к чему эти разговоры о бедных? Экономить нужно там где это действительно дает экономию, а не покупать сервер БД за сотню тысяч, а потом экономить по 20 долларов на дисках. В любом случае 10Гб было бы дешевле, почему же Вы остановились на 80Гб, раз зарплата маленькая, экономили бы уже по полной.

Sergei Obrastsov

c127

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

кол-во зарегистрированных сотовых телефонов в городе по годам:
2003  2004  2005-2006
0      1000   150000
как там будет выглядеть рост кол-ва звонков по ним?

Как арфиметическая прогрессия разумеется. Пусть каждый пользователь делает J звонков за интересующий нас период, тогда у одного пользователя будет
1*J звонков,
два пользователя - J+J звонков,
....
N пользователей - N*J звонков
N+1 пользователь - N*J+J звонков
....
То есть каждый следующий "на" J звонков больше предыдущего, а не "в" J раз, как это должно было бы быть в случае геометрической прогрессии. Еще раз повторяю, не растет база в геометрической прогрессии, неоткуда ей там взяться.

Sergei Obrastsov

я понимаю, что хочется "погнуть пальцы и постучать копытами". но может
лучше это делать не здесь?

Лучше выучить что такое арифметическая прогрессия, или же не использовать непонимаемые слова.

Sergei Obrastsov

c127

Sergei Obrastsov

эти вещи просьба мне в вину не ставить, SQL пакует числа, так
что нечего тут,
СКЛ числа не пакует.

пакует. в 2 байта, в 4 байта... для меня это упаковка.


Числа СКЛ сервером не пакуются, тут нечего обсуждать, а то получится как с геометрической прогрессией. Они хранятся в двух байтах, четырех, восьми и т.д. И что очень важно - как хранятся, так и обрабатываются, в этом же формате. Не тратит сервер времени на упаковку-распаковку, это родной формат современных процессоров. То что КЕШ поступает по-другому и хранит все в строках это его проблема и не повод чтобы весь мир под него подстраивался и менял систему понятий.




Sergei Obrastsov

v13 - заданный список
v14 - заданный список

Что такое заданный список?

Sergei Obrastsov

размер запросов не лимитирован, т.е. могут быть заданы все условия одновременно.

В таком случае говорить не о чем, нужны все индексы. Но ведь такого не бывает, обычно используется несколько процентов возможностей системы. У Вас ведь тоже нет всех индексов. Из всех Ваших запросов, которых по самым скромным оценкам не менее 2^13=8192, будут использоваться штук 10. Их нужно оптимизировать, остальные - пусть ждут, но скорее всего они никогда не встретятся.

Sergei Obrastsov

50% на 100Gb - существенная разница.

50% это и в африке 50%. Разница в цене диска долларов 10, если это сущестенно, то да, разница существенная. Но тогда нужно переходить на файерберд, он бесплатный, экономия на сервере БД.

Sergei Obrastsov
pgres
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

прокомментируйте плз

а ведь все банально просто - структура индексирована, следовательно
поиска дат по всей таблице не происходит, во время выборки снимаются
нужные значения сразу "под" нужной датой. и причем тут физика?

а вот "размер данного" - это да, система дольше читает.

Согласен, вывод противоречит законам физики. Поиск происходит даже если используется индекс. Если КЕШ использует древовидные индексы, то у них рост примерно O(log2(N)). Это немного, но заявлять что от количества даннных не зависит неверно.

А вот зависимость от размера данных очень подозрительна. Не строки ли, в которых хранит данные КЕШ в этом виноваты? Не должно заметно зависеть, если система не качает эти данные на клиент, а при выполнении запроса она их туда качать не должна, только результат.
24 май 06, 04:14    [2698636]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

Откуда:
Сообщений: 933
Sergei Obrastsov
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше

а по поводу 512М оперативки мы типа не заметим....
типа не критично...
;)
24 май 06, 05:36    [2698658]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
andy st
Sergei Obrastsov
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше

а по поводу 512М оперативки мы типа не заметим....
типа не критично...
;)


Вот имено для баз гораздо боле критичным ресурсом является объем оперативной памяти (так как больший объем позволяет избегать медленных дисковых операций за счет кеша) чем такторая частота процессора.
24 май 06, 05:42    [2698661]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
andy st
Sergei Obrastsov
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше

а по поводу 512М оперативки мы типа не заметим....
типа не критично...
;)


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

для Cache это не критично. она отгрызает свои там 80-100 метров на процессы
и дисковый кэш и все. говорят дескать увеличение дискового кэша дает прирост скорости... но на первом проходе все-равно нифига не дает.
сколько дисковый кэш был у меня? 16 метров, стандарт.
24 май 06, 07:31    [2698732]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

Откуда:
Сообщений: 933
Sergei Obrastsov
Joker_Ya
...
Вот имено для баз гораздо боле критичным ресурсом является объем оперативной памяти (так как больший объем позволяет избегать медленных дисковых операций за счет кеша) чем такторая частота процессора.

для Cache это не критично. она отгрызает свои там 80-100 метров на процессы
и дисковый кэш и все. говорят дескать увеличение дискового кэша дает прирост скорости... но на первом проходе все-равно нифига не дает.
сколько дисковый кэш был у меня? 16 метров, стандарт.


Sergei Obrastsov

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.

а про кеш windows тоже забудем.... )
особенно на 1 гиге оперативки
24 май 06, 07:53    [2698758]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
andy st
Sergei Obrastsov

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.

а про кеш windows тоже забудем.... )
особенно на 1 гиге оперативки

не забудем. и про выборку 100 раз тоже.
только вот разницы между первым прогоном и последующими нет.
ну, например, 60-62-62-61-62-60-60-62...
и от увеличения дискового кеша не меняется.
и от "kept in memory" тоже не меняется.
24 май 06, 08:46    [2698826]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
andy st
Member

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

не забудем. и про выборку 100 раз тоже.
только вот разницы между первым прогоном и последующими нет.
ну, например, 60-62-62-61-62-60-60-62...
и от увеличения дискового кеша не меняется.
и от "kept in memory" тоже не меняется.

а перед тестами все кеши, в т.ч. и виндовый, были сброшены ??
и вопрос 2:
как будет вести себя Cache, если в момент создания отчета будет происходить правка исходных данных?
24 май 06, 09:02    [2698854]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

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

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
24 май 06, 09:20    [2698924]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Sergei Obrastsov

сколько дисковый кэш был у меня? 16 метров, стандарт.


Вот потому то и получилось так медленно. 16 - это недопустимо мало для миллионов записей. Я просил Вас проверить программку, подозревая что у Вас маленький кэш. Ну а теперь и так ясно.

Увеличьте кэш до 200, хотя бы, и проверьте что выйдет с вашим тестом. Очень это интересно.
24 май 06, 11:07    [2699459]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura1976
Guest
Мои соображения.

У меня дома сейчас стоит SQL 2005 Express.
Недавно получил обещаный диск от Cache 5 (однопользовательский).
Базы данных будут расположены на FAT 32
Все настройки по дефолту

Комп P3 chipset 815 Hard 160 GB RAM 512 MB

Готов установить cahce 5 и провести тест

Пожалуйста, cache-исты подскажите мне прогу которая создает таблицу на 45 000 000 записей и заполянет ее случайными данными)

данные для таблицы
{
id_row int,
a_phone varchar(32)
b_phone varchar(32)
originating datetime
terminatin datetime
duration int
base_station_id int
disconnect_reason smallint
}

три некластерных индекса

a_phone
originating
base_station_id

Пожалуйста, подскажите, как потом те же данные перенести с Cache на SQL 2005 express.

Предложите процедуры сравнения для
1. SELECT - 3 разных запроса
2. INSERT - 2 разных запроса
3. UPDATE - 2 разных запроса
4. DELETE - 2 разных запроса.

Я постараюсь максимально не предвзято провести сравнение
24 май 06, 12:25    [2699943]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>Недавно получил обещаный диск от Cache 5 (однопользовательский).

Если у Вас нет лицензии, сравнения будут бессмысленны. Вам лучше обратиться в InterSystems за временной лицензией. Обьясните ситуацию и попросите временную лицензию.
24 май 06, 12:48    [2700095]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura1976
Guest
yww@escape.ru
>>Недавно получил обещаный диск от Cache 5 (однопользовательский).

Если у Вас нет лицензии, сравнения будут бессмысленны. Вам лучше обратиться в InterSystems за временной лицензией. Обьясните ситуацию и попросите временную лицензию.


Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
24 май 06, 14:23    [2700680]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
в однопользовательском режиме бстрее всего будут работать dbf файлы :)
--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
24 май 06, 14:47    [2700845]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Iura1976
Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять...
24 май 06, 14:47    [2700848]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?
24 май 06, 14:55    [2700908]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
version
Guest
pavelvp
Iura1976
Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять...


https://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su?
24 май 06, 14:56    [2700917]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
version2
Guest
version
pavelvp
Iura1976
Почему ?
В чем трабла ?
Я могу SQL тоже перключить в однопользовательский режим
Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять...


https://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su?


sorry,
https://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su�
24 май 06, 14:57    [2700925]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
version3
Guest
не проходит правильная ссылка...

"Именно. У версии, которая SU, кеш ограничен."
24 май 06, 15:00    [2700949]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

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

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?


я перестал Вас понимать
объясните к чему это
24 май 06, 15:05    [2700978]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
Sergei Obrastsov
pgres
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?


я перестал Вас понимать
объясните к чему это

уф... я же сказал, что рассчитывал значение времени в часах по КАЖДОЙ строке. потом указал, что пересчет с учетом этого изменения,
по первой структуре занимает 60-62 сек.
сейчас вот пересчитал по второй - 71-72

размер кеш значения не имеет. что 16 метров, что 200 - однофигово.
это и очевидно, слишком большой объем данных.
24 май 06, 15:58    [2701370]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
Sergei Obrastsov
pgres
2 Sergei Obrastsov

насчет превосходства каше в 2 раза Вы поторопились
а все остальные так просто поверили

datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек

не ожидал от Вас такого передергиванья

а я не ожидал такой невнимательности. может все-таки обратим внимание
на /3600?


я перестал Вас понимать
объясните к чему это

уф... я же сказал, что рассчитывал значение времени в часах по КАЖДОЙ строке. потом указал, что пересчет с учетом этого изменения,
по первой структуре занимает 60-62 сек.
сейчас вот пересчитал по второй - 71-72

размер кеш значения не имеет. что 16 метров, что 200 - однофигово.
это и очевидно, слишком большой объем данных.
24 май 06, 16:10    [2701441]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

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

Да пожалуйста провел я дефрагментацию индекса.
работает 68 сек
и я настаиваю что никакого превосходства каше над рдбмс нет - будь у меня гиг памяти будет работать еще на 40% , быстрее

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
25 май 06, 10:36    [2703994]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8 9 10 11      [все]
Все форумы / Сравнение СУБД Ответить