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

29

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?
wting
fuente
(1) Debe deletrear la relación entre 2 tablas en términos comerciales. Esto se debe a que puede haber relaciones paralelas. Por ejemplo, usuarios <--> usuarios no implica una relación de 1 mm. Podría significar más de 1. Por ejemplo: a un usuario le gusta otro usuario y odia a otros usuarios. Estas son 2 relaciones. (2) Sería útil si pudiera resumir lo que quiere "exactamente".
NoChance
@EmmadKareem: (1) No estoy buscando complicar el escenario. La única relación de usuario <-> usuario que me interesa es una amistad mutua, que es una conexión de muchos a muchos. (2) Me gustaría responder a las 4 preguntas que figuran en la parte inferior de la publicación.
Wting

Respuestas:

13

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.

Viejo pro
fuente
1
Me doy cuenta de que estaba preguntando mucho, por lo que una respuesta general hubiera estado bien. Las preguntas centrales son: (1) ¿Por qué utilizar la base de datos de documentos para un supuesto gran fragmentación cuando puede implementar el fragmentación horizontal en lógica utilizando el fragmentación de rango? (2) ¿Cómo diseñaría una base de datos de documentos para usar en un escenario FourSquare y cómo maneja algunos usos comunes (mostrar los registros de los usuarios, mostrar los amigos de los usuarios, mostrar los usuarios de los lugares actualmente registrados)?
wting
1
@William, hay docenas de artículos que responden sus preguntas fácilmente accesibles a través de Google. Incluso varios en Stack Overflow solo. Haz tu tarea.
Old Pro