¿Por qué elegir una base de datos relacional sobre una no relacional, si la consistencia y la disponibilidad no son factores?

Primero, proporcionemos un poco más de contexto a su pregunta. Como mencionas Google Spanner, la coherencia no se trata de ACID, sino del teorema de CAP.

En el teorema de CAP, consistencia significa linealidad.

La linealización es una propiedad reciente y conlleva un sistema distribuido. Ahora, dependiendo de su sistema, puede ser que realmente no necesite Linerizability después de todo. Aunque es una garantía más débil, la consistencia informal es muchas veces suficiente para muchos sistemas distribuidos.

En cuanto a la disponibilidad, también es una garantía específica del sistema. Por lo tanto, depende de cuánto dinero pierda cada segundo que su sistema no esté disponible. Si puede pagar el costo de indisponibilidad, entonces tiene suerte. Muchos sistemas empresariales no pueden permitirse perder dinero mientras el sistema no está disponible, por lo que debe realizar compensaciones. Google Spanner hace que sea menos probable que la base de datos no esté disponible debido a TrueTime y al hecho de que Google controla cada parte de la infraestructura de la nube, desde dispositivos de hardware hasta redes.

Ahora, volviendo a tu pregunta. Supongo que elegir una base de datos distribuida ACID y de relación como Spanner es una opción mucho mejor que una tienda NoSQL en muchas situaciones. Para explicar por qué, voy a citar el trabajo de investigación de Google Spanner:

Creemos que es mejor que los programadores de aplicaciones se ocupen de los problemas de rendimiento debido al uso excesivo de transacciones a medida que surgen cuellos de botella, en lugar de siempre codificar la falta de transacciones.

Por lo tanto, si es difícil para los programadores de Google codificar sin transacciones, probablemente sea difícil para todos los demás, ¿verdad?

Las bases de datos relacionales modernas tienen tantas características útiles (lenguaje de consulta muy sofisticado, XML, soporte JSON, herramientas, copia de seguridad, etc., etc.) fuera de la coherencia y la disponibilidad, realmente necesita estar en una situación en la que tenga necesidades muy específicas que son no cumplido por el RDBMS. Algunos ejemplos:

  • Recorrido de gráfico complejo frecuente
  • Disponibilidad muy alta

Dado que su pregunta es muy abierta y no tiene requisitos concretos, simplemente declararé el clásico: “Quédese con un RDBMS”. Las posibilidades de que te arrepientas de esta decisión en retrospectiva son mucho menores que las posibilidades de que te arrepientas de haber elegido otra cosa.

Además: entre todos los RDBMS, PostgreSQL es probablemente la opción más pragmática / más barata.

Si la consistencia y la disponibilidad no son una preocupación, entonces la pregunta obvia es por qué molestarse con sus datos. Simplemente envíelo a / dev / null, y funcionará espectacularmente bien 🙂

Estoy siendo gracioso, pero la realidad es que cuando dices “no es una preocupación”, me sorprende porque lo que realmente se dice es que hay un nivel mínimo de consistencia y disponibilidad que esperas.

En base a eso: elija una tecnología de base de datos que satisfaga esa necesidad, satisfaga las necesidades futuras previstas que tenga y proporcione un amplio conjunto de herramientas e interfaces para acceder / manipular sus datos.

Para mí, la madurez de las relaciones gana ese debate, pero otros, por supuesto, tendrán puntos de vista diferentes.