¿Hay ORM (OKM) para tiendas clave-valor?

Question

Los mapeadores relacionales de objetos se han creado para ayudar a las aplicaciones (que piensan en términos de objetos) a tratar los datos almacenados de una manera más amigable para las aplicaciones como cualquier otra clase/objeto.

Sin embargo, nunca he visto un OKM (Object-Key/Value-Mapper) para los sistemas de almacenamiento "Key/Value" de NoSQL. Lo cual parece extraño porque la necesidad debería ser mucho mayor, dado el hecho de que habrá más relaciones de valor que las de un objeto de fila de tabla de SQL único regular.

four requests: 
user:id 
user:id:name 
user:id:email 
user:id:created 

vs one request: 
user = [id => ..., name => ..., email => ...] 

Además, usted debe hacer un seguimiento de "listas" (comentarios sobre este tema has_many) ya que no tiene has_many través de tablas o claves externas.

INSERT INTO user_groups (user_id, group_id) VALUES (23, 54) 

vs 

usergroups:user_id = {54,108,32,..} 
groupsuser:group_id = {23,12,645,..} 

y hay muchos más ejemplos de la lógica adicional que necesitaría una aplicación para replicar algunas de las características básicas que utilizan bases de datos relacionales normales. Todas estas razones hacen que la idea de un OKM suene como un zapato.

¿Hay alguno? ¿Hay alguna razón por la que no hay ninguna?

Answer 1

El proyecto Ruby's DataMapper es un ORM y estará feliz de hablar con una tienda de valores-clave mediante el uso de un adaptador.

Redis y MongoDB tienen adaptadores que ya existen. CouchDB tiene un adaptador, no se mantiene, pero en un momento funcionó bastante bien. No creo que nadie haya hecho nada con Cassandra todavía, pero no hay ninguna razón para que no se pueda hacer. El Dubious framework para Google App Engine adopta un enfoque muy similar a Data Mapper para que el Data Store esté disponible para las aplicaciones.

Por lo tanto, es muy posible hacer ORM con tiendas de valores-clave. El ORM realmente necesita evitar la suposición de que SQL es su vocabulario principal.

Answer 2

Los ORM no se corresponden demasiado bien con la naturaleza sin esquema de los almacenes de clave-valor. Dicho esto, si está usando Riak y Ruby, puede echar un vistazo al Ripple. Hay varios otros controladores para Riak que pueden adaptarse a su idioma.

Si está buscando en MongoDB (más una tienda de documentos que una tienda k/v), hay un número de drivers disponible.

Answer 3

Uno de los objetivos de SQL es que cualquier información puede almacenarse/consultarse en cualquier base de datos relacional. Existen algunas diferencias entre plataformas, pero en general la forma correcta de manejar una estructura de datos particular es bien conocida y fácil de automatizar pero requiere un código bastante detallado. Ese no es el caso con NoSQL: en general, usted almacenará directamente los datos tal como se utilizan en su aplicación en lugar de tratar de asignarlos a una estructura relacional, y sin uniones u otras diferencias objeto/relación, el código de asignación es trivial.

Más allá de generar el código de acceso a datos estándar, uno de los propósitos principales de un ORM es la abstracción de las diferencias entre plataformas. En mi experiencia, la capacidad de cambiar de plataforma siempre ha sido puramente teórica, y este enfoque de mínimo denominador común simplemente no funcionará para NoSQL, ya que la plataforma generalmente se elige específicamente para las capacidades que no están presentes en otras plataformas. Su ejemplo es solo para el almacén de valores clave más trivial; según su plataforma, es probable que tenga algunos comandos adicionales útiles, por lo que su primer ejemplo podría ser

Usuario MGET: id: nombre usuario: id: correo electrónico ... (Multiget - obtener cualquier número de teclas en una sola llamada)

GET usuario: id: * (comodines clave)

HGETALL usuario: id (Redis de hash - Obtiene todas las subclaves de usuario)

Usted podría también tiene su objeto de usuario almacenado en forma serializada; a diferencia de una base de datos relacional, esto no romperá todas sus consultas.

Trabajar con listas no es genial si su plataforma no tiene soporte integrado: el soporte nativo de listas/conjuntos es una de las razones por las que me gusta usar redis, pero aparte de que posiblemente necesite bloqueos, no es peor que obtener el lista de sql.

También vale la pena señalar que puede que no necesite todas las relaciones que definiría en sql; por ejemplo, si tiene un grupo que contiene un millón de usuarios, la capacidad de obtener una lista de todos los usuarios de un grupo es completamente inútil, por lo tanto, nunca crearía la lista de usuarios de grupos y, en lugar de una lista de grupos de usuarios separada, tendrá user: id: groups como una propiedad de valores múltiples. Si solo necesita verificar la membresía, puede configurar claves como grupos de usuarios: ID de usuario: groupid y obtener una búsqueda de tiempo constante.

Me resulta útil pensar en términos de índices en lugar de relaciones: al configurar su código de acceso a datos, decida qué campos necesitarán ser consultados y agregar registros de índice apropiados cuando se escriben esos campos.

Answer 4

El db UNIVERSE, que es un descendiente de Pick, le permite almacenar una lista de pares de valores clave para una clave determinada. Sin embargo, esta es una tecnología muy antigua y el mundo escapó de estas bases de datos hace mucho tiempo.

Puede implementar esto en una base de datos SQL con una tabla de tres columnas

CREATE TABLE ATTRS (KEYVAL VARCHAR(32), 
         ATTRNAME VARCHAR(32), 
         ATTRVAR VARCHAR(1024) 
        ) 

Aunque la mayoría de los administradores de bases que se golpeó en la cabeza con la muy gruesa Codd y fecha edición de tapa dura, si usted propone esto, es en de hecho, es un patrón muy común en las aplicaciones empaquetadas que le permite agregar atributos específicos del sitio a un sistema.

Para expresar claramente los comentarios de Richrd Stallmans sobre LISP. "Cualquier sistema de almacenamiento de datos razonablemente funcional eventualmente terminará implementando su propia versión de RDBMS".