Sin esquema / flexible + Base de datos ACID?

Estoy buscando reescribir una aplicación local basada en VB (instalada localmente) (facturación + inventario) como una aplicación Clojure basada en la web para clientes de pequeñas empresas. Tengo la intención de que esto se ofrezca como una aplicación SaaS para clientes en el comercio similar.

Estaba buscando opciones de base de datos: mi elección fue un RDBMS: Postgresql / MySQL. Podría escalar hasta 400 usuarios en el primer año, con un promedio de 20 a 40 páginas vistas por día por usuario, principalmente para transacciones que no son vistas estáticas. Cada vista implicará buscar datos y actualizar datos. El cumplimiento de ACID es necesario (o eso creo). Entonces el volumen de la transacción no es enorme.

Hubiera sido obvio elegir cualquiera de estos según mi preferencia, pero para este requisito, que creo que es típico de una aplicación SaaS: el esquema cambiará a medida que agregue más clientes / usuarios y para cada cliente requisitos comerciales cambiantes (para empezar, ofreceré cierta flexibilidad limitada). Como no soy un experto en bases de datos, según lo que puedo pensar y leer, puedo manejarlo de varias maneras:

1. Tenga un diseño de esquema RDBMS tradicional en MySQl / Postgresql con una única base de datos que hospede a varios inquilinos. Y agregue suficientes columnas "flotantes" en cada tabla para permitir cambios futuros a medida que agregue más clientes o cambios para un cliente existente. Esto podría tener la desventaja de propagar los cambios a la base de datos cada vez que se realiza un pequeño cambio en el esquema. Recuerdo haber leído que en el esquema de Postgresql las actualizaciones se pueden hacer en tiempo real sin bloqueo. Pero no estoy seguro, qué tan doloroso o práctico es en este caso de uso. Y también, como los cambios en el esquema también pueden introducir cambios SQL nuevos / menores.
2. Tenga un RDBMS, pero diseñe el esquema de la base de datos de manera flexible: con un valor cercano al atributo de la entidad o simplemente como un almacén de valores clave. (Workday, FriendFeed por ejemplo)
3. Tenga todo en la memoria como objetos y guárdelos periódicamente en archivos de registro (por ejemplo, edval, lmax)
4. Elija una base de datos NoSQL como MongoDB o Redis. Pero según lo que puedo reunir, no son adecuados para este caso de uso y no son totalmente compatibles con ACID.
5. Elija algunos NewSQL Dbs como VoltDb o JustoneDb (basados ​​en la nube) que conservan el comportamiento compatible con SQL y ACID y son RDBMS de "nueva generación".
6. Miré neo4j (graphdb), pero no estoy seguro de si eso encajará en este caso de uso

En mi caso de uso, más que la escalabilidad o la informática distribuida, estoy buscando una mejor manera de lograr "Flexibilidad en Schema + ACID + un rendimiento razonable". La mayoría de los artículos que pude encontrar en la red hablan de la flexibilidad en el esquema como una causa que conduce al rendimiento (en el caso de NoSQL DB) y la escalabilidad mientras se omite el lado ACID / Transacciones.

¿Es este un caso "cualquiera o" de transacciones de 'Flexibilidad de esquema vs ACID' o hay una mejor salida?

Opción 1

Hay varias razones para esto, que explicaré a continuación. Primero, aquí está cómo hacerlo.

• Utilice su elección de plataforma RDBMS estándar.

• Configure su esquema con varios campos configurables por el usuario y haga que su aplicación facilite la configuración por inquilino.

• A partir de los metadatos por inquilino, puede crear una vista por inquilino de sus datos, que tiene los filtros integrados y las columnas nombradas a partir de sus metadatos. Cualquier informe proporcionado también puede heredar los metadatos. Si quieren hacer MI fuera de los datos, entonces proporciónenles un extracto de los datos transaccionales, o tal vez alguna aplicación MIS adicional en un servidor diferente si pagarán por eso.

• No intente proporcionar más personalización que esta (es decir, sin cambios radicales en el esquema) a menos que el cliente esté preparado para pagar su propia instancia privada y mantener una compilación personalizada.

Las razones detrás de esto son:

• Estos sistemas de bases de datos manejarán el tipo de volúmenes que usted describe en hardware bastante ordinario. Realmente no tiene el tipo de volumen de transacción que merece una base de datos NoSQL. A menos que tenga alguna otra razón arquitectónica para querer uno, no tiene mucho sentido ir a la vanguardia.

• Son tecnologías maduras y bien entendidas.

• La gestión del sistema, la copia de seguridad / restauración, la replicación, los informes y la recuperación ante desastres están bien ordenados en las plataformas RDBMS.

• Puede obtener bibliotecas de clientes que incluyen JDBC para todas las principales plataformas RDBMS.

• Las vistas pueden usarse para la personalización por usuario y generarse a partir de los metadatos de su aplicación.

• Es sustancialmente más eficiente que los campos XML o las estructuras EAV.

Con PostgreSQL tiene la opción de usar bases de datos separadas, esquemas o vistas separadas para lidiar con la tenencia múltiple.

El uso de múltiples bases de datos (dentro del mismo servidor de bases de datos) hace que la administración sea más compleja porque cada base de datos debe administrarse individualmente. Por lo tanto, esto solo es aconsejable si la seguridad entre inquilinos es la mayor preocupación.

Los esquemas separados ofrecen mucha flexibilidad y seguridad, pero hacen que las actualizaciones sean más complejas porque deben aplicarse individualmente y probablemente solo sean necesarias si sus inquilinos usan estructuras de tabla completamente diferentes; lo cual es poco probable si están utilizando la misma aplicación.

Las vistas permiten a los inquilinos ver diferentes partes de una estructura de tabla común y le permite controlar qué tablas, qué columnas y a qué filas tienen acceso. La única advertencia es que su aplicación debe asegurarse de que solo usa esas vistas y no las tablas base; de ​​lo contrario, existe la posibilidad de pérdidas de datos accidentales entre los inquilinos debido a defectos de software.

Realmente no necesita crear columnas antes de los requisitos de la aplicación. Las columnas se pueden agregar a las tablas dinámicamente (sin ningún impacto notable en los usuarios) y las vistas también se pueden actualizar dinámicamente. Solo necesita pensar en el orden de hacer cambios, es decir. cambiar las tablas, luego las vistas y luego el código de la aplicación.

Su única preocupación potencial es si necesita agregar una nueva columna que debe agregarse a un índice existente o si necesita un nuevo índice. Es entonces cuando la tabla se puede bloquear del uso mientras se está creando el índice, pero PostgreSQL admite la capacidad de crear índices simultáneamente sin bloquear la tabla. Esto funciona bien a menos que el nuevo índice necesite ser único y encuentre una violación de unicidad.

Probablemente no necesite una base de datos NoSQL, ya que eliminan efectivamente el esquema de la base de datos y requieren que la aplicación lo administre. No parece que tus volúmenes exijan ese tipo de sacrificio.