Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Обращение к записи по RID  [new]
по RID
Guest
По идее обращение к записи по RID, который включает в себя непосредственно номер страницы и номер записи, будет быстрее индексного поиска Index Seek, т.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.
Действительно ли возможно так ускорить работу и что этому может помешать?
И использовали ли вы когда-нибудь подобный подход?
25 янв 12, 22:12    [11972180]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
SERG1257
Member

Откуда:
Сообщений: 2934
по RID
т.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.
И сколько будет выигрыш (особенно если корневые блоки индекса скорее всего в буферном кэше). Кроме того сервер имеет полное право переместить строку никого при этом не уведомляя и не ожидая, то есть мы можем на ровном месте поймать трудноуловимый баг. Мое мнение - овчинка выделки не стоит.
В Оракле есть хэш кластер - способ организации таблиц с минимальной ценой доступа по первичному ключу, imho куда более достойная альтернатива.
25 янв 12, 23:43    [11972683]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
по RID
Guest
SERG1257
по RID
т.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.
И сколько будет выигрыш (особенно если корневые блоки индекса скорее всего в буферном кэше). Кроме того сервер имеет полное право переместить строку никого при этом не уведомляя и не ожидая, то есть мы можем на ровном месте поймать трудноуловимый баг. Мое мнение - овчинка выделки не стоит.
В Оракле есть хэш кластер - способ организации таблиц с минимальной ценой доступа по первичному ключу, imho куда более достойная альтернатива.

Выигрышь будет равен числу уровней индекса не уместившихся в ОЗУ. А вот с тем что он перемещает ничего не говоря - это делает малопригодной данную методу. Надо будет обращаться по RID, после прочтения строки сверять с искомым ID, и если не найден, то уже выполнять Index Seek по ID.

А что за хэш-кластер в оракле? Знаю RAC-кластер, кластерные сджойненные таблицы, хэш-индекс, но хэш-кластер не знаю :)
25 янв 12, 23:56    [11972734]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
Слышал звон
Guest
SERG1257
В Оракле есть хэш кластер - способ организации таблиц с минимальной ценой доступа по первичному ключу
Какое отношение первичный ключ имеет к хэш-кластеру?
26 янв 12, 09:47    [11973427]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
по RID
Действительно ли возможно так ускорить работу и что этому может помешать?

Так действительно возможно ускорить работу, но при этом надо чётко понимать время достоверной жизни адреса (то есть между "получили RID" и "использовали RID" не должно происходить операций, способных его изменить)

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

Ну, например он автоматически используется в кляузе UPDATE .. WHERE CURRENT OF.

по RID
А что за хэш-кластер в оракле

Можете считать, что это таблица, первичный ключ которой построен над хэш-индексом.
26 янв 12, 12:33    [11974608]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
по RID
Guest
softwarer
по RID
Действительно ли возможно так ускорить работу и что этому может помешать?

Так действительно возможно ускорить работу, но при этом надо чётко понимать время достоверной жизни адреса (то есть между "получили RID" и "использовали RID" не должно происходить операций, способных его изменить)

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

Ну, например он автоматически используется в кляузе UPDATE .. WHERE CURRENT OF.

А при отношении записей 1 к 1 описанный мною вариант пригоден? "Надо будет обращаться по RID, после прочтения строки сверять с искомым ID, и если не найден, то уже выполнять Index Seek по ID."
Если мы не нашли запись по RID, т.е. не тот ID в ней или вообще не найдена строка, мы её ищем по ID.


softwarer
по RID
А что за хэш-кластер в оракле

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

Т.е. если я строю хэш-индекс по ID, а затем создаю по нему PK, то это будет хэш-кластер?
А если построю b-tree индекс по ID, а затем по нему PK, то это b-tree-кластер? :)
"Хэш-кластер" это действительно официальное название?

К примеру в том же MS SQL кластерный индекс - это индекс по PK, когда в листьях не RID, а сами данные, фактически это IOT. Т.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно.
26 янв 12, 15:13    [11976394]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
по RID
Если мы не нашли запись по RID, т.е. не тот ID в ней или вообще не найдена строка, мы её ищем по ID.

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

