就像所有北欧的神和漫威的反派一样，每个开源项目都有一个好的起源故事。
新一集“格拉弗娜的大帐篷”播客提供了构建Grafana Mimir的代码背后的视角，这是一个水平可扩展的、高性能的开源时间序列数据库bob电竞频道Grafana实验室于今年3月首次亮相．
在我们的"Grafana Mimir:维护者什么都说的节目中，Big Tent的主持人Tom Wilkie和Mat Ryer欢迎来自Grafana实验室的两位工程师Marco Pracucci和Cyril Tovena，他们也是Mimir的维维者，对我们最新的开源项目的计bob电竞频道划和生产进行深入的讨论。
在这一集里，你将了解我们为什么推出Mimir，我们是如何扩大规模的10亿有源系列，都是关于新功能的拆分合并压缩器以及为什么我们将这个项目命名为Mimir (Tom说:“实际上我亲自游说过Mjölnir，雷神之锤。”)。
注:为了篇幅和清晰度，本文已经过编辑。
Grafana Mimir是什么?
马可:Mimir是Prometheus及其他版本的下一代时间序列数据库。这是我们在Grafana实验室建立的一个时间序列数据库，它具有高可用性、水平可扩展性、支持bob电竞频道多租户、持久存储和超长时间的快速查询性能。
汤姆:您提到了高可伸缩性。这是什么意思?这从何而来?
马可:我们看到越来越多的客户需要大规模的收集和查询指标。我们看到，整个行业都在不断增长对各种指标的需求，这在几年前是不可想象的。当我们运行Grafana Mimir时，我们谈论的是一个租户，一个客户超过十亿的活动时间序列。
汤姆:十亿年。
马可:我甚至不知道十亿有几个零。
汤姆:这是十亿美元，对吧?所以是9。不是英国的10亿，英国有12亿。西里尔，米米尔那飞快的表演是什么?
西里尔:例如，现在有越来越多的客户希望跨多个集群进行查询。因此，存在跨单个查询的高数据基数，而Mimir的设计目的就是能够满足这种需求。因此，您可以跨许多系列、跨许多集群、跨许多名称空间进行查询，并且您将能够跨集群或跨多个集群获取信息。
汤姆:当人们问我的时候，我总是说，我们使用的技术使某些高基数查询的速度提高了40倍。
马可:每次我们谈论它的时候，它都在增加。(笑)
汤姆:是吗?
马可:是的，我们从10开始然后是20 30 40。它越来越大了。
汤姆:这是几个月前的事了。在我看到的结果中，有一个查询要快40倍。
马可:有一些边缘情况发展得很快。但是我们观察到，使用查询分片的速度通常是查询分片的10倍。
垫:什么是查询分片?这是怎么回事?
西里尔:其思想是我们将并行化一个查询。到目前为止，我们实际上是按天或按时间并行处理一个查询。但在这种情况下，就像马可说的，在一个集群中有十亿个活跃的时间序列，那么按时间计算是不够的。你想要按数据进行分割，我们称之为碎片。碎片实际上是一系列的集合。我们要做的是在一组选定的级数上执行PromQL。例如，我们将使用16次，每一次只能处理1/16的数据。然后我们会在前端重新组合数据你将能够将查询速度提高16倍-显然是40倍。
“我们一直在寻找以开源方式发布(功能)的方法。所以我们做Mimir的原因之一就是把我们已经建立的核心技术展示给更多的人。”
汤姆·威尔基
可扩展性限制:Mimir vs. Cortex vs. Thanos
马可:我们发现了不同的(可扩展性)极限。首先要了解这些限制，我们需要了解数据是如何存储的。Cortex、灭霸和Mimir使用Prometheus TSDB将指标数据存储在长期存储器中。基本上，普罗米修斯TSDB按时间划分数据。在给定的一段时间内，数据被存储到一个数据结构中，这个数据结构被称为块。同样，在块内部，我们有一个索引用来查询这个数据和实际的时间序列数据，这些数据是压缩的数据块。现在我们发现了一些局限性。TSDB索引中有一些众所周知的限制，比如索引不能超过64gb，甚至不能在索引内增长，有多个分段，有些分段不能超过4GB。
最后，这意味着您对可以为给定的租户或给定的客户存储多少指标有限制。通过Mimir，我们引入了一种新的压缩器，我们称之为分割合并压缩算法，它基本上允许我们克服这些限制。我们不是在给定的时间段内为客户或租户使用单个块，而是将数据分片为多个块，并且可以将数据分片为尽可能多的块，从而克服单个块限制或单个块索引限制。现在我们发现了另一个问题，这也是众所周知的，那就是摄入数据，即使是非常大量的数据也没有那么复杂，但当涉及到快速查询数据时，事情就变得更加棘手了。
我们遇到的一个主要的可伸缩性限制是PromQL是单线程的。所以如果你运行一个单一的查询，一个复杂的查询，一个涉及大量指标的查询，不管你的机器有多大。这与你有多少个cpu无关。引擎将只使用一个CPU核心。实际上，我们希望充分利用我们或我们的客户拥有的所有计算能力。我们拥有的是查询分片，它允许我们在多台机器或多个CPU核上运行单个查询。
汤姆:对于新的拆分合并夯实机，现在的限制是什么?比如我可以建立多大的集群，或者我可以有一个租户?
马可:没有一个系统可以无限扩展。每个系统都有局限性。我们仍然在运行Grafana Mimir，为单个租户提供多达10亿个活动时间序列。在这种情况下，单个租户是关键，因为如果你有10亿个时间序列，但是跨越1000个不同的租户，那么每个租户都非常小，对吧?只是每个租户有一百万个系列。我提到一个租户的十亿时间序列是因为这是一个单一的单元，在Cortex，灭霸，甚至是Mimir的背景下，它很难被分割和分割。
汤姆:所以我们已经测试了10亿，我们不认为它是无限的。它在十亿和无限大之间。
西里尔:我们用Grafana转k6,太。因此，我们在k6中创建了一个扩展，用于发送Prometheus远程写数据。所有这些都是开源的，所以任何人都可以在家里尝试，看看它是如何扩展的。你只需要大量的CPU来达到发送十亿序列的能力。
马可:和记忆。(笑)
汤姆:我们还没有在播客中提到Grafana k6。是什么?
西里尔:Grafana k6是我们的负载测试工具。所以有两个生成物。bob手机app官网有一个产品，就是k6 CLI，您可以在其中定义一个计划。通过CLI，我们可以通过运行测试计划自动加载测试您的应用程序。因此，它可以是发送度量的计划，但也可以是对您的商店网站进行负载测试。另一个产品是Grafana k6 Cloud，它采用相同的计划，但它在云中运行，因此可以实际扩展负载测试。
垫:转k6使用作证,顺便说一下，流行的go测试包。
汤姆:你为什么在这里提到这个，麦特。
垫:因为普罗米修斯也用它....哦，我创造了它。
汤姆:哦，好了。
垫:基本上，没有我，写围棋代码的人就不能确保他们的代码有效。(笑)
汤姆:您将每个if语句从三行缩减为一行。
垫:我节省了很多行。想想有多少磁盘空间。
汤姆:你放出来的那些花括号!
为什么要构建一个新的开源项目?
汤姆:为什么我们选择将Mimir作为一个单独的项目来构建呢?为什么我们不把这些改进贡献给《Cortex》?
西里尔:我认为有两个答案。首先，指标领域的竞争非常激烈。所以我认为我们想要建立一个新的项目。我们是《Cortex》最大的维护者和贡献者，拥有自己的项目让我们更加敏捷。它还帮助我们确保其他竞争对手没有免费利用我们的工作。另一个答案是，我们有很多功能是封闭源码的，我们想把它们变成开放源码，让其他人可以使用和试验这些功能。
马可:公平地说，这是一个非常艰难的决定，这都是关于权衡的。这是关于找到一个模型，它允许我们在商业上取得成功，同时保持我们大部分代码的开放。在Grafana实验室与Mimir合作开展一个新的第一方项目，我们认为这非常符bob电竞频道合这个决定的权衡。
汤姆:我们在Mimir中添加的许多特性，我们构建的许多代码，我想值得一提的是，我们之前已经为我们的Grafana企业产品和Grafana云产品完成了所有这些工作。bob手机app官网很多这样的想法都是在封闭源码中建立的，作为Grafana实验室的一个公司，我们真的希望这些东西是开放源码的。bob电竞频道我们一直在寻找将它们作为开源发布的方法。所以我们做Mimir的部分原因是把我们已经建立的核心技术展示给更多的人。
马可:当我们推出Mimir时，作为Cortex用户或社区用户，我们反复遇到的问题是:“我能跳到Mimir上吗?”我可以升级吗?它有多稳定?”最酷的是，我们在Mimir中发布的特性已经在Grafana实验室的任何规模的生产环境中运行了几个月——从小型集群到非常大的集群，包括我们前面提到的10亿系列集群。bob电竞频道这就是为什么我们对这个系统的稳定性有信心。
西里尔:一些久经沙场的。
“我们希望继续致力于我们的大帐篷哲学……目前，Mimir专注于Prometheus指标，但我们希望在Mimir中支持OpenTelemetry、Graphite或datdog指标。”
——马可·普拉奇
米米尔这个名字是怎么来的?
汤姆:我们有这种LGTM策略，如日志、图表、跟踪和度量。Loki，记录系统以L开头，Grafana，绘图系统以G开头，Tempo，追踪系统以T开头，Cortex，度量系统以c开头，所以它必须以m开头，然后我们回到我们的斯堪的纳维亚根源。我们在寻找一个神话中以M开头的单词，于是我们想到了Mimir。我亲自游说Mjölnir，雷神之锤。
垫:那很酷。但是很难拼写。
汤姆:米米尔是挪威神话中以知识和智慧闻名的人物，他在战争中被斩首。奥丁带着米米尔的头，向他背诵秘密知识和建议。
垫:他最终也会成为漫威的反派吗?
汤姆:可能。
Grafana Mimir的新功能
垫:未来的计划是什么?我们能谈谈，让大家先了解一下吗?
马可:我们有大计划。首先，我认为我们要坚持我们的大帐篷哲学，我们希望Mimir成为一个通用时间序列数据库。现在，Mimir专注于Prometheus度量，但我们希望在Mimir中支持OpenTelemetry或Graphite或datdog度量。这是我们已经在做的事情，很快就会在Mimir中实现。
西里尔:所以我喜欢查询性能。这就是为什么我要谈谈我们未来想要做的两个改进。所以在Loki LogQL中，我们正在研究分割即时范围查询。所以如果你有一个持续时间非常长的范围向量，比如30天，速度会非常慢。我们希望能够分割即时查询。我们现在就在Loki中这样做，因为30天的数据量与你在指标中可以获得的样本量相比是巨大的。我们肯定会把这个功能移植回Mimir。
当我们和Marco一起研究查询分片时，我们发现了一些问题和我们想要做的实现。我们想让TSDB碎片感知。能够从索引中请求特定的分片或者从一开始就为特定的分片计算出数据。显然，我认为最好的进入Mimir的方法是上游进入普罗米修斯所以这是我们肯定可以尝试做的事情。
马可:另一个在不久的将来可能会有很大改进的领域是关于Mimir可操作性的。我们已经提到我们简化了很多配置。让Mimir启动并运行起来很容易。但是像任何分布式系统一样，随着时间的推移，仍然需要一些努力来维护系统—考虑版本升级或考虑扩展或微调不同租户的限制，诸如此类的事情。因此，关于这个项目，我最大的梦想之一就是拥有Mimir自动驾驶仪，并尝试尽可能接近零操作，以便大规模运行和维护Mimir集群。
垫:是的,请!
马可:这是一件说起来容易做起来难的事情，但我们已经有了一些想法。在Grafana实验室，我们正在进行一些关于如何显著提高规模操作的讨论。bob电竞频道
西里尔:这非常有趣。我们目前有红帽团队，他们实际上已经成为洛基项目的成员，他们正在为洛基开发一个操作员。我认为他们的目标和你刚刚描述的是一样的，马可。他们想让大规模操作Loki变得超级简单，特别是升级集群或维护集群。也许这些东西也可以重复使用。
马可:我认为在Grafana实验室工作非常酷的一件事是有很多跨团队(合作)。bob电竞频道仅提一点:在我们将查询分片构建到Mimir之前，Cyril将查询分片构建到Loki中。然后他带着关于如何成功构建查询分片的知识找到了我和Mimir团队的其他人。然后我们把它也植入了米米尔的身体里。我们互相学习，自动驾驶将是另一个向其他团队学习的好机会。
西里尔:实际上，我们在Mimir中构建查询分片的方式比在Loki中更好。所以现在我有点嫉妒了。
汤姆:你得去把它背传给洛基。
西里尔:那就是我现在正在做的事。
汤姆:当你想出如何在Loki中比在Mimir中做得更好时，你就必须回来把你的改进带回Mimir。
