将以不同速度增长的表拆分到各自的数据库中是明智的做法吗？
在我的数据库中，我的表将以不同的速度增长：
- 相当静态的表，我根本不希望增长太多；
- 中等等级的表，会随着用户数量及其活动的增长而线性增长；
- 快速增长的表，会快速增长因为它们保存着记录的数据点，所以
随着数据库的不断增长，我一直对维护这个数据库感到有点烦恼。这是一个平衡的场景：
- 单个数据库更容易使用，但将来可能会产生更高的维护成本。
- 部署应用程序后，多个数据库可以更容易维护，但需要更多的研发时间，
您可以推荐一个还是根据您过去的经验，另一种解决方案是什么？
谢谢，
In my database I have tables that will grow at different speeds:
- fairly static ones that I dont expect to grow much at all,
- medium-grade ones that will grow somewhat linearly with number of users and their activity
- fast-growing ones that will grow rapidly as they hold logged data points
I have been fretting a little bit about maintaining this database as it is growing. It is a balancing scenario:
- A single database is easier to work with but it may have higher maintenance costs in the future
- Multiple databases can be easier to maintain once the application is deployed, but will require more R&D time
Can you recommend one or the other solution based on your past experience?
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为数据增长的速度有多快无关紧要。我认为根据映射到现实世界的原因来划分数据库更有意义。
例如，通常，我们编写的每个应用程序都有一个数据库。我们有一个用于营养和成分数据库的数据库，另一个用于职位列表等的数据库。我们这样做是因为我们可以更轻松地跟踪哪个数据库影响哪些应用程序。 （为了避免换句话说造成混淆。）
但我们确实有一个通用数据库，其中保存了多个应用程序中使用的信息。 （如公司信息、位置等）这样我们就可以避免重复数据删除。 （为什么要在每个数据库中维护一个位置列表）。
我并不是说这就是您应该如何构建数据，但我将此作为将数据拆分到多个数据库的一个充分理由的示例。
除了针对不同增长的数据库制定不同的维护计划之外，我看不出有任何理由根据数据库活动进行拆分。
无论哪种方式，将它们拆分到负载均衡器后面都是相同的。部署后维护它们应该以受控的、预先测试的方式完成，无论表增长的速度有多快...
除非我遗漏了某些东西，否则我不这样做我没有看到这样做的充分理由，但我也没有看到不这样做的充分理由。如果它对您有意义，并且简化您的业务流程而不增加混乱或其他问题，那么它对您的情况有意义，而且我认为它没有任何坏处。
I think that how fast the data grows is irrelevant. I think that it makes more sense to have databases split up based on something mapped to a real-world reason.
For example, Typically, we have one database per app that we write. We have a database for a Nutrition and Ingredients database, another one for Job Listings, etc. We do this because it's easier for us to keep track of which database affects which apps. (To avoid confusion in other words.)
But we do have one Common database that holds information that's used in multiple applications. (Such as corporate info, locations, etc) so that we can avoid data de-duplication. (Why maintain a list of locations in each database).
I'm not saying this is how you should structure your data, but I listed this as an example of a good reason to have data split across multiple databases.
Other than having different maintenance plans for databases with varying growth, I can't see any reason to split based on database activity.
Splitting them behind a load balancer is the same either way.. Maintianing them once they're deployed should be done in a controlled, pre-tested manner regardless of how fast the tables grow...
Unless I'm missing something, I don't see a good reason for it, but I don't see a good reason not to do it, either. If it makes sense for you, and simplifues your business process without adding confusion or other problems, then it makes sense in your situation, and I see no harm in it at all.