Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 39 40 41 42 43 [44] 45 46 47 48 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Sergei Obrastsov
pavelvp
Прямым обращением можно назвать только доступ по ROWID к записи таблицы.
В ROWID входит номер блока и смещение внутри него? Если так, то конечно. А если нет?
Так и кое что сверх того, например номер файла, номер партиции ...
именно поэтому его нельзя считать номером записи. Это физический адрес записи (в Oracle во всяком случае)
Я так и думал. Следует ли мне полагать, что позиция записи в блоке неизменна? Потому как изменение позиции записи ведет к пересборке индексов.
21 ноя 06, 13:23    [3429420]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
SergSuper
Rus000
Требуется имея Вашу таблицы из двух полей
1) загрузить эти документы
2) осуществлять выборки/изменения и удаления заданных атрибутов/элементов
3) делать стат.отчеты по загруженным документам по заданной структуре элементов и атрибутов

1. Вобще-то разбор файла XML - всяко не задача СУБД. Хотя и не сложная
2,3. Никаких трудностей не вижу. Давайте примеры

Rus000

P.S. это ж надо так до абсурда из двух полей скатиться :(

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


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

Вам нужны примеры xml-документов? или что?
21 ноя 06, 13:24    [3429424]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Rus000
Однако можете Вы напомнить при каких значениях N константное время поиска будет меньше времени поиска в сбалансированном дереве? Думаю здеь дела обстоят также как и про вырожденные случаи с фуллсканом, обсужденным выше.


Ой, ну нельзя же быть таким дремучим :( Константное время поиска может быть больше логарифимического только в тех случаях, которые Вы называете "вырожденными", да и то не факт, потому что на малых выборках у B-деревьев издержки тоже будь здоров откушивают (потому FullScan и рулит, чем проще тем лучше). Формулы поиска хэш-ключей как правило весьма просты.

У хэш-таблиц есть другие недостатки и выше по треду я их озвучивал. Если коротко, из них нельзя удалять и они вырождаются при заполнении сверх определенного объема. Эти проблемы можно порешать, но время доступа после этого станет, вообще говоря, неконстантным.
Также есть задачи в которых хэш-таблицы то что доктор прописал даже с учетом всех их ограничений.
21 ноя 06, 13:25    [3429431]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

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

можно поинтересоваться почему?
Тут в соседней ветке обсуждалось решение на M стоимостью в $4B ... думаете за абсурд будут столько платить?


будут, это вопрос маркетинга и откатов
И Вы прекрасно знаете. Что меня удивляет так это то, что находятся лохИ что на это ведутся
21 ноя 06, 13:28    [3429456]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Gluk (Kazan)
Sergei Obrastsov
pavelvp
Прямым обращением можно назвать только доступ по ROWID к записи таблицы.
В ROWID входит номер блока и смещение внутри него? Если так, то конечно. А если нет?
Так и кое что сверх того, например номер файла, номер партиции ...
именно поэтому его нельзя считать номером записи. Это физический адрес записи (в Oracle во всяком случае)
Я так и думал. Следует ли мне полагать, что позиция записи в блоке неизменна? Потому как изменение позиции записи ведет к пересборке индексов.


Ну с чего бы изменение позиции одной записи вело к ПЕРЕСБОРКЕ цельного индекса ?
В индексе будет поправлен ROWID
21 ноя 06, 13:31    [3429474]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ну я
12 правил "ну я" для форума SQL.RU
Отлично :-) Этот список нужно обощить и в FAQ :-)
21 ноя 06, 13:36    [3429513]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
>>Чтобы узнать как работает $order посмотрите на план запроса SergSuper.

Мне ?? Бу-га-га Ы-ы-ы-ы - а ну марш rtfm, открою по секрету плана там два. И второй ничем от SergSuper не отличается - но к сажалению коньюктивит лечать врачи а не оппоненты :)

ЗЫ: Пишу из пад стула, белые и пушистые РУСБД-ники меня учить будут как у нас проги работают ы-ы-ы [смахивает слезу умиления]. Что бы мы без ваз делали то Бу-га-га.

