Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
На обсуждение два предположения. 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.05.2006, 08:57 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Iura1. По 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.05.2006, 16:39 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 18:35 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 20:43 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 23:11 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 23:26 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 09:06 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
IuraТы сделай кластерный индекс по userid и закидай дачиком случайных числе и текст данные в таблицу. Накопи более 100 миллионов записей и посмотри как умирать начнет твой комп. У меня нет возможности сделать такую большую базу. Если у Вас есть - попробуйте и выложите цифры. Пока что есть только Ваши ощущения И кстати: зачем делать именно кластерный индекс? Его применение далеко не всегда оправдано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 10:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 11:27 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Что значит спокойнее жить? Или беспокойнее? У нас ежедневно добавляется только 2 млн. записей (в mssql и такие же объемы в oracle). Таблички вроде немаленькие, да и место нужно прогнозировать и индексы там имеются и все живет и не загибается. ЗЫ: сусликофф видели? а они есть! :) ЗЫЫ: очередной флэйм, вместо разведения которого не проще взять и поделать тесты? пусть далеко не идеальные, но на которых можно выяснить что нужно для себя под конкретные свои задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 11:55 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Ценый совет и плюс в пользу MSSQL 2005 http://msdn.microsoft.com/SQL/default.aspx?pull=/library/en-us/dnsql90/html/sql2k5partition.asp&print=true ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 12:08 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ilikerНе перестраивает asa каждый раз таблицу.Перестройка делается ручками при помощи reorganize table. А MSSQL, похоже, перестраивает каждый раз.(маловато информации в MSDN) MSDN 1 MSDN 2 При вставке записей ASA просто стремится ложить записи в конец не до конца заполненных страниц, которые по значениям кластерного ключа близки к вставляемым записям. При изменении записей сервер их оставляет на тех же страницах. В итоге получается этакая блоковая дефрагментация, где никто не гарантирует сортировки записей таблицы по кластерному ключу и страницы таблицы более менее содержат близкие по кластерному ключу записи, но не обязательно эти страницы идут одна за одной, что с моей точки зрения является вполне нормальным и оправданным демократичным подходом к организации кластерного ключа, где с одной стороны не тормозится скорость вставки новых записей, с другой стороны при выполнении запросов оптимизатор учитывает наличие кластерного ключа и получает более быстрое чтение записей засчет того, что они часто лежат в пределах одинаковых страниц. Для проведения физической полной онлайн дефрагментации таблицы по кластерному ключу (или PK eсли у теблицы нет кластерного ключа), используется оператор REORGINIZE TABLE, который во время работы не блокирует сессии и работает в фоновом режиме, незаметном для других сессий, действуя методом последовательного переноса записей в новые или пустые страницы, удаляя их с оригинальных, однако естественно реагируя на транзакции других сессий. В принципе для ASA кластерные ключи нужны достаточно редко - для таблиц с большим кол-вом записей, где запросами часто обрабатываются множества данных одного условия и соответствующе было бы не желательно на страницах держать записи разных условий, что привело бы к считыванию лишних страниц. Плюс встроенная поддержка параллейного считывания индексов и таблиц для RAID, где сервер сам определяет, какие страницы БД лежат на разных устройствах и их можно считывать параллейным доступом, дает вкупе с кластерным ключом неплохие результаты по производительности запросов (даже на обычном зеркале). MSSQL насколько я помню, физически держит отсортированными по кластерному ключу записи и каждый раз их перестраивает, что с моей точки зрения (и видимо разработчиков ASA) не самый оптимальный вариант реализации кластерного ключа и, помимо уменьшения скорости вставки записей в таблицу с кластерным ключом, может приводить к различным нехорошим эффектам, таким, как например блокировка страниц. -- www.rusug.ru - портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 12:12 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ASCRUSMSSQL насколько я помню, физически держит отсортированными по кластерному ключу записи и каждый раз их перестраивает, что с моей точки зрения (и видимо разработчиков ASA) не самый оптимальный вариант реализации кластерного ключа и, помимо уменьшения скорости вставки записей в таблицу с кластерным ключом, может приводить к различным нехорошим эффектам, таким, как например блокировка страниц. память подвела... ;) в mssql2000 и далее есть такая штука, как fill factor, которая собственно и определяет, сколько свободного места резервировать на страницах нижнего уровня кластерного индекса. т.е. идентично ASA ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 12:20 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenУ нас ежедневно добавляется только 2 млн. записей (в mssql и такие же объемы в oracle). Таблички вроде немаленькие, да и место нужно прогнозировать и индексы там имеются и все живет и не загибается. интересно. а поконкретнее можно? сколько, например, это в мегабайтах (вместе с индексами, понятное дело)? С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 12:21 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
andy st ASCRUSMSSQL насколько я помню, физически держит отсортированными по кластерному ключу записи и каждый раз их перестраивает, что с моей точки зрения (и видимо разработчиков ASA) не самый оптимальный вариант реализации кластерного ключа и, помимо уменьшения скорости вставки записей в таблицу с кластерным ключом, может приводить к различным нехорошим эффектам, таким, как например блокировка страниц. память подвела... ;) в mssql2000 и далее есть такая штука, как fill factor, которая собственно и определяет, сколько свободного места резервировать на страницах нижнего уровня кластерного индекса. т.е. идентично ASA Да нет, по моему не подвела: MSSQL BOLClustered 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.05.2006, 12:32 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ASCRUS... ну если есть BOL - может стоит посмотреть повнимательнее? ;) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 12:42 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
вот некоторые таблички 68 млн записей, 29гиг данные, 16 - индекс 23 12 6 23 11 5,5 28 12,4 7 200 52 23 42 11 5 173 40 17 ... ширину считать лениво, но если оченно нужно, то могу посчитать структуру по определенным причинам привести не могу, но вообщем-то и не в этом суть, не понимаю при чем тут объемы если взять гис какую-нить, то там может быть мало записей, но вес... как впрочем и наоборот ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 12:47 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Не стоит думать что SQL Server будет перестраивать 100 000 000 записей при одном добавлении. Да они храняться упорядоченно но перестраивается при добавлении и т.п. только одна страница, в крайнем случае разбивается на 2. Это абсолютно не влияет на быстродействие. Проблема не в отсортированности записей а в размере самого индекса. Кластерный он или нет не имеет значения. Единственный метод борьбы с тормозом в таком случае партишоны. -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 12:52 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ASCRUSто есть записи, в отличие от ASA хранятся в порядке сортировки кластерного ключа, что по идее означает их физическое перестраивание на странице(ах).Внутри страницы записи не сортируются в порядке кластерного ключа. Почитайте, например, Kalen Delaney "Inside SQL Server", и не надо будет фантазировать. P.S. Всегда восхищает способность людей - по капле воды догадаться о существовании океанов. На этом форуме, к сожалению, их особенно много :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 13:36 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 14:00 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ChAВнутри страницы записи не сортируются в порядке кластерного ключа. Почитайте, например, Kalen Delaney "Inside SQL Server", и не надо будет фантазировать. К слову - на курсах (авторизованных, а как же иначе...) по mssql2000 авторизованный тренер (типа преподаватель) наверно с полчаса рассказывал что в кластерном ключе mssql2000 хранит записи всегда сортированными и во всем наборе записей. Меня потом долго клинило, что же произошло - он на самом деле так считает или был вынужден повторять неудачный перевод BOL. Или он доверился проверке на десятке записей и поверил переводу. Надолго запомнилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 14:01 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ASCRUS MSSQL BOLClustered 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.05.2006, 14:03 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 14:42 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
зы: данные в Мб, первый столбец - общий объем, второй - используемый ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 14:45 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 14:46 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
авторMS SQL-ю можно указать сколько в процентах использовать места в страницах-листьях для кластерного индекса. При вставке запись делается на страницу с близкими значениями кластерного ключа, если не хватает места, то страница разделяется на две и идет добавление на одну из них. внутри страницы судя по BOL физической пересортировки не делается. ИТОГ: перестройка таблицы с кластерным индексом идет только тогда, когда запись не влезает на страницу. при этом происходит расщепление страницы и соответствующая перестройка индекса. Спасибо за обьяснение. Получается основное отличие от ASA - у нас страница не будет расщепляться, просто если запись не входит по размерам на все подходящие страницы, она уйдет на другую или новую страницу. Ну и соотвествующе и FILL FACTOR в ASA из за этого в индексах не предусмотрено. -- www.rusug.ru - портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 15:35 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDen Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. итого, +1561Mb в сутки для 20 млн. записей, из них индексы занимают 446Mb посчитаем: 446 / 20 = 22.3 байта на индекс даже с учетом сжатия маловато вроде теперь данные: 1115 / 20 = 55.75 байт на запись и тоже вроде как маловато получается. хотя может там одни числа? может я что-то не так считаю? С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 16:08 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov ASCRUS MSSQL BOLClustered 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.05.2006, 16:13 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
авторможет в ASA внутри MUMPS сидит :) уж очень схема связей идентична doubly-linked list интересно про ASA почитать Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;) -- www.rusug.ru - портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 16:15 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ASCRUS авторможет в ASA внутри MUMPS сидит :) уж очень схема связей идентична doubly-linked list интересно про ASA почитать Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;) Да они хоть бы что-то читали... В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 16:24 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov SiDen Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. итого, +1561Mb в сутки для 20 млн. записей, из них индексы занимают 446Mb посчитаем: 446 / 20 = 22.3 байта на индекс даже с учетом сжатия маловато вроде теперь данные: 1115 / 20 = 55.75 байт на запись и тоже вроде как маловато получается. хотя может там одни числа? может я что-то не так считаю? С уважением. Сергей Народ когда такие сравнения делаете, пожалуйста сначала седала truncate log а потом dbcc shrink database. Результаты вас приятно удивят. Во вторых страшен как размер индекса, так и высота дерева, которая используется при построении индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 16:26 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SergSuperВ-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше. Судя по фразе автора топика ( "... Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева..." ) некоторые думают, что как раз таки в кеше деревьев нет никаких, стал быть и перестраивать нечего. Или, быть может, думают, что дерево в кеше - волшебное, самоперестраивающееся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 16:35 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ЛП SergSuperВ-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше. Судя по фразе автора топика ( "... Полагаю, что при такой нагрузке Cache будет жить спокойней. Проблема для SQL будет в нагрузке на пересчет индексного дерева..." ) некоторые думают, что как раз таки в кеше деревьев нет никаких, стал быть и перестраивать нечего. Или, быть может, думают, что дерево в кеше - волшебное, самоперестраивающееся. некоторые думают, что Cache - это такая же колбаса, только в другой обертке, отсюда все непонимание. B-дерево, действительно, вещь тривиальная, не спорю, но ведь используют же. значит что-то в нем есть. причем используют именно там "где рвется". я прав? С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 17:05 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SergSuper ASCRUS авторможет в ASA внутри MUMPS сидит :) уж очень схема связей идентична doubly-linked list интересно про ASA почитать Гм, цитата была взята из BOL для MSSQL 2000. Так что лучше читать про MSSQL ;) Да они хоть бы что-то читали... В-дерево - довольна тривиальная вещь и наивно думать что она есть только в кеше. А дерево где - в моем посте нет про дерево ................. ..мальчики кровавые в глазах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 17:11 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov........ некоторые думают, что Cache - это такая же колбаса, только в другой обертке, отсюда все непонимание. ....... Сергей, с интересом слежу за обсуждением. Слово "колбаса" впервые встретилось в Вашем посте. Есля я не прав, приведите ссылку, кто думает, что Cache - это колбаса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 17:11 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
мясник Sergei Obrastsov........ некоторые думают, что Cache - это такая же колбаса, только в другой обертке, отсюда все непонимание. ....... Сергей, с интересом слежу за обсуждением. Слово "колбаса" впервые встретилось в Вашем посте. Есля я не прав, приведите ссылку, кто думает, что Cache - это колбаса. впервые. но оно не главная значимая часть этого предложения, главная - "такая же" :) С уважением. Сергей P.S. ну что, блин, за детство? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 17:33 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Сергей, речь не о 20, а о 2 млн, внимательнее плз To lura: 1. лог приведен отдельно (опять же внимательнее), 2. вы пробовали шринкать полутеррабайтные базы на системах 24х7? Занимательное однако занятие :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 17:36 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenСергей, речь не о 20, а о 2 млн, внимательнее плз To lura: 1. лог приведен отдельно (опять же внимательнее), 2. вы пробовали шринкать полутеррабайтные базы на системах 24х7? Занимательное однако занятие :) а действительно. прошу прощения теперь верю С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 18:03 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenСергей, речь не о 20, а о 2 млн, внимательнее плз To lura: 1. лог приведен отдельно (опять же внимательнее), 2. вы пробовали шринкать полутеррабайтные базы на системах 24х7? Занимательное однако занятие :) В таких случаях полгаюа делают shrink file. А кол-во файлов там наверняка больше чем 2. Не разумно в таком случае в одном файле хранить всю инфо :) В зависиомост от модели базы данных MSSQL FULL or Simple, shrink приводит к совершенно разным результатм. А шринкать в случае FULL обязательно надо, а то база будет разрастаться, не только от инсерт но и от delet & update. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 18:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ЛПИли, быть может, думают, что дерево в кеше - волшебное, самоперестраивающееся. Вот именно, самоперестраивающееся. При вставке в любое место дерева изменяется максимум несколько блоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 19:24 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
IuraВ зависиомост от модели базы данных MSSQL FULL or Simple, shrink приводит к совершенно разным результатм.Что значит "совершенно разные результаты" ? Можно подробнее ? IuraА шринкать в случае FULL обязательно надо, а то база будет разрастаться, не только от инсерт но и от delet & update.База будет "разрастаться" от delete ? Вы подразумеваете транзакционный лог ? А зачем "шринкать" ? Чтобы потом сервер опять корячился снова выделяя место под тот же самый лог ? В принципе, есть еще и другие способы создавать проблемы серверу и его пользователям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 19:25 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 LittleCat >>Вот именно, самоперестраивающееся. При вставке в любое место дерева изменяется максимум несколько блоков. Так там не В*-дерево ? А что тогда ? Ссылочку на алгоритм приведёте. Интересно посмотреть.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 19:59 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ChA IuraВ зависиомост от модели базы данных MSSQL FULL or Simple, shrink приводит к совершенно разным результатм.Что значит "совершенно разные результаты" ? Можно подробнее ? IuraА шринкать в случае FULL обязательно надо, а то база будет разрастаться, не только от инсерт но и от delet & update.База будет "разрастаться" от delete ? Вы подразумеваете транзакционный лог ? А зачем "шринкать" ? Чтобы потом сервер опять корячился снова выделяя место под тот же самый лог ? В принципе, есть еще и другие способы создавать проблемы серверу и его пользователям. На самом деле зависит от логики сервера. Как часто происходит delete & update & insert. Если очень часто, то помимо того, что у тебя лог файл разрастется и файл данных, когда ты будешь делать любые операции - у тебя в такой базе число операций поиска и чтения страниц с диска увеличится. Ведь на диске не все последоавтельно находится, и нужна инфа не в одной странице находится. А чтобы, сервер не мучался, ты делаешь shrink до задоного предела. Ты должен расчитать, сколько тебе нужно места в запасе на неделю и столько места хранить. А все лишнее чистить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 22:31 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
IuraНа самом деле зависит от логики сервера. Как часто происходит delete & update & insert. Если очень часто, то помимо того, что у тебя лог файл разрастется и файл данных, когда ты будешь делать любые операции - у тебя в такой базе число операций поиска и чтения страниц с диска увеличится. Ведь на диске не все последоавтельно находится, и нужна инфа не в одной странице находится. А чтобы, сервер не мучался, ты делаешь shrink до задоного предела. Ты должен расчитать, сколько тебе нужно места в запасе на неделю и столько места хранить. А все лишнее чистить.Если Вы считате, что ответили на прямо поставленные вопросы, то вынужден огорчить, это не так. Вы браво продолжаете изрекать банальности, не считая откровенного, очень мягко говоря, непонимания. Будьте любезны ответить на более простые вопросы. Какой у Вас опыт работы с MS SQL Server-ом ? А вообще опыт работы с СУБД ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2006, 23:12 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 23:20 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Iura На самом деле зависит от логики сервера. Как часто происходит delete & update & insert. Если очень часто, то помимо того, что у тебя лог файл разрастется и файл данных, когда ты будешь делать любые операции - у тебя в такой базе число операций поиска и чтения страниц с диска увеличится. Бред какой-то. Физически СКЛ сервер записи не удаляет, это неэффективно, только помечает как удаленные, поэтому размер базы при делитах не меняется. Я удивлюсь, если в КЕШ-е не аналогично. Если был делит, потом инсерт, то запись может попасть на место удаленной, размер базы не изменится. Поэтому файл не обязательно разрастается. Лог растет, но на то он и лог, туда пишется большинство операций и ничего само по себе не удаляется по определению. Правда не все операции пишутся в лог, truncate table, например, в АСА не пишется. Если Вы так озабочены размером лога, то его можно отключить, но делать это по понятным причинам не рекомендуется. Iura А чтобы, сервер не мучался, ты делаешь shrink до задоного предела. Ты должен расчитать, сколько тебе нужно места в запасе на неделю и столько места хранить. А все лишнее чистить. Чушь. Во-первых скорость работы сервера от размера файлов БД не зависит, поскольку, как Вы правильно сказали, информация на современных дисках хранится не последовательно. Поэтому ужимать файлы БД не обязательно, если есть место на диске. В утилитах АСА шринка по-моему вообще нет, по крайней мере у меня ни разу в жизни не возникала необходимость его использовать, при обычной работе пустых мест в файле БД не так много. Во-вторых база с необходимостью растет только при инсертах и отсутствии пустых мест в таблицах. Чудес же не бывает, нужно где-то хранить информацию. Или может КЕШ способен все на свете засунуть в пространство фиксированного размера, например в один байт? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 00:22 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
c127Кластерный индекс в данной ситуации совершенно не подходит, организовав кластерный индекс Вы сделали откровенную глупость. В этом нет ничего страшного, Вы же не администратор СКЛ серверов, но вот только нужно не выкручиваться, а признать это. вот я уж точно не администратор СКЛ серверов, а потому просто спрошу: может Вы мне подскажете как обойтись без организации "кластерных индексов" в таблице типа A B C D E F, где при выборке на любое поле может придти условие вида 1. VAL = x1,x2,x3... или 2. x1<VAL<x2 при количестве записей в таблице ~90 млн. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 03:06 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 Sergei Obrastsov При чем здесь кластерные индексы? Вы вообще понимаете о чем говорите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 03:33 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 Sergei Obrastsov При чем здесь кластерные индексы? Вы вообще понимаете о чем говорите? свихнешься тут с вами, все перепутал, sorry :) вопрос снимается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 04:18 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsovсвихнешься тут с вами Ну вот, мы еще и виноваты :) Sergei Obrastsovвсе перепутал, sorry :) Ничего, приходите еще :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 04:21 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Andreww Так там не В*-дерево ? А что тогда ? Ссылочку на алгоритм приведёте. Интересно посмотреть.... Вы правы, именно оно, родимое, там и есть :-) Ссылочку поищу, если не найду, попробую своими словами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 08:01 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
c127 Это понятно, когда ничего кроме кеша не знаешь, то кажется что все что есть в мире - взято из кеша. Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 08:04 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
LittleCat Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья) Спасибо, что не про РМД и (или) ООМД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 08:47 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 09:03 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Допустим, что реальный размер данных в базе - 100 мегов на дату и 50 мегов лог. Как я понимаю из обсуждения, многие участники считают, что производительность базы данных не будет отличатся между случаемя 1. Данные хранятся в 120 мегабайтном файле данный и 70 мегабайтном файле логов 2. Те же самые данные хранятся в 1 гигабайтном файле и 500 мегабайтном файле логов. Во втором случае база сами данные максимально разбросаны друг от друга по всему файлу. То есть в 1 и 2 случае производительность будет одинакова (софт и хард одинаков) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 09:09 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
http://www.optim.su/cs/2005/4/cache/cache.asp программы в CACHE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 09:47 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
LittleCat c127 Это понятно, когда ничего кроме кеша не знаешь, то кажется что все что есть в мире - взято из кеша. Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья) При чем тут "современные базы"? Уже в r-system были индексы для ускорения выполнения запросов. А то, что индексы имеют структуру B*-tree - так это самые удобные структуры. В м-технологии их тоже не от балды взяли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 09:57 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Самое сложное, что можно придумать в СУБД - это работа с ненаправленным/ненаправленным графом.(ИМХО конечно) Вот тут, именно на этой непростой задаче следовало бы проверить возможности и того и другого. Одна из задач - найти кратчайший (можно оптимальный) путь между двумя узлами чисто средствами СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 10:34 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Iura ... 1. Данные хранятся в 120 мегабайтном файле данный и 70 мегабайтном файле логов ... В логе данные не храняться А разница в производительности думаю будет небольшая(мое мнение, обосновать не могу - просто не с чего ей падать вроде) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 10:55 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 11:39 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 LittleCat >>Вы правы, именно оно, родимое, там и есть :-) Ссылочку поищу, если не найду, попробую своими словами. Можно своими, если там что-то интересное, будет сразу видно. Пока что было заявление - "Вот именно, самоперестраивающееся. При вставке в любое место дерева изменяется максимум несколько блоков." Говорит только о том, что либо в М(КАШЕ) какой-то НОВЫЙ и довольно сложный алгоритм, либо вы слабо владеете предметом, т.к. при вставке значительного числа элементов в B*дерево узлы будут быстро заполняться и часто требуется расшепление всех родительских вершин вплоть до корня,что в многопользовательской среде приводит к блокированию значительной части дерева (а никак не НЕСКОЛЬКИХ блоков), кроме того помимо расщепления есть ещё и слияние блоков (что бы не тратить зря место) тоже не самая быстрая операция. других алгоритмов я не знаю, потому и прошу поделиться. И кстати :) Индексы в виде B*-деревьев, существуют в Рел. системах от рождения (ещё от SYSTEM-R) :) Но это именно ИНДЕКСЫ, данные (как правило) хранятся в других структурах - почувствуйте разницу,все уже много лет как ушли от хранения ДАННЫХ в B*-дереве именно из-за того что поддерживать балланс в многопользовательской среде накладно и сложно,хотя для некоторых случаев можно и в B*-дереве хранить (в оракле например есть IOT про DB/2 MSSQL не знаю) и тут появляется М-технология и зовёт нас обратно в 70-е :) Странно, не находите ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 11:46 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SergSuper Iura ... 1. Данные хранятся в 120 мегабайтном файле данный и 70 мегабайтном файле логов ... В логе данные не храняться А разница в производительности думаю будет небольшая(мое мнение, обосновать не могу - просто не с чего ей падать вроде) Правильно. Это же журнал транзакций! Так кто нибудь пусть ответит на мой вопрос. Значит производительность никак не зависит от размера фалов и используемого пространства ? Например если размер файла будет 100 GB (data и столько же log) и при этом used space будет 0.1%, = производительность такойже базы данных, но с файлами размера (100 MB) и usage space 100% ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 13:43 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
mirRudolf Bayer, Binary B-Trees for Virtual Memory, ACM-SIGFIDET Workshop 1971, San Diego, California, Session 5B, p. 219-235. рыдалъ, спасиба ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 13:50 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
[quot Gluk (Kazan)рыдалъ, спасиба[/quot]? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 14:02 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
IuraЗначит производительность никак не зависит от размера фалов и используемого пространства ?Ответьте сами себе на вопрос, быстрее или медленнее вы будете работать с файлами, если у Вас HDD 1ГБ или 100ГБ ? Ни разу не замечали, что проблемы с производительностью начинаются, когда на HDD остается мало места, а не когда на диске его полным-полно ? А почему ? Может хватит фантазировать, а пора читать документацию и проводить эксперименты ? А то проект помрет не успев начаться или его отдадут другим :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 14:31 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
mir[quot Gluk (Kazan)рыдалъ, спасиба?[/quot] B-деревья в 60-х годах :) порадовало ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 14:53 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 15:15 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ChA IuraЗначит производительность никак не зависит от размера фалов и используемого пространства ?Ответьте сами себе на вопрос, быстрее или медленнее вы будете работать с файлами, если у Вас HDD 1ГБ или 100ГБ ? Ни разу не замечали, что проблемы с производительностью начинаются, когда на HDD остается мало места, а не когда на диске его полным-полно ? А почему ? Может хватит фантазировать, а пора читать документацию и проводить эксперименты ? А то проект помрет не успев начаться или его отдадут другим :) Вот именно почитай. Любая информация занимает место. Не важно она полезная или нет. Важно другое, когда ты начинаешь искать то что тебе нужно, тебе приходится просматривать и ненужную инфо тоже. Причем тем чаще, чем длинее файл. Индекс тебе указывает номер страницы в которой находится нужная информация, но не конкретный row И не тем более конкретный физический адрес на hard disk. Сервак полностью просматривает страницу на которую указывает индекс. Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию. Чтобы в самом индексе найти нужную конечну "ветку + лист" нужно немного потрудится. И чем длинее файл тем болеьше надо трудится. Ведь индекс в память полностью не загружается. Да возможно для того чтобы ему дойти до последней ветки нужно сделать не более 10-50 if, но эти же значения разбросанны на диске и причем не эффективно. Поэтому опять возникнет нагрузка на файл и диск. А если это многопользовательская система ? а если еще там isolations куча, тогда что. Так, что думай. Базы бывают разными и нагрузка на них бывает тоже разной. Если у тебя ьаза работает только на чтение, то сорри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 15:31 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres за счет чего кашэ быстрее или считается быстрее ? объясните пожалуйста теоретически - не должно практически - возможно за счет более простого механизма управления страницами (то есть меньше "накладные расходы") но разница не так уж велика ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 15:32 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 Iura ChA Вы браво продолжаете изрекать банальности, не считая откровенного, очень мягко говоря, непонимания. Будьте любезны ответить на более простые вопросы. Какой у Вас опыт работы с MS SQL Server-ом ? А вообще опыт работы с СУБД ? присоединяюсь Iura уволь сибя сам какую траву ты куришь поделись есть такой психологический тест "понимание при чтении" так вот даже и не пробуй его сдавать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 15:59 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 16:05 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
IuraЛюбая информация занимает место. Не важно она полезная или нет. Важно другое, когда ты начинаешь искать то что тебе нужно, тебе приходится просматривать и ненужную инфо тоже. Причем тем чаще, чем длинее файл. Индекс тебе указывает номер страницы в которой находится нужная информация, но не конкретный row И не тем более конкретный физический адрес на hard disk. Сервак полностью просматривает страницу на которую указывает индекс. Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию. Чтобы в самом индексе найти нужную конечну "ветку + лист" нужно немного потрудится. И чем длинее файл тем болеьше надо трудится. Ведь индекс в память полностью не загружается. Да возможно для того чтобы ему дойти до последней ветки нужно сделать не более 10-50 if, но эти же значения разбросанны на диске и причем не эффективно. Поэтому опять возникнет нагрузка на файл и диск. А если это многопользовательская система ? а если еще там isolations куча, тогда что. Уважаемый Iura. По вашему посту видно, что вы очень плохо знакомы с технологией организацией индексного поиска в БД. Советую некоторое время посвятить чтению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 16:09 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Andreww2 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.05.2006, 16:11 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
предыдущий слишком рано отправил перефразируя: только листы дерева хранят данные в этом разница с класическим В-деревом, где каждая вершина даже корневая хранит данные -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 16:17 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 pgres Понятно что не по одному и понятно что отсортированные. Но в случае IOT где же ДАННЫЕ (ACTUAL DATA ) храняться как не в листовых вершинах (index leave) B*-дерева ? По OTN выходит там, по вашему - "...в IOT не хранятся данные в В-дереве..." ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 16:17 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
IuraВот именно почитай.Читаю, Вы продолжаете нести бред, смешивая в кучу умные слова. Может пора остановиться и заняться делом ? Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 16:18 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 pgres Такая структура (данные только в листах) называется B+ или B* деревом, и именно она используется на практике, почему-то часто этот * или + опускают (я кстати стараюсь не опускать) видимо считая, что практически Bдерево может быть реализованно только как B+ :). Читайте внимательнее мой изначальный пост к lura (/topic/293038&pg=3#2673227) я в нём говорю про B*, а вы уже отвечаете про "...в IOT не хранятся данные в В-дереве...". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 16:29 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 16:37 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Iura уволь сибя сам какую траву ты куришь поделись есть такой психологический тест "понимание при чтении" так вот даже и не пробуй его сдавать Это все еще актуально 2 Andreww Я прошу прощения. буду знать -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 16:46 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
To lura: имхо вы несколько заблуждаетесь, например, есть первая страница хранения индекса, в конце нее стоит линк на следующую страницу, и так далее (при чем список двунаправлен), читать левые(чужие, пустые) страницы никто не будет вне зависимости от того сколько там их пустых. такая же штука с данными + имеются страницы, где хранится информация о том какие страницы свободны, а какие нет, на сколько заполнены эти страницы в дискретном процентном соотношении (0-50,51-80,81-95,96-100) вероятно такие фичи как упреждающее чтение и прочее влияют на процесс чтения при близком расположении нужных страниц, но это нужно тестировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 17:22 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Перечитал доку по новой. Признаю, в чем-то был не прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 17:59 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
AndrewwГоворит только о том, что либо в М(КАШЕ) какой-то НОВЫЙ и довольно сложный алгоритм, либо вы слабо владеете предметом, т.к. при вставке значительного числа элементов в B*дерево узлы будут быстро заполняться и часто требуется расшепление всех родительских вершин вплоть до корня,что в многопользовательской среде приводит к блокированию значительной части дерева (а никак не НЕСКОЛЬКИХ блоков), кроме того помимо расщепления есть ещё и слияние блоков (что бы не тратить зря место) тоже не самая быстрая операция. других алгоритмов я не знаю, потому и прошу поделиться. ну вот, например, физическая реализация хранения некоего двухуровневого массива ^X(i1,i2) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. разбиения заполненного блока и переноса части его содержимого, но принцип вообще-то такой. как мы видим, изменением затрагивается либо один блок, либо два блока + блок указателей. есть, конечно, вариант с уже полным блоком указателей. в этом случае процедура обработки нового блока повторяется на уровне указателей (намного реже чем для данных). при этом естественно происходит блокировка именно этих (и только этих блоков) модулем работы с БД. задачи работающие с ^X(555,500) или ^X(1) могут ожидать только освобождения блока #50, если уж они сами породили в процессе своей работы новый блок данных. И кстати :) Индексы в виде B*-деревьев, существуют в Рел. системах от рождения (ещё от SYSTEM-R) :) Но это именно ИНДЕКСЫ, данные (как правило) хранятся в других структурах - почувствуйте разницу,все уже много лет как ушли от хранения ДАННЫХ в B*-дереве именно из-за того что поддерживать балланс в многопользовательской среде накладно и сложно,хотя для некоторых случаев можно и в B*-дереве хранить (в оракле например есть IOT про DB/2 MSSQL не знаю) и тут появляется М-технология и зовёт нас обратно в 70-е :) Странно, не находите ? будьте так добры, напомните мне систему, в которой данные ранее хранились вместе с индексами, а потом, следуя оптимальным теориям были перемещены в отдельную структуру. я вообще-то вижу нечто обратное. вот тот же IOT, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 18:12 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
AndrewwТакая структура (данные только в листах) называется B+ или B* деревом Не "или", а просто B+. Причём в B+дереве листья ещё и связаны между собой. B* дерево - следующая модификация. Его особенность в улучшенном алгоритме вставки за счёт использования идеи "переливания" и сокращении количества делений узлов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 18:29 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 pavelp Конечно так, просто недоговорил. Хотел обратить внимание на то, что данные в листах в В+ ИЛИ В* деревьях, вроде нигде не говорил, что это одно и то же :( у В*, перелив иной, это факт и вроде как у В* листья тоже связаны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 18:38 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsovзадачи работающие с ^X(555,500) или ^X(1) могут ожидать только освобождения блока #50, если уж они сами породили в процессе своей работы новый блок данных. А если не породили, то не должны ждать? Что они будут делать, если в процессе работы других задач произойдёт деление блока #50 и увеличение уровня дерева? Разделяемая блокировка должна накладываться в любом случае. Кто-то кого-то да должен подождать :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 18:44 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pavelvp Sergei Obrastsovзадачи работающие с ^X(555,500) или ^X(1) могут ожидать только освобождения блока #50, если уж они сами породили в процессе своей работы новый блок данных. А если не породили, то не должны ждать? Что они будут делать, если в процессе работы других задач произойдёт деление блока #50 и увеличение уровня дерева? Разделяемая блокировка должна накладываться в любом случае. Кто-то кого-то да должен подождать :-) а кто спорит? только блокировка накладывается на затронутые изменением блоки, а не на все блоки подряд. когда изменится блок указателей, то его разблокировки будут ждать все те задачи, которые получают доступ к узлам, указанным в нем, но не к узлам, указанным в предыдущем или последующем блоке указателей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 18:52 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 Sergei Obrastsov Уффф. А надо ли комментировать...... Дерево с одним уровнем. Посмотрите внимательнее, блок указателей у вас "бесконечный" т.к. данных мноооого или мало, но это СПИСОК указателей ведь тоже надо хранить и скорее всего на диске (т.к. вы сами заранее разбили всё хранилище на блоки) ? Если вы настаиваете на блоке указателей ФИКСИРОВАННОГО размера (который растёт когда появляются новые блоки), то тогда БЛОКИ ДАННЫХ у вас быстро превращяются в связанные списки (т.к. вы сами заранее разбили всё хранилище на блоки) и, опять же, если данных мнооого списки будут длинююющие и поиск в них небыстрый (хотя в сортированных списках конечно искать легче, но при вставке придётся двигать). И чего вы добились, сохранив указатели в одном списке, а данные разбросав по блокам? Уменьшили время поиска в столько раз, сколько указателей помещается в список ? B*дерево решает проблемы поиска совсем по-другом (там размер блока фиксированный и число уровней переменное, но за это приходится платить расщеплением и слиянием). >>будьте так добры, напомните мне систему, в которой данные ранее хранились вместе с индексами, а потом, следуя оптимальным теориям были перемещены в отдельную структуру D3 от Rainingdata (ровесник МУ-МУ). Данные сначала хранились В ТОЧНОСТИ КАК ВЫ ОПИСАЛИ, даже размер списка указателей требует при создании ФАЙЛА, спустя некоторое время (не так давно) было добавленно отдельно живущее и автоматически поддерживаемое B*(или B+ не помню точно) дерево. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 19:12 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Andreww2 Sergei Obrastsov Уффф. А надо ли комментировать...... Дерево с одним уровнем. Ну зря Вы так, Сергей же просто пример привел, при разрастании дерева в М системах строится несколько уровней указателей. Размер блока указателей (да и вообще блока базы данных, с которым ведется операция как на диске, так и в кэше) является фиксированным (как впрочем и блока в котором хранятся данные). В ранних М системах этот размер был фиксированным (например в DSM-11 это был килобайт). С размером блока были связаны ограничений как на длину полной ссылки, так и на длину отдельного узла данных. С ростом потребностей (ну неудобно иметь длину локальной переменной в 32 кБ, а глобальной всего 511 байт или около того, сейчас не помню) разные производители внесли соответствующуе улучшения (в Cache блок базы сделали 8 кБ, в GT.M вообще этот параметр для базы сделали настраиваемым, можно для разных баз задать разный размер блока базы). Так что насчет уровней, торопиться не надо, тем более число индексов может быть до 63... PS. Блоки делятся на: Блок главного каталога, Блок указателей, Блок указателей на нижний уровень (т.е. на блоки данных), и собственно блоки данных. Ну это если вкратце... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 20:26 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
все РСУБД-шники - необразованные демагоги, это факт. Просто куда ни ткни. Очередной яркий пример от Andreww: И кстати :) Индексы в виде B*-деревьев, существуют в Рел. системах от рождения (ещё от SYSTEM-R) :) Но это именно ИНДЕКСЫ, данные (как правило) хранятся в других структурах - почувствуйте разницу,все уже много лет как ушли от хранения ДАННЫХ в B*-дереве именно из-за того что поддерживать балланс в многопользовательской среде накладно и сложно,хотя для некоторых случаев можно и в B*-дереве хранить (в оракле например есть IOT про DB/2 MSSQL не знаю) и тут появляется М-технология и зовёт нас обратно в 70-е :) Странно, не находите ? >>будьте так добры, напомните мне систему, в которой данные ранее хранились вместе с индексами, а потом, следуя оптимальным теориям были перемещены в отдельную структуру D3 от Rainingdata (ровесник МУ-МУ). Данные сначала хранились В ТОЧНОСТИ КАК ВЫ ОПИСАЛИ, даже размер списка указателей требует при создании ФАЙЛА, спустя некоторое время (не так давно) было добавленно отдельно живущее и автоматически поддерживаемое B*(или B+ не помню точно) дерево. ------------ Оказывается "все" это D3, и конечно же, ничего общего с mumps у D3 нет и не было (а если и есть, то то же самое общее, что и с Oracle и т.п.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 20:33 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Andreww Уффф. А надо ли комментировать...... Дерево с одним уровнем. не надо торопиться с выводами. во-первых, с двумя. во-вторых, дерево вида ^X(i1,i2,i3,i4,i5,i6,i7) ложится в такую же структуру Код: plaintext 1. 2. 3. 4. 5. и что это я все сбалансированные деревья рисую? вот так нагляднее? Код: plaintext 1. 2. 3. 4. 5. 6. 7. Посмотрите внимательнее, блок указателей у вас "бесконечный" т.к. данных мноооого или мало, но это СПИСОК указателей ведь тоже надо хранить и скорее всего на диске (т.к. вы сами заранее разбили всё хранилище на блоки) ? а разве я не упоминал про возможность заполнения блока указателей? конечно блок фиксирован размером, какой же это был бы иначе блок? сейчас, скажем, 8Kb (как и блок данных и прочие другие блоки). Если вы настаиваете на блоке указателей ФИКСИРОВАННОГО размера (который растёт когда появляются новые блоки), то тогда БЛОКИ ДАННЫХ у вас быстро превращяются в связанные списки (т.к. вы сами заранее разбили всё хранилище на блоки) и, опять же, если данных мнооого списки будут длинююющие и поиск в них небыстрый (хотя в сортированных списках конечно искать легче, но при вставке придётся двигать). а ведь очевидно, что поиск идет через блоки указателей, а не через всю цепочку блоков данных. или нет? блоки указателей тоже растут по мере роста блоков данных, хоть и не так быстро. вот скажем массив с 162 млн. узлов занимает 366,061 блоков данных, 515 блоков указателей 2-го уровня и один блок указателей 1-го уровня. (ага, все тот же, из сравнения) И чего вы добились, сохранив указатели в одном списке, а данные разбросав по блокам? Уменьшили время поиска в столько раз, сколько указателей помещается в список ? я вообще-то ничего не добивался, я просто показал как хранятся данные. в ответ на соответствующий вопрос. время поиска сокращается очень значительно, иначе бы эти структуры не использовались. и не только в M, ага. :) B*дерево решает проблемы поиска совсем по-другом (там размер блока фиксированный и число уровней переменное, но за это приходится платить расщеплением и слиянием). вот странно, а все полагают, что это оно и есть. D3 от Rainingdata (ровесник МУ-МУ). Данные сначала хранились В ТОЧНОСТИ КАК ВЫ ОПИСАЛИ, даже размер списка указателей требует при создании ФАЙЛА, спустя некоторое время (не так давно) было добавленно отдельно живущее и автоматически поддерживаемое B*(или B+ не помню точно) дерево. данные там и сейчас хранятся так же как и раньше, в итемах и файлах. и откуда, интересно, информация про "В ТОЧНОСТИ ТАК..."? раньше использовали hash-indexing, потом добавили B-tree, молодцы, растут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2006, 20:38 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 22:39 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
LittleCat c127 Это понятно, когда ничего кроме кеша не знаешь, то кажется что все что есть в мире - взято из кеша. Не все в мире взято из кеша, а просто современные базы данных пришли к тому, что в М технологиях существовало от их рождения, с далеких 60-х ;-) (Я про B* деревья) Деревья не изобретение КЕШ-а. Запатентуйте еще блок питания и постоянный ток. Данные в РСУБД (по-видимому это они понимаются под именем "современные базы данных") хранятся в таблицах, которые есть отношения. Как было у Кодда в самом начале, так и осталось, никто никуда не пришел. А индексы - это средство, вопрос удобства и вряд ли их взяли из КЕШ-а. Iura Вот именно почитай. Любая информация занимает место. Не важно она полезная или нет. Важно другое, когда ты начинаешь искать то что тебе нужно, тебе приходится просматривать и ненужную инфо тоже . Причем тем чаще, чем длинее файл. Не приходится. На устройстве прямого доступа можно перейти на заданный сектор (страницу) без прохода по промежуточным. Это Вы перепутали с ленточным устройством, которое последовательного доступа. Ненужные данные читаются всегда, существует минимальная порция считывания с диска, сектор по-моему, меньше него железо прочитать физически не в состоянии. Но ненужные сектора не читаются, даже если они принадлежат тому же файлу. Iura Так кто нибудь пусть ответит на мой вопрос. Значит производительность никак не зависит от размера фалов и используемого пространства ? Отвечаю: не зависит никак. Связи размера файла БД современного СКЛ сервера с производительностью нет. К тому же, повторяю еще раз, при обычной работе файлы растут не так быстро. Iura Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию. Не кучу, гораздо меньше чем данные, но безусловно занимают. А что, в КЕШ-е индексы места вообще не занимают? Иерархия деревьев в КЕШ-е тоже сложная. Мы выяснили в соседнем топике что в М, например, индексы отсутсвуют в принципе. Вместо них предлагается ДУБЛИРОВАТЬ ДАННЫЕ в деревья подходящей структуры. Вот это действительно КУЧА места. Место под индексы по сравнению с этим - детские шалости. IuraЧтобы в самом индексе найти нужную конечну "ветку + лист" нужно немного потрудится. И чем длинее файл тем болеьше надо трудится. Ведь индекс в память полностью не загружается. Да возможно для того чтобы ему дойти до последней ветки нужно сделать не более 10-50 if, Опять чепуха. Есть хеш индексы, поиск в них - константа, не зависит ни от чего, только от начальной конфигурации. Iuraно эти же значения разбросанны на диске и причем не эффективно. Как файл расположен на диске - проблема операционной системы. КЕШ ведь тоже не сама рассовывает файлы по секторам и дорожкам. Как показывает опыт ничего страшного на больших файлах не происходит. Кластерные индексы определенные не к месту убивают базу гораздо быстрее, чем размер файла. Не упорствуйте, чем дольше Вы пытаетесь выкрутиться, тем глубже закапываетесь и тем комичнее это выглядит. Признайте что ошиблись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 00:22 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 03:30 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
c127Деревья не изобретение КЕШ-а. Запатентуйте еще блок питания и постоянный ток. Данные в РСУБД (по-видимому это они понимаются под именем "современные базы данных") хранятся в таблицах, которые есть отношения. Как было у Кодда в самом начале, так и осталось, никто никуда не пришел. А индексы - это средство, вопрос удобства и вряд ли их взяли из КЕШ-а. Cache здесь, честно говоря, вообще не причем. речь идет о M-технологии. ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как видим, они оказались дальновидны. а ведь все очень просто, с большими объемами данных первыми столкнулись именно они. Не приходится. На устройстве прямого доступа можно перейти на заданный сектор (страницу) без прохода по промежуточным. Это Вы перепутали с ленточным устройством, которое последовательного доступа. Ненужные данные читаются всегда, существует минимальная порция считывания с диска, сектор по-моему, меньше него железо прочитать физически не в состоянии. Но ненужные сектора не читаются, даже если они принадлежат тому же файлу. приходится. над физическое размещение файла наложена его логическая структура, которая ну никак в секторы по 512 байт не укладывается. об этом Вам и говорят. вот тот же блок в 8Kb, например. Iura Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию. Не кучу, гораздо меньше чем данные, но безусловно занимают. А что, в КЕШ-е индексы места вообще не занимают? Иерархия деревьев в КЕШ-е тоже сложная. Мы выяснили в соседнем топике что в М, например, индексы отсутсвуют в принципе. Вместо них предлагается ДУБЛИРОВАТЬ ДАННЫЕ в деревья подходящей структуры. Вот это действительно КУЧА места. Место под индексы по сравнению с этим - детские шалости. как мы уже заметили в "соседнем топике", наличие этого дублирования почему-то не занимает КУЧУ места, а занимает объем гораздо меньший, чем прекрасно организованные индексы в SQL. можем повторить опыт, если есть желание. :) IuraЧтобы в самом индексе найти нужную конечну "ветку + лист" нужно немного потрудится. И чем длинее файл тем болеьше надо трудится. Ведь индекс в память полностью не загружается. Да возможно для того чтобы ему дойти до последней ветки нужно сделать не более 10-50 if, Опять чепуха. Есть хеш индексы, поиск в них - константа, не зависит ни от чего, только от начальной конфигурации. ну да, головки ведь у дисков мгновенного действия, позиционирования нынче не существует, индексный файл прекрасно влезает в память... Как файл расположен на диске - проблема операционной системы. КЕШ ведь тоже не сама рассовывает файлы по секторам и дорожкам. Как показывает опыт ничего страшного на больших файлах не происходит. Кластерные индексы определенные не к месту убивают базу гораздо быстрее, чем размер файла. "операционной системе" пофигу сколько времени нужно задаче на собирание вместе кусков файла БД. а вот задаче - нет. дефрагментация всегда давала выигрыш в скорости, дает и сейчас, даже при наличии "супер-файловых" систем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 03:58 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
to Andreww & c127 Ребята, вы что-то заговариваться стали... to Sergei Obrastsov может и нет там ограничений вовсе? нет, ограничение конечно есть - 32Tb на размер БД, то есть блок в БД адресуется 4-мя байтами. и все это укладывается в 3 уровня (2 уровня указателей и уровень данных). Никак не может такого быть. Страница 8К, следовательно порядок дерева около 500 (реально возможно и меньше). Дерево такого порядка при размере 32Т будет, как минимум, 4-х уровневое. А то и пяти... я вот вижу, что B-дерево увидели только в способе хранения. а то, что хранится тоже дерево - нет. В-дереву по барабану что в нём хранят :-) Точно такой же индекс можно и в реляционке организовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 13:05 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pavelvp to Sergei Obrastsov может и нет там ограничений вовсе? нет, ограничение конечно есть - 32Tb на размер БД, то есть блок в БД адресуется 4-мя байтами. и все это укладывается в 3 уровня (2 уровня указателей и уровень данных). Никак не может такого быть. Страница 8К, следовательно порядок дерева около 500 (реально возможно и меньше). Дерево такого порядка при размере 32Т будет, как минимум, 4-х уровневое. А то и пяти... нет фактических типов промежуточных блоков указателей, только TOP и BOTTOM. впрочем, может они ими извращаются? не знаю, как только найду такую базу - сразу посмотрю. pavelvp я вот вижу, что B-дерево увидели только в способе хранения. а то, что хранится тоже дерево - нет. В-дереву по барабану что в нём хранят :-) Точно такой же индекс можно и в реляционке организовать. правильно, по барабану. но мне-то нет. :) это не индекс, это ВСЯ структура. C уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 13:35 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 14:20 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsovнет фактических типов промежуточных блоков указателей, только TOP и BOTTOM. впрочем, может они ими извращаются? Да причём тут типы. Их то как раз два - узлы и листья :-) С 8-ми килобайтной страницей никак такое дерево не влезет в три уровня... Sergei Obrastsovправильно, по барабану. но мне-то нет. :) это не индекс, это ВСЯ структура. Да какая разница!? Точно такую же логическую структуру хранения данных в виде дерева, или как вы их назваете красиво - многомерные разреженные массивы :-), можно хранить и в реляционке (в любой РСУБД). Физически будет отличаться только тем, что данные в узлах лежат отдельно от индексов. Логически - ничем абсолютно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 14:29 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
А вот кстати вопрос кешевцам. Как уже вами не раз упомяналось типизации нет, числа хранятся строчками и следовательно "2" будет больше чем "111". Значит ли это что фактически для чисел можно использовать только запросы где есть точное сравнение? Т.е. запросы типа i between 2 and 111 или просто i>2 использовать нельзя Если я не прав то объясните как это решается Имеется ввиду конечно использование индексного поиска ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 16:01 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SergSuperА вот кстати вопрос кешевцам. Как уже вами не раз упомяналось типизации нет, числа хранятся строчками и следовательно "2" будет больше чем "111". нет, если речь идет об индексе. если его можно интерпретировать в число без потери символов, то он и запишется как число. это для правильной сортировки, то есть цифровой, она же дефолтная. чтобы было наоборот нужно указывать "строковую" сортировку для массива. Значит ли это что фактически для чисел можно использовать только запросы где есть точное сравнение? Т.е. запросы типа i between 2 and 111 или просто i>2 использовать нельзя Если я не прав то объясните как это решается Имеется ввиду конечно использование индексного поиска надо полагать вопрос к народу, занимающемуся Cache-SQL? я работаю с массивами напрямую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 16:16 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsovнадо полагать вопрос к народу, занимающемуся Cache-SQL? я работаю с массивами напрямую. причём здесь SQL... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 16:22 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SergSuperКак уже вами не раз упомяналось типизации нет, числа хранятся строчками и следовательно "2" будет больше чем "111". По стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111". Имплементации мампса могут поддерживать (дополнительно) задание других соглашений, в частности строковой безотносительно содержания. В ней "2" пойдет после "111". По умолчанию сортировка индексная. Код: plaintext 1. 2. 3. 4. SergSuperЗначит ли это что фактически для чисел можно использовать только запросы где есть точное сравнение? Т.е. запросы типа i between 2 and 111 или просто i>2 использовать нельзя Если я не прав то объясните как это решается Имеется ввиду конечно использование индексного поиска Код: plaintext Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 16:27 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pavelvp Sergei Obrastsovнадо полагать вопрос к народу, занимающемуся Cache-SQL? я работаю с массивами напрямую. причём здесь SQL... а причем тут "запросы типа i between 2 and 111 или просто i>2"? впрочем ладно, может я просто неправильно воспринимаю. но я все-равно ответил, числа отсортируются правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 16:33 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ну яUSER>s i=2 f s i=$o(a(i)) q:(i="")!'(111]]i) w i,! 3 34 [/src] а зачем так мудрить "'(111]i)"? не проще написать i>111, все-равно ведь известно, что там числа? :) С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 16:37 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 17:16 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ну яПо стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111". Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться? Если типизации нет, и все хранится как строки, то как он отличает строку "111" от строкового представления числа 111? Или никак не отличает, а просто сортирует строки "неправильно"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 17:23 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Т.е. если есть набор строк: Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 17:37 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох ну яПо стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111". Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться? Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом. Пьяный ЛохЕсли типизации нет, и все хранится как строки, то как он отличает строку "111" от строкового представления числа 111? Или никак не отличает, а просто сортирует строки "неправильно"? Есть детальное описание (в стандарте) того, что называется каноническим представлением числа. Полное определение довольно длинное, не буду приводить. Например "2" это число, а "2.00" или "2." это уже строки. Речь идет именно о каноническом представлении чисел для индексной сортировки, ни о чем другом. Если работать с мампсом, то путаницы обычно ни у кого не возникает более одного раза ))). Выяснить что из себя есть каноническое и неканоническое представление можно через операцию +: значение переменной str есть каноническое представление числа если +str=str. Исключения и нюансы - с плавающей точкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 17:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохТ.е. если есть набор строк: Код: plaintext 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. 5. при числовой сортировке именно так. есть правда маленькая деталь, а нафига совать в индекс разные логические типы данных? там где нужны числа у меня будут числа, а там где строки - строки С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 17:52 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 ну я Пьяный Лох ну яПо стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111". Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться? Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом. Оп-ля... Это как это - "приписать пробел"? У меня строка безо всякого пробела в начале, однако. С какой радости я её модифицировать должен? ----------- 2 Sergei Obrastsov при числовой сортировке именно так. есть правда маленькая деталь, а нафига совать в индекс разные логические типы данных? там где нужны числа у меня будут числа, а там где строки - строки Нафига? Не знаю... А нафига отсутствие типизации сделали? Значит это кому-нибудь нужно? Если это кому-нибудь нужно - наверное и работать с этим кому-нибудь приходится? Были бы типы данных - не было бы таких вопросов. Поле числового типа сортировалось бы как набор чисел, и строку туда нельзя было бы записать, а в поле строкового типа можно было бы записать любую строку (хоть бы даже и содержащую "каноническое представление числа"), и сортировалось бы это как набор строк. А так получается, что я могу записать в одно и то же поле и "строки", и "числа" (и это действительно иногда нужно). И если "строковое" подмножество содержит что-то, по несчастливой случайности совпадающее по внешнему виду с "каноническим представлением числа" - то отсортировать корректно полученное множество уже никак не получится, патамушта либо часть "строк" уедет в область "чисел" (при "числовой" сортировке), либо "числа" будут сортироваться как "строки" (при выставленном ascii collation'е для глобали). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:08 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 ну я Пьяный Лох ну яПо стандарту если строки являются представлениями чисел то в индексном сравнении они сравниваются как числа, поэтому в индексе "2" сортируется перед "111". Стоп. А если это должны быть все-таки строки? Все равно как числа будут сортироваться? Если сортировка должна быть как строк, то нужно выставлять глобали ascii collation если его поддерживает имплементация либо насильно приводить строку к виду, не представляющему число, например приписать спереди пробел. Обычно для переносимости пользуются вторым вариантом. Оп-ля... Это как это - "приписать пробел"? У меня строка безо всякого пробела в начале, однако. С какой радости я её модифицировать должен? Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь. А про радость не могу ничего сказать - это нетехнический вопрос. Пока не вижу чего тут пугаться или радоваться - соглашение о правиле индексной сортировке на редкость практичное. Если бы в мампсе была типизация - то мы бы зашились с этими типами. Есть куча систем которые должны быть по своему устройству (как следствие их назначения) непрерывно изменяемы. В первую очередь бизнес-ориентированные. Если нам еще и типами заниматься - зашились бы точно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:23 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохБыли бы типы данных - не было бы таких вопросов. Поле числового типа сортировалось бы как набор чисел, и строку туда нельзя было бы записать, а в поле строкового типа можно было бы записать любую строку (хоть бы даже и содержащую "каноническое представление числа"), и сортировалось бы это как набор строк. интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :) и зачем вот это "нельзя записать"? я сам строю БД и решаю куда что писать. А так получается, что я могу записать в одно и то же поле и "строки", и "числа" (и это действительно иногда нужно). И если "строковое" подмножество содержит что-то, по несчастливой случайности совпадающее по внешнему виду с "каноническим представлением числа" - то отсортировать корректно полученное множество уже никак не получится, патамушта либо часть "строк" уедет в область "чисел" (при "числовой" сортировке), либо "числа" будут сортироваться как "строки" (при выставленном ascii collation'е для глобали). можно пример такой необходимости, что-то я навскидку ничего представить не могу? ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я". только это не операция на уровне "послать запрос 2<i<111 и получить список" это несколько другой уровень абстракции С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:37 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 ну я Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь. Т.е. все строки - с пробелом в начале? И тогда уж не "первый символ отбрасываешь", а "первый символ анализируешь, если пробел - отбрасываешь"? Если бы в мампсе была типизация - то мы бы зашились с этими типами. Есть куча систем которые должны быть по своему устройству (как следствие их назначения) непрерывно изменяемы. В первую очередь бизнес-ориентированные. Если нам еще и типами заниматься - зашились бы точно. Да ладно Вам. Я даже не буду спорить с тем, что иногда сильная типизация хуже, чем слабая (но только иногда, имхо). Речь не про то. Если уж система расчитана на слабую типизацию - кто мешает факт наличия этой самой слабой типизации унутре себя учесть? Хранили бы в месте со значением переменной еще один байт - "тип", не имели бы проблем с определением этого самого типа. Собственно предложенное решение ("при записи конкатенируешь с пробелом, при чтении пробел выкидываешь") и есть та самая информация о типе значения. Тока почему-то не на уровне системы, а ручками делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:39 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 Sergei Obrastsov интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :) Кто мешает-то? В чем проблема отсортировать по разному? По-моему проблемы с сортировкой нет, более того, в вашем М именно по разному и сортируется - числа одним способом, строки другим, между собой еще как-то. Только у вас проблема с невозможностью определения типа для некоторых значений. можно пример такой необходимости, что-то я навскидку ничего представить не могу? Это мумпсисты должны примеры приводить, когда необходимо в одном поле хранить разнотипные переменные. Все ж из их лагеря раздаются крики о том, что слабая типизация это хорошо, и без этого "зашились бы". Если бы такой необходимости не было бы - то и хранили бы себе в одном поле значения строго одного типа, и не вносили бы в стандарты способов "индексного сравнения чисел со строками". ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я". Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. Так что не четко проверяются. Можно лишь четко определить случай, когда строка НЕ является строковым представлением числа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:51 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 ну я Перед записью берешь и пишешь используя не твое значение а конкатенацию его с пробелом спереди. При получении значения из индекса первый символ отбрасываешь. Т.е. все строки - с пробелом в начале? И тогда уж не "первый символ отбрасываешь", а "первый символ анализируешь, если пробел - отбрасываешь"? ))) Я, конечно, понимаю, что хочется повыделываться, но это неверное правило. Если вам придется работать с мампсом, вы сами себя переубедите, на простых контрольных примерах. А если не придется - то не берите в голову. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ну яэто неверное правило. Тогда какое верное? Не всем строкам пробел спереди приписывать? А каким? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:58 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Если вам придется работать с мампсом не дай бог :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 18:58 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохЭто мумпсисты должны примеры приводить, когда необходимо в одном поле хранить разнотипные переменные. Все ж из их лагеря раздаются крики о том, что слабая типизация это хорошо, и без этого "зашились бы". Гнать не нужно. Никто вам ничего не должен, не выдумывайте. И криков никаких нет и лагеря никакого нет. Пьяный ЛохЯ Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. А зачем это может понадобиться? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Вот для чего это необходимо, хотелось бы понять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 19:04 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох ну яэто неверное правило. Тогда какое верное? Не всем строкам пробел спереди приписывать? А каким? Быстрый вопрос - проявление нежелания подумать даже немного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 19:07 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 Sergei Obrastsov интересно, как будет выглядеть массив, где все индексы рассортированы по разным принципам? :) Кто мешает-то? В чем проблема отсортировать по разному? По-моему проблемы с сортировкой нет, более того, в вашем М именно по разному и сортируется - числа одним способом, строки другим, между собой еще как-то. Только у вас проблема с невозможностью определения типа для некоторых значений. а зачем мне это может понадобиться-то? за кучу лет я сортировал индексы строковым способом только один раз, это помогло значительно уменьшить скорость поиска. но это была очень хитрая структура. сортируется вообще-то в М все одинаково (в цифровой сортировке), но для хитрожопых дается еще и строковая (раз уж приперло, как скажем меня). но правило распространяется на весь массив, а не на отдельный уровень. можно пример такой необходимости, что-то я навскидку ничего представить не могу? Это мумпсисты должны примеры приводить, когда необходимо в одном поле хранить разнотипные переменные. ну вот он я, "мумпсист", и я спрашиваю - "нафига"? у меня никогда не было такой необходимости. а если уж в индекс попадают строки вперемежку с числами, значит это не числа, а просто строки из цифровых символов. и абсолютно все-равно как они там хранятся. ну, так не бывает, чтобы нельзя было отсортировать. числа четко проверяются на принцип "str=+str", как справедливо заметил "ну я". Я Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. Так что не четко проверяются. Можно лишь четко определить случай, когда строка НЕ является строковым представлением числа. я прошу прощения, конечно, но я не вижу разницы между 111 и "111": Код: plaintext 1. 2. учту при выводе, раз уж так кому-то захотелось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 19:10 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ну я Пьяный ЛохЯ Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. А зачем это может понадобиться? Код: plaintext 1. 2. А что, такого не может быть: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 19:10 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
в общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное. не видите разницу между "111" и 111 - говорить наверное больше не о чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 19:14 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох ну я Пьяный ЛохЯ Вам еще раз повторяю - таким образом вы не отличите строку "111" от строкового представления числа 111. А зачем это может понадобиться? Код: plaintext 1. 2. А что, такого не может быть: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Нет, первых три случая не может быть. Четвертый должен быть. Если нужна конкатенация - то ее и нужно использовать. Обозначается подчеркиванием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 19:17 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ну яНет, первых три случая не может быть. Четвертый должен быть. Если нужна конкатенация - то ее и нужно использовать. Обозначается подчеркиванием. Ок. Это, видимо, вопрос синтаксиса. Что вернется в результате такой операции: Код: plaintext Т.е. операция "+" перегружена (в зависимости от типов операндов), или четко и строго является арифметическим сложением двух чисел (и ничем другим являться не может)? Я, пардон, синтаксиса мумпса не знаю, потому и спрашиваю. Можно в какой-нибудь онлайн хелп послать, не обижусь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 20:25 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохЧто вернется в результате такой операции: Код: plaintext Т.е. операция "+" перегружена (в зависимости от типов операндов), или четко и строго является арифметическим сложением двух чисел (и ничем другим являться не может)? + это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. тынц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 21:12 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ну я+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. USER>w +"123" USER>w +"0123" USER>w +"00000123" выдадут одинаковый результат? если да, то считаются ли эти строки ("123", "0123" и "00000123") равными? в частности при записи в эту... как её... в глобаль? Документация ставится при установке, также есть онлайн тынц сенкс, на досуге поизучаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 21:26 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох ну я+ это арифметическая операция. Аргументы приводятся к числу. Из строки берется первая часть подходящая под число, остальное отбрасывается. Если не подошло ни одного символа то 0. В приведенном случае будет 0. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. USER>w +"123" USER>w +"0123" USER>w +"00000123" выдадут одинаковый результат? Да. Пьяный Лохесли да, то считаются ли эти строки ("123", "0123" и "00000123") равными? в частности при записи в эту... как её... в глобаль? Нет, лидирующий ноль - неканоничен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2006, 22:43 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лохв общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное. не видите разницу между "111" и 111 - говорить наверное больше не о чем. А ведь есть еще даты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 00:29 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
c127 Пьяный Лохв общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное. не видите разницу между "111" и 111 - говорить наверное больше не о чем. А ведь есть еще даты. не будем о грустном ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 00:40 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох c127 Пьяный Лохв общем ладно, рассказывать людям, что число это число, а строка это строка - занятие неблагодарное. не видите разницу между "111" и 111 - говорить наверное больше не о чем. А ведь есть еще даты. не будем о грустном а что с ними такого страшного? нет, конечно, можно и хранить их в виде dd.mm.gggg, но это неудобно. обычно пользуются их машинным форматом, т.е. 19.05.2006 = 60404. аналогично для времени ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 01:13 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov c127Деревья не изобретение КЕШ-а. Запатентуйте еще блок питания и постоянный ток. Данные в РСУБД (по-видимому это они понимаются под именем "современные базы данных") хранятся в таблицах, которые есть отношения. Как было у Кодда в самом начале, так и осталось, никто никуда не пришел. А индексы - это средство, вопрос удобства и вряд ли их взяли из КЕШ-а. Cache здесь, честно говоря, вообще не причем. речь идет о M-технологии. Речь идет как раз о КЕШ-е, которая, если не ошибаюсь, построена на М. Sergei Obrastsov ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как видим, они оказались дальновидны. а ведь все очень просто, с большими объемами данных первыми столкнулись именно они. Как же, знаем, они также первыми высадились на берега Америки, еще до викингов. А ссылочку не приведете на большие объемы данных? Sergei Obrastsov Не приходится. На устройстве прямого доступа можно перейти на заданный сектор (страницу) без прохода по промежуточным. Это Вы перепутали с ленточным устройством, которое последовательного доступа. Ненужные данные читаются всегда, существует минимальная порция считывания с диска, сектор по-моему, меньше него железо прочитать физически не в состоянии. Но ненужные сектора не читаются, даже если они принадлежат тому же файлу. приходится. над физическое размещение файла наложена его логическая структура, которая ну никак в секторы по 512 байт не укладывается. об этом Вам и говорят. вот тот же блок в 8Kb, например. Что Вы знаете о физической структуре файла данных СКЛ сервера? Наверняка же ничего не знаете. Я тоже почти ничего не знаю, но это же совершенно очевидно, что файл подряд с самого начала каждый раз не читается. Сервер знает где у него лежат таблицы, где индексы, если нужен индекс читается только он и то не целиком, таблица тоже, только то что нужно, остальное не читается. Ну какая разница, сколько занимает файл? Абсолютно то же самое, как если бы все индексы и таблицы были сложены в отдельные файлы. Кстати так тоже можно, но никто этого не делает, потому что никакого выигрыша в скорости нет. Sergei Obrastsov Iura Дополнительно. Сами индексы занимают кчу места и имеют сложную иерархию. Не кучу, гораздо меньше чем данные, но безусловно занимают. А что, в КЕШ-е индексы места вообще не занимают? Иерархия деревьев в КЕШ-е тоже сложная. Мы выяснили в соседнем топике что в М, например, индексы отсутсвуют в принципе. Вместо них предлагается ДУБЛИРОВАТЬ ДАННЫЕ в деревья подходящей структуры. Вот это действительно КУЧА места. Место под индексы по сравнению с этим - детские шалости. как мы уже заметили в "соседнем топике", наличие этого дублирования почему-то не занимает КУЧУ места, а занимает объем гораздо меньший, чем прекрасно организованные индексы в SQL. можем повторить опыт, если есть желание. :) Мы этого к сожалению не заметили. Приведите ссылку, где это обсуждалось и где выяснилось, что так называемые индексы в М не занимают кучу места. Дублирование данных (индексирование по-Вашему) обсуждалось тут: /topic/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.05.2006, 01:45 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
интересно... математика на нетипизированных значениях (типа все строки). 1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится? 2. Если для всех математических вычислений приходится производить конвертацию каждого аргумента к числовому виду (если это возможно, конечно), то вряд ли можно получить выигрыш по скорости. 3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 02:22 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
AAronматематика на нетипизированных значениях (типа все строки). 1. "1" / "3" это сколько? Это с плавающей точкой, до какого знака и как хранится? .3333333333333333333 так и хранится, как строка. если тебя интересует как это обрабатывает модуль вычислений - понятия не имею. 2. Если для всех математических вычислений приходится производить конвертацию каждого аргумента к числовому виду (если это возможно, конечно), то вряд ли можно получить выигрыш по скорости. по сравнению с компилятором? конечно же нет. а никто и не утверждал обратного. 3. байтовое представление числа 255 - 0x323535. То же самое представление типизированного числа (byte) - 0xFF. Разница в объемах - в три раза. Хотя может там упакованый формат? все равно он больше размером. как после этого можно говорить о выигрыше М перед другими в объемах данных? в 3. нет. но упаковывать можно, если уж так хочется, есть соответствующие функции. может в базах данных хранятся, в основном, не числа? С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 02:33 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 03:01 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
в 3. нет. но упаковывать можно, если уж так хочется, есть соответствующие функции. может в базах данных хранятся, в основном, не числа? С уважением. Сергей А что по вашему в основном храниться в БД строки ? Большенство баз в мире имеет отношение к финансовой и производственной деятельности. В них храняться показатели данных сфер деятельности (деньги, количество). Имено с ними и приходиться выполнять такие операции как например суммирование или сложение и вычитание. При больших объемах данных перевод строк в числа и обратно процедура настолько затратная что обещание фантастических скоростей при использовании MUMPS сомнительно. Что в общем то и подтвердилось у нас. Скорость расчетов на M ситеме оказалась намного меньше чем в том же ORACLE. Чудес не бывает. Не может тот же PHP (который так же использует нетипизированные пременные и является как и MUMPS интерпритатором обогнать в скорости вычислений программу на С). Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 03:15 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как видим, они оказались дальновидны. а ведь все очень просто, с большими объемами данных первыми столкнулись именно они. Как же, знаем, они также первыми высадились на берега Америки, еще до викингов. А ссылочку не приведете на большие объемы данных? а сами объемы не нужно привести? Mumps создавался для системы здравоохранения, по-моему можно прикинуть количество данных, которые там крутятся (если честно, я притомился искать в инете конкретные цифры) Что Вы знаете о физической структуре файла данных СКЛ сервера? Наверняка же ничего не знаете. Я тоже почти ничего не знаю, но это же совершенно очевидно, что файл подряд с самого начала каждый раз не читается. Сервер знает где у него лежат таблицы, где индексы, если нужен индекс читается только он и то не целиком, таблица тоже, только то что нужно, остальное не читается. Ну какая разница, сколько занимает файл? Абсолютно то же самое, как если бы все индексы и таблицы были сложены в отдельные файлы. Кстати так тоже можно, но никто этого не делает, потому что никакого выигрыша в скорости нет. а разве я говорил про полное чтение файла? речь, скажем, о чтении индексного дерева, которое явно читается не по секторам. как мы уже заметили в "соседнем топике", наличие этого дублирования почему-то не занимает КУЧУ места, а занимает объем гораздо меньший, чем прекрасно организованные индексы в SQL. можем повторить опыт, если есть желание. :) Мы этого к сожалению не заметили. Приведите ссылку, где это обсуждалось и где выяснилось, что так называемые индексы в М не занимают кучу места. Дублирование данных (индексирование по-Вашему) обсуждалось тут: /topic/54920&pg=12#2406070 от слов "В предположении, что индекса по пассажирам нет" и дальше по топику /topic/288398&pg=4#2628282 /topic/288398&pg=5#2629383 еще раз скажу, что сравнивалась SQL (MySQL, MSSQL) таблица с одним индексом и Cache-структура с 9-ю. Опыт повторить - никаких проблем, я только за, а то я уже устал предлаготь провести хоть какие-нибудь тесты. Только я не очень понимаю о каком именно опыте идет речь. Приведите ссылку, чтобы не быть голосовным. я только ЗА. ссылки приведены. Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся. я бы рад избавиться, но пока приходится дефрагментировать. не часто и все же. про ext2 ничего не скажу, мне приходится работать под Windows ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 03:51 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 04:09 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Joker_YaА что по вашему в основном храниться в БД строки ? Большенство баз в мире имеет отношение к финансовой и производственной деятельности. В них храняться показатели данных сфер деятельности (деньги, количество). Имено с ними и приходиться выполнять такие операции как например суммирование или сложение и вычитание. При больших объемах данных перевод строк в числа и обратно процедура настолько затратная что обещание фантастических скоростей при использовании MUMPS сомнительно. Что в общем то и подтвердилось у нас. Скорость расчетов на M ситеме оказалась намного меньше чем в том же ORACLE. красиво звучит, но хотелось бы увидеть конкретные цифры. затраты есть, спорить не буду. в больших математических расчетах M проигрывает специализированным приложениям. но не проиграет СУБД, которые под это дело тоже не заточены. значит речь о другом. о неправильной организации данных, о неумелых выборках и прочем. я ведь могу залить в бак "болида" воду и сказать "херня эта ваша гоночная машина, мой велосипед быстрее!" :) Чудес не бывает. Не может тот же PHP (который так же использует нетипизированные пременные и является как и MUMPS интерпритатором обогнать в скорости вычислений программу на С). однозначно не может. а он что, пытался? Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз. я просто привык верить собственным глазам и рукам, так что знаю о чем говорю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 04:20 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз. я просто привык верить собственным глазам и рукам, так что знаю о чем говорю.[/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.05.2006, 09:04 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov в больших математических расчетах M проигрывает специализированным приложениям. но не проиграет СУБД, которые под это дело тоже не заточены. Так во-первых, чаще всего СУБД именно заточены для работы с разными языками (БД в общем случае предназначена для многих приложений и стало быть на разных языках). И потому в паре в такими языками имеют преимущество перед языком М по обоими направлениям. По вычислениям специализрованные приложения, по хранению и обработке СУБД тоже как спекциализированная на БД. Во-вторых, для некоторых специализированных приложений, например, ОЛАП и Датамайнинг СУБД могут иметь дополнительные специализированные возможности (в виде дополнительных опций) - поддерживать Движки для соответсвующих вычислений , напрмер, прогнозирования, распределения и проч. Я уже пытался сказать об этом. Вы теперь сами почти пришли к этому - кооперация из специализированных часто лучше чего-то одного универсального. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 09:35 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Joker_YaЕсть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные ... Оракл потому что система на М просто не справлялась. Жду от вас результатов тестирования на подобном обеме. Тесты на таблице из 100 записей не состоятельны для серьезных систем. Видимо поэтому ни одна из М систем не представлена независимых тестах TCP. хороший тест. а про "железо" можно что-нибудь услышать, чтобы я имел представление с чем идет сравнение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 10:22 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 12:16 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov да, конечно, я тоже вот вспомнил последнюю базу по телефонным звонкам - одни числа. и все же, разница в объемах есть. а когда в дело вступают индексы, то разница становится очень большой. И все-таки, я не понимаю, как индексы могут помочь уменьшить объем фактических данных. Если есть такие факты: "Маша", "Даша", "Саша", "Паша", "Глаша" и т.п. как не строй индекс - все равно эти строки останутся. Точно так же и в том же телекоме - если есть продолжительность звонка, то никуда от нее не избавится. Да еще если хранить эту продолжительность в виде строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 12:51 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Вот и я стал уже кое что понимать каше. Конечно сжатие данных это круто, но того же самого можно добиться в оракле на индексном кластере. Однако он бычно применяется для нескольких таблиц для ускорения джоинов. Однако только то что данные занимают меньше места не очень серьезный плюс. Винты сейчас большие и дешевые. Есть ли еще что нибудь в каше изза чего на него стоит смотреть? Пока видны такие минусы: - специалистов по каше мало и они малоподвижы - распростанена система слабо поэтому найти работу с применением знаний по каше будет сложно, похожих применяемых систем я тоже не знаю, так что нельзя как в рсубд - знаешь sql знаешь как работает версионник а как блокировочник и все на любом движке можно работать - строгой математической теории, такой как под рсубд без белых пятен и простым решением любой проблемы, под каше нету (только не надо заваливать ссылками, я же сказал без белых пятен, где ясно абсолютно все) - по скорости работает также как и все остальное -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 12:52 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Joker_YaЕсть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные еще один вопрос: а эти данные нужно получить на всей таблице или только на выборке за 1 месяц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 12:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
AAronИ все-таки, я не понимаю, как индексы могут помочь уменьшить объем фактических данных. Если есть такие факты: "Маша", "Даша", "Саша", "Паша", "Глаша" и т.п. как не строй индекс - все равно эти строки останутся. Точно так же и в том же телекоме - если есть продолжительность звонка, то никуда от нее не избавится. Да еще если хранить эту продолжительность в виде строки. вот ведь. разве я такое говорил? конечно, меньший объем вряд ли получится, только за счет сжатия данных, а это чревато нагрузкой при выборке. но вот объем БД вместе с индексами будет меньше чем у других СУБД на этих же данных и с такой же индексацией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 13:00 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgresВот и я стал уже кое что понимать каше. Конечно сжатие данных это круто, но того же самого можно добиться в оракле на индексном кластере. Однако он бычно применяется для нескольких таблиц для ускорения джоинов. было бы интересно посмотреть на результаты "того же самого можно добиться". pgres Однако только то что данные занимают меньше места не очень серьезный плюс. Винты сейчас большие и дешевые. а вот это аргумент хороший. правда данные тоже растут в геометрической прогрессии. но, как говорится, на наш век винтов хватит, а там наплевать. pgres Есть ли еще что нибудь в каше изза чего на него стоит смотреть? Пока видны такие минусы: - специалистов по каше мало и они малоподвижы yeees! правильно, но они уже есть. через год их будет больше. pgres - распростанена система слабо поэтому найти работу с применением знаний по каше будет сложно, похожих применяемых систем я тоже не знаю, так что нельзя как в рсубд - знаешь sql знаешь как работает версионник а как блокировочник и все на любом движке можно работать true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да работают. pgres - по скорости работает также как и все остальное я бы не стал так говорить, не имея на руках результатов сравнений. впрочем, я так понимаю, что даже имея такие результаты, вы их все-равно опротестуете ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 13:19 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
можно посравнивать для разнообразия, что бы было не голословно http://msdn2.microsoft.com/en-us/library/ms178085.aspx http://msdn2.microsoft.com/en-us/library/ms190620.aspx ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 13:20 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 14:01 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 14:21 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 yww@escape.ru ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 14:38 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgresДа что Вы заладили каше - большие объемы данных / данные растут в геометрической прогрессии до боли напоминает рекламные с программированием ассоциаций наверное это на тренингах по каше как мантру повторяют понятия не имею, я там никогда не был. pgres лично у меня с большими объемами данных ассоциируется оракл и дб2 да откройте наконец секрет какие у Вас например объемы и почему так остро стоит проблема дискового пространства диск небольшой, а MSSQL много кушает. ~300 млн. записей, а ведь индексировать еще нужно. если мне сейчас скажут, что это все ерунда и без индексов SQL выберет все, что нужно за минуту, я не поверю. pgres автор true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да работают. это говорит в пользу рсубд "на безрыбье..." :) pgres если прочитаете 5 пункт то увидите что данные надо выбирать за месяц я не слепой. а мат.операции делались на этой выборке или на всей базе? pgres с нетерпением жду результатов ЗЫ: если результаты будут такими которые легко опротестовать то зачем эти результаты как только Joker ответит еще кстати не хило бы спросить: а выбранные данные куда-то складывались, пересылались или как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 14:41 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres2 yww@escape.ru ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) Не понял вопрос.. возможно вы с кем то обсуждали эту тему.. но не со мной. О какой гордости идет речь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 14:50 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov диск небольшой, а MSSQL много кушает. ~300 млн. записей, а ведь индексировать еще нужно. если мне сейчас скажут, что это все ерунда и без индексов SQL выберет все, что нужно за минуту, я не поверю. и это послужило причиной перехода с mssql на cache ? в таком случае Вы просто фанатик 300 млн. - ну пусть это 300 Гб ну пусть еще 150 Гб на индексы да сейчас люди домой для фильмов такие диски покупают(не плохо былоб если б Вы указывали иногда и физический размер, все таки диски со строками не работают) авторкак только Joker ответит еще кстати не хило бы спросить: а выбранные данные куда-то складывались, пересылались или как? я вас умоляю скоьлко там данных - за три года 1096 строк автор"на безрыбье..." :) опять не в пользу каше PS так почему Вы замалчиваете ответ про TPC :) -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 15:00 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru pgres2 yww@escape.ru ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать Не понял вопрос.. возможно вы с кем то обсуждали эту тему.. но не со мной. О какой гордости идет речь? простите, действительно tpc не с вами но по поводу вашего поста о целесообрзности тестов скажу что в оракле тоже не все так просто работает как вы думаете однако никто не заявляет что нет смысла в тестах так как cost based optimizer & materialized views -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 15:08 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных. да не только поэтому. во-первых, надо проверять на одном оборудовании, во-вторых, при одинаковой нагрузке. ну будет у меня быстрее, а мне скажут - фигня, это у тебя 40 пользователей не работали. а будет медленнее, я скажу - извините, господа, у меня простенький комп на 1.8Ghz/1Gb с IDE. >>2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды), вот тоже самое.. не будет программист на Каше делить на 3600. Там есть встроенные функции преобразования количества секунд во время формата ЧЧ:ММ:СС .. они входят в сам язык, поэтому реализованы на C. ну-ну, чего это он не будет? может стандартная функция возьмет значение часа более 23? :) >>3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню), вот это сравнение может что нибудь и даст.. а вот тут вообще забавно. средняя продолжительность получается делением значения из пункта 2. на значение из пункта 1. причем тут групповые операции? может я что-то путаю? или его нужно каждый раз перевычислять во время выборки? это было бы странно 5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.) опять не выйдет сравнение.. в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу. ну, так нельзя. прочитают люди и подумают, что так оно там всегда и пишется. конечно же не так. я, например, буду организовывать индекс по дате, так правильнее, вдруг выборка будет за неделю. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 15:11 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
>>конечно же не так. я, например, буду организовывать индекс по дате, так правильнее, вдруг выборка будет за неделю. если вы уже на этапе постановки задачи знаете что вам портебуются выборки по датам, то и данные можно хранить в узлах, организованных на $h... а здесь уже всё равно - по месяцу, по неделе, по году - принцип то один и тот же.. становитесь на начало периода и двигаетесь до конца.. дополнительные индексы здесь могут и не понадобиться. ИМХО, конечно.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 15:27 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ну, так нельзя. прочитают люди и подумают, что так оно там всегда и пишется. конечно же не так. я, например, буду организовывать индекс по дате, так правильнее, вдруг выборка будет за неделю да мудро. эти данные и так аплодятся по порядку через append это же udr так что за оракл не волнуйтесь он возьмет только нужные блоки -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 15:28 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 15:33 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Сергей, я же привел ссылки по подсчету размеров индексов, давайте сравним. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 16:30 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenСергей, я же привел ссылки по подсчету размеров индексов, давайте сравним. я прочитал. а что с чем будем сравнивать-то? С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 16:35 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
с вашей табличкой с индексами, где ~300млн. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 16:40 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenс вашей табличкой с индексами, где ~300млн. дык сравнивайте. все данные для этого есть здесь /topic/288398&pg=4#2628282 /topic/288398&pg=5#2629383 если я неправильно использовал индексирование в SQL и на самом деле индекс по дате займет гораздо меньше места, то самое время мне об этом сказать. а то как-то все промолчали. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 16:45 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 16:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenметодику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным не могу, вроде как формул не описано, тем более они жмутся по префиксам. я привел конкретные данные, полученные до и после полной индексации по 9 полям. не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 16:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Я и не сомневаюсь что не врете: итого, что вышло, по той таблице что Вы приводили с 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.05.2006, 17:29 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov SiDenметодику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным не могу, вроде как формул не описано, тем более они жмутся по префиксам. я привел конкретные данные, полученные до и после полной индексации по 9 полям. не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью. С уважением. Сергей 1.15Gb это те самые 300млн строк ? чувак это не объем у тебя ж памяти гиг ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 17:38 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Сергей, еще было бы не безинтересно посмотреть на размер без сжатия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 17:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov дык сравнивайте. все данные для этого есть здесь /topic/288398&pg=4#2628282 /topic/288398&pg=5#2629383 если я неправильно использовал индексирование в SQL и на самом деле индекс по дате займет гораздо меньше места, то самое время мне об этом сказать. а то как-то все промолчали. Про измерение индексов в MySQL на FAT32 улыбнуло коментировать как то более развернуто не до сук P.S. не серьезно это ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 17:53 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 18:07 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres Sergei Obrastsov SiDenметодику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным не могу, вроде как формул не описано, тем более они жмутся по префиксам. я привел конкретные данные, полученные до и после полной индексации по 9 полям. не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью. С уважением. Сергей 1.15Gb это те самые 300млн строк ? чувак это не объем у тебя ж памяти гиг а внимательнее читать по ссылке не получается? там ведь прямо сказано, что тестируется база из 18 млн. записей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 18:09 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenСергей, еще было бы не безинтересно посмотреть на размер без сжатия. без моего "ручного" или без сжатия индексов? с индексами никак не смогу, они жмутся системой, а вот "ручное" могу и убрать. только пересчитываться будет долго. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 18:12 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Про измерение индексов в MySQL на FAT32 улыбнуло коментировать как то более развернуто не до сук P.S. не серьезно это верю. я потому и ждал каких-либо серьезных замечаний. вроде как "а у меня в DB2" или там "а мой MSDE", или уж "а вот Oracle"... делов-то на полчаса. нет ничего. ну и какие ко мне претензии тогда? вот человек откликнулся, спасибо ему. надеюсь, все-таки доведем эту тему до логического завершения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 18:16 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Без ручного конечно. Встроенное незачем трогать да и "никак" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 18:26 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SiDenБез ручного конечно. Встроенное незачем трогать да и "никак" :) можно и так прикинуть. если брать по-максимуму, то добавится 16 символов на каждую запись. итого ~289 Mb, если еще грубее, с учетом увеличения число блоков БД, то 300. С уважением. Сергей P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 18:38 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
На мой взгляд, Вы пока еще не начали понимать про MUMPS, pgres. Именно в РСУБД "теория" вся в белых пятнах. Очередной пример - горячо обсуждаемые "индексы". "Индексы" - это банальный пример денормализации для повышения производительности. В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные. Это в бОльшей степени данные, чем так называемые метаданные (словари данных). Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ? Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД. Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных. И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД. Специалистов по MUMPS намного меньше, и распространены системы на MUMPS меньше, чем на РСУБД. Это факт. В любой области есть попса, и есть альтернативные направления для "высоколобых", "идиотов", "интеллектуалов", "маргиналов" (кому как больше нравится). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 21:08 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :) А вот еще вопрос: чего Вы периодически всё про разделители упоминаете? Они как-то суются в данные? Просто странно как-то, я единственно когда про разделители думал - ну разве что при экспорте текстовых файлов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 23:57 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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 /topic/288398&pg=4#2628282 /topic/288398&pg=5#2629383 еще раз скажу, что сравнивалась SQL (MySQL, MSSQL) таблица с одним индексом и Cache-структура с 9-ю. Хорошо, смотрю. Sergei Obrastsov я только ЗА. ссылки приведены. Это теперь, после напоминания они приведены. Sergei Obrastsov Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся. я бы рад избавиться, но пока приходится дефрагментировать. не часто и все же. про ext2 ничего не скажу, мне приходится работать под Windows Неправда, Вы уже сказали: "дефрагментация всегда давала выигрыш в скорости, дает и сейчас, даже при наличии "супер-файловых" систем ." /topic/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.05.2006, 00:34 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Чернышев Андрей Леонидович "Индексы" - это банальный пример денормализации для повышения производительности. Особенно к денормализации индексы имеют отношение. Еще бы в нормализованной схеме индексов не может быть никогда? Если канечно это реальный ЧАЛ, а не разводка на флейм. Чернышев Андрей Леонидович В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные. Не иначе - выдержавшие проверку временем. От того и такие настоящие. Чернышев Андрей Леонидович Это в бОльшей степени данные, чем так называемые метаданные (словари данных). Совсем похоже на разводку. Чернышев Андрей Леонидович Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ? Ко всему что хранится в отношениях можно писать запросы на SQL (это ни какой-нибудь там МУМПС). А к якобы данным ("индексам") писать запросы ломает. Они лучше для другого подходят. Чернышев Андрей Леонидович Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД. Забыли ЧАЛа спросить. Вот от того все и происходит. Чернышев Андрей Леонидович Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных. Смотря кому. Некоторые, может, наконец через несколько лет пребывания на форуме и узнают разницу между "логическим уровнем" и физическим. Чернышев Андрей Леонидович И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД. Чтобы писать циклы вместо нормального запроса "подвижность специалиста", наверное, понадобится какая-то особенная. Да и "теория" для обоснования такого подхода тоже нужно придумать особенную. Не иначе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 00:42 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
SergSuper Sergei Obrastsov P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :) А вот еще вопрос: чего Вы периодически всё про разделители упоминаете? Они как-то суются в данные? Просто странно как-то, я единственно когда про разделители думал - ну разве что при экспорте текстовых файлов правильно думали, поскольку здесь сходная ситуация. в M нет фиксированного задания полей для структур, поскольку и сами структуры тоже не заданы. поэтому есть только один тип данного - строка. и есть возможность указать в строке символы-разделители, чтобы получить "виртуальные" поля данных. Код: plaintext Код: plaintext Код: plaintext Код: plaintext Код: plaintext это, конечно, не единственный вариант хранения данных в M. я часто встречаю такой: Код: plaintext про "проблему концевых разделителей" можно посмотреть здесь: /topic/288398&pg=17#2655401 С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 01:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov /topic/288398&pg=4#2628282 /topic/288398&pg=5#2629383 еще раз скажу, что сравнивалась SQL (MySQL, MSSQL) таблица с одним индексом и Cache-структура с 9-ю. Посмотрел. Пока увидел, что сравнивался на самом деле не MySQL-MSSQL, а только MySQL. Каким образом сделан вывод, что "впрочем, MS SQL 15 млн. записей с индексацией по дате в 3.5 Gb тоже не запишет. :))" пока непонятно. МССКЛ мелькал только как рабочая база, сравнивать ее с тестовой не совсем корректно, тем более что имели место многочисленные неточности. Никто не может поручиться, что о рабочей базе не забыли упомянуть какую-нибудь деталь. К тому же неизвестно что случится, например, с размером файла данных КЕШ-а, если он поработает несколько месяцев, как МССКЛ. Крчать что ничего не случиться не нужно, нужно поставить базы в одинаковые условия и проверить. /topic/288398&pg=5#2629383 Sergei Obrastsov эти вещи просьба мне в вину не ставить, SQL пакует числа, так что нечего тут, СКЛ числа не пакует. Идем дальше. На данных без индексов выигрыш КЕШ-а по объему аж 30% (1.970 гиг в МуСКЛ - 1.155 гиг в КЕШ-е). Обсуждать смешно. С индексами - не понимаю кешового синтаксиса, хорошо бы пояснить. Также хорошо бы привести скрипт для создания индекса в МУСКЛ-е и параметры сервера, например сколько fillfactor, или как он там называется в МуСКЛ-е. Пока вижу что разница аж на те же 30-40%, игнорируя количество индексов. Тоже нечего обсуждать, это не разница. Что же касается разных индексов, то зачем об этом постоянно говорить, проще уберать лишние из кеша, либо добавить необходимые в МуСКЛ, тогда можно сравнить. Так что пока ничего существенного. Можете поставить в заслугу КЕШ-у выигрыш в 50% по размеру файлов. По-видимому это выдающееся достижение, но из-за экономии места в пол-файла я, например, на КЕШ не перейду. Еще приведите время создания индекса кешем и МуСКЛ-ем. Хоть это и не типичная операция, но интересно. Что касается необходимости индекса, то в РСУБД действительно не всегда нужно индексировать все подряд. Например если в запросе участвует индексированное поле, которое выдаст небольшое количество записей (порядка 20 в случае обычного индекса), скажем фамилия, то остальные поля можно не индексировать, все равно прямой перебор по этому множеству будет быстрее. Кроме того существуют составные индексы, в некоторых случаях по подмножествам полей индекс заводить уже не обязательно. Так что то что в КЕШ-е делается девятью индексами, в РСУБД может быть сделано меньшим (или большим) числом индеков. Есил выложите типичные запросы, то можно пообсуждать необходимые индексы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 02:05 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
c127 yww@escape.ru Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных. Ага, придумали новый отмазон. Да какая разница как они там данные организованы, мы же и не собираемся сравнивать способ организации данных, мы собираемся сравнивать производительность. Производительность тоже принципиально разная? Ее что нельзя измерить в секундах на запрос, а секунды что, разные для всех серверов? это он поторопился. А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве. Двадцать раз уже говорилось, что в дерево хорошо укладываются только очень ограниченное множество задач, а остальные не укладываются вообще никак. Причем даже в хороших случаях все нужно знать заранее, в процессе работы поменять уже ничего нельзя. Поэтому не будут у Вас в узлах лежать данные по месяцам, поскольку отчеты по месяцам всплывут в самый разгар реализации проекта. Вы вообще почти никогда не будете знать заранее чего от системы захочет начальство и какие отчеты оно потребует выдавать пользователям в биллах, оно и само этого не знает. вот ведь забавно. сколько раз уже объясняли, что при необходимости ввести новый индекс он просто создается и все. и в SQL его надо создавать, и в M его надо создавать. в SQL это менее затратно? согласен. за удобство работы с данными нужно платить. Sergei Obrastsov а вот насчет дисков проблема, 80Gb - все, что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :) Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb. ну, не все живут красиво. а еще меня можно попрекнуть зарплатой. это тоже хороший критерий, сразу видно, кто чего стоит. Нужно ведь быть немного резонным. Никто же не спорит, что можно найти задачу, где преимущества КЕШ-а будут очевидными. Например поставить условия, что данные внутри сервера должны храниться в виде строк. Зачем - неизвестно, нужно и все. Но ведь это несерьезно, мы же обсуждаем СУБД общего назначения, которые работают на человеческом железе. а ведь мне лучше было бы работать на связке Clarion+SQL, чем на Clarion+Cache, меньше возни с интерфейсом. так что я не пытался засунуть "вшивый КЕШ" в очередную дырку, вопреки всем правилам и традициям. Sergei Obrastsov а вот это аргумент хороший. правда данные тоже растут в геометрической прогрессии. но, как говорится, на наш век винтов хватит, а там наплевать. Вы по-видимому просто не представляете себе что такое геометрическая поргрессия. Ей там неоткуда взяться, скорее всего Вы перепутали с арифметической прогрессией. кол-во зарегистрированных сотовых телефонов в городе по годам: Код: plaintext 1. 2. Хотя нет, понял. Недооценил оказывается свою фантазию. Вспомнил, что говорю с КЕШ-истом, так вот по КЕШ-овым революционным правилам действительно получается нечто очень похожее на геометрическую прогрессию: И все бы хорошо, но вот только к реальному росту БД эта прогрессия никакого отношения не имеет. я понимаю, что хочется "погнуть пальцы и постучать копытами". но может лучше это делать не здесь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 02:45 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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 в случае обычного индекса), скажем фамилия, то остальные поля можно не индексировать, все равно прямой перебор по этому множеству будет быстрее. Кроме того существуют составные индексы, в некоторых случаях по подмножествам полей индекс заводить уже не обязательно. Так что то что в КЕШ-е делается девятью индексами, в РСУБД может быть сделано меньшим (или большим) числом индеков. Есил выложите типичные запросы, то можно пообсуждать необходимые индексы. буду только рад. итак для таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. необходимы выборки по полям: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. минимальный объем данных ~80 млн. записей, максимальный - ~300. "префиксный выбор..." это когда задан список в виде: 413 22522 4412 8787890201 и нужно найти записи, где данное в этом поле начинается с указанного в списке значения (sorry, если говорю банальные вещи) списки не фиксированы размером. размер запросов не лимитирован, т.е. могут быть заданы все условия одновременно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 03:24 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 09:52 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
c127А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель) Что ж вы так горячитесь? Не помещайте данные по месяцам в узлы - поместите их в узлы по дате.. все вопросы с неделями снимутся... как и, впрочем, с часами и минутами.. $h - хранит и дату и время одновременно. Что касается других выборок - постройте для них подходящие индексы. И не думайте, пожалуйста, что лично вас кто то пытается обмануть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 13:40 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
авторАга, придумали новый отмазон. Да какая разница как они там данные организованы, мы же и не собираемся сравнивать способ организации данных, мы собираемся сравнивать производительность. Если очень хочется сравнить самостоятельно - сравнивайте... А можете и просто посмотреть : "Начисление всем абонентам повременка 1 286 093 109 (записей) 12 часов 25 мин Справка по доходам 1 час 13 мин Сортировка всех абонентов по адресам для печати квитанций 2 часа 50 мин 43 сек" Вот здесь это находится http://www.asr.orel.ru/news/tenmillion.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 14:46 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru А можете и просто посмотреть : "Начисление всем абонентам повременка 1 286 093 109 (записей) 12 часов 25 мин Справка по доходам 1 час 13 мин Сортировка всех абонентов по адресам для печати квитанций 2 часа 50 мин 43 сек" слишком долго, похоже сильно понизили приоритет задачи составления отчетов. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 15:36 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Но ведь там ещё "3000 процессов с выполнением фонового задания формирования отчетных данных." .. хотя, может и не очень быстро.. судить не берусь.. для других систем тесты такого объёма ведь не проводились.. на 10 миллионов абонентов - в России это единственная сертифицированная система ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2006, 16:02 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Отцы, да НАПЛЕВАТЬ сколько база занимает 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.05.2006, 00:51 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ruна 10 миллионов абонентов - в России это единственная сертифицированная система Гыыыы... "на 10 миллионов абонентов" - это что значит? Сколько абонентов прямо или косвенно пользуется этой системой в действительности? 10000000 телефонных абонентов в Орле? Та хде вы их там нашли, в Орле людей в двадцать раз меньше, при этом половина в своей жизни телефона не видала. Или речь идет о максимальном (предельном) размере справочника абонентов? Типа с (максимум) десятимиллионным справочником каша способна работать, и её на это сертифицировали, а с пятнадцатимиллионным справочником - уже ой, не сертифицировали? Или под фразой "предназначена для обслуживания сети емкостью 10000000 абонентов" понимается тот и только тот факт, что всего лишь в системе номера являются семизначными? Писец рекламные клоуны нах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 00:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
DimonanaОтцы, да НАПЛЕВАТЬ сколько база занимает Гыыы... Очередной тупой му**к. Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов. В случае фуллскана, разумеется. В случае не фуллскана - надо более другие вещи смотреть, но завязанные опять таки на объем этих самых более других вещей. Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО Вывод - иногда лучше жевать, чем говорить. Если после "жевать" возникло желание "говорить" - предварительно почитать учебники. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 00:59 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Dimonana Отцы, да НАПЛЕВАТЬ сколько база занимает Не скажите. Например, если одна и та же табла с одной и той же инфой занимает разный объем на диске, то на той которая меньше меньше болков считывать надо. А это имеет значение для скорости выполнения запросов в общем случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 01:02 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох DimonanaОтцы, да НАПЛЕВАТЬ сколько база занимает Гыыы... Очередной тупой му**к. Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов. В случае фуллскана, разумеется. В случае не фуллскана - надо более другие вещи смотреть, но завязанные опять таки на объем этих самых более других вещей. Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО Вывод - иногда лучше жевать, чем говорить. Если после "жевать" возникло желание "говорить" - предварительно почитать учебники. Нда, ну от ника странно ожидать чего-то другого. Специально для пьяных и тупых лохов попытаюсь разжевать: Разница даже в 2 раза несущественно при нынешнмх производительных и дешевых системах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 01:10 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
DimonanaСпециально для пьяных и тупых лохов попытаюсь разжевать: Разница даже в 2 раза несущественно при нынешнмх производительных и дешевых системах. [удалено модератором] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 01:15 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох yww@escape.ruна 10 миллионов абонентов - в России это единственная сертифицированная система Гыыыы... Писец рекламные клоуны нах. Никакой рекламы.. Боже упаси меня от такого занятия. Уточните, пожалуйста, про клоунов. К кому возглас то направлен? По ссылке было показано то, что "АСР ОРЕЛ-М получила Сертификат соответствия № ОС/1-СТ-76 как универсальная тиражируемая автоматизированная система расчётов высшего уровня" и "В ноябре 2002г прошли испытания системы в рамках инспекционного контроля на базе, смоделированной на платформе Cache'и предназначенной для обслуживания сети емкостью 10 000 000 и более абонентов". Эта ссылка предложена в качестве альтернативы самостоятельным проверкам производительности Каше. В Орле действительно нет 10 миллионов абонентов.. их нет ни в одном городе России.. только речь то идёт о других цифрах. Был вопрос - справится ли Каше с 50 миллионами записей? Вот в Орле есть ответ (для 1 286 093 109). Если есть желание, проверьте это лично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 10:51 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 yww@mail.ru Никакой рекламы.. Боже упаси меня от такого занятия. Уточните, пожалуйста, про клоунов. К кому возглас то направлен? Большей частью оно было в сторону авторов штатьи, на которую Вы ссылку привели. Может они и не совсем рекламные, но смеяццо можно над многими кусками штатьи. К Вам по прежнему вопрос - что значит "сертифицирована на 10 миллионов абонентов"? На 500 тысяч - не сертифицирована? Или на 15 миллионов? Что вообще означает термин "сертификация на определенное количество абонентов"? По ссылке было ... предназначенной для обслуживания сети емкостью 10 000 000 и более абонентов" Т.е. на 10000000 - предназначена, на более - предназначена. А на менее, чем 10 миллионов? Если да, то это фраза из серии "до 16 и старше". Что-то сказали, цифру красивую засветили, информации ноль. Эта ссылка предложена в качестве альтернативы самостоятельным проверкам производительности Каше. Нет уж, лучше самостоятельно, чем по такой штатье. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 17:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный ЛохЧто вообще означает термин "сертификация на определенное количество абонентов"? Я, пожалуй, соглашусь, что рекламная составляющая в той статье есть. Как именно проводится сертификация биллинговых систем я не знаю, но о самом термине, у меня следующее представление: Сертификация - процесс проведения испытаний, с целью определения соответствия действительных показателей заявленным. Это относится не только к программым продуктам, но и ко всем продуктам вообще (минералка, в общем то, тоже должна соответствовать тому, что написано на этикетке). Организация, выдавшая сертификат, должна иметь некоторый "законный авторитет" в той области, для которой проводит испытания.. Для связистов это Ленинградский институт связи. То есть, если сертификация проведена, значит есть подтверждение качеств продукта. Смысл 10 миллионов абонентов можно (при желании) увидеть в таком примере: - для 10 миллионов абонентов можно вычислить ожидаемое количество разговоров в сутки (у связистов есть методики) - биллинговая система должна успевать провести расчет стоимости (или хотя бы выгрузку данных со станции) суточного массива за время менее 24 часов. Если она не успевает это сделать, то значит не пригодна для обслуживания биллинга 10 миллионов абонентов. Пример, конечно, искуственный, но вполне возможно что похожее требование может присутсвовать в программе сертификации. Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 18:44 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
> DS400 2 Тб (и 12 Тб) можно найти по гораздо более привлекательной цене при сопоставимой производительности, надежности и масштабируемости. Dimonana, Вы напрасно в этом треде упомянули СХД. ;) Здесь кодеры (язык не поворачивается назвать их разработчиками) заняты любимым делом: сравнением длины пиписек. О популярности этого занятия Вы можете судить по длине обсуждения. ;)) О глубине - по фразе "Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов". ;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 18:50 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 yww@escape.ru Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет. Так вот, откуда Вы взяли факт сертификации на 10 млн.? В штатье по ссылке есть следующие факты: - система как-то кем-то сертифицирована "для обслуживания сети электросвязи ёмкостью до 500 000 номеров" - система еще как-то кем-то сертифицирована, но без указания кол-ва абонентов - система тестировалась для "обслуживания сети емкостью 10 000 000 и более абонентов". Как я уже указывал, сказать "10000000 и более" - это значит не сказать ничего, тока циферки красивые засветить. Я уж не говорю о том, что тестирование само по себе не много значит, если оно стоит в одном абзаце с государственной сертификацией. Ну тестировали чего-то там в Орле, ну получили какой-то результат. Например тот результат, что список абонентов сортировался по адресам в течение почти трех (!) часов. Это, пардон, пузырьковой сортировкой надо было сортировать.. на 286-ом компе.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 19:40 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох2 yww@escape.ru Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет. Так вот, откуда Вы взяли факт сертификации на 10 млн.? В штатье по ссылке есть следующие факты: - система как-то кем-то сертифицирована "для обслуживания сети электросвязи ёмкостью до 500 000 номеров" - система еще как-то кем-то сертифицирована, но без указания кол-ва абонентов - система тестировалась для "обслуживания сети емкостью 10 000 000 и более абонентов". Как я уже указывал, сказать "10000000 и более" - это значит не сказать ничего, тока циферки красивые засветить. Я уж не говорю о том, что тестирование само по себе не много значит, если оно стоит в одном абзаце с государственной сертификацией. Ну тестировали чего-то там в Орле, ну получили какой-то результат. Например тот результат, что список абонентов сортировался по адресам в течение почти трех (!) часов. Это, пардон, пузырьковой сортировкой надо было сортировать.. на 286-ом компе.. Да нет.. зачем придумывать? Статья устарела уже, но всё там правда. Я разговаривал с одним из разработчиком этой системы. Сертифицировал её ЛНИИС (Ленинградский НИИ связи). И не сортировку сертифицировали а весь комплекс. У меня нет причин не доверять тем людям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:18 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Ну сертифицирующая контора вааще-то называецца ЛОНИИС ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:31 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Что какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс). Там больше параметров используется. Один из них - длина квитанции. Печать то производится не на рулонную бумагу, а на (жаргонно) листинг. Поэтому нужно знать как сформатировать квитанции, что бы доставщики смогли их быстро и просто разделить. Вот вычисление длины квитанции и занимает много времени. Там не только счета к оплате, но и извещения и реклама, и еще какие либо тексты присутсвуют. Причем для каждого клиента свой набор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:35 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ИзопропилНу сертифицирующая контора вааще-то называецца ЛОНИИС Ну пусть и так.. что с того? Чем хуже ЛНИИСА? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:37 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 yww@escape.ru Да нет.. зачем придумывать? Хммм... То ли я не по-русски говорю, то ли Вы не по-русски понимаете. Еще раз. Откуда взялось утверждение о сертификации на 10 млн, если в статье приведены только факты о сертификации на "до 500 тысяч абонентов"? Я вот Вас и спрашиваю - зачем придумывать? Статья устарела уже, но всё там правда. Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД. Точно-точно. Все правда. Только вот почему-то абонентов по адресу сортировали три часа. Наверное забыли включить опцию "беспрецедентной производительности". Я разговаривал с одним из разработчиком этой системы. Сертифицировал её ЛНИИС (Ленинградский НИИ связи). Да по мне хоть бы её Карабас Барабас сертифицировал. Вы на знакомых не кивайте, лучше ответьте на вопрос - откуда взялась сертификация на 10 млн.? Это Вы сами выдумали, или Ваш знакомый разработчик? У меня нет причин не доверять тем людям. А у меня нет причин им доверять. Пока что общедоступные факты - это сертификация на обслуживание сетей емкостью до 500000 номеров. Зачем Вы это число в двадцать раз увеличили - непонятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:39 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ruЧто какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс). В статье вижу слова: "... Сортировка всех абонентов по адресам для печати квитанций... " Вы пытаетесь утверждать, что это не сортировка по адресам. ЛОЛ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:41 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох yww@escape.ruЧто какается сортировки для печати, то это не сортировка по адресам (для адресов наверняка есть индекс). В статье вижу слова: "... Сортировка всех абонентов по адресам для печати квитанций... " Вы пытаетесь утверждать, что это не сортировка по адресам. ЛОЛ. Именно это я и утверждаю. >>>Да по мне хоть бы её Карабас Барабас сертифицировал. А зачем тогда вообще разговор вести? Предвзятость - ана и в Африке предвзятость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:46 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru>>>Да по мне хоть бы её Карабас Барабас сертифицировал. А зачем тогда вообще разговор вести? Предвзятость - ана и в Африке предвзятость. А зачем тогда ссылку на штатью было приводить? Так бы и заявили сразу, мол одна бабка сказала, что на 10 миллионов (и более), но слова бабки ничем подтвердить не можете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД. ??? А это то здесь причем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:49 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД. ??? А это то здесь причем? А это из штатьи, однако. В которой все правда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:50 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох yww@escape.ru>>> Ага. Особенно правда про двадцатикратное превосходство над реляционными базами, беспрецендентную производительность и масштабируемость, полноценную поддержку концепции объектного программирования, и совместимость не только с предыдущими версиями каши, но и с традиционными реляционными СУБД. ??? А это то здесь причем? А это из штатьи, однако. В которой все правда. аа.. да.. есть там такое.. перебор с рекламоу.. Но всё равно не пойму я вас что то.. Что Вы хотите сказать? Можете в паре абзацев изложить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Но всё равно не пойму я вас что то.. Фсе, это финиш... Товарисч, сколько раз Вам нужно повторить вопрос, прежде чем Вы его поймете? Вопрос: Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов? Если в вопросе Вам какое-то слово не понятно - откройте словарь живого великорусского языка Владимира Даля. Если все равно не понятно - это будет Вашим домашним заданием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 20:59 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Сертификация - дело серьёзное. Нет в природе такой сертифицирующей конторы -ЛНИИС. Следовательно можно писать всё что угодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 21:00 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох Но всё равно не пойму я вас что то.. Фсе, это финиш... Товарисч, сколько раз Вам нужно повторить вопрос, прежде чем Вы его поймете? Вопрос: Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов? Если в вопросе Вам какое-то слово не понятно - откройте словарь живого великорусского языка Владимира Даля. Если все равно не понятно - это будет Вашим домашним заданием. Товарисч, спуститесь с небес. Мания величия - симптом. >>Откуда взялась информация про сертификацию орловской системы для использования в сетях с десятью миллионами абонентов? Информация взята со слов разработчиков. Документальным подтверждением не располагаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 21:01 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
ИзопропилСертификация - дело серьёзное. Нет в природе такой сертифицирующей конторы -ЛНИИС. Следовательно можно писать всё что угодно. ЛОНИИС конечно.. я неправильно назвал его раньше. ЛОНИИС - Ленинградский Отраслевой Научно-исследовательский институт связи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 21:03 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ruИнформация взята со слов разработчиков. Документальным подтверждением не располагаю. И почему я не удивлен? Наверное потому, что уже не первый раз на этом форуме фанаты какой-то СУБД толкают какие-то слухи, документально ничем не подтверждаемые. То Interbase в танках Абрамсь используют, то вся NASA переходит на MySQL, то пенсионный фонд во всех регионах РФ на мумпсе работает, то кашовые системы сертифицируются на шесть с половиной миллиардов абонентов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 21:06 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Пьяный Лох yww@escape.ruИнформация взята со слов разработчиков. Документальным подтверждением не располагаю. И почему я не удивлен? Наверное потому, что уже не первый раз на этом форуме фанаты какой-то СУБД толкают какие-то слухи, документально ничем не подтверждаемые. То Interbase в танках Абрамсь используют, то вся NASA переходит на MySQL, то пенсионный фонд во всех регионах РФ на мумпсе работает, то кашовые системы сертифицируются на шесть с половиной миллиардов абонентов... Какие слухи то? Вот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан.. Проверяйте на здоровье. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2006, 21:19 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ruВот здесь, http://www.press-release.ru/branches/hitech/4635/view_print/ например, номер сертификата указан.. Проверяйте на здоровье. Скажу по секрету - туда постить может все кому не лень - можно даже запостить что Орловская ГТС отказалась от использования Каше. Пришли новость не от Инфосис ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 08:05 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
http://rusmetall.orel.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 09:23 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 10:09 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
DimonanaОтцы, да НАПЛЕВАТЬ сколько база занимает Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО А это : "Серверный комплекс, на котором тестировалась АСР CBOSS, включал в себя 72 процессора – в испытаниях системы Орловского филиала ОАО «ЦентрТелеком» их было 2." смешно? (Отсюда взято : http://www.connect.ru/article.asp?id=6341 ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 11:36 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Если действительно все правда об испытаниях на 50 млн, то разработчики просто молодцы. Снимаю шляпу. Однако, тесты системы и тесты движка базы данных не одно и то же. Не секрет что в мире биллинговых систем не много оптимальных решений как по стуктуре базы так и по логике приложения. Знаю я одну систему не буду говорить как называется где биллинг работает вабще с плоскими файлами, буквально выгружает все из базы в файл поднимает все в память считает записывает в другой файл и грузит обратно в базу. Полет архитекторской мысли не правда ли. И ничего продается система. Самый большой сайт 2.5 млн абонентов, у которых не только обычные телефоны с количеством разговоров вычесленным по формулам каких то нии (знаю как они сертификаты выдают, да там стандарты небось 80-х годов, странно что на 100млн не провели испытания), но и линии доступа в инет и т.п. Однако это не позволяет нам судить о качестве рдбмс оракл. Если бы проводилась такая параллель я бы сказал оракл дерьмо ничем не лучше аксеса. Точно так же то что на каше создан супер удачный биллинг не дает возможности утверждать что каше 20 раз быстрее чем любой рдбмс. да и выигрыш по размеру базы в 2 раза это не слишком много. если б хотыя бы в 5. а так ну купишь себе в 2 раза больше винтов, слава богу с этим нет проблемы так что давайте кашисты не изворачивайтесь а делайте придложенный тест -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 12:24 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
>>>Однако, тесты системы и тесты движка базы данных не одно и то же. Трудно не согласиться >>>так что давайте кашисты не изворачивайтесь а делайте придложенный тест Смысл в таких действиях может быть только в случае, когда тестеру нужно принять решение о выборе СУБД.. вот пусть автор топика и тестирует. Остальным - вряд ли это нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 12:50 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru DimonanaОтцы, да НАПЛЕВАТЬ сколько база занимает Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО А это : "Серверный комплекс, на котором тестировалась АСР CBOSS, включал в себя 72 процессора – в испытаниях системы Орловского филиала ОАО «ЦентрТелеком» их было 2." смешно? (Отсюда взято : http://www.connect.ru/article.asp?id=6341 ) Если это правда, то я только радуюсь. По крайней мере есть ориентиры на скорость топовых решений. А относительно оборудования - ну реально было 12, но их логи фиксировали что только на 2х была работа. Ок. Если так строится беседа, то СБОСС может написать - да у нас из 72 процов ваще только один чуть чуть юзался. Не серьезно. Взяли бы двухпроцессорный Зеон и задали бы жару. А так... А за ... и получили многомерные скоростные достижения мирового масштаба. надо назначать изнасилование в особо извращенной форме :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 13:18 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 Чернышев Андрей Леонидович Сам дурак. Чернышев Андрей ЛеонидовичНа мой взгляд, Вы пока еще не начали понимать про MUMPS, pgres. Именно в РСУБД "теория" вся в белых пятнах. Очередной пример - горячо обсуждаемые "индексы". "Индексы" - это банальный пример денормализации для повышения производительности. В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные. Это в бОльшей степени данные, чем так называемые метаданные (словари данных). Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ? Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД. Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных. 1. хорошо известно в каких случаях индексы надо использовать а в каких нет. 2. они отлично вписываются в модель: меньше нормализации - больше скорость и наоборот. 3. таким образом индексы это материализованные представления данных 4. отношения индексов дублируют отношения таблиц т.к дублируют данные. 5. индексы не храняться в отдельной субд и запросы на индексы могут быть составлены разработчиком. можно так и дальше, но видно Ваши белые пятна в понимании рдбмс невосполнимы изначально автор И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД. аргументы в студию, пока что аргументов не вижу авторСпециалистов по MUMPS намного меньше, и распространены системы на MUMPS меньше, чем на РСУБД. Это факт. В любой области есть попса, и есть альтернативные направления для "высоколобых", "идиотов", "интеллектуалов", "маргиналов" (кому как больше нравится). а по-моему последователи алтернативных направлений реализации сексуальных желаний подругому называются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 16:17 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres так что давайте кашисты не изворачивайтесь а делайте придложенный тест хорошо, привожу результаты тестирования. в связи с тем, что заказчик теста не указал размер записи, тестировались 2 структуры: a) Код: plaintext 1. b) Код: plaintext 1. $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.05.2006, 17:06 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
автор"количественный" вывод: время, затраченное на выборку данных не зависит от количества записей в БД, а зависит от размера данного/записи. что то Вы темните почем Вы там говорите индексы создавали сдается что имели место некоторые предрасчеты при добавлении записей -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 17:16 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres автор"количественный" вывод: время, затраченное на выборку данных не зависит от количества записей в БД, а зависит от размера данного/записи. что то Вы темните почем Вы там говорите индексы создавали сдается что имели место некоторые предрасчеты при добавлении записей "почем", "почему" или "по чем"? видимо, третье. :) конечно, я создавал его по дате. я уверен, что у заказчика записи аналогичным образом по дате проиндексированы. какие там, интересно, могут быть предрасчеты? или проблема в том, что я строго зафиксировал количество записей на дату? ну и что? что система переберет 40 млн. записей с разным количеством записей на дату, что с одинаковым - один фиг, 40 млн. и будет. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 17:47 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
заинтриговал сам вывод, противоречащий законам физики > время, затраченное на выборку данных не зависит от количества записей в БД, а зависит от размера данного/записи. прокомментируйте плз -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 17:51 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgresзаинтриговал сам вывод, противоречащий законам физики > время, затраченное на выборку данных не зависит от количества записей в БД, а зависит от размера данного/записи. прокомментируйте плз а ведь все банально просто - структура индексирована, следовательно поиска дат по всей таблице не происходит, во время выборки снимаются нужные значения сразу "под" нужной датой. и причем тут физика? а вот "размер данного" - это да, система дольше читает. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2006, 17:57 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov pgres так что давайте кашисты не изворачивайтесь а делайте придложенный тест хорошо, привожу результаты тестирования. в связи с тем, что заказчик теста не указал размер записи, тестировались 2 структуры: a) Код: plaintext 1. b) Код: plaintext 1. $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.05.2006, 03:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Joker_YaВот хоть что-то конкретное. Тест конечно не совсем корректный т.к. структура данных совсем упрощена вследствии чего объем данных совсем маленький. 3.7 Gb это не серьезно а я и говорю, что тест несерьезный. надо было сразу показывать свою структуру. впрочем, речь шла, как я понимаю, о кол-ве записей, а не о их размере, так что мне пришлось поджаться, размещая нужное кол-во в 4Gb. (Кстати очеь большой объем для 2 то полей) не стоит забывать, что это таблица + индекс по дате Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД? Если добавить в тест условие что необходимо обеспечить выборки данных с условиями по многим полям то результат я думаю будет еще хуже. я бы сказал, что измерение производительности СУБД на последовательном переборе данных не есть правильное тестирование. Мне для выборки всех данных потребовалось написать 1 запрос (привожу ниже). Если не секрет поделитесь своим кодом. пожалуйста, если Вам это что-нибудь даст. как видите, общего - 0. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 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 ........ пожалуйста Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Я тут немного поэксперементировал и получил время работы запроса 105 с. убрав вычисление часов по КАЖДОЙ записи, я тоже оптимизировал выборку - 60-62 с. Так что при условии оптимизации запросов я получил результат не хуже вашего на гораздо больших объемах и большей нагрузке на систему. Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте). отсюда можно сделать только один правильный вывод: сравнивать можно только в одинаковых производственных условиях и на одинаковом оборудовании. и не только на последовательном переборе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 08:26 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Joker_Ya Sergei Obrastsov pgres так что давайте кашисты не изворачивайтесь а делайте придложенный тест хорошо, привожу результаты тестирования. в связи с тем, что заказчик теста не указал размер записи, тестировались 2 структуры: a) Код: plaintext 1. b) Код: plaintext 1. $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.05.2006, 08:34 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 09:14 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 10:07 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov pgresзаинтриговал сам вывод, противоречащий законам физики > время, затраченное на выборку данных не зависит от количества записей в БД, а зависит от размера данного/записи. прокомментируйте плз а ведь все банально просто - структура индексирована, следовательно поиска дат по всей таблице не происходит, во время выборки снимаются нужные значения сразу "под" нужной датой. и причем тут физика? а вот "размер данного" - это да, система дольше читает. С уважением. Сергей я не совсем правильно понял думал что время вычисления за день не зависит от количества записей за день ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 10:17 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
LittleCat Не могли бы Вы привести конфигурацию оборудования, на котором производилось тестирование ? В примере, который привел Сергей, она присутствует. Мне кажется, выводы можно начать делать, когда мы ее сравним с Вашей. А пока они преждевременны :-) Пожалуйста. 4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb доступно 2,5 так как остальное забирается под их хитрый райд массив и горячую подмену (Объемы очень большие так ак надо хранить все данные минимум за 3 года). Память 4 Гб. На этом железе работает примерно 100 чел. В пики до 160. Выполняется куча аналитической отчетности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 10:22 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 10:36 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. Код: plaintext 1. Что сравнивается в таких разных условиях, не понял. Хотя интересно было-бы узнать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 10:39 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
iscrafm Код: plaintext 1. Код: plaintext 1. Что сравнивается в таких разных условиях, не понял. Хотя интересно было-бы узнать. Ну так и нагрузка разная слегка не заметили. Там 1 чел. сидит а у меня 100. У него при более выгодных условиях (с базой работает 1 чел. Практически больша никаких задач не выполняется, объем значительно меньше и т д.) скорость работы не сильно выше. Это говорит о многом в том числе о том что при многопользовательской работе и на реальных данных все работать будет гораздо медленнее. Конечно усиление железа немного спасет ситуацию но вы никогда не получите 3-5 кратного превосходства над тем же Ораклом. В общем то я хотел показать имено это. Так что не поддавайтесь на рекламу о чудо постреляционных СУБД придуманных в 60-70 гг. прошлого века. И еще сравните код на SQL и на М. Интересно в каком коде быстрее разберется человек. Если на SQL надо написать 1 команду то на М надо целую программу. Достаточно приличного объема. Я конечно понимаю что поклонники М хитрят и не пишут операторы полностью чтоб хоть как то визуально приблизить свое творение к размерам SQL запроса. Пусть это будет на их совести. Кстати SQL можно вообще не писать есть куча графических построителей запросов. Ну это к слову. Не хочу обидеть стороников М систем. Просто мне надоело что постояно говорят о том что М может сделать любую РСУБД в несколько раз. А как доходит до реальных примеров ничего доказать не могут. Причем этим страдают не только программисты но и сама Intersystems. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 10:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 11:31 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Joker_YaИ еще сравните код на SQL и на М. Интересно в каком коде быстрее разберется человек. Насчет кода конечно Вы правы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 11:33 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
iscrafmНагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен. не был бы. обратите внимание, что идет последовательный перебор. С уважением. Сергей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 11:34 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 12:14 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru Sergei Obrastsov Если возьмётесь, исправьте одну строчку.. ошибся я.. нужно так автор .s Сortege=$LB(DateTime,SPhone,Length,RPhone) ; кортеж данных Если не возьмётесь - я не обижусь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 12:17 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov iscrafmНагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен. не был бы. обратите внимание, что идет последовательный перебор. С уважением. Сергей а что Вы предлагаете ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 12:40 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres а что Вы предлагаете Выслать тест на TPC и попросить их прокомментировать или хотя бы посмотреть на их реакцию. Что же еще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 13:12 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
пожалуйста вполне адекватные условия 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) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. количество записей за месяц ~43млн по дням распределены неравномерно в таблице немного больше но при существовании индекса это неважно размер базы 1.7Гб не самый лучший запрос Код: plaintext 1. 2. 3. 4. 120 сек не вижу обещаного превосходства каше в 5 раз (ну или хотя бы в 2) -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.05.2006, 17:54 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgresпожалуйста вполне адекватные условия Win XP SP2 P4 3GHz 512 Mb RAM 80 Gb HDD SATA действительно, просто одно и то же, подумаешь на 1Ghz больше Код: plaintext 1. 2. 3. 4. может кто-нибудь все-таки проверит сколько времени займет Код: plaintext 1. не вижу обещаного превосходства каше в 5 раз (ну или хотя бы в 2) в 2 и есть. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 01:06 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
iscrafmНагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен. За процессорами не следил в этот раз но до этого специально мониторил систему. Загрузка в рабочее время в среднем составляет 30-40%. К сведению для вас 100 подключений даже неактивных требуют довольно боольших ресурсов системы сами по себе. Это прежде всего память (около 1 М если ничего не делали на процесс, у меня в среднем 2-5). Это время процессора так как постояно проверяется активно ли соеденение. Вообще внутри системы происходит значительное кол-во телодвижений для поддержания пула соеденений, для обеспечения целостности транзакций как читающих так и пишущих. Кстати у меня запрос был в рамках 1 транзакции, т. е. все данные были полученвы на момент начала транзакции. В приведенном тесте на М о транзакциях не слова и если данные необходимые для выборки были изменены после начала обработки то уже измененные данные попадут у них в выборку. Я же получу те данные которые были на момент начала транзакции даже если после начала выполнения запроса кто либо изменил данные. Поддержка транзакция весьма ресурсоемкая вещ. Так что тест в принципе показал что никакого особого приемущества М системы не дают. Железо у них было послабее. Так и работала в однопользовательском режиме без поддержки транзакций на сильно урезанных данных (у меня кол-во записей в таблице порядка 500 млн. у них всего 261 кроме того у меня длина записи почти в 15 раз больше). И при всех этих условиях скорость выполнения у них всего в 1.5 - 2 раза выше. Если добавить в их тест еще пару работающих человек, уравнять структуры хранения добавить транзакции то результат будет не сильно лучше. Тут Сергей постояно говорит: обратите внимание, что идет последовательный перебор И что это проблемы Каше и других М систем. Сделайте аналогичный SQL запрос если вам перебор не нравиться. Я думаю там вообще результат будет хуже раза в 2. В одном из топиков кто-то делал сравнение SQL в Оракле и Каше. Результат был не в пользу Каше раза в 1.5. Еще раз повторюсь я не против Каше. Просто при практически одинаковой стоимости лицензий на Каше и Оракл вы получите конструктор сделай сам все на языке похожем на курсовую работу студента филолагического факультета (так как с математикой очень плохо у них было приоретета операций нет) с криво пределаным SQL производительность которого не блещет а синтаксис застыл на уровне 90 годов, с жесткими ограничениями на кол-во подключений (у оракла нет никаких ограничений. Только совесть клиента и если например в какой то момент ононеожидано превысит кол-во лицензий купленных то ничего страшного все будет работать дальше. А вы можете спокойно докупить лицензии), с практически полным отсутствием литературы на русском, с отсутствием нормальной бесплатной версии (практически у всех РСУБД они есть с определенными ограничениями, по объему и количеству процессоров которые позволяют спокойно работать). Есть еще много минусов. Плюсов я например от приверженцев Каше так и не дождался. Одни обещают беспрецидентной производительности раз в 5 больше чем у РСУБД но этого нет как мы видим на реальных тестах. Другие говорят об удобстве хранения данных в деревьях, но его тоже нет так как под очередной запрос надо структуру данных подгонять. В общем сплошной гемморой за нехилые бабки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 02:47 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru c127А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель) Что ж вы так горячитесь? Не помещайте данные по месяцам в узлы - поместите их в узлы по дате.. все вопросы с неделями снимутся... как и, впрочем, с часами и минутами.. $h - хранит и дату и время одновременно. А я ничего никуда не помещаю, это Вы их туда помещаете: " в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу ." /topic/293038&pg=6#2684408 yww@escape.ruЧто касается других выборок - постройте для них подходящие индексы. Ну да, как же, только что нам втюхивали что индексы могут не потребоваться: " если вы уже на этапе постановки задачи знаете что вам портебуются выборки по датам, то и данные можно хранить в узлах, организованных на $h... а здесь уже всё равно - по месяцу, по неделе, по году - принцип то один и тот же.. становитесь на начало периода и двигаетесь до конца.. дополнительные индексы здесь могут и не понадобиться . ИМХО, конечно.." /topic/293038&pg=8#2687245 Я же об этом и говорю, что стоит немного поменять постановку задачи, а это по-моему происходит всегда, все достоинства КЕШ-а пропадают, остаются давно всем хорошо известные недостатки иерархических БД. yww@escape.ru И не думайте, пожалуйста, что лично вас кто то пытается обмануть Расслабтесь, я так не думаю. Но даже если и пытаются, это меня не беспокоит, не должно беспокоить и Вас. Хотя имете право беспокоиться разумеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 03:31 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Joker_YaТут Сергей постояно говорит: обратите внимание, что идет последовательный перебор И что это проблемы Каше и других М систем. Сделайте аналогичный SQL запрос если вам перебор не нравиться. Я думаю там вообще результат будет хуже раза в 2. В одном из топиков кто-то делал сравнение SQL в Оракле и Каше. Результат был не в пользу Каше раза в 1.5. а вот не надо утверждать за меня, ладно? не надо путать "последовательный перебор записей" и "работу с последовательными файлами". Cache действительно сильно подсаживает систему при работе с обычным файлом, по крайней мере так в 5.0.11 перебор записей, лежащих в БД подряд, в РСУБД будет быстрее, это однозначно. с таким же успехом я могу утверждать, что простенькая программка на C круче обеих тестируемых СУБД, поскольку сделает все то же с обычным файлом намного быстрее. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 04:13 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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 Вы по-видимому просто не представляете себе что такое геометрическая поргрессия. Ей там неоткуда взяться, скорее всего Вы перепутали с арифметической прогрессией. кол-во зарегистрированных сотовых телефонов в городе по годам: Код: plaintext 1. 2. Как арфиметическая прогрессия разумеется. Пусть каждый пользователь делает 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.05.2006, 04:14 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov pgresпожалуйста вполне адекватные условия Win XP SP2 P4 3GHz 512 Mb RAM 80 Gb HDD SATA действительно, просто одно и то же, подумаешь на 1Ghz больше а по поводу 512М оперативки мы типа не заметим.... типа не критично... ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 05:36 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
andy st Sergei Obrastsov pgresпожалуйста вполне адекватные условия Win XP SP2 P4 3GHz 512 Mb RAM 80 Gb HDD SATA действительно, просто одно и то же, подумаешь на 1Ghz больше а по поводу 512М оперативки мы типа не заметим.... типа не критично... ;) Вот имено для баз гораздо боле критичным ресурсом является объем оперативной памяти (так как больший объем позволяет избегать медленных дисковых операций за счет кеша) чем такторая частота процессора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 05:42 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
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.05.2006, 07:31 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov Joker_Ya... Вот имено для баз гораздо боле критичным ресурсом является объем оперативной памяти (так как больший объем позволяет избегать медленных дисковых операций за счет кеша) чем такторая частота процессора. для Cache это не критично. она отгрызает свои там 80-100 метров на процессы и дисковый кэш и все. говорят дескать увеличение дискового кэша дает прирост скорости... но на первом проходе все-равно нифига не дает. сколько дисковый кэш был у меня? 16 метров, стандарт. Sergei Obrastsov методика тестирования: выбирались данные за 31 день (40.3 млн. записей), начальная дата выбиралась случайным образом, выборка проводилась 100 раз. а про кеш windows тоже забудем.... ) особенно на 1 гиге оперативки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 07:53 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
andy st Sergei Obrastsov методика тестирования: выбирались данные за 31 день (40.3 млн. записей), начальная дата выбиралась случайным образом, выборка проводилась 100 раз. а про кеш windows тоже забудем.... ) особенно на 1 гиге оперативки не забудем. и про выборку 100 раз тоже. только вот разницы между первым прогоном и последующими нет. ну, например, 60-62-62-61-62-60-60-62... и от увеличения дискового кеша не меняется. и от "kept in memory" тоже не меняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 08:46 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov не забудем. и про выборку 100 раз тоже. только вот разницы между первым прогоном и последующими нет. ну, например, 60-62-62-61-62-60-60-62... и от увеличения дискового кеша не меняется. и от "kept in memory" тоже не меняется. а перед тестами все кеши, в т.ч. и виндовый, были сброшены ?? и вопрос 2: как будет вести себя Cache, если в момент создания отчета будет происходить правка исходных данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 09:02 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 Sergei Obrastsov насчет превосходства каше в 2 раза Вы поторопились а все остальные так просто поверили datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек не ожидал от Вас такого передергиванья -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 09:20 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov сколько дисковый кэш был у меня? 16 метров, стандарт. Вот потому то и получилось так медленно. 16 - это недопустимо мало для миллионов записей. Я просил Вас проверить программку, подозревая что у Вас маленький кэш. Ну а теперь и так ясно. Увеличьте кэш до 200, хотя бы, и проверьте что выйдет с вашим тестом. Очень это интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 11:07 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Мои соображения. У меня дома сейчас стоит 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.05.2006, 12:25 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
>>Недавно получил обещаный диск от Cache 5 (однопользовательский). Если у Вас нет лицензии, сравнения будут бессмысленны. Вам лучше обратиться в InterSystems за временной лицензией. Обьясните ситуацию и попросите временную лицензию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 12:48 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
yww@escape.ru>>Недавно получил обещаный диск от Cache 5 (однопользовательский). Если у Вас нет лицензии, сравнения будут бессмысленны. Вам лучше обратиться в InterSystems за временной лицензией. Обьясните ситуацию и попросите временную лицензию. Почему ? В чем трабла ? Я могу SQL тоже перключить в однопользовательский режим ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 14:23 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
в однопользовательском режиме бстрее всего будут работать dbf файлы :) -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 14:47 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Iura1976Почему ? В чем трабла ? Я могу SQL тоже перключить в однопользовательский режим Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 14:47 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres2 Sergei Obrastsov насчет превосходства каше в 2 раза Вы поторопились а все остальные так просто поверили datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек не ожидал от Вас такого передергиванья а я не ожидал такой невнимательности. может все-таки обратим внимание на /3600? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 14:55 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pavelvp Iura1976Почему ? В чем трабла ? Я могу SQL тоже перключить в однопользовательский режим Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять... http://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 14:56 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
version pavelvp Iura1976Почему ? В чем трабла ? Я могу SQL тоже перключить в однопользовательский режим Там ограничение на память жестокое. Я нарвался на это, когда пытался тесты погонять... http://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su? sorry, http://www.sql.ru/forum/actualthread.aspx?tid=288398&pg=14&hl=su ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 14:57 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
не проходит правильная ссылка... "Именно. У версии, которая SU, кеш ограничен." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 15:00 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
Sergei Obrastsov pgres2 Sergei Obrastsov насчет превосходства каше в 2 раза Вы поторопились а все остальные так просто поверили datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек не ожидал от Вас такого передергиванья а я не ожидал такой невнимательности. может все-таки обратим внимание на /3600? я перестал Вас понимать объясните к чему это ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 15:05 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres Sergei Obrastsov pgres2 Sergei Obrastsov насчет превосходства каше в 2 раза Вы поторопились а все остальные так просто поверили datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек не ожидал от Вас такого передергиванья а я не ожидал такой невнимательности. может все-таки обратим внимание на /3600? я перестал Вас понимать объясните к чему это уф... я же сказал, что рассчитывал значение времени в часах по КАЖДОЙ строке. потом указал, что пересчет с учетом этого изменения, по первой структуре занимает 60-62 сек. сейчас вот пересчитал по второй - 71-72 размер кеш значения не имеет. что 16 метров, что 200 - однофигово. это и очевидно, слишком большой объем данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 15:58 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
pgres Sergei Obrastsov pgres2 Sergei Obrastsov насчет превосходства каше в 2 раза Вы поторопились а все остальные так просто поверили datetime - хранит как время так и дату, так что мой тест аналогичен Вашему тесту №2 который как раз и занял 123-126 сек не ожидал от Вас такого передергиванья а я не ожидал такой невнимательности. может все-таки обратим внимание на /3600? я перестал Вас понимать объясните к чему это уф... я же сказал, что рассчитывал значение времени в часах по КАЖДОЙ строке. потом указал, что пересчет с учетом этого изменения, по первой структуре занимает 60-62 сек. сейчас вот пересчитал по второй - 71-72 размер кеш значения не имеет. что 16 метров, что 200 - однофигово. это и очевидно, слишком большой объем данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.05.2006, 16:10 |
|
||
|
Слабые стороны Cache & SQL
|
|||
|---|---|---|---|
|
#18+
2 Sergei Obrastsov Да пожалуйста провел я дефрагментацию индекса. работает 68 сек и я настаиваю что никакого превосходства каше над рдбмс нет - будь у меня гиг памяти будет работать еще на 40% , быстрее -- Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2006, 10:36 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553584]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
243ms |
get tp. blocked users: |
1ms |
| others: | 172ms |
| total: | 485ms |

| 0 / 0 |
