从实验到生产，通往 Supercolumn 的旅程

我们很高兴欢迎 NANO Corp. 作为我们博客的嘉宾。继续阅读，了解他们为什么使用 ClickHouse 以及他们从发现到生产的旅程。

关于 NANO Corp. 为什么选择 ClickHouse 来支持其 NOC 作为服务 (NOCaaS) 产品，并且再也没有回头！

从外部看，我们通往 ClickHouse 的旅程可能并不具有开创性。但对于一家由经验丰富的软件开发老绅士创办的公司，他们秉持着关于技术的古老理念，我们没有预料到自己的信念会以这种方式被彻底粉碎 ????。

但在我们详细介绍这段旅程之前，让我们先谈谈我们自己，我们所做的事情以及我们过去、现在和将来想要实现的目标。

NANO Corp. 是一家由前国防人员于 2019 年创办的法国初创公司。我们围绕着我们自己开发和获得专利的内部技术创建了这家公司：对软件网络探测器应该是什么的突破性“除尘”。我们使它们变得多功能，比以往任何时候都更轻巧，同时也能轻松处理高达 100 Gbit/s 的带宽，而无需使用任何令人羞愧的技巧，如数据包切片或采样。我差点忘了，它也完全在商品硬件上运行（而且是便宜的硬件，你可以查看我们的博客了解一些规格，如果你想看看），以全 CPU 为基础（再次强调，我们没有使用昂贵的 FPGA 或 ASIC）。

我们提供的内容可以用一个词概括：**可观察性**。但不是传统的“网络监控”类型。我们不使用 *Netflow、sflow、IPFIX* 或 *SNMP* 等。这些技术工作得很好，但它们缺乏广度和发展空间。它们在某种程度上都缺乏可见性，而且 none of them 可以真正进行网络安全。基于绝对统一的联系：**网络**，我们的核心愿景是，网络性能和网络安全是同一枚硬币的两个方面，没有第二个解决第一个毫无意义。

我们的主要目标是现在以线速高速分析复杂且不断变化的网络流量。并以异步馈送方式进行（不同的探测器安装在网络的多个层级中和周围）。很有挑战性，对吧？基本上，我们正在寻找的数据库必须

• 能够处理快速（且持续）插入，同时运行用于警报的周期性查询以及由多个用户发起的自定义查询，
• 配备热/冷数据缓冲系统，将数据存储在 RAM 中以供警报查询使用，
• 易于维护和部署，
• 能够在一个系统上接收大量数据，同时仍然保持灵活。这意味着：在达到 10TB 大关之前（实际上甚至之后）不必过快地进行多集群/分片
• 在 RAM 使用方面非常高效

正如您可能猜到的，为了充分利用我们的网络探测器的全部潜力，并将它们捆绑成我们希望它们尽可能普遍的产品，同时能够解决当今的许多混合挑战（M/L、网络安全等），我们需要我们的探测器得到一个非常好的数据库的支持。这就是我们最初遇到的一些障碍的原因。因为我们当时并不知道，但实际上，我们需要一个与我们的探测器一样具有开创性的数据库！

传统的 RDBMS 长期以来都是围绕智能事务管理系统构建的。这项技术很好地服务于许多用例，并且已经很好地服务了几个世纪。我们主要的工程师在他们之前的职业生涯中成功地使用了 MySQL 或 PostgreSQL。我们知道他们中的大多数人从长远来看无法胜任。它们的数据模式过于依赖于更新速度，并且当整体性能成为问题时，需要进行集群。

但我们仍然尝试了一些这样的“爸爸级数据库”????。主要是因为 OLTP 似乎是我们心中的一些查询的先决条件。我不确定我是否能说出他们的名字（都是好数据库，但它们只是不适合我们的需求）。假设我们当时并没有期待太多，即使这样，我们仍然感到失望。

为了让您更多地了解背景，我们必须获得从 1Gb/s 网络中提取流量元数据的成功基准测试。在极端情况下，我们必须将多达 140 万个流量/秒输入数据库（根据情况，大约 30 到 250 列）。假设传统的 RDBMS 或图数据库在我们拥有的硬件上并没有给我们提供所需性能的 25%。

而我们的最终目标是在 100Gb/s 网络上让它平稳运行…… 我想这就是你通过 **crud** 工作得到的 ;-)

但让我们稍微回溯一下，让我更多地了解背景。

说实话，亲爱的读者，OLAP 并不是我的首选数据库。ClickHouse 也不是。来自 Yandex（但它是开源的），我们有一些保留意见。首先，我正在寻找 OLTP 超级扩展数据库，其中分片或多集群是关键。

流行语很重要。我记得我的一位早期客户，那是 COVID 之前，在另一家公司（那真的是黑暗时代）。那位客户死心塌地要使用 Hadoop 多集群基础设施，其总拥有成本（TCO）达到 7 位数（欧元）。所有这些都是为了支持非常基本的 NLP ETL，预计每月处理数百 MB 的数据…… 。但当时，Hadoop 风靡一时，该管理部门的 CTO 想要玩弄这个闪闪发光的玩具。而没有意识到它真正意味着什么。那是我第一次真正体会到流行语在科技界的力量。所以，当 Nano 的故事开始时，多集群已经是解决数据存储据称存在的所有问题的答案。

