对于有竞争力的在线门票销售，您会建议哪种数据库解决方案
您能给我一个数据库设计建议吗？
我想出售活动门票，但问题是，当许多用户同时购买同一活动的门票时，数据库可能会成为瓶颈。
- 如果我有一个用于每个活动剩余门票的柜台，那么该字段将会有更多更新（锁定），但是如果我提前为每个活动生成门票，我将很容易找到还剩多少门票，
- 则很难知道有多少门票 ？
如果每个事件都可以使用单独的数据库（如果预计该事件的请求很高），可能会更好
可能预订也必须异步操作？
我必须使用关系数据库（MySQL、Postgres）还是不用关系数据库（MongoDB）？
我计划使用 AWS EC2 服务器，以便在需要时可以运行更多服务器。
我听说“关系数据库无法扩展”，但我认为我需要它们，因为它们具有在处理一定数量的票证时需要的事务和数据一致性，我对吗？
您知道互联网上有关此类主题的一些资源吗？
Can you please give me an database design suggestion?
I want to sell tickets for events but the problem is that the database can become bootleneck when many user what to buy simultaneously tickets for the same event.
- if I have an counter for tickets left for each event there will be more updates on this field (locking) but I will easy found how much tickets are left
- if I generate tickets for each event in advance it will be hard to know how much tickets are left
May be it will be better if each event can use separate database (if the requests for this event are expected to be high)?
May be reservation also have to asynchronous operation?
Do I have to use relation database (MySQL, Postgres) or no relation database (MongoDB)?
I'm planing to use AWS EC2 servers so I can run more servers if I need them.
I heard that "relation databases don't scale" but I think that I need them because they have transactions and data consistency that I will need when working with definite number of tickets, Am I right or not?
Do you know some resources in internet for this kind of topics?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您在 5 分钟内售出 100,000 张门票，则需要一个每秒至少可以处理 333 笔交易的数据库。几乎所有最新硬件上的 RDBMS 都可以处理如此大的流量。
除非你有一个不太优化的数据库模式和/或 SQL，但这是另一个问题。
If you sell 100.000 tickets in 5 minutes, you need a database that can handle at least 333 transactions per second. Almost any RDBMS on recent hardware, can handle this amount of traffic.
Unless you have a not so optimal database schema and/of SQL, but that's another problem.
首先，当涉及销售商品（电子商务）时，您确实需要交易支持。这基本上排除了任何类型的 NoSQL 解决方案，例如 MongoDB 或 Cassandra。
所以必须使用支持事务的数据库。 MySQL 确实如此，但并非在每个存储引擎中都如此。确保使用 InnoDB 而不是 MyISAM。
当然，许多流行的数据库都支持事务，所以选择哪一个取决于您。
为什么要交易？因为您需要完成一堆数据库更新，并且必须确保它们作为一个原子操作全部成功。例如：
1) 确保车票可用。
2）将可用门票数量减少一张
3）处理信用卡，获得批准
4) 将购买详细信息记录到数据库中
如果任何操作失败，您必须回滚以前的更新。例如，如果信用卡被拒绝，您应该回滚可用机票的减少。
数据库将为您锁定这些表，因此在步骤 1 和 2 之间没有任何变化，其他人尝试购买门票，但可用门票的数量尚未减少。因此，如果没有表锁，则可能会出现仅剩 1 张票可用但已出售给 2 个人的情况，因为第二次购买是在第一次交易的步骤 1 和步骤 2 之间开始的。
在开始电子商务项目编程之前了解这一点至关重要
First things first: when it comes to selling stuff (ecommerce), you really do need a transactional support. This basically excludes any type of NoSQL solutions like MongoDB or Cassandra.
So you must use database that supports transactions. MySQL does, but not in every storage engine. Make sure to use InnoDB and not MyISAM.
Of cause many popular databases support transactions, so it's up to you which one to choose.
Why transactions? Because you need to complete a bunch of database updates and you must be sure that they all succeed as one atomic operation. For example:
1) make sure ticket is available.
2) Reduce the number of available tickets by one
3) process credit card, get approval
4) record purchase details into database
If any of the operations fail you must rollback the previous updates. For example if credit card is declined you should rollback the decreasing of available ticket.
And database will lock those tables for you, so there is no change that in between step 1 and 2 someone else tries to purchase a ticket but the count of available tickets has not yet been decreased. So without the table lock it would be possible for a situation where only 1 ticket is left available but it is sold to 2 people because second purchase started between step 1 and step 2 of first transaction.
It's essential that you understand this before you start programming ecommerce project
查看有关释放库存的问题。
我认为您不会遇到关系数据库系统的限制。然而，您需要一个能够处理交易的系统。正如我在所引用的问题中向发布者建议的那样，您应该能够处理影响库存的保留门票与购买者在交易完成之前退出的订单上的门票。
Check out this question regarding releasing inventory.
I don't think you'll run into the limits of a relational database system. You need one that handles transactions, however. As I recommended to the poster in the referenced question, you should be able to handle reserved tickets that affect inventory vs tickets on orders where the purchaser bails before the transaction is completed.
你的问题似乎比数据库设计更广泛。
首先，关系数据库将对此进行完美的扩展。您可能需要考虑一个 Web 服务层，它将向最终用户提供实际的票务经纪服务。在这里，您将能够以独立于实际数据库设计的缓存方式管理事物。但是，您需要考虑数据插入、更新和选择的适当步骤，以优化性能。
第一步是继续构建一个良好规范化的关系模型来保存您的信息。
其次，构建一些 Web 服务接口来与数据模型交互
然后将其放入用户界面并对许多同时交易进行压力测试。
我敢打赌，您需要迭代地重新设计您的 Web 服务层，直到您满意为止 - 但您的数据库（良好规范化）不会给您带来任何瓶颈问题。
your question seems broader than database design.
first of all, relational database will scale perfectly well for this. You may need to consider a web services layer which will provide the actual ticket brokering to the end users. here you will be able to manage things in a cached manner independent of the actual database design. however, you need to think through the appropriate steps for data insertion, and update as well as select in order to optimize your performance.
first step would be to go ahead and construct a well normalized relational model to hold your information.
second, build some web service interface to interact with the data model
then put that into a user interface and stress test for many simultaneous transactions.
my bet will be you need to then rework your web services layer iteratively until you are happy - but your database (well normalized) will not be cusing you any bottleneck issues.