本站整理下载：

相关截图：

 

主要内容：
Yandex.Metrica以及其他Yandex服务的使用案例 在Yandex.Metrica中，ClickHouse被用于多个场景中。 它的主要任务是使用原始数据在线的提供各种数据报告。它使用374台服务器的集群，存储了20.3万亿行的数据。在去除重复与副本数据的情况下，压缩后的数据达到了2PB。未压缩前（TSV格式）它 大概有17PB。 ClickHouse还被使用在： 存储来自Yandex.Metrica回话重放数据。 处理中间数据 与Analytics一起构建全球报表。 为调试Yandex.Metrica引擎运行查询 分析来自API和用户界面的日志数据 ClickHouse在其他Yandex服务中至少有12个安装：search verticals, Market, Direct, business analytics, mobile development, AdFox, personal services等。 聚合与非聚合数据 有一种流行的观点认为，想要有效的计算统计数据，必须要聚合数据，因为聚合将降低数据量。 但是数据聚合是一个有诸多限制的解决方案，例如： 你必须提前知道用户定义的报表的字段列表 用户无法自定义报表 当聚合条件过多时，可能不会减少数据，聚合是无用的。 存在大量报表时，有太多的聚合变化（组合爆炸） 当聚合条件有非常大的基数时（如：url），数据量没有太大减少（少于两倍） 聚合的数据量可能会增长而不是收缩 用户不会查看我们为他生成的所有报告，大部分计算将是无用的 各种聚合可能违背了数据的逻辑完整性 如果我们直接使用非聚合数据而不进行任何聚合时，我们的计算量可能是减少的。 然而，相对于聚合中很大一部分工作被离线完成，在线计算需要尽快的完成计算，因为用户在等待结果。 Yandex.Metrica 有一个专门用于聚合数据的系统，称为Metrage，它可以用作大部分报表。 从2009年开始，Yandex.Metrica还为非聚合数据使用专门的OLAP数据库，称为OLAPServer，它以前用于报表构建系统。 OLAPServer可以很好的工作在非聚合数据上，但是它有诸多限制，导致无法根据需要将其用于所有报表中。如，缺少对数据类型的支持（只支持数据），无法实时增量的更新数据（只能通过每天重写 数据完成）。OLAPServer不是一个数据库管理系统，它只是一个数据库。 为了消除OLAPServer的这些局限性，解决所有报表使用非聚合数据的问题，我们开发了ClickHouse数据库管理系统。 ClickHouse的特性 真正的列式数据库管理系统 在一个真正的列式数据库管理系统中，除了数据本身外不应该存在其他额外的数据。这意味着为了避免在值旁边存储它们的长度«number»，你必须支持固定长度数值类型。例如，10亿个UInt8类型的 数据在未压缩的情况下大约消耗1GB左右的空间，如果不是这样的话，这将对CPU的使用产生强烈影响。即使是在未压缩的情况下，紧凑的存储数据也是非常重要的，因为解压缩的速度主要取决于未压 缩数据的大小。 这是非常值得注意的，因为在一些其他系统中也可以将不同的列分别进行存储，但由于对其他场景进行的优化，使其无法有效的处理分析查询。例如： HBase，BigTable，Cassandra，HyperTable。在这些系统中，你可以得到每秒数十万的吞吐能力，但是无法得到每秒几亿行的吞吐能力。 需要说明的是，ClickHouse不单单是一个数据库， 它是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询，而无需重新配置或重启服务。 数据压缩 在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。但是, 若想达到比较优异的性能，数据压缩确实起到了至关重要的作用。 数据的磁盘存储 许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但 如果有可以使用SSD和内存，它也会合理的利用这些资源。