小编AID*_*SEY的帖子

我在设计一个需要在未来进行水平分区的多租户数据库模式时,试图找出最佳方法.

数据库上的一些粗糙数字..

租户总数约为10,000.每个租户存储的数据量在500MB - > 3GB之间变化.租户的数量将从小开始,并在几年内增长到10,000,所以最初我们可以从单个多租户数据库开始,但从长远来看,由于性能原因需要横向扩展.

更新 - 一个复杂的因素是偶尔租户(公司)可以合并在一起,我也需要支持这个...,

多租户将使用共享数据库,共享架构架构实现,如本文所述http://msdn.microsoft.com/en-us/library/aa479086.aspx

鉴于我们将来会面临水平分区,并且很可能我们会在客户安定下来之前将客户端从一个数据库移动到另一个数据库,我认为最好将GUID用作每个表的主键以及唯一的tenantID列.

我知道使用GUID作为主键存在性能开销,但这是我需要接受的权衡吗？还有另一种设计水平分区的方法吗？

下面是一个例子 - 假设我想将公司与租户100和200合并在一起,如果PK是一个整数,当我将数据库2中的行复制到数据库1时可能会发生冲突,{guids}我保证不会发生碰撞......

数据库1数据库2 tenantid,id,description tenantid,id,description 100,1,'foo'200,1,'xxx'100,2,'boo'200,2,'yyy'

数据库1数据库2 tenantid,id,description tenantid,id,description 100,{aaa},'foo'200,{ccc},'xxx'100,{bbb},'boo'200,{ddd},'yyy'

我正在寻找一个SQL Server中的多租户工具.我正在考虑这里描述的共享数据库,共享架构和租户视图过滤器.唯一的缺点是碎片连接池......

根据http://msdn.microsoft.com/en-au/architecture/aa479086,租户视图过滤器描述如下:

"SQL视图可用于授予单个租户访问给定表中某些行的权限,同时防止他们访问其他行.

在SQL中,视图是由SELECT查询的结果定义的虚拟表.然后可以查询生成的视图并将其用于存储过程,就好像它是一个实际的数据库表一样.例如,以下SQL语句创建一个名为Employees的表的视图,该表已被过滤,以便只显示属于单个租户的行:

CREATE VIEW TenantEmployees AS 
SELECT * FROM Employees WHERE TenantID = SUSER_SID()

此语句获取访问数据库的用户帐户的安全标识符(SID)(您可以回忆,它是属于租户的帐户,而不是最终用户),并使用它来确定视图中应包含哪些行"

考虑到这一点,如果我们有一个数据库存储5,000个不同的租户,那么连接池就完全碎片化,每次向数据库发送请求时,ADO.NET都需要建立一个新的连接并进行身份验证(请记住连接池适用于每个唯一连接字符串)这种方法意味着你有5,000个连接字符串......

我有多担心这件事？有人能给我一些真实世界的例子,说明连接池对繁忙的多租户数据库服务器有多大影响(比如每秒处理100个请求)？我可以在这个问题上投入更多硬件吗？它会消失吗？

思绪??

有人可以发布一个node.js应用程序的工作代码示例,该应用程序使用在iisnode和azure上运行的socket.io.似乎IIS不能很好地使用socket.io和我发现的任何代码示例都不能在iisonde/azure上运行...

当我尝试将vie socketio连接到http:// mysite:8080时, azure会返回HTTP 500错误...

谢谢