Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обращение к записи по RID / 17 сообщений из 17, страница 1 из 1
25.01.2012, 22:12
    #37631749
по RID
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
По идее обращение к записи по RID, который включает в себя непосредственно номер страницы и номер записи, будет быстрее индексного поиска Index Seek, т.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.
Действительно ли возможно так ускорить работу и что этому может помешать?
И использовали ли вы когда-нибудь подобный подход?
...
Рейтинг: 0 / 0
25.01.2012, 23:43
    #37631835
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
по RIDт.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.И сколько будет выигрыш (особенно если корневые блоки индекса скорее всего в буферном кэше). Кроме того сервер имеет полное право переместить строку никого при этом не уведомляя и не ожидая, то есть мы можем на ровном месте поймать трудноуловимый баг. Мое мнение - овчинка выделки не стоит.
В Оракле есть хэш кластер - способ организации таблиц с минимальной ценой доступа по первичному ключу, imho куда более достойная альтернатива.
...
Рейтинг: 0 / 0
25.01.2012, 23:56
    #37631851
по RID
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
SERG1257по RIDт.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.И сколько будет выигрыш (особенно если корневые блоки индекса скорее всего в буферном кэше). Кроме того сервер имеет полное право переместить строку никого при этом не уведомляя и не ожидая, то есть мы можем на ровном месте поймать трудноуловимый баг. Мое мнение - овчинка выделки не стоит.
В Оракле есть хэш кластер - способ организации таблиц с минимальной ценой доступа по первичному ключу, imho куда более достойная альтернатива.
Выигрышь будет равен числу уровней индекса не уместившихся в ОЗУ. А вот с тем что он перемещает ничего не говоря - это делает малопригодной данную методу. Надо будет обращаться по RID, после прочтения строки сверять с искомым ID, и если не найден, то уже выполнять Index Seek по ID.

А что за хэш-кластер в оракле? Знаю RAC-кластер, кластерные сджойненные таблицы, хэш-индекс, но хэш-кластер не знаю :)
...
Рейтинг: 0 / 0
26.01.2012, 09:47
    #37632094
Обращение к записи по RID
SERG1257В Оракле есть хэш кластер - способ организации таблиц с минимальной ценой доступа по первичному ключуКакое отношение первичный ключ имеет к хэш-кластеру?
...
Рейтинг: 0 / 0
26.01.2012, 12:33
    #37632531
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
по RIDДействительно ли возможно так ускорить работу и что этому может помешать?
Так действительно возможно ускорить работу, но при этом надо чётко понимать время достоверной жизни адреса (то есть между "получили RID" и "использовали RID" не должно происходить операций, способных его изменить)

по RIDИ использовали ли вы когда-нибудь подобный подход?
Ну, например он автоматически используется в кляузе UPDATE .. WHERE CURRENT OF.

по RIDА что за хэш-кластер в оракле
Можете считать, что это таблица, первичный ключ которой построен над хэш-индексом.
...
Рейтинг: 0 / 0
26.01.2012, 15:13
    #37633066
по RID
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
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. Т.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно.
...
Рейтинг: 0 / 0
26.01.2012, 16:09
    #37633258
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
по RIDЕсли мы не нашли запись по RID, т.е. не тот ID в ней или вообще не найдена строка, мы её ищем по ID.
Я крайне сомневаюсь в том, что люди на практике будут регулярно реализовывать подобные танцы, просто плюнут на "прирост эффективности".

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

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

по RIDТ.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно.
В Oracle кластером называется объединение произвольного количества таблиц. Основной смысл этого - материализация join-ов.
...
Рейтинг: 0 / 0
26.01.2012, 16:13
    #37633268
по RID
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
softwarerпо RIDТ.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно .
В Oracle кластером называется объединение произвольного количества таблиц. Основной смысл этого - материализация join-ов.
В хэш-кластере объединяется произвольное количество таблиц?
...
Рейтинг: 0 / 0
26.01.2012, 16:22
    #37633293
по RID
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
softwarerпо RIDТ.е. если я строю хэш-индекс по ID, а затем создаю по нему PK , то это будет хэш-кластер?
Когда сумеете это сделать, тогда будем придумывать этому название.
В чем разница?
softwarerпо RIDА что за хэш-кластер в оракле
Можете считать, что это таблица, первичный ключ которой построен над хэш-индексом .
Или вы утверждаете, что в Oracle нельзя создать PK с использованием уже имеющегося индекса, в том числе хэш-индекса?
...
Рейтинг: 0 / 0
26.01.2012, 17:07
    #37633435
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
по RIDВ хэш-кластере объединяется произвольное количество таблиц?
Код: plsql
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.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
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.
...
Рейтинг: 0 / 0
26.01.2012, 18:27
    #37633663
