sql >> Base de Datos >  >> RDS >> Oracle

Oracle:búsqueda de texto completo con condición

Texto de Oracle

1 - Puede mejorar el rendimiento creando el índice CONTEXT con FILTRAR POR:

create index my_idx on my_table(text) indextype is ctxsys.context filter by group_id;

En mis pruebas el filter by definitivamente mejoró el rendimiento, pero aun así fue un poco más rápido usar solo un índice btree en group_id.

2 - Los índices CTXCAT usan "subíndices" y parecen funcionar de manera similar a un índice de varias columnas. Esta parece ser la opción (4) que estás buscando:

begin
  ctx_ddl.create_index_set('my_table_index_set');
  ctx_ddl.add_index('my_table_index_set', 'group_id');
end;
/

create index my_idx2 on my_table(text) indextype is ctxsys.ctxcat
    parameters('index set my_table_index_set');

select * from my_table where catsearch(text, 'blah', 'group_id = 43') > 0

Este es probablemente el enfoque más rápido. El uso de la consulta anterior contra 120 MB de texto aleatorio similar a su escenario A y B requirió solo 18 obtenciones consistentes. Pero en el lado negativo, la creación del índice CTXCAT llevó casi 11 minutos y usó 1,8 GB de espacio.

(Nota:Oracle Text parece funcionar correctamente aquí, pero no estoy familiarizado con Text y no puedo garantizar que este no sea un uso inapropiado de estos índices como dijo @NullUserException).

Índices de varias columnas frente a uniones de índice

Para la situación que describe en su edición, normalmente no habría una diferencia significativa entre usar un índice en (A, B) y unir índices separados en A y B. Construí algunas pruebas con datos similares a los que describiste y una unión de índice requirió solo 7 obtenciones consistentes versus 2 obtenciones consistentes para el índice de varias columnas.

La razón de esto es que Oracle recupera datos en bloques. Un bloque suele ser de 8K y un bloque de índice ya está ordenado, por lo que probablemente pueda ajustar los valores de 500 a 2000 en unos pocos bloques. Si le preocupa el rendimiento, normalmente lo único que importa es la E/S para leer y escribir bloques. Ya sea que Oracle tenga o no que unir unas pocas miles de filas, es una cantidad intrascendente de tiempo de CPU.

Sin embargo, esto no se aplica a los índices de Oracle Text. Puede unir un índice CONTEXT con un índice btree (¿un "mapa de bits y"?), pero el rendimiento es deficiente.