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

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

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

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

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

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

по RIDТ.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно.
В Oracle кластером называется объединение произвольного количества таблиц. Основной смысл этого - материализация join-ов.
...
Рейтинг: 0 / 0
Обращение к записи по RID
    #37633268
по RID
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarerпо RIDТ.е. кластерный индекс - объединение индекса и данных. А что в хэш-кластере объединяется - не понятно .
В Oracle кластером называется объединение произвольного количества таблиц. Основной смысл этого - материализация join-ов.
В хэш-кластере объединяется произвольное количество таблиц?
...
Рейтинг: 0 / 0
Обращение к записи по RID
    #37633293
по RID
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarerпо RIDТ.е. если я строю хэш-индекс по ID, а затем создаю по нему PK , то это будет хэш-кластер?
Когда сумеете это сделать, тогда будем придумывать этому название.
В чем разница?
softwarerпо RIDА что за хэш-кластер в оракле
Можете считать, что это таблица, первичный ключ которой построен над хэш-индексом .
Или вы утверждаете, что в Oracle нельзя создать PK с использованием уже имеющегося индекса, в том числе хэш-индекса?
...
Рейтинг: 0 / 0
Обращение к записи по RID
    #37633435
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по 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
Обращение к записи по RID
    #37633663
по RID
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer , ясно, хэш-кластер это и есть кластерные (сджойненные) таблицы? :)
Или есть все-таки разновидность физического размещения в тех же страницах строк сджойненных таблиц - это кластерные таблицы, и есть разновидность реализации соединения таблиц через внутренние хэш-индексы, т.е. строки разных таблиц лежат на разных страницах, но быстрое соединение осуществляется через внутренние хэш-индексы - и это хэш-кластер?
...
Рейтинг: 0 / 0
Обращение к записи по RID
    #37633692
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по RIDясно, хэш-кластер это и есть кластерные (сджойненные) таблицы?
Кластер - это сджойненные таблицы. На одних и тех же страницах вместе лежат строки всех таблиц кластера. В вырожденном случае в кластере может быть только одна таблица. Кластер строится на базе специального кластерного индекса, который может быть b-tree или hash. Доступ к записи может быть осуществлён на основании кластерного индекса (в том числе hash). Это является единственной в Oracle возможностью создать штатный (то есть не user defined) хэш-индекс. Почему не дают делать их без кластера - без понятия.
...
Рейтинг: 0 / 0
Обращение к записи по RID
    #37634093
softwarerПочему не дают делать их без кластера - без понятия.Потому что в Oracle не существует хэш-индексов. Ну и потому, что все, что написано ниже (за исключением фразы "Доступ к записи может быть осуществлён на основании кластерного индекса", которая истинна, но только для индексного кластера), - не верно.

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

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

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

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

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

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

Вот здесь кратко и хорошо описано
http://docs.oracle.com/cd/E11882_01/server.112/e25789/tablecls.htm#CNCPT608
По-русски и на доступном уровне описано в книге Тома Кайта "Oracle для профессионалов" - в гугле полно ссылок на закачку
...
Рейтинг: 0 / 0
Обращение к записи по RID
    #37634974
Фотография artemana
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по 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
17 сообщений из 17, страница 1 из 1
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обращение к записи по RID
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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