Можем ли мы создать индекс Bitmap в столбце таблицы в Oracle 11, который перезагружается ежедневно с использованием задания

Question

У нас есть таблица, в которой хранится информация о клиентах, которая ежедневно загружается с использованием запланированного задания из хранилища данных. В этой таблице содержится более 1 миллиона записей. Я хотел определить индекс BitMap Index on Country, так как будет ограниченное количество значений. Имеет ли это влияние на индексы, если мы ежедневно удаляем и перезагружаем данные в таблицу. Нужно ли явно перестроить индекс после каждой загрузки.

Answer 1

Индекс растрового изображения опасен, когда таблица часто обновляется (индексированный столбец), поскольку DML в одной строке может блокировать много строк в таблице. Вот почему это больше инструментов хранилища данных, чем OLTP. Также истинная мощность индексов битмапа включает в себя объединение большего количества из них с использованием логических операций и перевод результата в ROWID (а затем доступ к строкам или их объединение). В Oracle вообще не так много причин для восстановления индекса. При частом изменении он всегда будет адаптироваться к расколу 50/50. Не имеет смысла пытаться свести его к минимально возможному пространству. Сегодня миллион строк - ничто, если каждая строка не содержит большого количества данных.

Также имейте в виду, что для индексов BITMAP требуется лицензия Enterprise edition.

Answer 2

Основанием для определения индекса растрового изображения является не несколько значений в столбце, а запрос (ы), который может получить от него доступ к строкам таблицы.

Например, если вы говорите, что 4 страны равны населению, Oracle не будет использовать индекс, поскольку FULL TABLE SCAN дешевле.

Если у вас есть «экзотические» страны (очень мало записей), можно использовать индекс BITMAP, но вы, скорее всего, не заметите разницы с обычным индексом.

Answer 3

Я хотел бы определить индекс BitMap Index в столбце Country, так как будет ограниченное количество значений.

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

Хорошее объяснение от Tom Kyte here.

Битовые индексы чрезвычайно полезны в средах, где у вас есть много нерегламентированных запросов, особенно запросов, которые ссылаются на много столбцов в бессистемно или производят агрегаты, такие как COUNT. Предположим, например, что у вас большой стол с тремя столбцами: GENDER, LOCATION и AGE_GROUP. В этой таблице GENDER имеет значение M или F, LOCATION может принимать значения от 1 до 50, а AGE_GROUP - код , представляющий 18 и младше, 19-25, 26-30, 31-40 и 41 и над.

Например,

Вы должны поддерживать большое количество специальных запросов, которые имеют следующий вид:

select count(*) 
    from T 
where gender = 'M' 
    and location in (1, 10, 30) 
    and age_group = '41 and over'; 

select * 
    from t 
where ( (gender = 'M' and location = 20) 
     or (gender = 'F' and location = 22)) 
    and age_group = '18 and under'; 

select count(*) from t where location in (11,20,30); 

select count(*) from t where age_group = '41 and over' and gender = 'F'; 

Вы нашли бы, что традиционная схема B*Tree индексации будет подведет. Если вы хотите использовать индекс для получения ответа, для доступа к данным через индекс вам потребуется не менее трех и до шести комбинаций возможных индексов B*Tree.Поскольку любой из трех колонок или любого подмножества из трех столбцов может показаться, что вам нужно будет большой конкатенации B индексов * Tree на

• пола, места жительства, age_group: Для запросов, которые используют все три, или ПОЛ с РАСПОЛОЖЕНИЕ, или в одиночку GENDER
• МЕСТО, age_group: Для запросов, используемых МЕСТОПОЛОЖЕНИЕ и age_group или РАСПОЛОЖЕНИЕ в одиночку
• age_group, ПОЛ: Для запросов, которые используются age_group с гендерными или age_group в одиночку

Answer 4

Наличие только одного индекса Bitmap на столе в большинстве случаев бесполезно. Преимущество индексов Bitmap, которые вы получаете, когда у вас несколько созданных на столе, и ваш запрос объединяет их.

Возможно, List-Partition более подходит в вашем случае.