Estructura de datos que permite búsquedas eficientes basadas en etiquetas

Estoy buscando una estructura de datos altamente eficiente para el almacenamiento de datos similar a la siguiente.

Etiquetas de identificación Order1 Order2 
--------------------------
1 1,2 1 1
2 2,5 2 3
3 1,7 4 7
4 6 3 0

Tengo que ser capaz de consultar esta estructura de tal manera que me daría una lista de todos los identificadores que contienen una expresión de etiquetas - el apoyo ANDy ORy NOToperaciones. P.ej. ((1 o 2) y no 7)

También necesito poder especificar el orden de los resultados (Order1 u Order2) y poder especificar las filas máximas devueltas con un desplazamiento opcional. El rendimiento para la obtención de los primeros 30-100 resultados es clave.

Finalmente, necesito una forma barata de buscar "relaciones de etiqueta", por ejemplo, quiero saber qué etiquetas "se relacionan" con las etiquetas (1 O 2) y con qué frecuencia. Significa qué etiquetas aparecen en el mismo conjunto que 1 O 2 ... ordenadas por frecuencia.

¿Alguna idea de qué estructura de datos (o conjunto de estructuras) sería altamente eficiente para este tipo de trabajo?

(Me gustaría usar esto como una prueba de concepto para rediseñar las páginas etiquetadas de la familia de sitios SE)

ds.data-structures application-of-theory db.databases Sam Azafrán
fuente

Solo un comentario (quizás trivial). ¿Por qué no confía en un sistema de gestión de bases de datos relacionales? Puede definir una tabla con los pares <id, tag> y agregar un índice en la columna de etiqueta. Luego puede usar consultas SQL estándar para extraer datos. El RDBMS realizará eficientemente el trabajo "sucio" de optimización de consultas y clasificación de salida.

Marzio De Biasi

@Vor, las expresiones son increíblemente ineficientes a gran escala, las autouniones se convierten en consultas de pesadilla.

Sam Saffron

@ Sam: ok. Su tarea es bastante común, así que pensé que un buen RDBMS (con una herramienta de minería de datos) podría hacer el trabajo. Dejo la palabra a un experto en estructura de datos. :-)

Marzio De Biasi

Creo que permitir todas las combinaciones de AND, OR, NOT dificultará la creación de una estructura de datos que no enumere todos los elementos (¿tal vez podría limitarse a 3-CNF?). Si no existe tal limitación, entonces quizás solo revise los registros (en el orden especificado) hasta que encuentre 30-100 que pasen los requisitos de su etiqueta. Aunque, en general, estoy de acuerdo con la sugerencia de Vor de utilizar una base de datos para hacer el trabajo pesado por usted.

bbejot 05 de

No soy un experto, pero creo que si no impones algunas restricciones a la forma de preguntar sobre las etiquetas, será difícil. Limitarlos a CNF (como sugirió bbejot) es de una manera, otra está restringiendo el número de etiquetas diferentes que la consulta puede preguntar por un pequeño número (digamos 6).

Kaveh

Respuestas:

Esto no es exactamente una respuesta de una estructura de datos eficiente, sino más bien una elaboración de los comentarios de @bbejot y @Kaveh dando un argumento de saludo a mano por qué dada la pregunta actual, no deberíamos esperar algo que haga mucho mejor que buscar Base de datos completa. El argumento se basa en una reducción de SAT, la hipótesis del tiempo exponencial y un montón de movimientos manuales.

$n$ $x$ $|x| = n$ $x_j = 1$ $j$ $x_j = 0$ $1$ $2^n$ $k$ $k$ $AND$ $OR$ $NOT$ $n$ $2^n$

No deberíamos esperar una búsqueda eficiente en la duración de la consulta (por reducción a SAT). Tampoco deberíamos esperar mucho mejor que mirar todos los elementos en la base de datos por la hipótesis del tiempo exponencial.

$n$ $1$

Artem Kaznatcheev
fuente

Buena observación. Cada pregunta tiene como máximo 5 etiquetas, por lo que una consulta sobre etiquetas es equivalente a un 5-CNF.

Kaveh

¡gracias! Sí, podemos suponer 5-CNF aquí más, el comportamiento de etiquetado no es aleatorio. En general, las personas etiquetarán las cosas con las etiquetas más comunes, por lo que permitirá algunos otros atajos.

Sam Saffron

@Kaveh, terminamos rodando una estructura en memoria. Hay algunos atajos no triviales, la ordenación es un cuello de botella, el uso de la ordenación de montón o una ordenación rápida modificada le permite seleccionar eficientemente N superior sin necesidad de realizar una ordenación completa. los tipos de cálculo previo le permiten elegir pivotes de manera más eficiente y evitar los tipos cuando se necesita un escaneo completo. multihilo acelera las selecciones. Se puede diferir mucho trabajo en segundo plano antes de que los usuarios interactúen con las estructuras. Sorprendentemente, nuestras estructuras en memoria tienen un promedio de 0 ms para una búsqueda en el conjunto de datos de desbordamiento de pila.

Sam Saffron

@SamSaffron - ¿Dónde está la publicación de MSO que detalla esta característica? Tenemos un informe de error aquí .

Kevin Vermeer

Esta es una respuesta bastante directa, pero creo que es efectiva:

Map Tag ([Id],[Id]) $O(log (n))$

Map Id (Set Tag)Id $O(n * log (m))$

sclv
fuente

Tiendo a estar de acuerdo en que algunas estructuras muy simples, como un mapa en cola varias veces, pueden ser la mejor manera de llegar aquí. la memoria es barata y mantener múltiples cachés no es demasiado difícil

Sam Saffron