OS/360
>>а чем они отличаются???

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

Не хотелось бы попасть под одно из "12 правил ну я", но кто-нибудь может это перевести на нормальный язык?
21 ноя 06, 13:41    [3429535]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Sergei Obrastsov
Gluk (Kazan)
Sergei Obrastsov
pavelvp
Прямым обращением можно назвать только доступ по ROWID к записи таблицы.
В ROWID входит номер блока и смещение внутри него? Если так, то конечно. А если нет?
Так и кое что сверх того, например номер файла, номер партиции ...
именно поэтому его нельзя считать номером записи. Это физический адрес записи (в Oracle во всяком случае)
Я так и думал. Следует ли мне полагать, что позиция записи в блоке неизменна? Потому как изменение позиции записи ведет к пересборке индексов.


Ну с чего бы изменение позиции одной записи вело к ПЕРЕСБОРКЕ цельного индекса ?
В индексе будет поправлен ROWID
Естественно. Но глупо было бы перемещать только одну запись в блоке на свободное место, не подтягивая остальные. Или наличие дыр считается нормальным?
21 ноя 06, 13:41    [3429537]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
pavelvp
Sergei Obrastsov
В M нет "встроенного алгоритма поиска", а есть прямое обращение к узлу дерева.
Как мы тут выяснили всё-таки есть - функция $order. Учите матчасть :-) Шутка.
И вообще, Ваше "прямое обращение к узлу дерева" суть поиск по ключу в B*-дереве. Не говорите больше про "прямое обращение", т.к. нет в М никаких прямых обращений (ну конечно когда уже мы в дерево спустились, только не в узел, а в лист, тогда уж перебор прямой идёт).


на физическом уровне это называется поиском по заданному ключу.

pavelvp

Прямым обращением можно назвать только доступ по ROWID к записи таблицы.


ух ты как смело :)

а можно определение "прямого обращение (доступа)" в студию?

если бы ROWID содержал адрес физического дискогового блока тогда еще можно было бы говорить про слово "прямой"
21 ноя 06, 13:41    [3429539]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
Rus000
SergSuper
Rus000
Требуется имея Вашу таблицы из двух полей
1) загрузить эти документы
2) осуществлять выборки/изменения и удаления заданных атрибутов/элементов
3) делать стат.отчеты по загруженным документам по заданной структуре элементов и атрибутов

1. Вобще-то разбор файла XML - всяко не задача СУБД. Хотя и не сложная
2,3. Никаких трудностей не вижу. Давайте примеры

Rus000

P.S. это ж надо так до абсурда из двух полей скатиться :(

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


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


Гм... Вот сижу, смотрю на родный склад... И вижу именно иерархию,
и именно на двух таблицах - список товаров, и иерархия групп товаров.
Использую, вот что странно... Или опять раночтения? ;-)))
21 ноя 06, 13:42    [3429549]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Rus000
pavelvp
Sergei Obrastsov
В M нет "встроенного алгоритма поиска", а есть прямое обращение к узлу дерева.
Как мы тут выяснили всё-таки есть - функция $order. Учите матчасть :-) Шутка.
И вообще, Ваше "прямое обращение к узлу дерева" суть поиск по ключу в B*-дереве. Не говорите больше про "прямое обращение", т.к. нет в М никаких прямых обращений (ну конечно когда уже мы в дерево спустились, только не в узел, а в лист, тогда уж перебор прямой идёт).


на физическом уровне это называется поиском по заданному ключу.

pavelvp

Прямым обращением можно назвать только доступ по ROWID к записи таблицы.


ух ты как смело :)

а можно определение "прямого обращение (доступа)" в студию?

если бы ROWID содержал адрес физического дискогового блока тогда еще можно было бы говорить про слово "прямой"


упс! увидел разъяснения Gluk про ROWID. Если все так как он пишет, тогда слово прямой уместно
21 ноя 06, 13:43    [3429557]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Vlad2005
Гм... Вот сижу, смотрю на родный склад... И вижу именно иерархию,
и именно на двух таблицах - список товаров, и иерархия групп товаров.
Использую, вот что странно... Или опять раночтения? ;-)))

