对于有竞争力的在线门票销售，您会建议什么数据库解决方案答案

【问题标题】：What database solution will you suggest for competitive online tickets sale对于有竞争力的在线门票销售，您会建议什么数据库解决方案
【发布时间】：2011-07-06 12:29:37
【问题描述】：

你能给我一个数据库设计建议吗？

我想出售活动门票，但问题是当许多用户同时购买同一活动的门票时，数据库可能会成为瓶颈。

如果我为每个活动提供剩余门票的柜台，则此字段将有更多更新（锁定），但我会很容易找到剩余的门票数量
如果我提前为每个活动生成门票，将很难知道还剩多少门票

如果每个事件都可以使用单独的数据库可能会更好（如果对该事件的请求预计很高）？

可能预留也得异步操作？

我必须使用关系数据库（MySQL、Postgres）还是无关系数据库（MongoDB）？

我计划使用 AWS EC2 服务器，以便在需要时运行更多服务器。

我听说“关系数据库无法扩展”，但我认为我需要它们，因为它们具有事务和数据一致性，这是我在处理确定数量的工单时所需要的，我说的对吗？

你知道互联网上有一些这类主题的资源吗？

【问题讨论】：

您听说过“关系数据库无法扩展”。我听说猪会飞。想想世界上最复杂、最大的数据处理，它是一个关系数据库。直到最近，NoSQL 数据库才解决了非常具体的问题，并通过改变关系范式来解决这些问题。
实际上，当您想到一些最大、最复杂的数据处理时，您可能会喜欢 CICS 之类的东西，这就像我父亲的 NoSQL... ;-)
带有 ID 键的设计糟糕的“关系”数据库无法扩展，设计良好的关系数据库可以很好地扩展。所以要正确设计。并确保您了解事务控制、OLTP 和并发要求并实施它们。所有高端的关系型数据库平台都提供异步操作，您不必自己动手。低端的免费软件平台甚至没有真正的服务器架构，所以要小心。
但它们是网络规模吗？ youtube.com/watch?v=b2F-DItXtZs
@PerformanceDBA：这是个玩笑，而且你显然不会明白，因为视频是针对反对漫画的 NoSQL 狂热分子编写的。如果你只是假装我不存在，我会很高兴，因为我发现你的 cmets 很累。

标签： sql mongodb postgresql database-design nosql

【解决方案1】：

如果您在 5 分钟内卖出 100.000 张门票，您需要一个每秒可以处理至少 333 笔交易的数据库。几乎所有最新硬件上的 RDBMS 都可以处理这么大的流量。

除非您的数据库架构和/或 SQL 不是那么理想，否则这是另一个问题。

【讨论】：

【解决方案2】：

首先要做的是：在销售商品（电子商务）方面，您确实需要交易支持。这基本上不包括任何类型的 NoSQL 解决方案，例如 MongoDB 或 Cassandra。

所以你必须使用支持事务的数据库。 MySQL 可以，但不是在每个存储引擎中都有。确保使用 InnoDB 而不是 MyISAM。

因为很多流行的数据库都支持事务，所以你可以选择哪一个。

为什么要交易？因为您需要完成一堆数据库更新，并且您必须确保它们都作为一个原子操作成功。例如： 1）确保门票可用。 2) 可用票数减少一张 3）处理信用卡，获得批准 4) 将购买细节记录到数据库中

如果任何操作失败，您必须回滚以前的更新。例如，如果信用卡被拒绝，您应该回滚可用票的减少。

并且数据库将为您锁定这些表，因此在第 1 步和第 2 步之间没有任何变化，其他人尝试购买门票但可用门票的数量尚未减少。因此，如果没有表锁定，可能会出现仅剩 1 张票可用但由于第二次购买开始于第一次交易的第 1 步和第 2 步之间而出售给 2 人的情况。

在开始编写电子商务项目之前，您必须了解这一点

【讨论】：

当我只需要锁定一条记录（又名票证）时，我不会锁定整个表。性能会很糟糕。
是的，但您说“数据库会为您锁定这些表”。表锁是非常不同的东西，也是您不想要的东西。有时你必须自己锁定一条记录，SELECT ... FOR UPDATE 是此类应用程序中的常见语句。
弗兰克，我认为这只是一个语义问题......但我加了你的评论因为这是真的
@Steph。它不是“语义”。阅读 ISO/IEC/ANSI 标准 SQL 隔离级别和事务控制命令。
我想我不会。不过，感谢您的提示。

【解决方案3】：

看看这个question regarding releasing inventory。

我认为您不会遇到关系数据库系统的限制。但是，您需要一个处理事务的。正如我在引用的问题中向发帖人建议的那样，您应该能够处理影响库存的保留票与购买者在交易完成之前保释的订单上的票。

【讨论】：

【解决方案4】：

您的问题似乎比数据库设计更广泛。

首先，关系数据库可以很好地扩展。您可能需要考虑一个 Web 服务层，该层将为最终用户提供实际的票证代理。在这里，您将能够以独立于实际数据库设计的缓存方式管理事物。但是，您需要考虑数据插入、更新和选择的适当步骤，以优化您的性能。

第一步是继续构建一个规范化的关系模型来保存您的信息。二、构建一些web服务接口与数据模型交互然后将其放入用户界面并对许多同时进行的事务进行压力测试。

我敢打赌，您需要迭代地重新设计您的 Web 服务层，直到您满意为止 - 但您的数据库（正常化）不会给您带来任何瓶颈问题。

【讨论】：