最终，我也想设计和实施多集群数据库。因为这很酷，而且因为我脑海中一直在玩弄的数字，我非常确定除了 XXXXXXXX 之外，没有其他数据库能够处理预期的海量数据。除非使用许多集群和复制节点来快速查询。不幸的是，在没有花费足够的时间来设计和构建健壮的数据模式的情况下，部署多集群数据库就像鱼与熊掌不可兼得。除非您身处一家利润丰厚的公司，其高管人员对科技领域的真实价格一无所知，否则您很快就会意识到，天下没有免费的午餐，对吧？

我们当初的要求非常苛刻，我们想要的是最顶尖的性能，胜过一切……这是科技领域梦寐以求的渐进式追求。但随后我们不得不讨论一件科技人员不太愿意去想的事情：成本。因为在他们的脑海中，性能在完美数字和理想的世界中是一种纯粹的抽象概念。在这个世界里，金钱是肮脏的，只会被那些想要扼杀他们梦想的枯燥乏味的会计师谈论。记住，我们可以花几个星期的时间，为探测器管理的每个网络数据包节省 3 到 4 纳秒……我们必须在思维方式上做出相当大的改变。

例如，早期用于支持用于从多个 10Gbit/s 探测器中摄取数据的数据库的硬件要求……令人震惊。而且这还没有考虑使用 OLTP 数据库意味着我们需要人员来维护这种复杂的架构。有些人会说多集群总是很乱，尤其是当它做得对的时候。但是……我们（在我写下这些文字时仍然是）一家小公司。我们想要便宜，我们想要强大，可扩展，当然，我们希望在所有阶段都“容易”。我可以告诉你，这绝非易事。

最终，我们对传统 OLTP 数据库的所有初始测试……好吧……至少可以说令人失望。而且它没有扩展。即使他们说它做到了。为了提高效率，我们不得不花在硬件上的钱过多。这与我们所有的核心信念（以及我们所有客户采购部门的信念 ;-)）背道而驰。

有一天，当我正在稳步掉头发和睡眠时，我的首席数据科学家来了。他一只手拿着咖啡，另一只手拿着手机，开玩笑地对我说：“我想试一下 ClickHouse！”

我无法告诉你，那个家伙当时有多么胆大妄为！

我们有一位客户想要进行规模调整，我花了几天（和周末）时间设计一个巧妙的数据方案，并筛选硬件选项……而他来找我，要求我们部署一个数据库社区中的后起之秀。

在他寻找一个能够在海量数据上运行分析查询并实现交互式延迟的数据存储时，他偶然发现了 ClickHouse，ClickHouse 被誉为市场上最快的数据库。

我相信你已经开始思考了。最快的数据库……我们以前都听过，对吧？剧透警告：它确实是速度最快。实际上，它速度快到让我确信我们的第一个基准测试一定有错误，结果一定是假的。我让我的首席数据科学家查看一下那些基准测试。他停下来，好奇地看着，他一个接一个地发送查询，并在眨眼之间返回结果，而我以前使用的传统数据库通常需要几秒钟甚至几分钟才能完成的任务，现在只需几毫秒就能完成。哇。

当时我想：“如果 Cloudflare，一家专门从事网络并以其网络著称的全球性公司，选择了 ClickHouse，那就只能说明他们一定发现了什么东西？？？？”

在我们进行了一系列不同的测试之后，我们被说服了。但究竟为什么呢？好吧，主要是由于 ClickHouse 的快速多重插入、快速索引、强大的物化视图、奇妙的 MergeTree 函数，当然，还有它由一个更好的社区支持的出色文档（当然，这是非常个人的观点）。

即使后来，我们快速地查看了其他 OLAP 数据库，比如 Druid 或 Pinot，我们仍然坚持使用 ClickHouse。很大程度上是因为 ClickHouse 中的数据摄取比它的替代方案要高效得多。它不需要准备包含严格落入特定时间间隔的所有数据的“段”，并且它允许更简单的数据摄取架构和更轻松的维护（记住，我们仍然是一家小型初创公司），并且它节省了计算能力。这是因为我们的探测器会不断地发送数据供 ClickHouse 摄取，同时还在冷热数据上运行持续的查询。ClickHouse 的批量插入理念也非常适合我们的技术，因为我们自己为所有要摄取的数据创建了中间批量（实际上，有点像 Kafka，虽然规模要小得多）。

基本上，ClickHouse 中的数据摄取要简单得多，对资源的消耗更少，并且允许你进行极其快速的查找查询！两全其美。现在，如果 ClickHouse 能够原生处理 JSON 格式文件……什么？他们现在可以做到了？哇……

最后，我可以说，我们在对所有其他替代方案感到沮丧后偶然发现了 ClickHouse，并且留下来是因为它非常适合我们 ;-)

下次，我们将讨论一个具体的用例：我们如何处理针对高容量输入的多个异步数据馈送。