¿Cuándo debe usar una base de datos de documentos vs relacional vs gráfica? [cerrado]

Para fines de discusión, consideremos un escenario FourSquare.

Guión

Entidades:

• Los usuarios
• Lugares

Relaciones:

• Checkins: usuarios <-> lugares, muchos a muchos
• Amigos: usuarios <-> usuarios, muchos a muchos

Diseño de bases de datos

Lo más probable es que tengan errores, indíquelos.

RDBMS

Mesas:

• Los usuarios
• Lugares
• Checkins (unión)
• Amigos (unión)

Pros:

• CAP: consistencia, disponibilidad

Contras:

• CAP: tolerancia de partición, también conocido como fragmentación
• esquemas = estructura inflexible
• mala replicación?

Grafico

Objetos:

• Los usuarios
• Lugares

Bordes:

• Amigos: Usuario <-> Usuario
• Registros: Usuario -> Lugares
  • contiene marca de tiempo

Pros:

• CAP: consistencia, disponibilidad?
• sin esquemas, objetos y bordes fácilmente mutables
• consultas transversales de gráficos, por ejemplo:
  • agrupamiento
    • encontrar grupos de amigos
    • encontrar restaurantes que le gusten a personas similares
  • ¿Alguna otra consulta común / útil?

Contras:

• CAP: tolerancia de partición?

Documento / objeto

3 bases de datos separadas?

• Los usuarios
  • lista de amigos
• Registros
  • marca de tiempo
  • usuario
  • lugar
• Lugares

Pros:

• CAP: disponibilidad, tolerancia de partición
• objetos sin esquemas, fácilmente mutables

Contras:

• CAP: consistencia

Preguntas

Para el registro, terminaron usando MongoDB. Además de todos esos signos de interrogación anteriores:

1. No estoy seguro de cómo implementar una base de datos de documentos.
2. ¿Cómo las bases de datos de documentos ganan tolerancia de partición?
3. Para obtener los registros de un solo usuario, supongo que la operación analizará todos los registros y filtrará los metadatos por nombre de usuario (mapa + filtro). El rendimiento de analizar más de 1,000,000 de documentos para cada usuario sería terriblemente pobre. ¿Asumo que este no es el comportamiento correcto?
4. ¿Qué otras ventajas y desventajas hay?

Tu pregunta podría ser el tema de un curso universitario de un semestre. Necesita dividirlo en trozos manejables. Como tal, simplemente arrojaré algunas respuestas parciales.

Una de las primeras cosas a tener en cuenta al decidir qué tipo de base de datos usar es qué tipo de consultas ejecutará y si las conocerá todas antes de crear la base de datos. Las bases de datos SQL tienen la ventaja de consultas potentes y flexibles en todos los datos de la base de datos. Las bases de datos de gráficos tienen capacidades de consulta altamente especializadas que las hacen las mejores para datos de gráficos y realmente malas para datos que no son de gráficos (aunque las bases de datos de gráficos pueden ser componentes en bases de datos SQL). Las bases de datos NoSQL tienen una capacidad mucho más limitada para recuperar y operar datos.

El siguiente es cómo te sientes acerca de las propiedades de ACID: atomicidad, consistencia, aislamiento y durabilidad. Las bases de datos SQL brindan fuertes garantías sobre los 4. Las bases de datos NoSQL generalmente no prometen los 4, y las formas en que parten se encuentran entre las diferencias clave que diferencian las diversas implementaciones de bases de datos NoSQL. Por otro lado, no es posible garantizar la coherencia y la disponibilidad frente a una partición (consulte el teorema CAP de Brewer ), por lo que ninguna base de datos SQL funcionará si insiste en la disponibilidad total frente a una partición. Personalmente, me importa mucho la durabilidad de los datos en la base de datos, ya que normalmente trabajo con datos donde incluso una pérdida de datos del 0.0001% es inaceptable, y los conjuntos de datos son lo suficientemente pequeños como para no tener que preocuparme por las particiones, por lo que favorecen en gran medida las bases de datos SQL.

Otra consideración muy práctica es la calidad del código del servidor, la disponibilidad de los administradores y programadores de la base de datos, la calidad del soporte disponible para los problemas que surjan, la calidad y disponibilidad de las bibliotecas de interfaz para conectar su aplicación a la base de datos, etc. MySQL ha existido durante casi 2 décadas, ha solucionado la gran mayoría de los errores, es muy utilizado y tiene un gran soporte y una gran disponibilidad de personal, y es probable que sea compatible durante los próximos 10 años. No puedes decir ninguna de esas cosas sobre Riak.

Tenga en cuenta que si bien Google prácticamente inventó las bases de datos NoSQL para poder almacenar una versión en caché e indexada de toda la red mundial, todavía usan MySQL para algunas cosas.