Последовательные (гребенчатые) идентификаторы GUID для Oracle

Мы находимся в процессе перехода от генератора случайных руководств C # Guid.NewGuid () к последовательному алгоритму руководств, предложенному в этот пост. Хотя это, кажется, хорошо работает для MS SQL Server, я не уверен в том, что это может быть связано с базами данных Oracle, в которых мы храним идентификаторы в необработанном (16) поле. Есть ли у кого-нибудь представление о том, подойдет ли этот алгоритм для создания последовательных руководств для Oracle, а также для MS SQL Server, или следует использовать другой вариант.

Спасибо!


c# sql-server oracle guid sequential
person Eyvind    schedule 07.04.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Использование raw (16) кажется разумным типом данных для GUID. Максимальный размер необработанных данных составляет 2000 байт и поддерживается в Oracle 9i, 10g и 11.

Также существует функция sql для генерации GUID, она называется SYS_GUID. см. документацию здесь-> http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/functions153.htm

Возможно, вам будет интересна эта статья -> http://feuergotits.blogspot.com/2006/02/watch-out-for-sequential-oracle-guids.html

person Oliver Michels    schedule 07.04.2010
comment
Спасибо за ваш ответ. Однако меня интересует не то, является ли raw хорошим типом данных для руководств в Oracle, а скорее то, вызовет ли рассматриваемый алгоритм ненужную фрагментацию индекса в Oracle, даже если он кажется хорошим выбором для MS SQL Server. Кроме того, мне нужно сгенерировать свои гиды на клиенте, поэтому функция SYS_GUID не поможет. - person Eyvind; 07.04.2010
comment
Что такое ненужная фрагментация индекса? Конечно, идентификаторы GUID будут разбросаны (фрагментированы) по всей комнате возможных данных. Вот для чего нужен GUID. Фрагментация данных - это неотъемлемое свойство алгоритма GUID, которое база данных должна обрабатывать, независимо от того, является ли это sql-сервером или оракулом. Реализация индекса может справиться с этим, см. - ›en.wikipedia.org/wiki/B-tree < / а> - person Oliver Michels; 07.04.2010
comment
Идея состоит в том, чтобы использовать алгоритм, который генерирует последовательные направляющие вместо стандартной рандомизированной версии. - person Eyvind; 07.04.2010
comment
Итак, вы имеете в виду упорядоченные идентификаторы GUID (COMB), как описано в informit. ru / article / article.aspx? p = 25862 & seqNum = 7. Здесь (COMB) первые 10 байтов случайны и имеют постфикс из 6 байтов, представляющий DATETIME, когда были сгенерированы GUID. Я не вижу проблемы с фрагментацией индекса. - person Oliver Michels; 07.04.2010
comment
Да, я имею в виду COMB GUID (как указано в заголовке). В частности, я имею в виду реализацию последовательных (гребенчатых) GUID в NHibernate (также ссылки на которые приведены в сообщении). Как видно из этого алгоритма, биты упорядочены специально для алгоритма сортировки, применяемого MS SQL Server для типа данных UNIQUEIDENTIFIER. Таким образом, повторю свой вопрос (надеюсь, на этот раз более ясный): как такие данные будут сортироваться в необработанном (16) поле в Oracle? Будут ли значения по-прежнему находиться в случайном порядке из-за битов алгоритма .NET Guid.NewGuid () или они будут упорядочены последовательно? - person Eyvind; 09.04.2010
comment
Итак, возможно, вы имеете в виду это обсуждение сообщества NHibernate - ›nhforge.org/blogs/nhibernate/archive/2009/03/20/ NHibernate изобрел алгоритм Guid.Comb, который решает проблему фрагментации таблиц в ms-sqlserver. В связи с тем, что оракулы работают совершенно иначе, чем my-sqlserver, когда дело доходит до управления дисковыми блоками базы данных, я считаю алгоритм Guid.Comb бесполезным, но не вредным при использовании в качестве генератора идентификаторов для оракула. - person Oliver Michels; 09.04.2010
comment
oracles работает совершенно иначе, чем ms-sqlserver, при вставке новых строк в блоки базы данных (PCTFREE, PCTUSED, расширение размеров, локально управляемые табличные пространства и т. д. и т. д. и т. д.), поэтому требования для предотвращения фрагментации таблиц совершенно другие . - person Oliver Michels; 09.04.2010
comment
@Oliver Michels: у вас есть идеи, как действовать, чтобы избежать фрагментации таблиц / индексов в Oracle? - person massimogentilini; 02.03.2011
comment
единственная стратегия против фрагментации таблиц / индексов, о которой я могу думать, - это сбор точной статистики таблиц и индексов. Если обновленная статистика показывает наличие реальной проблемы, индекс следует реорганизовать. Главное - определить существенную необходимость реорганизации. - person Oliver Michels; 14.03.2011

arrow_upward
1
arrow_downward

Когда индексный блок «переполнен» для еще одной записи, он разбивается.

Oracle имеет два пути: один оптимизирован для значений «последовательного» стиля, а другой - для значений «случайного» типа. Если новая запись находится в самом правом конце индекса, вы получите разделение 90-10. Если он находится где-то посередине, вы получите 50-50. Если вы хотите, чтобы «новые» значения были сгруппированы вместе в индексе, полезно использовать последовательное значение. Если вы хотите, чтобы они были разбросаны (например, чтобы избежать конкуренции за «горячие» блоки), тогда полезно использовать случайные значения.

Подходит ли эта техника Oracle, зависит от того, какую проблему вы пытаетесь решить.

person Gary Myers    schedule 08.04.2010