Именно они, к сожалению. Речь идет об одной таблице с двумя полями. Слабо запихнуть? :)
21 ноя 06, 13:45    [3429571]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
Sergei Obrastsov
Следует ли мне полагать, что позиция записи в блоке неизменна? Потому как изменение позиции записи ведет к пересборке индексов.


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

Gluk (Kazan)
В индексе будет поправлен ROWID


Имхо, нет. Ничего поправлено не будет Т.к. в ROWID ссылка на Row Directory (которая лежит в Block Head, сами строки , или ссылки на другие блоки в случае Row Migration, в Tail)

Примерно так (+-)
21 ноя 06, 13:45    [3429574]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
pavelvp
Да, пожалуйста :-) Испытывайте. Только зачем, непонятно...
Запросто. Я просто надеялся, что Вы загоритесь желанием доказать несостоятельность Cache.
Но Вы, конечно, все знаете заранее и без тестирования.

Во-первых, ни в коем разе не собирался и не собираюсь доказывать несостоятельность Cache. С большим уважением отношусь к этому продукту.
Во-вторых, уже тестировал. Только у демо-версии Cache есть ограничение (на размер кеша), которое не позволяет провести полноценных тестов. Да и снёс я её уже. Нужно было место под другие тесты.
Поэтому и предложил потестировать Вам. Вот и всё. Очень простое объяснение.
21 ноя 06, 13:49    [3429604]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Andreww
Gluk (Kazan)
В индексе будет поправлен ROWID

Имхо, нет. Ничего поправлено не будет Т.к. в ROWID ссылка на Row Directory (которая лежит в Block Head, сами строки , или ссылки на другие блоки в случае Row Migration, в Tail)

Примерно так (+-)
Спасибо, это полезная информация.
21 ноя 06, 13:51    [3429612]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67529
Блог
Sergei Obrastsov
Не стоит упирать на то, чего я не говорил. Это про невиданное быстродействие.
По меньшей мере некрасиво с Вашей стороны.

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

Sergei Obrastsov
Ну а что насчет варианта 2, который на строке? Тоже не то?

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

Sergei Obrastsov
Ну тогда я плюну на B-tree, займу блоков у системы и, пользуясь возможностями прямого доступа к блокам БД, сам построю то, что мне нужно. Правда, не понимаю зачем.

OK. То есть, у "ассемблера" M, позволяющего строить эффективные решения, не хватает встроенных средств для эффективного решения задачи, придется писать user-defined extension. Как я уже упоминал, в РСУБД мне никто не мешает сделать тот же самый "займу блоков", но есть и встроенные средства:

SQL> declare
  2  
  3    type TTestData is table of integer index by binary_integer ;
  4    TestData TTestData ;
  5  
  6    procedure Fill ( cnt integer ) is
  7    begin
  8      TestData.Delete ;
  9      for i in 0..cnt - 1 loop TestData ( i ) := i ; end loop ;
 10    end ;
 11  
 12    procedure TestAccess is
 13      time_start timestamp with time zone := systimestamp ;
 14      t_size integer := TestData.count ;
 15      dummy integer ;
 16    begin
 17      for i in 1..10000000 loop
 18        dummy := TestData ( mod ( i, t_size )) ;
 19      end loop ;
 20      dbms_output.put_line ( 'Size = ' || t_size || ' time = ' || ( systimestamp - time_start )) ;
 21    end ;
 22  
 23  begin
 24    Fill ( 1000 ) ;
 25    TestAccess ;
 26    Fill ( 10000 ) ;
 27    TestAccess ;
 28    Fill ( 100000 ) ;
 29    TestAccess ;
 30    Fill ( 1000000 ) ;
 31    TestAccess ;
 32  end ;
 33  /

Size = 1000 time = +000000000 00:00:10.937000000
Size = 10000 time = +000000000 00:00:10.875000000
Size = 100000 time = +000000000 00:00:11.094000000
Size = 1000000 time = +000000000 00:00:10.797000000