по RID
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
softwarer , ясно, хэш-кластер это и есть кластерные (сджойненные) таблицы? :)
Или есть все-таки разновидность физического размещения в тех же страницах строк сджойненных таблиц - это кластерные таблицы, и есть разновидность реализации соединения таблиц через внутренние хэш-индексы, т.е. строки разных таблиц лежат на разных страницах, но быстрое соединение осуществляется через внутренние хэш-индексы - и это хэш-кластер?
...
Рейтинг: 0 / 0
26.01.2012, 18:37
    #37633692
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
по RIDясно, хэш-кластер это и есть кластерные (сджойненные) таблицы?
Кластер - это сджойненные таблицы. На одних и тех же страницах вместе лежат строки всех таблиц кластера. В вырожденном случае в кластере может быть только одна таблица. Кластер строится на базе специального кластерного индекса, который может быть b-tree или hash. Доступ к записи может быть осуществлён на основании кластерного индекса (в том числе hash). Это является единственной в Oracle возможностью создать штатный (то есть не user defined) хэш-индекс. Почему не дают делать их без кластера - без понятия.
...
Рейтинг: 0 / 0
26.01.2012, 22:54
    #37634093
Обращение к записи по RID
softwarerПочему не дают делать их без кластера - без понятия.Потому что в Oracle не существует хэш-индексов. Ну и потому, что все, что написано ниже (за исключением фразы "Доступ к записи может быть осуществлён на основании кластерного индекса", которая истинна, но только для индексного кластера), - не верно.

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

Также в примере создание первичных ключей - лишнее и непонятно для чего продемонстрированное действие
...
Рейтинг: 0 / 0
26.01.2012, 23:03
    #37634108
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
Слышал звонНу и потому, что все, что написано ниже - не верно
Учитывая, что ниже той фразы только Ваш пост - завидная способность к самокритике.

Слышал звонТакже в примере создание первичных ключей - лишнее и непонятно для чего продемонстрированное действие
Ну подумайте.
...
Рейтинг: 0 / 0
26.01.2012, 23:11
    #37634118
по RID
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
Слышал звонsoftwarerПочему не дают делать их без кластера - без понятия.Потому что в Oracle не существует хэш-индексов. Ну и потому, что все, что написано ниже (за исключением фразы "Доступ к записи может быть осуществлён на основании кластерного индекса", которая истинна, но только для индексного кластера), - не верно.

softwarerКластер строится на базе специального кластерного индекса, который может быть b-tree или hash. Доступ к записи может быть осуществлён на основании кластерного индекса (в том числе hash). Это является единственной в Oracle возможностью создать штатный (то есть не user defined) хэш-индекс.
Так расскажите нам как же правильно, ответьте на вопрос по ссылке:
Обращение к записи по RID
...
Рейтинг: 0 / 0
27.01.2012, 07:58
    #37634336
Обращение к записи по RID
softwarerСлышал звонНу и потому, что все, что написано ниже - не верно
Учитывая, что ниже той фразы только Ваш пост - завидная способность к самокритике.Саша, не ёрничай. Я же вежливо написал - "не верно", а мог написать как есть на самом деле - "бред" ;-)
Почитай Concepts по ссылке, освежать старые знания и получать новые - полезно

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

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

Вот здесь кратко и хорошо описано
http://docs.oracle.com/cd/E11882_01/server.112/e25789/tablecls.htm#CNCPT608
По-русски и на доступном уровне описано в книге Тома Кайта "Oracle для профессионалов" - в гугле полно ссылок на закачку
...
Рейтинг: 0 / 0
27.01.2012, 13:51
    #37634974
artemana
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Обращение к записи по RID
по RIDПо идее обращение к записи по RID, который включает в себя непосредственно номер страницы и номер записи, будет быстрее индексного поиска Index Seek, т.к. не нужно несколько случайных чтений по каждому уровню индекса, а обращение идет непосредственно к странице и записи.
Действительно ли возможно так ускорить работу и что этому может помешать?
И использовали ли вы когда-нибудь подобный подход?

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

Пример.
Код: sql
1.
2.
3.
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, а больше. В реальных условиях большой ИС, заметить интегральный выигрыш скорее всего не удастся. Мы не мерили.
...
Рейтинг: 0 / 0
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обращение к записи по RID / 17 сообщений из 17, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]