用于SaaS应用程序的无架构/灵活ACID数据库？

Question

我正在考虑将基于内部部署（本地安装）应用程序（发票+库存）的VB重写为基于Web的小型企业客户Clojure应用程序。我打算将此作为SaaS应用程序提供给类似行业的客户。

我在看数据库选项：我的选择是RDBMS：Postgresql / MySQL。我可能在第一年扩展到400个用户，通常每个用户每天有20-40页的页面浏览量 - 主要用于非静态视图的交易。每个视图都将涉及获取数据和更新数据。 ACID合规是必要的（或者我认为）。因此交易量并不大。

根据我的偏好选择其中任何一个都是不费脑子的，但对于这个要求，我认为这是SaaS应用程序的典型要求：随着我添加更多客户/用户，Schema将会发生变化为每个客户不断变化的业务需求（我将提供一些有限的灵活性，仅限于开始）。由于我不是数据库专家，基于我能想到和阅读的内容，我可以通过多种方式解决这个问题：

1. 在MySQl / Postgresql中使用单个数据库托管多个租户进行传统的RDBMS架构设计。并在每个表中添加足够的“自由浮动”列以允许将来更改，因为我为现有客户添加了更多客户或更改。每次对Schema进行小的更改时，这可能会导致将更改传播到DB。我记得读过Postgresql架构更新可以实时完成而不需要锁定。但不确定，在这个用例中它是多么痛苦或多么实际。而且，由于架构更改也可能会引入新的/次要的SQL更改。
2. 拥有RDBMS，但以灵活的方式设计数据库模式：接近实体属性值或仅作为键值存储。 （工作日，例如FriendFeed）
3. 将整个内存作为对象存储并定期存储在日志文件中（例如，edval，lmax）
4. 去寻找像MongoDB或Redis这样的NoSQL数据库。但根据我可以收集的内容，它们不适用于此用例，并且不完全符合ACID。
5. 寻找一些像VoltDb或JustoneDb（基于云）的NewSQL Dbs，它们保留了SQL和ACID兼容行为，并且是“新一代”RDBMS。
6. 我看了neo4j（graphdb），但不确定这是否适合这个用例

在我的用例中，不仅仅是可伸缩性或分布式计算，我正在寻找一种更好的方法来实现“Schema + ACID的灵活性+一些合理的性能”。我在网上可以找到的大多数文章都提到了模式的灵活性，这是导致性能（在NoSQL DB的情况下）和可伸缩性同时省略ACID / Transactions方面的原因。

这是“架构灵活性与ACID”交易的“或者”案例，还是有更好的出路？

Answer 1

我认为tarantool可以帮到你。该解决方案有事务，lua，msgpack等。还可以看到video