实时余额更新的大批量交易的最佳实践
我目前拥有一个处理大量交易的MySQL数据库。为了简单起见，这是一个实时进行的操作（点击和其他事件）的数据流。结构是这样的，用户属于子分支机构和分支机构属于分支机构。实时余额更新的大批量交易的最佳实践
我需要保持点击的平衡。为了简单起见，假设我需要将用户，子关联公司和关联公司的点击余额增加1（实际上有更多的处理取决于事件）。目前我很简单地做到这一点 - 一旦我收到事件，我会在PHP中进行顺序查询 - 我读取用户的余额，递增1并存储新值，然后我读取子子公司的余额，增量和写入等等。
用户的余额对我来说是最重要的指标，所以我想尽可能保持实时。其他关于sub-aff和affiliate等级的指标并不重要，但它们越接近实时越好，但是我认为5分钟的延迟可能没问题。
随着项目的发展，它已经成为一个瓶颈，我现在正在寻找替代品 - 如何重新设计天平的计算。我想确保新设计能够每天处理5000万个事件。对我来说，不要丢失一个事件也很重要，而且我实际上将每个更改周期都包装在SQL事务中的点击余额上。
有些事情我考虑：
1 - 创建一个cron作业，将更新的子子公司和附属水平不实时余额，假设每5分钟。
2 - 使用存储过程将数字计算和平衡更新移动到数据库本身。我正在考虑添加一个单独的数据库，也许Postgress会更适合这份工作？我试图看看是否有严重的性能改善，但互联网似乎在话题上存在分歧。
3 - 将这个特定的数据流移动到类似hadoop和parquet（或Apache Kudu？）之类的东西，并在需要时添加更多的服务器。
4 - 分割现有的数据库，基本上为每个分支机构添加一个单独的数据库服务器。
这种类型的任务是否存在一些最佳实践/技术或者我可以做的一些明显的事情？任何帮助真的很感激！
我对高速摄取的建议是here。在你的情况下，我会在它描述的乒乓表中收集原始信息，然后让其他任务总结表来做计数器的质量UPDATEs。当交通突然爆发时，它变得更加高效，从而不会被击倒。
点击余额（和“Like counts”）应该在与所有关联数据分开的表中。这有助于避免干扰系统中的其他活动。如果您拥有的数据多于buffer_pool中缓存的数据，则可能会提高余额的缓存能力。
请注意，我的设计不包括cron作业（除了可能作为“保持活动”）。它处理一个表格，翻转表格，然后循环回到处理 - 尽可能快。
如果我是你，我会实施Redis内存存储，并在那里增加你的指标。它非常快速和可靠。你也可以从这个数据库中读取。也创建cron作业，这将把这些数据保存到MySQL DB中。
您的网络层是否正在进行数字运算，因为它收到&处理HTTP请求？如果是这样，你首先要做的就是将其移动到工作队列中，并异步处理这些事件。我相信你在第3项中暗示了这一点。
解决方法有很多，选择一个范围是这个答案的范围，但一些包来考虑：
- 的Gearman/PHP
- Sidekiq /红宝石
- 亚马逊SQS
- 的RabbitMQ
- NSQ
...等...
就存储而言，它取决于你想要达到的目标，快速读取，快速写入，大容量读取，分片/分布，高可用性......每个点向您提供不同方向的答案
这听起来像是一个很好的候选人Clustrix这是一个替代MySQL的下降。他们做类似分片的事情，但不是将数据放在单独的数据库中，而是将其拆分并在同一数据库集群中的节点上复制。他们称之为切片，而数据库自动为你做。对开发者来说它是透明的。其上有一个good performance paper，它显示了它是如何完成的，但缺点是它是一个横向扩展的OTLP数据库，它恰巧能够吸收疯狂的实时数据分析处理。