我的任务是设计电子商务解决方案。导致我最多问题的方面是数据库。
目前，该网站由10多个基于国家/地区的商店组成，每个商店都有自己的数据库（全部驻留在同一个mysql实例上）。
对于新网站，我宁愿将所有这些商店数据库合并到一个数据库中，以便所有表格（产品，订单，客户等）都有shop_id字段。从编程的角度来看，这似乎最有意义，因为我们不必跨多个数据库管理数据。
目前，整个网站每年产生约12万个订单，但正在经历相当大的增长，我们需要设计一个可扩展的解决方案。在5年内，每年可能有超过一百万个订单和一个包含5年订单历史的数据库（存档可能是此处的解决方案）。问题是 - 我们使用单个数据库，还是保留每个数据库的数据库结构？
我目前正试图寻找任何一种途径的支持证据。我正在设计解决方案的公司更喜欢每个商店的数据库结构，因为他们相信它将允许网站扩展。但我的论点是，该商店的数据库在未来几年内可能不会那么繁忙，因为它们超出了mysql数据库的容量和“无费用”硬件设置。
我想知道是否有人有任何建议吗？有没有人对拥有包含数百万条记录的表的网站/电子商务网站有经验？我知道这里可能没有一个明确的答案，但是在什么阶段我们有太多的记录或太大的表格文件才能有一个快速加载网站？
此外，如果有人对信息来源有任何建议 - 书籍，网站等，我可以进一步研究，我们将非常感谢！
答案 0 :(得分：2)
我实施了一个剧院门票销售解决方案，其中包含数十万条记录的表格，并且没有性能问题可言（硬件没什么特别之处）。虽然我很难比较负载，但我认为数据量增加10倍不太可能显着影响性能。如果它是相同的应用程序和相同的模式，我很可能倾向于单个中央数据库（可能具有故障转移），因为：
可能还有其他一些原因。拥有多个实例的明显优势在于您可以获得穷人的高可用性：如果一台服务器出现故障，只有一家商店无法正常工作，您就可以开箱即用。
答案 1 :(得分：2)
我认为更容易保留单独的数据库。对这些没有直接关系的实体进行逻辑分离更有意义。它也将更容易扩展，以便每个站点可以在时间到来时在单独的硬件上运行。备份/恢复和一般维护程序在单独的实例上也会更容易，因为它允许每个商店的自定义程序。任何灾难情景也只影响一个逻辑数据库，而不是可能搞砸每个商店。
您当前的提案意味着几乎每个表都需要一个“商店ID”列，该列也会被编入索引以防止冲突。稍后当你需要扩大规模时分离这些数据不会太大问题，但重新编程很可能非常耗时。