PL/SQL procedure successfully completed

То же с R-индексами, которых не помню кто из участников дискуссии остро хотел страниц двадцать назад.
21 ноя 06, 13:53    [3429629]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Gluk (Kazan)
Ну с чего бы изменение позиции одной записи вело к ПЕРЕСБОРКЕ цельного индекса ?
В индексе будет поправлен ROWID
Естественно. Но глупо было бы перемещать только одну запись в блоке на свободное место, не подтягивая остальные. Или наличие дыр считается нормальным?


Там идет номер блока и номер (а не смещение) строки в блоке. Так что если порядок строк не изменяется ничего в индексах поправлять не надо
21 ноя 06, 13:54    [3429634]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

Естественно. Но глупо было бы перемещать только одну запись в блоке на свободное место, не подтягивая остальные. Или наличие дыр считается нормальным?

Если перенос строки связан с нехваткой места ей в блоке, то блок и так заполнен (наскокак ему разрешено), а на месте старой зписи остается ссылка на новое место. На эту ссылку указывает ROWID. Ну два чтения вместо одного. Это вопросы физ проектирования, если таких окажется много.
Что глупо а что нет зависит от системы. Искать глупое в Оракле нам с Вами слишком не скромно. Для этого есть, например, Каша. Тут еще куда ни шло.
21 ноя 06, 13:56    [3429650]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Sergei Obrastsov
Gluk (Kazan)
Ну с чего бы изменение позиции одной записи вело к ПЕРЕСБОРКЕ цельного индекса ?
В индексе будет поправлен ROWID
Естественно. Но глупо было бы перемещать только одну запись в блоке на свободное место, не подтягивая остальные. Или наличие дыр считается нормальным?

Там идет номер блока и номер (а не смещение) строки в блоке. Так что если порядок строк не изменяется ничего в индексах поправлять не надо

А какой же это "прямой доступ", коли строки в блоке перебирать надо?
21 ноя 06, 14:01    [3429696]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67529
Блог
Sergei Obrastsov
Но глупо было бы перемещать только одну запись в блоке на свободное место, не подтягивая остальные.

Сомнительное утверждение.
21 ноя 06, 14:02    [3429702]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Gluk (Kazan)

Ой, ну нельзя же быть таким дремучим :(


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

Gluk (Kazan)

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


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

Gluk (Kazan)

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


безусловно, что недостатки есть, иначе все СУБД имели бы только хэш реализацию физического хранения индексных структур. Однако скажите, в каких типах задач требуется именно применение hash-organized-index?
21 ноя 06, 14:03    [3429709]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
А какой же это "прямой доступ", коли строки в блоке перебирать надо?


Я думаю, Вы понимаете, что издержки на любые операции внутри блока пренебрежимо малы по сравнению с логическими чтениями блоков
21 ноя 06, 14:08    [3429752]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Rus000
Gluk (Kazan)

Ой, ну нельзя же быть таким дремучим :(

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


К тому чтобы в следующий раз Вы подумали дважды прежде чем писать заведомую глупость
21 ноя 06, 14:09    [3429761]     Ответить | Цитировать Сообщить модератору
 Re: 12 правил "ну я" для форума SQL.RU  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Rus000
безусловно, что недостатки есть, иначе все СУБД имели бы только хэш реализацию физического хранения индексных структур. Однако скажите, в каких типах задач требуется именно применение hash-organized-index?


Все что предоставляет Oracle в плане физического хранения было востребовано в реальных задачах. Даже такая экзотика как кластеры по хэш. В любом случае лучше иметь НАБОР возможностей чем ОДНУ возможность за приблизительно ТЕ ЖЕ деньги.

Разьве не так ?
21 ноя 06, 14:12    [3429780]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Lulay
CACHE очень хорошо работает с иерархическими структурами, в этом её сила.

Еще один... Вы хоть знаете что это такое - иерархическая структура ? Определение в студию
21 ноя 06, 14:29    [3429901]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 39 40 41 42 43 [44] 45 46 47 48 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить