Лучшая комбинация индексов и разделов для больших таблиц Oracle с большим количеством поисковых запросов?

У меня есть база данных Oracle 10g геномных данных с несколькими таблицами> 100 миллионов строк, которые выглядят примерно так:

ID    AssayID    Sample      Mutation    Call Frequency
101   12578      Sample01    T367G       P    0.87
102   31384      Sample01    A2345C      A    0.28
103   3453       Sample01    T247C       P    0.67
104   12578      Sample02    G235del     M    0.11
105   7868       Sample02    None        P    0.98
  • ID — это уникальный ПК, AssayID и Sample — внешние ключи.
  • Предположим, что для каждого значения Sample есть ~ 50 тыс. строк.
  • Каждый AssayID встречается ровно один раз в Sample.
  • Mutation является относительно случайным, а Call может быть одним из трех значений.
  • Запросы к этой таблице могут использовать любую комбинацию AssayID, Sample, Mutation, Call или значение в связанной таблице через AssayID и Sample.

Типичный запрос:

select t.*
from this_table t
    join assay_table a on t.assayid = a.assayid
    join sample_table s on t.sample = s.sample
where 
    s.name = 'xxx' and a.gene in ('abc', 'xyz') and t.call = 'P'
  • Запросы к этим таблицам всегда объединяют несколько меньших таблиц.
  • Оператор WHERE обычно фильтрует данные по нескольким столбцам, но никогда только по базовой таблице данных.

Как спроектировать таблицу, чтобы добиться наилучшей производительности запросов при выборе всех столбцов?
Использую ли я только индексы, только разделы или их комбинацию? Место на диске и производительность вставки/обновления не являются проблемой.


person woemler    schedule 26.06.2012    source источник
comment
Когда вы говорите сочетание, вы имеете в виду И или ИЛИ?   -  person Branko Dimitrijevic    schedule 27.06.2012
comment
Оба. Мне любопытно, даст ли комбинация индексов и схем секционирования, или просто партиций, или просто индексов наилучшую производительность запросов в описанной ситуации.   -  person woemler    schedule 27.06.2012
comment
Если для каждого уникального значения name имеется ~ 50 тыс. строк, каждое attr2 встречается 1 тыс. раз для каждого имени, откуда берется другой множитель 50? Если каждый attr1 и otherID встречается один раз для каждого имени, остается только id для создания дополнительного 50-кратного множителя, что кажется странным. Таблица, которую вы описываете, также кажется очень денормализованной: если для каждого name существует 1000 различных значений attr2, это означает, что attr2 должно находиться в другой таблице, связанной с этой с помощью первичного ключа. Почему вы не нормализуете таблицу, если вас беспокоит производительность?   -  person Justin Cave    schedule 27.06.2012
comment
Общее практическое правило: секционирование для повышения производительности будет работать правильно только в том случае, если ваши запросы всегда содержат ключ секционирования.   -  person a_horse_with_no_name    schedule 27.06.2012
comment
@Justin Cave: Извините, это представление таблицы немного упрощено, но я попытался представить поля, которые будут запрашиваться. Я обновил свой вопрос, чтобы включить больше столбцов данных для лучшей картины. Что касается нормализации, эта база данных очень сильно нормализована. Подобные таблицы данных часто связаны с несколькими таблицами аннотаций (например, через OtherID), которые могут иметь более 10 дочерних таблиц. Иногда такие столбцы, как Attr2, не имеют дополнительных метаданных, поэтому нет необходимости в еще одной таблице.   -  person woemler    schedule 27.06.2012
comment
@a_horse_with_no_name: Если запрос к многораздельным таблицам не включает ключ раздела, всегда ли будет происходить полное сканирование таблицы всех разделов? Если это так, это устранит разделение из моих вариантов, поскольку запрашиваемые столбцы могут различаться.   -  person woemler    schedule 27.06.2012
comment
Если запрос не фильтрует ключ разделения, вам придется либо просмотреть все разделы, либо просмотреть глобальный индекс, либо просмотреть все разделы локального индекса, чтобы получить данные. Мне трудно согласовать ваше описание очень сильно нормализованной таблицы с описанием этой таблицы, в которой данные повторяются 50 тысяч раз. Если существует связь 1:many между name и attr2, attr2 должна находиться в отдельной таблице. Если таблица на самом деле нормализована, возможно, некоторые примеры данных помогут нам понять, как согласовать ваши описания.   -  person Justin Cave    schedule 27.06.2012
comment
Добавлены некоторые примеры данных, которые, надеюсь, помогут.   -  person woemler    schedule 27.06.2012
comment
На самом деле вы не получаете максимальную производительность от таблицы, а только от запросов к этой таблице. Чтобы иметь возможность ответить на ваш вопрос, нам нужно просмотреть все или только важные запросы к этой таблице.   -  person Rob van Wijk    schedule 27.06.2012
comment
@Rob van Wijk: Достаточно честно. Обычно запросы к этим таблицам извлекают все столбцы.   -  person woemler    schedule 27.06.2012
comment
Спасибо за все конструктивные комментарии. Я продолжаю редактировать вопрос, чтобы сделать его более информативным и простым для ответа. Я знаю, что на этот вопрос невозможно ответить однозначно.   -  person woemler    schedule 28.06.2012
comment
Что, если в данном примере я разобью таблицу по Sample и создам глобально разделенный индекс по Mutation? Если 90% запросов ссылаются на Sample и 10% ссылаются на Mutation, имеет ли это смысл? Насколько я могу судить, индексирование и разбиение примера таблицы не имеет значения, если запрос фильтрует только столбец в объединенной таблице.   -  person woemler    schedule 28.06.2012


Ответы (2)


В качестве первого шага вы можете запустить Oracle SQL Access Advisor и посмотреть, какие рекомендации он дает.

person mavroprovato    schedule 27.06.2012
comment
К сожалению, на моей машине Enterprise Manager работает некорректно, поэтому я не могу попробовать SQL Access Advisor. - person woemler; 27.06.2012
comment
Если у вас есть учетная запись службы поддержки Oracle, загрузите и примените исправление 8350262. Во время установки Enterprise Manager для 10g происходит сбой из-за просроченного сертификата. - person mavroprovato; 27.06.2012
comment
Проблема, похоже, связана с неправильным синтаксисом в файле tnsnames.ora (что странно, поскольку у меня нет этой проблемы с любым другим приложением, которое его читает). Я еще не обнаружил проблему, но я проверю это, когда выясню это. В настоящее время я жду, чтобы применить патч. - person woemler; 28.06.2012

После создания многочисленных тестовых копий таблиц с различными комбинациями индексов и разделов и проведения ряда анализов производительности с использованием широкого набора запросов я не думаю, что на этот вопрос существует единственный простой ответ. Каждая ситуация индивидуальна, и объем этого вопроса слишком широк для этого форума. Спасибо всем за отзывы, все было полезно.

person woemler    schedule 29.06.2012