小编tmb*_*dar的帖子

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

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

根据我的偏好选择其中任何一个是不费吹灰之力的，但对于这一要求，我认为这是 SaaS 应用程序的典型特征：随着我添加更多客户/用户以及每个客户的需求，架构将发生变化不断变化的业务需求（我将提供一些有限的灵活性，只是在开始时）。由于我不是数据库专家，根据我能想到和读到的内容，我可以通过多种方式处理这个问题：

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

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

这是“架构灵活性与 ACID”事务的“非此即彼”案例还是有更好的出路？