单个或多个数据库
我正在开发跟踪网站访问者的服务（网站所有者只是将一些java脚本放入他的网站......就像Google Analytic或Woopra一样）。可能存在每天访问量较低但访问量较大（超过 10 000 次）的网站。该服务的用户数量也可能增长到数千。数据库没有非常困难的结构（3或4个表）。我正在使用 MSSQL 2008。
该系统的最佳解决方案是什么？
- 单一数据库系统，所有用户一个数据库
- 多个数据库系统，每个用户一个数据库
- 多个数据库系统，某些用户范围一个数据库
所以 1. 可能是个坏主意，我无法在 2. 和 3. 之间做出决定。
谢谢你的答案
鲁迪
I am working on service which tracks visitors of websites (website owner just puts some java script to his site... just like Google Analytic or Woopra). There can be websites with low but also heavy traffic (more than 10 000) visits per day. Also count of users of this service can grow to thousands. Database does not have very difficult structure (3 or 4 tables). I am using MSSQL 2008.
What would be the best solution for this system?
- Single database system, one database for all users
- Multiple database system, one database for each user
- Multiple database system, one database for some range of users
So 1. is probably bad idea, I can't decide between 2. and 3.
Thanks for your answers
Rudy
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我假设您将拥有某种可以通过 http 调用的服务接口，并且通过此接口统计信息将保存到数据库中。
我将从使用单个数据库开始，它（根据定义）将是一个能够为多个用户提供服务的数据库。对于您的前 200 个（300？800？1000？）用户来说，这个（简单）系统很可能表现得足够好。然后您将拥有一个运行良好的简单系统。
当您注意到数据库负载增加到一定水平（监视它）时，您可以通过将用户组提供给不同的数据库来稍微改变您的服务。无需更改数据库设计，因为它已经适用于多个用户。仅调整服务应用程序，使其根据用户选择正确的数据库。
您可以选择具有商业意义的用户组；例如，一家网络托管公司的一组 150 个用户，该公司向您（或您的客户）付费以收集统计数据。
在这种情况下，单个数据库可以更轻松地对所有用户进行分组统计。
I assume that you will have some sort of service interface that can be called over http and that through this interface statistics are persisted to the db(s).
I'd start with using a single database, which (by definition) will be a database capable serving multiple users. It might well be that this (simple) system performs well enough for your first 200 (300? 800? 1000?) users. And then you'll have a simple system that works well.
As you notice database payload increasing to a certain level (monitor it), you can slightly change you're service by serving sets of users to different db's. No need to change your db design, because it works for multiple users already. Only adjust the service app such that it chooses the right db based on the user.
You can choose sets of user that make business sense; for instance a set of 150 users of a single webhosting company, that pays you (or your customer) to gather statistics.
In this case, the single db makes it easier to group statistic over all users.
选择选项 1。
数据库旨在扩展和管理大量数据。尝试使用多个数据库只会让事情变得混乱并在您这边添加更多代码。想象一下必须为每个新用户创建一个数据库，然后记录哪个数据库适合哪个用户......
Go with option 1.
Databases are meant to scale and manage large amounts of data. Trying to use several databases will just get things messy and add more code on your side. Just imagine having to create a database for each new user, then record which database is for which user...
好吧，只要数据库数量没有一些奇怪的限制，为什么不选择选项 3呢？
Well, as long as there isn't some weird constraint on the number of databases, why not go with option 3?
您是否想过“云计算”？在这里您根本不必担心可扩展性。
Have you thought of 'Cloud computing'. Here you don't have to worry about scalability at all.