MongoDB for SaaS中的多个数据库 [英] Multiple Databases in MongoDB for SaaS

问题描述

我正在node.js中构建SaaS应用程序，并希望将MongoDB用于Mongoose ODM的数据库.我将需要支持多个客户(希望有成千上万个)，并且每个客户的数据之间没有交互.

I am building a SaaS application in node.js and want to use MongoDB for a database with the Mongoose ODM. I will need to support multiple customers, between hundreds and thousands (hopefully) and there is no interaction between the data of each customer.

我的想法是为每个客户创建一个新数据库，并创建一个包含全球信息的主"数据库.例如，该应用程序将只有一个登录页面，因此我想将所有用户/密码信息存储在主"数据库中，但将所有用户的个人资料信息存储在他们所属的客户数据库中.我认为这将是一个很好的设计，因为它可以完全隔离每个客户的数据，并且可以轻松地分别备份/还原客户.

My thought was to create a new database for each customer and a single "master" database which held global information. For example, there will be a single login page for the app, so I wanted to store all user/password info in the "master" database, but all the user's profile information within the customer's database to which they belong. I felt that this would be a good design as it would completely isolate each customers' data and make it easy to backup/restore a customer individually.

我关心的是从node.js连接到多个数据库对性能的影响.有谁知道这将对该应用程序产生什么影响，或者总体上对体系结构有何看法?

My concern is regarding the performance impact of connecting to multiple databases from node.js. Does anyone know how that would impact that app, or any opinions about the architecture in general?

奖金问题:您是否知道在SaaS解决方案中进行反向操作并将所有客户数据存储在单个数据库中并与客户ID分开对审计有何影响?

Bonus Question: Do you know of any audit implications of doing the reverse and storing all customer's data in a single DB, separated with a customerid, in a SaaS solution?

推荐答案

这不是一个简单的答案，因为这在很大程度上取决于您的应用程序体系结构，使用情况和查询模式，客户端之间的分布(即:使用程度是否大致相同)跨客户，或者您是否有10％的客户使用90％的资源)，您可以在代码与运维管理上花多少钱以及其他很多问题.这里有一些要考虑的事情:

Not an easy answer because a lot depends on your app architecture, usage and query patterns, the distribution among clients (ie: will the usage levels be roughly the same across clients, or could you have 10% of the clients using 90% of the resources), how much you can spend on code vs ops management and a whole host of other issues. Here are some things to consider:

1)拥有一个数据库将使您的运维管理更轻松，需要的计算资源更少，并且可能使您可以更好地进行扩展，但是对访问层进行编码将变得更加困难，并且您确实必须很好地构建安全层，以实现显而易见的目标.原因.您还将在客户端/网络服务器端消耗更少的资源，因为连接数量将减少.

1) having one database will make your ops management easier, require less computing resources, and may allow you to scale out better, but coding the access layer will be more difficult and you really have to architect your security layer well for obvious reasons. You'll also consume less resources on the client/webserver end since there will be many fewer connections.

在访问一个整体数据库时，有两种流行的模式选项:

There are two popular schema options when approaching one monolithic database:

• 您可以将所有相似的数据放在一个集合中(即:所有帐户的配置文件都进入同一个集合)，并为每个文档提供一个clientid密钥，以识别哪些数据属于哪个帐户.这可能会为您提供最佳的选择(取决于您的架构体系结构)，以便使用最少的计算资源进行横向扩展.
• 另一种选择是按集合将客户端数据分开-每个客户端在数据库中都有自己的集合，并以clientid前缀(即:clientid_userprofiles)标识.

2)每个客户端使用数据库"选项将使您更加麻烦操作管理，并且由于需要更多的计算资源而花费更多.另一方面，您的编码成本应更低，因为代码将更易于编写.它还将使您能够在轻量级用户和轻量级用户之间更好地分配资源.例如，您可以将使用率较高的客户端移至功能更强大的计算机上，并按每个客户提供分片.

2) the database per client option will give you more ops management headaches and cost more as you will need more more computing resources. On the other hand, your coding costs should be less as the code will be easier to write. It will also allow you to better distribute your resources between heavy and light users. For example, you can move heavy usage clients to more powerful machines and provide sharding on a per customer basis.

3)，您可以提供两个选项的组合-高端用户专用数据库(支付更多费用的帐户)，然后共享一个数据库，其中低端客户和测试/免费帐户使用按收集的数据进行分隔.

3) you could provide a combo of the two options - dedicated databases for high end users (accounts that pay more), and then a shared database with data separated by collection for low-end clients and test/freemium accounts.

请注意，如果您使用许多数据库路由，则应查看--smallfiles启动选项.这将在您有很多人设置测试帐户"但对它们做得不多的情况下为您提供帮助.

Note that if you do go the many database route, you should look into the --smallfiles startup option. This will help you with situations where you have a lot of people setup "test accounts" but who don't do very much with them.

无论如何，希望以上内容能为您带来思考.在 https://groups.google.com/forum上进行搜索/?fromgroups#！searchin/mongodb-user/multitenant ，因为在Mongo论坛中已经有很多关于此特定问题的讨论.

Anyway, hopefully the above gives you food for thought. Do a search on https://groups.google.com/forum/?fromgroups#!searchin/mongodb-user/multitenant as there have been a number of discussions in the Mongo forums on this specific issue.

至于审计的含义，取决于您需要遵循的审计合规级别.如果您期望《财富》 1000强客户，则您的合规性要求会更高(并且成本更高-认为从几十美元到十万美元到十万美元不等)，如果您的客户是可能从未听说过SAS70的初创公司，等等.还取决于您存储的数据类型-是用户财务数据还是仅仅是用户论坛?基本上，如果担心将来需要通过大型公司的安全审核，甚至不用考虑共享数据库方法.

As for the audit implications, depends what level of auditing compliance you need to adhere to. If you expect fortune 1000 clients, your compliance requirements will be far higher (and way more costly - think $10s to $100s of thousands of dollars), than if your clients are startups who may never have heard of SAS70, etc. The answer also depends on what type of data you are storing - is it user financial data, or is it just user forums? Basically, if there are any concerns about needing to pass security audits for large companies in the future, don't even think of the shared database approach.

这篇关于MongoDB for SaaS中的多个数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！