¿Qué es una matriz/ordenado de búsqueda de la base de datos?

Question

Estoy buscando una base de datos que soporta la funcionalidad siguiente:

1) los Registros en la base de datos son como los diccionarios de Python o Perl hashes.Por ejemplo, una "compra" registro podría tener este aspecto:

<purchase 5436> = { product: "BMX Bike", price: 99.50, city: "Springfield" }

2) Los registros son almacenados en arrays de longitud variable.La base de datos contiene muchas de estas matrices.Por ejemplo, la compra de la tabla podría tener este aspecto:

purchase array 1: [ <purchase 5436>, <purchase 54>, <purchase 112> ]
purchase array 2: [ <purchase 76>, <purchase 5984>, <purchase 1102>, <purchase 12> ]
...
purchase array 658: [ <purchase 10142>, <purchase 35>, <purchase 6458>, <purchase 23> ]

3) quiero ser capaz de hacer dos tipos de consultas en esta base de datos:

3a) Contar el número de registros que cumplen una función de diversos criterios.Por ejemplo, ¿cuántos de compra fueron hechas con un valor de más de 50?Yo sé de un montón de bases de datos que apoyan esto.

3b) Contar el número de veces que los registros aparecen en un orden determinado.Por ejemplo, ¿cuántas matrices hubo una compra de más de 50 se hizo y, a continuación, una compra en "Springfield", se hizo?No sé qué tipo de base de datos que se puede usar para hacer esto.

editar:Respuesta a Steve Haigh:Yo debería haber mencionado que la velocidad es importante, y esta base de datos se necesita el apoyo de gigabytes de datos.Por ejemplo, podría ser 1.000.000.000 de compra de las matrices, y quiero contar cuántos de ellos tienen una compra en "Springfield", seguido por una compra en la "ciudad Natal" (tenga en cuenta que el orden es importante).Tal vez me equivoque, pero creo que una base de datos relacional sería demasiado lento para este propósito.

Answer 1

¿Estás seguro de que no puede hacer esto con una base de datos relacional utilizando una tabla de enlace o unión?

Se podría tener una columna de pedidos, una columna de productos y una tabla de pedidos de productos que tiene una fila para cada producto por pedido.

probablemente expresa mejor que yo pude.

Answer 2

Por ejemplo, podría ser 1.000.000.000 de compra de las matrices, y yo desea contar cuántos de ellos tienen un compra en "Springfield", seguido por una compra en la "ciudad Natal" (tenga en cuenta que el orden es importante).Tal vez me equivoque, pero creo que una base de datos relacional sería demasiado lento para este propósito.

Lo que usted describe son típicos almacén de datos consultas y AFAIK, esos son normalmente implementado utilizando relacional DBs, aunque las que están optimizados para la presentación de informes en lugar de para concurrente de procesamiento de transacciones.Sin embargo, no creo que la diferencia en la velocidad será extrema si se utiliza un "regular" RDBMS.Por supuesto, si usted tiene suficiente dinero, usted podría ir para un especial de almacén de datos DBMS.

La influencia más importante en la velocidad es lo que va a ser 1) una tecnología optimizada para hacer grandes discos basados en conjuntos de datos - eso es exactamente lo que todos los "reales" DMBSs oferta, y 2) los datos organizados en el camino correcto.

3b) Contar el número de veces que los registros aparecen en un orden determinado.Para ejemplo, ¿cuántos arreglos son de allí fueron una compra de más de 50 se hizo y luego de una compra en "Springfield", fue hecho?No sé qué tipo de base de datos que se puede usar para hacer esto.

Usted podría utilizar una base de datos relacional con un esquema diseñado para soportar ese tipo de consulta.Usted va a tener que renunciar a su idea preconcebida de cómo los datos deben ser representados.

Answer 3

Usted realmente no necesita una base de datos relacional puesto que sólo tienen número-> pares de valores agrupados en colecciones, que tendría que une entre las dos tablas (una para los registros, uno para las colecciones) para recorrer los registros de una recogida y en su caso no vale la pena el costo.

Para los requisitos de rendimiento, lo que necesita es asegurarse de que toda la estructura se ajusta en la memoria y no requiere acceso a disco. Es posible que tenga varios servidores para hacer esto, y un maestro que envía las actualizaciones para los otros servidores (suponiendo que el tamaño de su estructura es más grande que la cantidad razonable de memoria que un servidor moderna puede manejar, y que sus requisitos de velocidad son tan grande que no puede permitirse el lujo de paginación del disco.

Para el tipo de consultas que usted menciona, su mejor opción es tener un poco de redundancia de datos. En inserciones, sería realizar un seguimiento de los recuentos. tiendas de campaña redundancia de datos a las personas se asustan con sólo leer el nombre, pero a veces es necesario. Sólo ser extremadamente cuidadosos con su aplicación e invertir una buena cantidad de pruebas unitarias aquí.

Puede haber, sin embargo, algún tipo de consultas, que no va a ser capaz de hacerlo en tiempo real en cuestión de milisegundos, y que uno acerca de las compras para encontrar con una condición seguidos de compras con otra condición parece esta. Ya sea que encontrar una manera de mantener un seguimiento en directo de estos números al insertar / borrar / modificar, o tendrá que repetir podía comprender sus millones de matrices, no hay manera de evitar eso. Tendrá que tener en cuenta lo reciente de los datos tiene que ser, y tal vez pre-calcular cada pocas horas para generar las estadísticas y luego ser capaz de acceder a ellos en O (1) con claves de búsqueda.

En pocas palabras, el problema es mucho más allá de la tecnología que decida utilizar para resolverlo.

Answer 4

No estoy seguro de entender completamente lo que está buscando, pero ¿ha mirado couchdb ? . Su orientación del documento y el esquema de libre

Answer 5

Lo que usted describe es bastante similar al paperas aunque tenga algunas dudas sobre la capacidad para definir consultas, donde es posible el orden de los "registros" en las matrices.

Tenga una mirada en el enlace, hay versiones comerciales también actuales de este como se verá.