多个模式与巨大的表 [英] Multiple schemas versus enormous tables

问题描述

考虑一个包含每个用户信息的移动设备管理器系统，例如存储他在手机上安装的应用程序的表，审计详细信息，通知信息等。为每个用户创建独立模式是明智的对应的表？对于单个用户，表的数量是大的，每个大约30个表。最好有一个独立的模式，所有这些信息都放在这些表中（反过来又创建巨大的表？）或者为每个用户都有一个模式。

Consider a mobile device manager system that contains information for every user such as a table that stores the apps that he has installed on the phone, auditing details, notification information etc. Is it wise to create a seperate schema for each user with the corresponding tables? The number of tables is large for a single user amounting to about 30 tables each. Would it be better to have a seperate schema where all this information is placed into these tables (in turn creating enormous tables?) or have a schema for each user?

谢谢

我想要查看哪个方法在数据库中的查询方面更高效。

解决方案

推荐答案

。

在多租户数据库中，查询只是问题的一部分。其他部分的问题是成本，数据隔离和保护，维护和灾难恢复。这些是重要的;您不能在多租户数据库中仅考虑查询效率。

Multi-tenant solutions range from one database per tenant (shared nothing) to one row per tenant (shared everything).

多租户解决方案

无共享，单独数据库或每个租户一个数据库

• Most expensive per client. (Large numbers of clients imply large numbers of servers.)
• Highest degree of data isolation.
• Disaster recovery for a single tenant is simple and straightforward.
• Maintenance is theoretically harder, because changes need to be carried out in every database. But your dbms might easily support running stored procedures in each database. (SQL Server has an undocumented system stored procedure, sp_msforeachdb, for example. You can probably write your own.) "Shared nothing" is the most easily customizable, too, but that also raises more maintenance issues.
• Lowest number of rows per table. Querying speed is near optimal.

• 每个客户最贵。 （大量的客户端意味着大量的服务器。）


• 最高的数据隔离度。


• 单个租户的灾难恢复非常简单直接。


• 理论上维护更难，因为需要在每个数据库中进行更改。但是dbms可能很容易支持在每个数据库中运行存储过程。 （SQL Server有一个未记录的系统存储过程，例如sp_msforeachdb，你可以自己编写。）Shared nothing也是最容易定制的，但也会引起更多的维护问题。


• 每个表的最少行数。查询速度接近最佳。

"Shared everything", or "shared schema", or "one database per planet"

共享一切或共享模式

• 每个租户最贵。


• 最低的数据隔离度。每个表都有一个列，用于标识行所属的租户。由于租户行在每个表中混合，因此意外暴露其他租户的数据相对较为简单。


• 单个租户的灾难恢复相对复杂;您必须还原多个表中的单个行。另一方面，单租户灾难是相对不寻常的。大多数灾害可能会影响所有租户。


• 考虑到所有租户共享表，结构维护更简单。然而，它增加了通信负载，因为您必须与每个租户沟通和协调每个更改。


• 每个表格的最多行数。快速查询更难，但它取决于多少租户和多少行。

Between "shared nothing" and "shared everything" is "shared schema".

在无共享和共享的一切之间是共享模式 p>

共享模式

"Shared schema"

• 租户共享数据库，但每个租户都有自己的命名模式。成本落在无共享和共享一切之间;大系统通常比无共享需要更少的服务器，比共享一切更多的服务器。


• 比共享一切更好的隔离。不如没有共享的隔离。 （您可以对模式使用GRANT和REVOKE权限。）


• 单个租户的灾难恢复需要恢复多个模式中的一个。这是相对容易或相当困难，取决于你的dbms。


• 维护比shared nothing容易;不像共享一切那么容易。编写将在数据库中的每个模式中执行的存储过程是相对简单的。


• 通常每个服务器的活跃用户比无共享多，这意味着他们共享（降级）更多的资源。但是不如共享一切那么糟糕。

• Tenants share a database, but each tenant has it's own named schema. Cost falls between "shared nothing" and "shared everything"; big systems typically need fewer servers than "shared nothing", more servers than "shared everything".
• Much better isolation than "shared everything". Not quite as much isolation as "shared nothing". (You can GRANT and REVOKE permissions on schemas.)
• Disaster recovery for a single tenant require restoring one of many schemas. This is either relatively easy or fairly hard, depending on your dbms.
• Maintenance is easier than "shared nothing"; not as easy as "shared everything". It's relatively simple to write a stored procedure that will execute in each schema in a database. It's easier to share common tables among tenants than with "shared nothing".
• Usually more active tenants per server than "shared nothing", which means they share (degrade) more resources. But not as bad as "shared everything".

Microsoft有一篇关于多元化架构。 （链接只是多页文档的一页。）

Microsoft has a good article on multi-tenant architecture with more details. (The link is to just one page of a multi-page document.)

这篇关于多个模式与巨大的表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！