使用SQL / WCF / Silverlight的多租户

Question

我们正在构建一个将作为SaaS提供的Silverlight应用程序。最终产品是连接到WCF服务的Silverlight客户端。由于客户端数量可能很大，因此更新需要很容易，最好能够一次性更新所有实例。

之前没有实施多租户，我正在寻找有关如何实现的意见

• 轻松升级
• 数据安全性
• 可扩展性

msdn

列出了需要考虑的三种不同模型

1. 单独的数据库。这不容易维护，因为所有架构更改都必须单独应用于每个客户的数据库。还有其他缺点吗？专家是数据分离和安全。这也允许每个客户进行轻微修改（这可能比它的价值更麻烦！）
2. 共享数据库，单独的架构。 TenantID列将添加到每个表中。确保每个客户获得正确的数据具有潜在的危险性。易于维护和扩展（？）。
3. 共享数据库，单独的架构。与第一个模型类似，但每个客户在数据库中都有自己的一组表。难以为单个客户恢复备份。可维护性与模型1（？）相似。

有关该主题的文章的任何建议？有没有人用Silverlight SaaS应用程序探索类似的东西？我需要在客户端考虑什么？

Answer 1

取决于应用程序的类型和数据规模。每个人都有垮台。

1a）单独的数据库+ WCF /客户端的单个实例。保持一切同步将是一个挑战。如何同时升级X数量的数据库服务器，如果一个服务器出现故障并且现在不同步且与客户端/ WCF层不兼容怎么办？

1b）“Silos”，为每个客户分别设置DB / WCF / Client。您没有同步问题，但您确实需要管理每个层的许多不同实例。此外，您还必须查看SQL许可，我不记得是否单独许可SQL的单独实例（$$$）。即使您可以根据需要安装任意数量的实例，多个实例的开销在某一点之后也不会是微不足道的。

3）除了许可之外，基本上与1a / b相同。

2）最佳升级/管理方案。你是对的，保持数据隔离是一个巨大的问题（1a技术上在更高层次上分享这个问题）。另一个问题是如果您的应用程序是数据密集型的，您必须担心数据可伸缩性。例如，如果预计每个客户都有数十/数亿行数据。然后，由于总客户群数量的原因，您将开始遇到问题并查询各个客户的绩效。客户对他们自己的数据量造成的减速更加宽容。由于其他99个客户数据很大，被告知它很慢，通常是禁止的。

除非你知道一个事实，你将从一开始就处理大量数据，我现在可能会使用＃2，并且如果将来需要的话，开始考虑集群或转向1a / b设置。

Answer 2

我们还有一个SaaS产品，我们使用解决方案＃2（与TenandId共享数据库/共享架构）。共享数据库/所有人的相同模式需要考虑的一些事项：

1. 如上所述，如果您不小心，一个租户的大量数据可能会影响其他租户的表现;对于初学者来说，正确/仔细地索引你的表，永远不会做强制表扫描的查询。监控查询性能，至少计划/设计能够根据对您的域有意义的一些标准对您的数据库进行分区。

2. 数据分离非常重要，您不希望最终向属于其他租户的某个租户显示一段数据。每个查询都必须包含WHERE TenandId = ...并且您应该能够在开发期间验证/强制执行此操作。

3. 模式的可扩展性是解决方案1和3可能提供给您的，但您可以通过设计一种方法来扩展与您的域中的文档/表相关联的字段（有意义）（ ie。表格的元数据，如msdn文章所述）

Answer 3

提供像Apprenda的SaaSGrid这样开箱即用的架构的解决方案怎么样？它们允许您在部署和维护时制定数据库决策，而不是在设计时。他们似乎积极转型和管理数据层，并提供升级引擎。

Answer 4

我也有类似的情况，但我的解决方案同时具有优势。

数据和数据的放置方式是租户提出的问题。作为租户当然我不希望我的数据被共享，我希望我的数据是孤立的，安全的，我可以随时随地获取。

它可能共享的某些数据，例如：公司列表。因此数据库应该是全局和租户数据库，只需确保锁定操作租户数据库模式，并立即更新所有租户数据库的程序。

无论如何SaaS模型都是作为服务器/ Web服务提供的，所以无论数据库应该作为服务来到客户端，只能通过客户端GUI进行渲染。

由于

Answer 5

现有答案很好。您应该深入研究升级和管理多个数据库的问题。在不知道特定应用程序的情况下，拥有多个数据库可能会变得更加容易，而无需支付跟踪TenantID的额外成本。这可能不会成为正确的决定，但您当然应该对数据共享的开销成本保持警惕。