по RID
Т.е. если я строю хэш-индекс по ID, а затем создаю по нему PK, то это будет хэш-кластер?

Когда сумеете это сделать, тогда будем придумывать этому название.

по RID
"Хэш-кластер" это действительно официальное название?

Да.

по RID
Т.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно.

В Oracle кластером называется объединение произвольного количества таблиц. Основной смысл этого - материализация join-ов.
26 янв 12, 16:09    [11977024]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
по RID
Guest
softwarer
по RID
Т.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно.

В Oracle кластером называется объединение произвольного количества таблиц. Основной смысл этого - материализация join-ов.

В хэш-кластере объединяется произвольное количество таблиц?
26 янв 12, 16:13    [11977062]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
по RID
Guest
softwarer
по RID
Т.е. если я строю хэш-индекс по ID, а затем создаю по нему PK, то это будет хэш-кластер?

Когда сумеете это сделать, тогда будем придумывать этому название.

В чем разница?
softwarer
по RID
А что за хэш-кластер в оракле

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

Или вы утверждаете, что в Oracle нельзя создать PK с использованием уже имеющегося индекса, в том числе хэш-индекса?
26 янв 12, 16:22    [11977139]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
по RID
В хэш-кластере объединяется произвольное количество таблиц?

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 
Connected as test
 
