Когда вы используете табличные кластеры?

Основной особенностью кластеров таблиц является то, что вы можете хранить связанные строки разных таблиц в одном и том же физическом расположении.

Это может повысить производительность соединения на порядок. Однако это не так часто окупается, как кажется.

Единственный раз, когда я использовал его, было соединение с тремя таблицами, выполненное двумя hash соединениями. Это заняло слишком много времени ;). Однако соединение находилось в том же столбце, поэтому можно было использовать кластер таблиц hash, управляемый ключом столбца join. Это привело к тому, что все связанные строки будут храниться рядом (в идеале, в одном блоке базы данных). Зная это, Oracle может выполнить соединение со специальной оптимизацией ("Cluster join").

Он более или менее предварительно присоединен, но все еще чувствует себя как обычные таблицы (для INSERT/SELECT/UPDATE/DELETE).

С другой стороны, существуют "single table clusters", которые в основном используются для управления "clustering factor"-аналогичная идея, как кластеризованные индексы (называемые Index-Organized-Table в Oracle), но не добавляющие больших затрат при использовании вторичного индекса.

Можно много говорить о кластеризации, но я обнаружил, что почти полное объяснение о кластерах Oracle (плюсы и минусы , когда использовать и как использовать) можно найти в книге Тома Кайта - Effective Oracle by Design , также вы можете искать asktom для некоторых конкретных примеров использования кластеров ( 1, 2 и т. д.). Вы определенно должны взглянуть на эту книгу, если вы еще не сделали этого.

Некоторую информацию вы также можете найти здесь .

Но то, что вы всегда должны делать перед созданием сложных схемных структур, - это пробовать, тестировать, тестировать и выбирать одно решение, которое наилучшим образом соответствует вашим потребностям :)

Надеюсь, это поможет.

Я сам не использовал кластеры таблиц Oracle, но я понимаю, что его кластеры таблиц индексов очень похожи на кластеризованные индексы MS SQL Server. То есть данные строки физически организованы ключом кластеризованного индекса.

Это делает его идеальным для столбца с интенсивным доступом, который имеет достаточно малое число возможных значений (по сравнению с общим числом строк), где большинство запросов хотят получить все строки с определенным значением. Поскольку все такие строки физически хранятся вместе, диск I/O,, особенно время поиска, сокращается.

"Reasonably small" нелегко определить, но почтовые или zip коды в адресной таблице кажутся разумными, если вы часто запрашиваете все адреса в одном регионе кода. Province/state/territory коды, вероятно, слишком малы для выбора в таблице адресов по всей стране.

Таким образом, вы не хотите использовать их в Столбцах с несколькими возможными значениями (например, M/F для пола), потому что тогда кластеризация ничего вам не даст и, скорее всего, будет стоить вам вставок. Вы также никогда не захотите использовать кластеризацию на "autonumber" суррогатных ключевых столбцах (из последовательностей в Oracle), потому что это создаст "hot spot" в последнем экстенте таблицы, поскольку все вставки должны физически происходить там. Вы также не хотите применять кластеризацию к значению столбца, которое будет обновляться, поскольку RDBMS придется физически переместить запись для поддержания кластеризованного порядка.