ClickHouse > 实例探究 > DENIC 利用 ClickHouse 将查询时间缩短 10 倍

DENIC 利用 ClickHouse 将查询时间缩短 10 倍

技术

应用基础设施与中间件 - 数据库管理和存储
基础设施即服务 (IaaS) - 云数据库

适用行业

建筑物
电信

适用功能

采购
产品研发

用例

行为与情绪追踪
时间敏感网络

服务

数据科学服务
测试与认证

关于客户

DENIC eG（德国网络信息中心）是 .de（互联网上的德国命名空间）的管理员和运营商。它拥有超过 1720 万个域名组合，是世界上最大的顶级域名注册管理机构之一。 DENIC 以非营利为基础运营，提供支持快速、安全、可靠地访问 .de 顶级域名下的网站和 Web 服务的服务。 DENIC 运营着一个全球分布的名称服务器网络，并负责通过域数据库、注册系统和 .de 域信息服务进行注册管理。为了不断改善互联网社区的用户体验，DENIC越来越注重数据分析。

登录后查看完整内容

挑战

DENIC eG 是德国互联网命名空间的管理员和运营商，由于数据分析的限制，在改善互联网社区的用户体验方面面临着挑战。与分析相关的数据分布在关系数据库、服务器日志数据和各种其他来源中。这些来源已用于监测和系统改进，但其分析功能有限，而且跨多种来源的交叉评估成本高昂或不可行。开发数据科学平台的初始步骤涉及使用基于关系 DBMS 的数据库。来自不同来源的数据由 Kubernetes 上的容器中的 Python 代理进行整合，并将结果写入数据库中的目标表。这种方法产生了大量的目标表和容器，这些表和容器难以管理并且变得有些过于复杂。此外，关系数据库仅适用于有限范围内的大量数据，因为查询的处理时间可能需要几分钟到几小时。

登录后查看完整内容

解决方案

DENIC 决定测试面向列的数据库，该数据库专为快速查询大量数据而设计。经过多次案例研究和会议演示后，数据科学团队开始了解 ClickHouse。初步测试和PoC表明，ClickHouse在集群运行方面很好地满足了DENIC的要求，并且只需要很小的服务器占用空间，使其具有成本效益。其中一个用例涉及 ClickHouse 表的设计，该表由 DENIC 注册表数据库的多个实体提供数据。数据由注册表数据库的 REST 接口作为时间序列事件提供，并由 Python 代理每天获取、处理并写入 ClickHouse 集群。保存数百万条数据记录后，出现了第一个明显的问题。 REST 接口传递的数据的处理速度明显变慢。选择与持有人更新关联的域状态的查询大约需要 5 分钟。在调查了这种行为之后，我们发现随着数据量的增加，这将花费越来越长的时间，从而使其在未来变得不可持续。经过多次尝试和优化，查询运行时间从5分钟优化到30秒左右。

登录后查看完整内容

运营影响

The implementation of ClickHouse and its performance, even in small clusters, provided DENIC with extensive support in the development of a data science platform. This platform is expected to be sustainable in the future due to its expandability. The solution was cost-effective and required a small server footprint. The administrative effort was significantly reduced, and the processing time of queries was drastically improved. This allowed DENIC to enhance the user experience of the internet community by providing faster, more efficient data analytics. The successful implementation of ClickHouse also demonstrated the potential of column-oriented databases in handling large amounts of data and fast queries.

登录后查看完整内容

数量效益

Query runtime was optimized from 5 minutes to about 30 seconds, a 10x improvement.
The increase in query runtimes with continuous filling became much flatter than before.
Even with several hundred million data records imported and many thousands of holder updates per day, the optimized level of query runtime could be maintained.

登录后查看完整内容