无模式/灵活 + ACID 数据库？

Question

我正在考虑将基于 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”事务的“非此即彼”案例还是有更好的出路？

Answer 1

选项1

这有几个原因，我将在下面解释。首先，这是如何做到的。

• 使用您选择的标准 RDBMS 平台。

• 使用多个用户可配置的字段设置您的架构，并使您的应用程序在每个租户的基础上促进配置。

• 从每个租户的元数据中，您可以创建每个租户的数据视图，其中包含内置过滤器和从元数据命名的列。提供的任何报告也可以继承元数据。如果他们想对数据进行 MI，然后向他们提供交易数据的摘录，或者如果他们愿意支付费用，则可能在不同的服务器上提供一些额外的 MIS 应用程序。

• 不要尝试提供比这更多的定制（即不对模式进行根本性更改），除非客户端准备为他们自己的私有实例付费并维护定制构建。

这背后的原因是：

• 这些数据库系统将处理您在相当普通的硬件上描述的那种卷。您实际上没有那种值得使用 NoSQL 数据库的交易量。除非您有其他一些架构原因想要一个，否则采用前沿技术并没有多大意义。

• 它们是成熟的、易于理解的技术。

• 系统管理、备份/恢复、复制、报告和灾难恢复都在 RDBMS 平台上进行了很好的分类。

• 您可以获得客户端库，包括适用于所有主要 RDBMS 平台的 JDBC。

• 视图可用于每个用户的自定义并从您的应用程序元数据生成。

• 它比 XML 字段或 EAV 结构更有效。

Answer 2

使用 PostgreSQL，您可以选择使用单独的数据库、单独的模式或视图来处理多租户。

使用多个数据库（在同一数据库服务器中）会使管理更加复杂，因为每个数据库都必须单独管理。因此，这仅在租户之间的安全是最重要的情况下才是可取的。

单独的模式提供了很大的灵活性和安全性，但使升级更加复杂，因为它们必须单独应用，并且可能只有在您的租户使用完全不同的表结构时才需要；如果他们使用相同的应用程序，这是不太可能的。

视图允许租户查看公共表结构的不同部分，并允许您控制他们有权访问哪些表、哪些列和哪些行。唯一需要注意的是，您的应用程序必须确保它只使用这些视图而不是基表，否则由于软件缺陷，租户之间可能会发生意外的数据泄漏。

您实际上不需要在应用程序要求之前创建列。列可以动态添加到表中（对用户没有任何明显影响），视图也可以动态更新。您只需要考虑进行更改的顺序 - 即。更改表，然后是视图，然后是应用程序代码。

您唯一可能担心的是，您是否需要添加需要添加到现有索引或需要新索引的新列。那就是在构建索引时可以锁定表的使用情况 - 但 PostgreSQL 支持在不锁定表的情况下同时构建索引的能力。这工作正常，除非新索引需要唯一并发现唯一性违规。

您可能不需要 NoSQL 数据库，因为它们可以有效地从数据库中删除架构，而是需要应用程序来管理它。听起来您的音量并不需要那种牺牲。