取代统计汇总系统
我们目前在MySQL下有一个数据库，将汇总的统计数据存储在不同的表中(最近几个小时、几个小时、几天、几个月)。
根据数据所需的新鲜度，以不同的速率运行的工作人员会更新这些表。
然后，这些聚合被应用程序查询，通常查询涉及更多的聚合。
该解决方案在查询数据时显示了性能、伸缩性和灵活性方面的限制。
我们的目标是用一个基于事件来源的系统来取代它。
我们的第一个原型使用Dataflow (有点像MapReduce，但在流中工作)为部分数据预计算聚合，并将这些聚合放在BigTable中，并将原始事件(分区)放置在BigQuery中，用于我们无法预先计算的聚合。
该系统在全球范围内运行，但其成本令人望而却步，估计只有BigQuery每月25K美元。
这一成本主要是由于大量的查询，我们不能预先计算一个有效的聚合(通常我们不能预先计算一个聚合，因为我们需要一个数据流在事件处理时没有的早期事件)。
作为BigQuery的备用后端，我们测试了很少的其他选项，如古都、点击室、spanner…
到目前为止，只有clickhouse在次秒响应时间内表现得非常好，但是维护clickhouse集群似乎有点危险。
从那里我们还能去哪里找呢？我们在设计中做了一个根本的错误，从而解释了糟糕的性能吗？是否有可能平衡这种系统的成本可用性？
我觉得最常用的解决方案仍然是大型hadoop集群。
在正常载荷下，很少有技术信息：
- ~300项/S( 800项常规选拔赛/S)
- ~34000000事件/日
- 一个以原始人权值~200 B编码的事件
- 事件具有20个属性。
- 计算最后一个状态可能需要3-10个事件，这些事件分布在3个月的范围内。
回答 1
Database Administration用户
发布于 2017-07-17 14:23:04
披露:我是的产品经理。
假设这些统计数据与全局唯一的标识符(用户id、设备id等)有某种联系，这是否公平？
如果是这样的话，您可能可以在Bigtable中完成所需的一切，这取决于您需要发出的特定查询集。例如，WePay做了一些非常类似的事情，它们在Bigtable中给出了它们的解决方案和模式设计.用于度量数据的灵活聚合。
由于Bigtable是一个宽列的NoSQL数据库，您可以为任何给定的键创建多个列，并将原始数据存储在一列(事件的时间序列)中，将部分聚合分为几分钟、几天、几周、几个月等，每个列都在不同的列中，然后当需要在任意时间间隔内进行特定聚合时，根据需要读取部分聚合。
您还可以在两种不同的模式下这样做，这取决于成本和时间之间的权衡：
- 如果只访问了一些聚合，则在第一次访问时懒洋洋地计算它们，然后将它们写入Bigtable存储和查询
- 如果需要许多聚合，而且延迟对于第一次访问也是很重要的，那么急切地用Dataflow live计算您可以得到的内容，然后再计算不能计算的内容在后台进程中运行。
作为一个额外的数据点，最近快速发布了他们如何将历史统计数据从MySQL转移到Bigtable，但是我没有关于他们的模式设计的任何进一步信息；希望他们会在声明之后发布关于他们的实现的更多技术细节的后续信息。
如果您想更详细地讨论您的具体用例，那么让我们进一步谈谈。
https://dba.stackexchange.com/questions/165893
复制相似问题
腾讯云开发者
