为我的每个客户提供专用数据库和应用程序池是否可扩展？
我们的团队目前正在集思广益，讨论一个产品创意，这个创意已经挂在嘴边好几年了。
它很可能是托管在 WISC 堆栈（Windows、IIS、SQL Server、C#）上的 ASP.NET MVC Web 应用程序...
理想情况下，我们希望遵循与fog-creek 的人类似的路线Fogbugz 提供托管和“在您的服务器上运行”风格的解决方案。
当然，我们希望保持代码和数据库模式几乎相同（出于维护目的），以便我们可以一次性编译两者。
因此，“为所有用户提供一个大数据库”似乎会增加开发人员维护架构差异等方面的开销。
我记得在 2008 年听过 Stack Overflow 播客，其中 joel spolskey 提到他的 SQL Server 实例有数千个数据库的数据库，因为它们为每个用户提供专用数据库，但在 SQL Server 2000 管理如此多的数据库时存在扩展问题。
所以我的问题是：
- 这个解决方案易于管理吗？
- SS2008 是否可以更好地管理数千个数据库？
- IIS 可以处理那么多应用程序吗？泳池？
- 这种设置还有更多成功案例吗？
- 这在普通的 WISC 基础设施上可能吗？
Our team is currently brainstorming a product idea that's been on the tip of our tongues for a couple of years now.
It'll most probably be an ASP.NET MVC web application hosted on the WISC stack (Windows, IIS, SQL Server, C#)...
Ideally we'd love to follow a similar route to the guys at fog-creek did with fogbugz offering both hosted and "run on your server" style solutions.
Naturally we want to keep the code and database schema practically identical (for maintenance purposes) so we can compile for both in one go.
So having "one big database for all users" seems like it'd add developer overhead maintaining the difference in schema etc..
I remember listening to the stack overflow podcast from back in 2008 where joel spolskey mentioned that his instance of SQL Server had thousands of databases on as they provide each user with a dedicated database, but had scaling issues with SQL server 2000 managing that many databases.
So my question is:
- Is this solution easily manageable?
- Does SS2008 manage thousands of databases any better?
- Can IIS handle that many applications & pools?
- Are there any more success stories of this kinda setup working?
- Is this possible on vanilla WISC infrastructure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为 SQL Server 2008 对于这种方法不会有任何具体问题。
无论如何，如果您寻求高可用性、可靠性和可扩展的解决方案，您应该考虑拥有多个 Web 服务器和多个数据库服务器。只是为了确保万一一台机器发生故障，您的数千个用户/客户的所有内容不会立即变得不可用。
I think SQL Server 2008 would not have any specific issue with this approach.
Anyway if you look for high availability, reliability and scalable solution you should consider having multiple Web Servers and multiple database servers. Just to make sure that in case one machine fails, not everything for your thousand users/customers gets unavailable at once.