Database on Yeqown

列式数据库是怎么炼成的

Tue, 31 Mar 2026 14:44:37 +0800

列式数据库与行式数据库最大的区别在于数据的存储方式，也就是它们在磁盘上的组织方式不同。传统的行式数据库常用于 OLTP (Online Transaction Processing) 场景，在这个场景下需要频繁的进行数据的插入、更新、删除操作，操作的对象往往是单行数据。而列式数据库常用于 OLAP (Online Analytical Processing) 场景，对于数据的聚合查询更为常见，往往需要扫描某一列的大量数据进行计算。

Storage Difference

如果同时用过两种类型的数据库，就会发现：

这里列举的优化原则只是冰山一角，仅用于说明两种数据库最显眼的差异。

使用行式数据库过程中，最简单常见的优化原则就是 尽可能命中索引、降低 B+ 树高度、减少扫描行数，如：

优先对区分度高的列建立索引
覆盖索引（索引中包含查询所需的所有列，避免回表）
索引下推（在存储引擎层提前过滤不满足条件的数据）
最左前缀匹配原则
避免使用函数或者隐式类型转换（如：where date(create_time) = '2022-01-01'），会导致索引失效
避免在索引列上使用 !=、<> 等操作符，会导致索引失效
避免深度分页
分库分表（提出这一优化方向，也是基于单表数据量过大，索引维护的开销会增加，性能也会退化）
等等…

减少扫描行数这一思路对于列式数据库同样适用（如分区裁剪），但列式数据库还有另一个很重要的优化方向，那就是 减少列，如：

行存特性（如果是点查询，列数据库 I/O 反而会增加，这一点和行式数据库正好相悖）
只读取查询涉及的列（行存也提倡避免 SELECT *，但由于行存以行为单位读取磁盘，主要减少的是网络传输量而非磁盘 I/O；而列存中每列独立存储，少读一列就直接少一份磁盘 I/O）
等等…

当然，任何数据库的优化，都逃不开 减少 I/O 这一核心目的。说得更白话一点，如果有一种完美的存储介质，它没有I/O延迟，也不会丢失数据，那么这些优化也就不再需要了。

1. ClickHouse 的设计#

1.1 整体组件#

从 ClickHouse 的架构图来看，列式数据库包含以下核心组件：

ClickHouse Architecture

查询处理层：查询处理遵循传统范式：解析入站查询、构建并优化逻辑与物理查询计划，然后执行
- SQL Parser
- SQL Planner
- Physical Plan Builder
- Plan Executor
存储层：由不同的表引擎组成，这些表引擎封装了表数据的格式和位置
- MergeTree* Family Tables Engines：代表了 ClickHouse 中的主要持久化格式
- Special-Purpose Tables Engines：用于加速或分布查询执行的专用表引擎
  - Dictionary
  - Memory
  - Distributed (Data Sharding) 处理分布式
集成层：用于与外部系统进行双向数据交换的虚拟表引擎，例如关系型数据库 (如 PostgreSQL、MySQL) 、发布/订阅系统 (如 Kafka、RabbitMQ) ，或键值存储 (如 Redis) 。还可以与数据湖 (如 Iceberg) 或对象存储中的文件 (如 AWS S3、Google GCP) 交互
- Virtual Tables Engines
正交组件：提供辅助功能
- Thread pools
- Caches
- RBAC (Role-Based Access Control)
- Backups
- Monitoring
访问层：通过不同协议管理用户会话并与应用程序通信
- User Session
- Wire protocols

我们更进一步，丢掉分布式特性、集成和监控，只保留最影响 OLAP 查询性能的核心设计，如下所示：

ShardingSphere-Proxy问题几则

Sun, 18 Aug 2024 09:43:35 +0800

ShardingSphere Proxy 是 Apache ShardingSphere 的一个子项目，是一个基于 MySQL 协议的数据库中间件，用于实现分库分表、读写分离等功能。在使用过程中，遇到了一些问题，记录如下。

这里主要针对的是分库分表的使用场景。

问题概述#

数据库往往是一个系统最容易出现瓶颈的点，当遇到数据库瓶颈时，我们可以通过数据拆分来缓解问题。数据拆分的方式通常分为横向拆分和纵向拆分，横向拆分即分库分表；纵向拆分即把一个库表中的字段拆分到不同的库表中去。这两种手段并不互斥，而是在实际情况中相辅相成。本文即是横向拆分相关内容。

常见的部署方式有哪些？
数据分片规则怎么配置？
数据分片数应该怎么确定？
数据分片后唯一索引还有用吗？
数据分片后数据迁移？
数据分片后如何确定实际执行 SQL 语句？
数据分片后的查询优化？

0. 常见的部署方式#

官方提供了两种部署方式：

