Modelado de datos en Datomic

Advertencia Lector

Como Datomic es nuevo y mi experiencia con él es limitada, esta respuesta no debe considerarse como las mejores prácticas de ninguna manera. Tome esto en su lugar como una introducción a Datomic para aquellos con un trasfondo relacional y un anhelo de un almacén de datos más productivo.

Primeros pasos

En Datomic, modela sus datos de dominio como Entidades que poseen Valores para Atributos. Porque una referencia a otro Entidad puede ser el Valor de Atributo, usted puede modelar Relaciones entre Entidades, simplemente.

A primera vista, esto no es tan diferente de la forma en que se modelan los datos en una base de datos relacional tradicional. En SQL, las filas de tabla son Entidadesy los atributos de las columnas de una tabla que tienenValores . Una relación está representada por un valor de clave externa en una fila de la tabla referencia a la clave primaria Valor de otra fila de la tabla.

Esta similitud es buena porque puede esbozar sus diagramas ER tradicionales al modelar su dominio. Puede confiar en las relaciones como lo haría en una base de datos SQL, pero no necesita perder el tiempo con las claves foráneas, ya que eso se maneja por usted. Las escrituras en Datomic son transaccionales y sus lecturas son consistentes. Por lo tanto, puede separar sus datos en entidades en cualquier granularidad que se sienta correcta, confiando on se une para proporcionar la imagen más grande. Esa es una conveniencia que se pierde con muchas tiendas NoSQL, donde es común tener entidades GRANDES y desnormalizadas para lograr un nivel útil de atomicidad durante las actualizaciones.

En este punto, tienes un buen comienzo. Pero Datomic es mucho más flexible que una base de datos SQL.

Aprovechando

El tiempo es inherentemente parte de todos los datos datómicos, por lo que no es necesario incluir específicamente el historial de sus datos como parte de sus datos modelo. Este es probablemente el aspecto más hablado de Datomic.

En Datomic, su esquema no está definido rígidamente en la "forma rectangular" requerida por SQL. Es decir, una entidad1 puede tener los atributos que necesita para satisfacer su modelo. Una entidad no necesita tener NULL o valores predeterminados para atributos que no se le aplican. Y puede agregar atributos a una entidad particular e individual como mejor le parezca.

Para que pueda cambiar la forma de las entidades individuales en el transcurso del tiempo para responder a los cambios en su dominio (o cambios en su comprensión del dominio). ¿Y qué? Esto no es diferente a los almacenes de documentos como MongoDB y CouchDB.

La diferencia es que con Datomic puede implementar cambios de esquema atómicamente sobre todas las entidades afectadas. Lo que significa que puede emitir una transacción para actualizar la forma de todas las entidades, basado en una lógica de dominio arbitraria, escrito en su idioma [2] , que se ejecutará sin afectar a los lectores hasta que se comprometan. No soy consciente de nada cercano a este tipo de poder en los espacios relacionales o de almacenamiento de documentos.

Sus entidades tampoco están rígidamente definidas como "viviendo en una sola tabla". Usted decide qué define el" tipo " de una entidad en Datomic. Puede elegir ser explícito y ordenar que cada entidad en su modelo tenga un atributo :table que connota qué "tipo" es. O sus entidades pueden ajustarse a cualquier número de "tipos" simplemente por satisfacer los requisitos de atributo de cada tipo.

Por ejemplo, su modelo podría exigir que:

• Una persona requiere atributos :name, :ssn, :dob
• Un Empleado requiere :name, :title, :salary
• Un residente requiere :name, :address
• Un Miembro requiere :id, :plan, :expiration

Que significa una entidad como yo:{[27]]}

{:name "Brian" :ssn 123-45-6789 :dob 1976-09-15 
 :address "400 South State St, Chicago, IL 60605"
 :id 42 :plan "Basic" :expiration 2012-05-01}

Puede inferirse que es un Person, un Resident y a Member pero NO an Employee.

Las consultas Datomic se expresan en Datalog y pueden incorporar reglas expresadas en su propio idioma, haciendo referencia a datos y recursos que no están almacenados en Datomic. Puede almacenar Funciones de base de datos como valores de primera clase dentro de Datomic. Estos se asemejan a los Procedimientos almacenados en SQL, pero se pueden manipular como valores dentro de una transacción y también se escriben en su idioma. Ambas características le permiten expresar consultas y actualizaciones en un más forma centrada en el dominio.

Finalmente, el desajuste de impedancia entre el OO y los mundos relacionales siempre me ha frustrado. El uso de un lenguaje funcional centrado en los datos (Clojure) ayuda con eso, pero Datomic busca proporcionar un almacenamiento de datos duradero que no requiere gimnasia mental para pasar del código al almacenamiento.

Como ejemplo, una entidad extraída de Datomic se ve y actúa como un mapa Clojure (o Java). Se puede pasar a niveles más altos de una aplicación sin traducción a una instancia de objeto o estructura de datos general. Atravesar las relaciones de esa entidad buscará las entidades relacionadas de Datomic perezosamente. Pero con la garantía de que serán consistentes con la consulta original, incluso frente a actualizaciones concurrentes. Y esas entidades parecerán ser mapas viejos y simples anidados dentro de la primera entidad.

Esto hace que el modelado de datos sea más natural y mucho, mucho menos una pelea en mi opinión.

Potencial Trampas

• Atributos en conflicto

  El ejemplo anterior ilustra una trampa potencial en su modelo. ¿Qué pasa si luego decides que :id es también un atributo de un Employee? La solución es organizar sus atributos en espacios de nombres. Así que tendrías ambos :member/id y :employee/id. Hacer esto con anticipación ayuda a evitar conflictos más adelante.

• La definición de un atributo no se puede cambiar (todavía)

  Una vez que haya definido un atributo en su Datomic como un tipo particular, indexado o no, único, etc. no puedes cambiar eso más tarde. Estamos hablando ALTER TABLE ALTER COLUMN en lenguaje SQL aquí. Por ahora, podría crear un atributo de reemplazo con la definición correcta y mover sus datos existentes.

  Esto puede sonar terrible, pero no lo es. Debido a que las transacciones son serializadas, puede enviar una que cree el nuevo atributo, copie sus datos, resuelva conflictos y elimine el atributo anterior. Se ejecutará sin interferencia de otras transacciones y puede aprovechar la lógica específica del dominio en su idioma nativo para hacerlo. Es esencialmente lo que un RDBMS está haciendo detrás de escena cuando se emite un ALTER TABLE, pero se nombran las reglas.

• No seas"un niño en una tienda de dulces"

  Esquema flexible no significa ningún modelo de datos. Yo aconsejaría un poco de planificación por adelantado para modelar las cosas de una manera sana, al igual que lo haría para cualquier otro almacén de datos. Aproveche la flexibilidad de Datomic el camino cuando usted tiene que, no solo porque usted puede.

• Evite almacenar datos grandes y en constante cambio

  Datomic no es un buen almacén de datos para BLOBs o datos muy grandes que cambian constantemente. Porque mantiene un registro histórico de valores anteriores y no hay un método para purgar versiones anteriores (todavía). Este tipo de cosas es casi siempre un mejor ajuste para un almacén de objetos como S3. Actualización: Hay una manera de deshabilitar el historial en un atributo per basis .

Recursos

• Datomic mailing list
• Canal IRC # datomic en Freenode

Notas

1. Quiero decir entidad en el sentido de fila, no el sentido de tabla que se describe más adecuadamente como tipo de entidad.
2. Entiendo que Java y Clojure están soportados actualmente, pero es posible que otros lenguajes JVM puedan ser soportados en el futuro.