postgresql - orientada - Neo4j en lugar de base de datos relacional

base de datos orientada a grafos ejemplo (3)

La elección más adecuada depende del problema que intenta resolver.

Si solo tiene algunas tablas muchas a muchas, una base de datos relacional puede estar bien. En general, existe una mejor compatibilidad con OR-mapper para bases de datos relacionales, ya que son mucho más antiguas y tienen una interfaz estandarizada y una estructura de fila-columna. También se han mejorado durante mucho tiempo, por lo que son estables y optimizados para lo que están haciendo.

Una base de datos de gráficos es mejor si, por ejemplo, su problema es más sobre las conexiones entre entidades, especialmente si necesita conexiones a mayor distancia, como "detectar ciclos (de longitud no especificada)", algunos "qué les gusta a los amigos de un amigo". Cosas como esa se vuelven difíciles de manejar cuando están restringidas a SQL. Un lenguaje específico de problemas como Cypher en el caso de Neo4j lo hace mucho más conciso. En el lado negativo, hay mapeadores entre dbs de gráficos y objetos, pero no para todos los marcos y el lenguaje bajo el sol.

Recientemente implementé un prototipo de sistema usando neo4j y fue muy útil poder hablar sobre la estructura y las conexiones de nuestros datos y ser capaz de modelar ese uno a uno en el almacenamiento de datos. Además, agregar otras conexiones entre los puntos de datos fue fácil, neo4j es un almacenamiento sin esquema. Terminamos cambiando a mongodb debido a problemas con el rendimiento de escritura, pero no creo que pudiéramos haber terminado el prototipo con eso al mismo tiempo.

Otras áreas de almacenamiento de datos NoSQL como, por ejemplo, basadas en documentos, columnas y valores clave también cubren usos específicos. La persistencia de Polyglot es definitivamente algo a tener en cuenta, por lo que debe mantener su elección de backend razonablemente separada de la lógica de su negocio, para permitirle cambiar su tecnología más adelante si aprendió algo nuevo.

Estoy implementando un portal web basado en sinatra / rails que eventualmente podría tener pocas: muchas relaciones entre tablas / modelos. Este es un equipo de un solo hombre y una aplicación a tiempo parcial pero del mundo real.

Discutí mi entidad con alguien y me recomendaron probar neo4j. Viniendo del verdadero mundo empresarial ''no sexy'', mi inclinación es utilizar DB relacional hasta que deje de escalar o se convierta en una pesadilla debido a la fragmentación, etc. y luego piense en cualquier otra cosa.

SIN EMBARGO,

Estoy usando postgres por primera vez en este proyecto junto con datamapper y me toma tiempo para comenzar muy rápido
Solo estoy probando algunas cosas y construyendo más casos de uso, así que tengo que actualizar mi esquema (idea de creación de prototipos y comentarios de beta). No tendré que hacer esto en neo4j (excepto cambiar mis consultas)
Parece que es muy fácil de configurar la búsqueda con neo4j. Pero Postgres también puede hacer búsquedas de texto completo.
Postgres anunció recientemente el soporte para json y javascript. Me pregunto si debería seguir con PG e invertir más tiempo aprendiendo PG (que tiene una buena comunidad) en lugar de neo4j.

Buscando aplicaciones donde neo4j es mejor, especialmente en prototipos / fase inicial de un proyecto. Entiendo que si el sitio web crece, podría terminar teniendo múltiples tecnologías persistentes como s3, relacional (PG), mongo, etc.

También sería bueno saber cómo funciona con el ecosistema Rails / Ruby.

Actualización1:

Recibí muchas buenas respuestas y parece que lo correcto es seguir con Postgres por ahora (especialmente desde que despliegue en heroku)

Sin embargo, la idea de no tener esquemas es tentadora. Básicamente, estoy pensando en un enfoque en el que no se define un modelo de datos hasta que digas 100-150 usuarios y tú mismo hayas descubierto un buen esquema (casos de uso comercial) para tu producto, mientras solo estás demostrando el concepto y obteniendo retroalimentación con registros limitados. Entonces uno puede decidir un esquema y comenzar con relacional.

Sería bueno saber si hay una opción de esquema / menos persistencia fácil de usar (basada en la facilidad de uso / configuración para el nuevo usuario) que podría renunciar, por ejemplo, al escalado, etc.

No creo que acepte que solo debe usar una base de datos de gráficos cuando su modelo de datos es muy complejo. Estoy seguro de que también podrían manejar un modelo / relación de datos simple.

Si no tiene experiencia previa con Neo4j o Postgres, lo más probable es que ambos tomen un buen tiempo para aprender bien.

Algunas cosas a tener en cuenta al elegir:

No se trata solo de un desarrollo en contra de una tecnología de base de datos. Deberías considerar la implementación también. ¿Qué tan fácil es desplegar y escalar Postgres / Neo4j?
Considere la comunidad y las herramientas en torno a cada tecnología. ¿Hay un mapeador de datos para Neo4j como hay para Postgres?
Considere que los modelos de datos son considerablemente diferentes entre los dos. Si ya puedes pensar relacionalmente, entonces probablemente me quede con Postgres. Si usa Neo4j, va a cometer muchos errores durante varios meses con sus modelos de datos.
Con el tiempo he aprendido a mantenerlo simple cuando puedo. Posgres podría ser la opción aburrida en comparación con Neo4j, pero aburrido no te mantiene despierto por la noche. =)

Además, nunca veo a nadie mencionarlo, pero también debes mirar a Riak ( http://basho.com/riak/ ). Es una base de datos de documentos que también proporciona relaciones (enlaces) entre objetos. No es tan maduro como una base de datos de gráficos, pero puede conectar algunas entidades rápidamente.

Las bases de datos de gráficos deben considerarse si tiene un modelo de datos realmente caótico. Eran necesarios para expresar relaciones altamente complejas entre entidades. Para hacer eso, almacenan relaciones en el nivel de datos mientras que RDBMS usan un enfoque declarativo. Almacenar relaciones solo tiene sentido si estas relaciones son muy diferentes, de lo contrario terminarás duplicando datos una y otra vez, ocupando mucho espacio para nada. Para requerir tanta variedad en las relaciones, tendrías que manejar una gran cantidad de datos. Aquí es donde las bases de datos de gráficos brillan porque al hacer toneladas de combinaciones, simplemente seleccionan un registro y siguen sus relaciones. Para respaldar mi afirmación: notará que todos los casos de uso en el sitio web de Neo4j tratan con datos muy complejos.

En resumen, si no te preocupa lo que dije antes, creo que deberías usar otra tecnología. Si esto se trata solo de escalar, ausencia de esquemas o comenzar rápidamente un proyecto, entonces observe otras soluciones NoSQL (más específicamente, columnas o bases de datos orientadas a documentos). De lo contrario, debe seguir con PostgreSQL. También podrías, como dijiste, considerar la persistencia políglota ,

Acerca de su actualización, puede considerar hStore . Creo que se ajusta a tus necesidades. Es un módulo de PostgreSQL que también funciona en Heroku.