单机部署：将 ShardingSphere Proxy 部署在单台服务器上，用于测试和开发环境。
集群部署：将 ShardingSphere Proxy 部署在多台服务器上，用于生产环境。集群模式下使用 zookeeper 来存储元数据。

关于元数据，元数据是 ShardingSphere Proxy 的核心，用于存储分库分表规则、读写分离规则等信息。官方建议使用集群模式部署生产环境的 ShardingSphere Proxy

如果不按照官方的指引，选择部署了多个 Standalone 模式的 ShardingSphere Proxy，那么需要注意“每个这样的 proxy 节点会有自己的元信息，他们之间并不互通”。在这些情况下会出现节点之间元数据不一致的问题，参看如下测试：

# 启动 3 个 standalone 模式的 ShardingSphere Proxy
                                          +-------+
                                          |  LB   |
                                          +-------+
                                              |
                                |-------------|--------------|
                                |             |              |
                            +-------+     +-------+       +-------+
                            | Node1 |     | Node2 |       | Node3 |
                            +-------+     +-------+       +-------+

初始表结构如下：

数据库索引基础

Thu, 11 Jan 2018 19:08:44 +0000

数据库索引的简单介绍和使用注意事项

树#

二叉树#

性质1：在二叉树中第 i 层的结点数最多为2^(i-1)（i ≥ 1）
性质2：高度为k的二叉树其结点总数最多为2^k－1（ k ≥ 1）
性质3：对任意的非空二叉树 T ，如果叶结点的个数为 n0，而其度为 2 的结点数为 n2，则：n0 = n2 + 1

二叉搜索树 BST#

若左子树不空，则左子树上所有结点的值均小于它的根结点的值；
若右子树不空，则右子树上所有结点的值均大于或等于它的根结点的值；
左、右子树也分别为二叉排序树；
没有键值相等的节点

平衡二叉树 AVL树#

平衡二叉树（balanced binary tree）,又称 AVL 树。它或者是一棵空树,或者是具有如下性质的二叉树：

它的左子树和右子树都是平衡二叉树，
左子树和右子树的深度之差的绝对值不超过1。

平衡二叉树是对二叉搜索树(又称为二叉排序树)的一种改进。二叉搜索树有一个缺点就是，树的结构是无法预料的，随意性很大，它只与节点的值和插入的顺序有关系，往往得到的是一个不平衡的二叉树。在最坏的情况下，可能得到的是一个单支二叉树，其高度和节点数相同，相当于一个单链表，对其正常的时间复杂度有O(log(n))变成了O(n)，从而丧失了二叉排序树的一些应该有的优点。

B树#

BTree是平衡搜索多叉树，设树的度为2d（d>1），高度为h，那么BTree要满足以下条件：

每个叶子结点的高度一样，等于h；
每个非叶子结点由n-1个key和n个指针point组成，其中d<=n<=2d,key和point相互间隔，结点两端一定是key；
叶子结点指针都为null；
非叶子结点的key都是[key,data]二元组，其中key表示作为索引的键，data为键值所在行的数据；

B+树#

B+Tree是BTree的一个变种，设d为树的度数，h为树的高度，B+Tree和BTree的不同主要在于：

B+Tree中的非叶子结点不存储数据，只存储键值；
B+Tree的叶子结点没有指针，所有键值都会出现在叶子结点上，且key存储的键值对应data数据的物理地址；
B+Tree的每个非叶子节点由n个键值key和n个指针point组成；

索引#

聚簇索引和非聚簇索引（也叫：聚集和非聚集）#

MyISAM 非聚簇索引

MyISAM存储引擎采用的是非聚簇索引，非聚簇索引的主索引和辅助索引几乎是一样的，只是主索引不允许重复，不允许空值，他们的叶子结点的key都存储指向键值对应的数据的物理地址。非聚簇索引的数据表和索引表是分开存储的。非聚簇索引中的数据是根据数据的插入顺序保存。因此非聚簇索引更适合单个数据的查询。插入顺序不受键值影响。

InnoDB 聚簇索引

聚簇索引的主索引的叶子结点存储的是键值对应的数据本身，辅助索引的叶子结点存储的是键值对应的数据的主键键值。因此主键的值长度越小越好，类型越简单越好。聚簇索引的数据和主键索引存储在一起。聚簇索引的数据是根据主键的顺序保存。因此适合按主键索引的区间查找，可以有更少的磁盘I/O，加快查询速度。

但是也是因为这个原因，聚簇索引的插入顺序最好按照主键单调的顺序插入，否则会频繁的引起页分裂，严重影响性能。在InnoDB中，如果只需要查找索引的列，就尽量不要加入其它的列，这样会提高查询效率。

索引类型#

主键索引：根据主键pk_clolum（length）建立索引，不允许重复，不允许空值。