对于可以大规模扩展的应用程序，我们是否应该从多个小粒度数据库开始
我们正在开发一个新的电子商务网站，并首次使用 NHibernate。目前，我们将数据分成多个 SQL Server 数据库，按功能区域划分。因此，我们有一个用于用户信息，一个用于订单，一个用于产品目录等等...
我们做出这一决定的理由实际上是双重的：
该网站有潜力变得巨大（这是一个新网站，其中一个是英国最大的在线品牌），我们认为，通过按照功能线对数据进行分区，我们将能够将数据库移动到他们自己的服务器上，这将为我们提供一个简单的扩展路线（如果我们需要的话）；
我的团队一直以这种方式工作 - 部分原因是遵循以前项目中的 MS Commerce Server 模式。
然而，通过在互联网上阅读这一决定，我们发现对这种模型的正常反应是极其严厉的。 “现在为开发人员创造更多工作，以便以后为开发人员创造更多工作”是来自 Stack Overflow 的一条评论示例！
此外，NHibernate 更容易使用，只需一个数据库（只需要一个 SessionFactory）。知道 Stack Overflow 长期以来只运行一个盒子让我觉得也许我们不应该表现得如此聪明。
所以，我的问题是，“我们认为使用细粒度数据库可能会提高我们的扩展能力是否正确，或者我们应该为了更容易的开发而牺牲这一点”？
We're developing a new eCommerce website and are using NHibernate for the first time. At present we are splitting our data into multiple SQL Server databases, divided per area of functionality. So we have one for UserInfo, one for Orders, one for ProductCatalogue and so on...
Our justification for this decision is twofold really:
the website has the potential to be HUGE (it is a new website for one of the largest online brands in the UK) and we feel that by partitioning our data along functional lines we will be able to move the databases onto their own servers which would give us an easy scaling route should we need it;
my team has always worked this way - partly as a consequence of following the MS Commerce Server pattern from previous projects.
However, reading up on this decision on the internet, we find that the normal response to this sort of model is extremely scathing. "Creating more work for the devs now in order to create more work for the devs later" is one sample comment from Stack Overflow!
In addition, NHibernate is much easier to use with only one database (just one SessionFactory needed). And knowing that Stack Overflow ran off just one box for a long time makes me think that maybe we should not try to be so clever.
So, my question is, "are we correct in thinking that using fine-grained databases might increase our ability to scale or should we sacrifice this for easier development"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为什么不正确设计数据库并将文件放在适当的磁盘上呢？如有必要，请使用集群。创建多个数据库并不是本质上的扩展解决方案。另外 - 跨数据库引用完整性？祝你好运。
你对“巨大”的定义是什么？ SQL Server 可以处理海量数据库，但我了解到的一件事是，人们常常不知道大量数据是由什么构成的。
Why don't you just design your database properly and put the files on appropriate disk? Use a cluster if necessary. Creating multiple databases is not an inherently scaling solution. Also - cross database referential integrity? Good luck.
What's your definition of "HUGE"? SQL Server can handle massive databases, but one thing I've learnt is that people often have no idea what constitutes a lot of data.
我从未参与过这样的项目。我习惯了拥有数百个表的数据库，这从来都不是问题。
因此我不能说你的想法是不是一个好主意，我从未尝试过。 “我的团队一直以这种方式工作”的论点是许多决策的主要驱动力，我什至不能说它总是错误的。
使用 NHibernate，您可以在类中组织数据。它们可以位于不同的命名空间和程序集中。您通常不会直接使用数据库进行太多工作，因此不需要这种结构。
关于可扩展性争论：我不确定当您每次需要访问多个数据库时它是否真的可以很好地扩展。我的意思是：你总是需要用户和订单，甚至可能更多。然后您需要从多个数据库获取所有这些数据。
I've never worked in a project like this. I'm used to databases with several hundred tables, which had never been a problem.
Therefore I can't say if your idea is a good idea, I never tried it. The "my team has always worked this way"-argument is a major driver for many decisions, and I can't even say that it is always wrong.
With NHibernate you organize your data in classes. They can be in different namespaces and assemblies. You usually don't work much with the database directly, you don't need this kind of structure there.
About the scalability argument: I'm not sure if it is really scaling well when you need to access several databases every time. I mean: you always need users and orders and probably more. Then you need to get all this data from several databases.
完全同意 starskythehutch - 将相关表放在同一个数据库中。但是，您可能需要考虑为与您的主要产品不相关或不重要的事物建立单独的数据库；但这是应用程序的一部分。
例如：如果您决定在数据库中记录对该站点的每次访问/点击，您可能应该将其保存在单独的数据库中。
您应该考虑的原因：
1. 交易数量巨大——比如每秒数十万。将非关键的不相关内容放在单独的数据库中将确保避免因此而导致的 tlog 争用。
Agree fully with starskythehutch - keep your related tables together in the same DB. BUT, you may want to consider having separate databases for things that are not related or non-critical to your main product; but that are a part of the app.
For eg: if you decide to log every visit/hit to the site in a DB, you should probably keep that in a separate DB.
The reason you should consider:
1. huge number of transactions - say hundreds of thousands / sec. Having non-critical un-related stuff in a separate DB will ensure that tlog contentions because of this are avoided.