database database-design clojure datomic

database - ¿Cuándo debería usar Datomic?



database-design clojure (4)

Estoy intrigado con el servicio de base de datos Datomic, pero no estoy seguro de si se ajusta a las necesidades de los proyectos en los que trabajo. ¿Cuándo es Datomic una buena elección, y cuándo se debe evitar?


Con la condición de que no he usado Datomic en producción, pensé que te daría una respuesta.

Ventajas

  1. Las consultas de registro de datos son potentes (más que SQL no recursivo) y muy expresivas.
  2. Las consultas se pueden escribir con estructuras de datos Clojure, y NO es una DSL débil como muchas bibliotecas SQL que le permiten realizar consultas con estructuras de datos.
  3. Es inmutable, por lo que obtienes las ventajas que la inmutabilidad te brinda en Clojure / otros idiomas, así como a. Esto también le permite almacenar, al guardar estructuras, todos los hechos pasados ​​en su base de datos; esto es MUY útil para auditar y más

Desventajas

  1. Puede ser lento, ya que Datalog va a ser más lento que SQL equivalente (suponiendo que se pueda escribir una declaración SQL equivalente).
  2. Si está escribiendo MUCHO, tal vez necesite preocuparse de que la transacción individual se vea abrumada. Esto parece improbable para la mayoría de los casos, pero es algo en lo que pensar (aunque podrías hacer una especie de fragmento y probablemente salvarte a ti mismo, pero esto no es una base de datos, por ejemplo, almacenando datos de marcas en stock).
  3. Es un poco complicado comenzar a usarlo, y es costoso, y la licencia y el precio dificultan el uso de una instancia alojada: tendrás que lidiar con el administrador del sistema esto tú mismo en lugar de utilizar algo como Postgres en Heroku o Mongo en MongoHQ

Estoy seguro de que me falta algo de cada lado, y aunque tengo 3 enumerados en desventajas, creo que las ventajas son mayores que en otras circunstancias donde las desventajas no impiden su uso. El precio probablemente sea el que evitará que se use en la mayoría de los proyectos pequeños (que espera que dure más de 1 año de prueba gratuita).

Cf. esta breve publicación describe Datomic simplemente para obtener más información.

La expresividad (cf Datalog) y la inmutabilidad son impresionantes. Es muy divertido trabajar con Dataomic en ese sentido, y se puede decir que es poderoso con solo usarlo un poco.


Para completar las respuestas anteriores, me gustaría hacer hincapié en que la inmutabilidad y la capacidad de recordar el pasado no son "características de magia" adecuadas para algunos casos especiales, como la auditoría. Es un enfoque que tiene varios beneficios profundos en comparación con las bases de datos de "células mutables" (que actualmente son el 99% de las bases de datos). Stuart Halloway demuestra esto muy bien en este video: el desajuste de impedancia es nuestra culpa .

En mi opinión personal, este enfoque es fundamentalmente más sensato conceptualmente. Después de haberlo usado durante varios meses, no veo que Datomic tenga poderes locos y sofisticados, sino un paradigma más natural sin algunos de los grandes problemas que tienen los demás.

Aquí hay algunas características de Datomic que considero valiosas, la mayoría de las cuales están habilitadas por la inmutabilidad:

  1. porque la lectura no es remota, no tiene que diseñar sus consultas como una expedición por cable. En particular, puede separar inquietudes en varias consultas (por ejemplo, encontrar las entidades que son la entrada de mi consulta, responder algunas preguntas de negocios sobre estas entidades, buscar datos asociados para presentar el resultado)
  2. el esquema es muy flexible, sin sacrificar el poder de consulta
  3. es cómodo tener sus consultas integradas en el lenguaje de programación de su aplicación
  4. la API de la entidad te trae las partes buenas de los ORM
  5. el lenguaje de consulta es programable y tiene primitivas para abstracción y reutilización (reglas, predicados, funciones de base de datos)
  6. rendimiento: los escritores solo impiden a otros escritores, y nadie impide a los lectores. Además, mucha memoria caché.
  7. ... y sí, algunas superpotencias como viajar al pasado, escrituras especulativas o diversificar la realidad.

En cuanto a cuándo no usar Datomic, aquí están las restricciones y limitaciones actuales que veo:

  1. tienes que estar en la JVM (también hay una API REST, pero pierdes la mayoría de los beneficios de la OMI)
  2. no es adecuado para la escala de escritura, ni grandes volúmenes de datos
  3. no estará especialmente integrado en los marcos, por ejemplo, actualmente no encontrará una biblioteca que genere puntos finales REST CRUD a partir de un esquema Datomic
  4. es una base de datos comercial
  5. dado que la lectura ocurre en el proceso de solicitud (el ''Peer''), debe asegurarse de que el Peer tenga suficiente memoria para contener todos los datos que necesita para recorrer en una consulta.

Así que mi respuesta muy vaga e informal sería que Datomic es una buena opción para la mayoría de las aplicaciones no triviales, que la carga de escritura es razonable y no tienes un problema con la licencia y estar en la JVM .

Como analogía, puede hacerse la misma pregunta para Git en comparación con otros sistemas de control de versiones que no se basan en la inmutabilidad.


Solo para agregar tentativamente sobre las otras respuestas:

Probablemente sea justo decir que datomic presenta el mejor marco conceptual para un almacén de datos consultable de todas las demás opciones actuales, al tiempo que es parcialmente escalable y no tiene un rendimiento excepcional.

Digo solo parcialmente escalable, porque las consultas deben caber en la memoria RAM par o fallan. Y no es un rendimiento excepcional , ya que los motores SQL de primer nivel pueden optimizar las consultas para que quepan en la memoria a través de sofisticados planes de ejecución, algo que aún no he visto mencionado como una característica en datomic; El desacoplamiento de Datomic de las transacciones y las consultas podría compensar en general esta característica.

Sin embargo, a diferencia de muchos motores NoSQL, las transacciones son un ciudadano de primera clase, lo que lo sitúa a la par de los sistemas RDBMS en ese aspecto clave.

Para las aplicaciones donde los datos se leen más de lo que se escriben, se necesitan transacciones, las consultas siempre se ajustan en la memoria o la memoria es muy económica, y el tamaño total de los datos acumulados no es demasiado grande , podría ser un triunfo donde un producto solo comercial puede permitirse, para aquellos que estén dispuestos a adoptar su nuevo marco conceptual implícito en el API.


Una cosa importante al considerar si Datomic es la opción adecuada para su aplicación es pensar en la forma de los datos que va a almacenar y consultar, ya que los hechos Datomic son muy similares a los triples de RDF (+ noción de tiempo de primera clase) que se presta muy bueno para modelar relaciones complejas (datos de gráficos vinculados), algo que a menudo es engorroso con las bases de datos SQL tradicionales. Considero que este aspecto es uno de los más interesantes e importantes para mí, funcionó muy bien, incluso si esto no es algo exclusivo de Datomic, ya que hay muchas otras ofertas de alta calidad para bases de datos de gráficos, hay que mencionar a Neo4J cuando estamos hablando de soluciones basadas en JVM.
Con respecto al esquema Datomic, creo que es el equilibrio justo entre flexibilidad y estabilidad.