你能给我一个数据库设计建议吗？
我想出售活动门票，但问题是，当许多用户同时购买同一活动的门票时，数据库可以成为bootleneck。
如果每个事件都可以使用单独的数据库（如果预计此事件的请求很高），可能会更好吗？
可能预约还要异步操作吗？
我是否必须使用关系数据库（MySQL，Postgres）或无关系数据库（MongoDB）？
我正计划使用AWS EC2服务器，因此如果需要，我可以运行更多服务器。
我听说“关系数据库不能扩展”，但我认为我需要它们，因为它们具有交易和数据一致性，在使用一定数量的票时我需要这些，我是对还是不对？
您是否了解互联网上有关此类主题的一些资源？
答案 0 :(得分：5)
如果您在5分钟内售出100.000张票，则需要一个每秒至少可处理333笔交易的数据库。几乎所有近期硬件上的RDBMS都可以处理这种流量。
除非你有一个不太理想的数据库模式和/或SQL，否则这是另一个问题。
答案 1 :(得分：3)
查看此question regarding releasing inventory。
我认为你不会遇到关系数据库系统的限制。但是，您需要一个处理事务的方法。正如我在引用的问题中向海报推荐的那样，您应该能够处理在交易完成之前购买者保释的订单影响库存与门票的预订票据。
答案 2 :(得分：3)
首先要做的事情是：当涉及到销售（电子商务）时，您确实需要交易支持。这基本上排除了任何类型的NoSQL解决方案，如MongoDB或Cassandra。
因此，您必须使用支持事务的数据库。 MySQL可以，但不是在每个存储引擎中。确保使用InnoDB而不是MyISAM。
因为很多流行的数据库都支持交易，所以由你自己选择。
为什么交易？因为您需要完成一堆数据库更新，并且必须确保它们都可以作为一个原子操作成功完成。例如： 1）确保门票可用。 2）减少一张可用票数 3）处理信用卡，获得批准 4）将购买细节记录到数据库中
如果任何操作失败，则必须回滚以前的更新。例如，如果信用卡被拒绝，您应该回滚可用票证的减少。
数据库将为您锁定这些表，因此在步骤1和2之间没有任何更改，其他人尝试购买票证，但可用票证的数量尚未减少。因此，如果没有表锁，则可能只有1张票可用，但由于第二次购买在第一次交易的第1步和第2步之间开始，因此被出售给2人。
在开始编程电子商务项目
之前，了解这一点至关重要答案 3 :(得分：2)
你的问题似乎比数据库设计更广泛。
首先，关系数据库的扩展性非常好。您可能需要考虑一个Web服务层，它将为最终用户提供实际的票证代理。在这里，您将能够以独立于实际数据库设计的缓存方式管理事物。但是，您需要仔细考虑数据插入的相应步骤，并进行更新和选择以优化您的性能。
第一步是继续构建一个良好规范化的关系模型来保存您的信息。 第二，构建一些Web服务接口以与数据模型交互 然后将其放入用户界面并对许多同步事务进行压力测试。
我的赌注是你需要迭代地重新编写你的web服务层，直到你满意为止 - 但是你的数据库（很好地规范化）不会引起任何瓶颈问题。