Base de données sans schéma / flexible + ACID?

Je cherche à réécrire une application VB basée sur site (installée localement) (facturation + inventaire) en tant qu'application Web Clojure pour les petites entreprises. Je prévois que cela soit offert en tant qu'application SaaS pour les clients dans un commerce similaire.

Je cherchais des options de base de données: Mon choix était un SGBDR: Postgresql / MySQL. Je pourrais faire évoluer jusqu'à 400 utilisateurs la première année, avec généralement 20 à 40 pages vues / par jour et par utilisateur - principalement pour les transactions et non les vues statiques. Chaque vue impliquera la récupération de données et la mise à jour de données. La conformité à l'ACID est nécessaire (ou du moins je pense). Le volume de transactions n'est donc pas énorme.

Cela aurait été une évidence de choisir l'une ou l'autre de celles-ci en fonction de mes préférences, mais pour cette seule exigence, qui je pense est typique d'une application SaaS: le schéma changera à mesure que j'ajouterai d'autres clients / utilisateurs et pour chaque client. l'évolution des besoins de l'entreprise (je n'offrirai une flexibilité limitée que pour commencer). Comme je ne suis pas un expert DB, sur la base de ce que je peux penser et lire, je peux gérer cela de plusieurs manières:

1. Avoir une conception de schéma RDBMS traditionnelle dans MySQl / Postgresql avec une seule base de données hébergeant plusieurs locataires. Et ajoutez suffisamment de colonnes "flottantes" dans chaque table pour permettre des modifications futures à mesure que j'ajoute des clients ou des modifications pour un client existant. Cela peut avoir un inconvénient de propager les modifications apportées à la base de données chaque fois qu'une petite modification est apportée au schéma. Je me souviens d'avoir lu que dans Postgresql, les mises à jour du schéma peuvent être effectuées en temps réel sans verrouillage. Mais je ne sais pas à quel point c'est douloureux ou pratique dans ce cas d'utilisation. Et aussi, car les modifications de schéma peuvent également introduire des modifications SQL nouvelles / mineures.
2. Avoir un SGBDR, mais concevoir le schéma de base de données de manière flexible: avec une valeur d'attribut d'entité proche ou simplement comme un magasin de valeurs-clés. (Workday, FriendFeed par exemple)
3. Ayez le tout en mémoire en tant qu'objets et stockez-les périodiquement dans des fichiers journaux (par exemple, edval, lmax)
4. Optez pour une base de données NoSQL comme MongoDB ou Redis. Mais d'après ce que je peux comprendre, ils ne conviennent pas à ce cas d'utilisation et ne sont pas entièrement conformes à ACID.
5. Optez pour des DBS NewSQL comme VoltDb ou JustoneDb (basé sur le cloud) qui conservent le comportement conforme à SQL et ACID et sont des SGBDR "nouvelle génération".
6. J'ai regardé neo4j (graphdb), mais je ne sais pas si cela conviendra à ce cas d'utilisation

Dans mon cas d'utilisation, au-delà de l'évolutivité ou de l'informatique distribuée, je cherche une meilleure façon d'obtenir une "flexibilité dans le schéma + ACID + des performances raisonnables". La plupart des articles que j'ai pu trouver sur le net parlent de flexibilité dans le schéma comme une cause conduisant à la performance (dans le cas des bases de données NoSQL) et à l'évolutivité tout en omettant le côté ACID / Transactions.

S'agit-il d'un cas «soit ou» de transactions «flexibilité du schéma vs ACID» ou existe-t-il une meilleure solution?

Option 1

Il y a plusieurs raisons à cela, que j'expliquerai ci-dessous. Tout d'abord, voici comment procéder.

• Utilisez votre choix de plate-forme SGBDR standard.

• Configurez votre schéma avec plusieurs champs configurables par l'utilisateur et faites en sorte que votre application facilite la configuration par client.

• À partir des métadonnées par locataire, vous pouvez créer une vue par locataire de leurs données, avec les filtres intégrés et les colonnes nommées à partir de vos métadonnées. Tous les rapports fournis peuvent également hériter des métadonnées. S'ils veulent faire des MI à partir des données, fournissez-leur un extrait des données transactionnelles, ou peut-être une application MIS supplémentaire sur un autre serveur s'ils le paieront.

• N'essayez pas de fournir plus de personnalisation que cela (c.-à-d. Aucune modification radicale du schéma) à moins que le client ne soit prêt à payer pour sa propre instance privée et à maintenir une construction personnalisée.

Les raisons derrière cela sont:

• Ces systèmes de base de données géreront le type de volumes que vous décrivez sur du matériel assez ordinaire. Vous n'avez pas vraiment le type de volume de transaction qui mérite une base de données NoSQL. À moins que vous n'ayez une autre raison architecturale d'en vouloir, il n'y a pas grand intérêt à aller à la fine pointe.

• Ce sont des technologies matures et bien comprises.

• La gestion du système, la sauvegarde / restauration, la réplication, les rapports et la reprise après sinistre sont tous bien triés sur les plates-formes SGBDR.

• Vous pouvez obtenir des bibliothèques clientes, y compris JDBC, pour toutes les principales plates-formes SGBDR.

• Les vues peuvent être utilisées pour la personnalisation par utilisateur et générées à partir des métadonnées de votre application.

• Il est nettement plus efficace que les champs XML ou les structures EAV.

Avec PostgreSQL, vous avez la possibilité d'utiliser des bases de données, des schémas ou des vues distincts pour gérer la multi-location.

L'utilisation de plusieurs bases de données (au sein du même serveur de base de données) rend l'administration plus complexe car chaque base de données doit être gérée individuellement. Par conséquent, cela n'est conseillé que si la sécurité entre les locataires est de la plus haute importance.

Les schémas séparés offrent beaucoup de flexibilité et de sécurité mais rendent les mises à niveau plus complexes car elles doivent être appliquées individuellement et ne sont probablement nécessaires que si vos locataires utilisent des structures de table complètement différentes; ce qui est peu probable s'ils utilisent la même application.

Les vues permettent aux locataires de voir différentes parties d'une structure de table commune et vous permettent de contrôler les tables, les colonnes et les lignes auxquelles elles ont accès. La seule mise en garde est que votre application doit s'assurer qu'elle n'utilise que ces vues et non les tables de base, sinon il existe un risque de fuites de données accidentelles entre les locataires en raison de défauts logiciels.

Vous n'avez pas vraiment besoin de créer des colonnes avant les exigences de l'application. Les colonnes peuvent être ajoutées aux tables de manière dynamique (sans aucun impact notable sur les utilisateurs) et les vues peuvent également être mises à jour dynamiquement. Vous avez seulement besoin de réfléchir à l'ordre des changements - c'est-à-dire. changer les tables, puis les vues puis le code de l'application.

Votre seule préoccupation potentielle est de savoir si vous devez ajouter une nouvelle colonne qui doit être ajoutée à un index existant ou nécessite un nouvel index. C'est alors que la table peut être verrouillée lors de la construction de l'index - mais PostgreSQL prend en charge la possibilité de créer des index simultanément sans verrouiller la table. Cela fonctionne correctement, sauf si le nouvel index doit être unique et trouve une violation d'unicité.

Vous n'avez probablement pas besoin d'une base de données NoSQL car ils suppriment efficacement le schéma de la base de données et nécessitent que l'application le gère à la place. Il ne semble pas que vos volumes exigent ce genre de sacrifice.