SQL> create cluster hhh (n# integer) hash is n# hashkeys 256;
 
Cluster created
 
SQL> create table h1(n# integer, c# varchar2(100)) cluster hhh(n#);
 
Table created
 
SQL> create table h2(n# integer, k# integer, c# varchar2(100)) cluster hhh(n#);
 
Table created
 
SQL> create table h3(n# integer, k# integer, c# varchar2(100)) cluster hhh(n#);
 
Table created
 
SQL> alter table h1 add primary key(n#);
 
Table altered
 
SQL> alter table h2 add primary key(n#, k#);
 
Table altered
 
SQL> explain plan for select * from h1, h2 where h1.n# = h2.n#;
 
Explained
 
SQL> select * from table(dbms_xplan.display());
 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 128377940
---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   443 |    75   (0)| 00:00:01 |
|   1 |  NESTED LOOPS      |      |     1 |   443 |    75   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| H1   |     1 |   215 |    75   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS HASH| H2   |     1 |   228 |            |          |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("H1"."N#"="H2"."N#")
Note
-----
   - dynamic sampling used for this statement (level=2)
 
19 rows selected
 
SQL> 


по RID
Или вы утверждаете, что в Oracle нельзя создать PK с использованием уже имеющегося индекса,

Можно.

по RID
в том числе хэш-индекса?

В Oracle нельзя создать хэш-индекс. По этой причине немного затруднительно создавать над ним PK.
26 янв 12, 17:07    [11977612]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
по RID
Guest
softwarer, ясно, хэш-кластер это и есть кластерные (сджойненные) таблицы? :)
Или есть все-таки разновидность физического размещения в тех же страницах строк сджойненных таблиц - это кластерные таблицы, и есть разновидность реализации соединения таблиц через внутренние хэш-индексы, т.е. строки разных таблиц лежат на разных страницах, но быстрое соединение осуществляется через внутренние хэш-индексы - и это хэш-кластер?
26 янв 12, 18:27    [11978581]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
по RID
ясно, хэш-кластер это и есть кластерные (сджойненные) таблицы?

Кластер - это сджойненные таблицы. На одних и тех же страницах вместе лежат строки всех таблиц кластера. В вырожденном случае в кластере может быть только одна таблица. Кластер строится на базе специального кластерного индекса, который может быть b-tree или hash. Доступ к записи может быть осуществлён на основании кластерного индекса (в том числе hash). Это является единственной в Oracle возможностью создать штатный (то есть не user defined) хэш-индекс. Почему не дают делать их без кластера - без понятия.
26 янв 12, 18:37    [11978658]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
Слышал звон
Guest
softwarer
Почему не дают делать их без кластера - без понятия.
Потому что в Oracle не существует хэш-индексов. Ну и потому, что все, что написано ниже (за исключением фразы "Доступ к записи может быть осуществлён на основании кластерного индекса", которая истинна, но только для индексного кластера), - не верно.

softwarer
Кластер строится на базе специального кластерного индекса, который может быть b-tree или hash. Доступ к записи может быть осуществлён на основании кластерного индекса (в том числе hash). Это является единственной в Oracle возможностью создать штатный (то есть не user defined) хэш-индекс.


Также в примере создание первичных ключей - лишнее и непонятно для чего продемонстрированное действие
26 янв 12, 22:54    [11979918]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
Слышал звон
Ну и потому, что все, что написано ниже - не верно

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

Слышал звон
Также в примере создание первичных ключей - лишнее и непонятно для чего продемонстрированное действие

Ну подумайте.
26 янв 12, 23:03    [11979954]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
по RID
Guest
Слышал звон
softwarer
Почему не дают делать их без кластера - без понятия.
Потому что в Oracle не существует хэш-индексов. Ну и потому, что все, что написано ниже (за исключением фразы "Доступ к записи может быть осуществлён на основании кластерного индекса", которая истинна, но только для индексного кластера), - не верно.

softwarer
Кластер строится на базе специального кластерного индекса, который может быть b-tree или hash. Доступ к записи может быть осуществлён на основании кластерного индекса (в том числе hash). Это является единственной в Oracle возможностью создать штатный (то есть не user defined) хэш-индекс.

Так расскажите нам как же правильно, ответьте на вопрос по ссылке:
Обращение к записи по RID
26 янв 12, 23:11    [11979985]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
Слышал звон
Guest
softwarer
Слышал звон
Ну и потому, что все, что написано ниже - не верно

Учитывая, что ниже той фразы только Ваш пост - завидная способность к самокритике.
Саша, не ёрничай. Я же вежливо написал - "не верно", а мог написать как есть на самом деле - "бред" ;-)
Почитай Concepts по ссылке, освежать старые знания и получать новые - полезно

softwarer
Ну подумайте.
Чтобы показать, что можно создавать первичные ключи по таблицам, хранящимся в хэш-кластере? Чтобы показать, что знаешь команду по созданию первичных ключей?

по RID
Так расскажите нам как же правильно, ответьте на вопрос по ссылке:
Обращение к записи по RID


Вот здесь кратко и хорошо описано
http://docs.oracle.com/cd/E11882_01/server.112/e25789/tablecls.htm#CNCPT608
По-русски и на доступном уровне описано в книге Тома Кайта "Oracle для профессионалов" - в гугле полно ссылок на закачку
27 янв 12, 07:58    [11980697]     Ответить | Цитировать Сообщить модератору
 Re: Обращение к записи по RID  [new]
artemana
Member

Откуда: Днепропетровск
Сообщений: 1929
по RID
По идее обращение к записи по RID, который включает в себя непосредственно номер страницы и номер записи, будет быстрее индексного поиска Index Seek, т.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.
Действительно ли возможно так ускорить работу и что этому может помешать?
И использовали ли вы когда-нибудь подобный подход?


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

Пример.
select *
  from Chield
  left join Master on Master.Id=Chield.MasterId]

Коротко говоря, внутри записи Chield кроме значения MasterId, хранится физический адрес этой записи (RID-в Вашей терминологии). И в случае приведенного запроса, при подсоединение записи из таблицы Master индекс этой таблицы не используется, - запись Master грузится по RID.

Да, как уже сказали выше, физический адрес может изменятся, поэтому такая система оснащается блоком контроля актуальности запомненного физического адреса. Устроена она не сложно, сразу после загрузки Master записи по ее физическому адресу проверяется соответствие Master.Id=Chield.MasterId. Если он выполнено все Ок, если нет, то выполняется поиск нового RID по Chield.MasterId с сохранением его в записи Chield. Тут уже используется индекс, но так как физический aдрес меняется редко, то подавляющее число запросов, подобных приведенному, идет коротким путем. Цена – увеличение размера записи Chield таблицы

Добавлю, что такая оптимизация в лабораторных условиях, заметный (десятки процентов) выйгрыш дает. Особенно если соединений в запросе будет не 2, а больше. В реальных условиях большой ИС, заметить интегральный выигрыш скорее всего не удастся. Мы не мерили.
27 янв 12, 13:51    [11983018]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить