KWDB 数据库可高效处理海量且连续的数据流，但对于运维人员来说，根据业务需求进行硬件规划是确保系统稳定、高效运行的基础。本文将深入探讨 KWDB 集群规划，帮助运维人员从容应对数据增长和性能挑战，我们将从以下几个方面进行介绍：

1. 拓扑结构：介绍 KWDB 数据库在延迟、弹性方面的考量。

2. 硬件资源：介绍 KWDB 数据库在业务规模和性能角度，对 CPU、内存、存储和网络要求。

3. 安全性：从安全方面，介绍 KWDB 集群规划时应该注意的事项。

拓扑结构

在计划部署时，应选择最能满足延迟和弹性要求的拓扑模式：

• 为了提高可用性和降低数据丢失的风险，建议在一台服务器上只运行一个节点。由于 KWDB 跨节点复制，如果一台计算机运行多个节点，当计算机发生故障会增加数据丢失的可能性。

• KWDB 集群模式下的数据副本数为 3，为确保集群的稳定运行，需要保证集群中正常运行的节点数大于集群的副本数。

• 为保证 KWDB 集群正常运行，需要保证每个数据库节点都可以互相访问。

• KWDB 在面临节点故障时会自动进行数据迁移和补足，需要保证节点之间有足够的网络带宽。

综上，KWDB 建议每个节点都使用独立的服务器，在集群模式下至少有三个节点，各节点可以对等高速访问。

硬件资源

每个节点需要配备必要的 CPU、内存、网络和存储等资源。在部署集群前需要检查各个硬件设备。

下面列出了 KWDB 安装部署所需的硬件规格要求。在实际部署时，用户需要根据实际的业务规模和性能要求，进行硬件资源的规划。

CPU 和内存

单节点配置建议不低于 4 核 8G。越高的 CPU 和内存意味着越好的数据读写、复杂工作负载、高并发和高性能场景表现。同时，CPU 和内存应检查以下内容：

禁用 CPU 节能模式

在 X86 架构上，部分系统会模式使用 CPU 节能模式。为发挥最佳性能，需要配置为高性能模式来始终保持 CPU 在最高频率上工作。

检查系统 CPU 模式

cpupower frequency-info --policy

如果输出为 The governor "powersave"则说明当前是节能模式，需要调整为性能模式 performance。

sudo nano /etc/systemd/system/cpupower.service

添加以下内容

[Unit]Description=Set CPU performance governorAfter=network.target
[Service]Type=oneshotExecStart=/usr/bin/cpupower frequency-set --governor performanceExecStartPost=/bin/sleep 1ExecStartPost=/usr/bin/cpupower frequency-set --governor performanceRemainAfterExit=yes
[Install]WantedBy=multi-user.target

启用服务

sudo systemctl daemon-reloadsudo systemctl enable cpupower.servicesudo systemctl start cpupower.service

使用 64K PAGE_SIZE 内核

在 ARM 架构上，因为其 TLB 较小，在高性能计算和数据库场景中，应当使用 page size 为 64K 的 Linux 内核，从而获得更好的性能。

getconf PAGE_SIZE

如果您的系统使用小于 64K 的内核，应进行内核切换，可以参考>>Choosing between the arm64 and arm64+largemem installer options | Ubuntu

绑定 CPU

在部分国产 CPU 上，往往 Non-Uniform Memory Access (NUMA) 之间带宽是 CPU 的主要瓶颈，需要主动绑定 CPU 来发挥全部性能。

除此之外，如果 KWDB 和应用部署在同一个服务器上，为避免发生 CPU 争抢引发性能衰退，也需要进行绑定 CPU 来优化性能。

建议使用 numactl 来查看 NUMA 信息和绑定 CPU。numactl 是一个用于管理 NUMA 系统的工具。它可以用于查看 NUMA 配置，并将进程绑定到特定的 NUMA 节点或 CPU 上，从而优化性能。

• 查看 NUMA 节点的信息：使用 numactl --hardware 或 lscpu 命令查看系统中的 NUMA 节点及其关联的 CPU 和内存信息：

numactl --hardware

或者：

lscpu

这将输出类似以下的信息：

available: 2 nodes (0-1)     node 0 cpus: 0 1 2 3 4 5 6 7     node 0 size: 16384 MB     node 0 free: 12000 MB     node 1 cpus: 8 9 10 11 12 13 14 15     node 1 size: 16384 MB  node 1 free: 12000 MB    

这里显示了可用的 NUMA 节点，以及每个节点包含的 CPU 核心和内存信息。

• 绑定进程到特定的 NUMA 节点：如果想将 KWDB 进程绑定到 NUMA 节点 0，可以使用以下命令：

numactl --cpunodebind=0 --membind=0 kwbase  <args>   

• 绑定进程到特定的 CPU：如果想将 KWDB 进程绑定到特定的 CPU 核心（例如 CPU 0 和 CPU 1），可以使用以下命令：

numactl --physcpubind=0,1 kwbase <args> 

存储

建议使用 Ext4 文件系统。同时，存储应检查以下内容：

检测并关闭系统 swap

关闭 swap 可以提升 KWDB 的性能，但可能会损失部分稳定性。

swapon --show

如果没有输出，表示没有启用的 swap。如果存在 swap，可以通过以下方式永久禁用：编辑 /etc/fstab 文件，注释掉包含 swap 的行：

/swapfile none swap sw 0 0

重启系统永久生效。

调整 I/O 调度器为 noop

内核的 I/O 调度会导致性能损失，调整调度器为 noop 后，可以将 I/O 直接下发给硬件，从而获得更好的性能。

cat /sys/block/sdX/queue/scheduler

将 sdX 修改为您的磁盘（如 sda、sdb 等），如果为 deadline，则需要调整。

1. 创建一个新的 udev 规则文件，例如 /etc/udev/rules.d/60-io-scheduler.rules：

sudo nano /etc/udev/rules.d/60-io-scheduler.rules

2. 添加规则：

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="noop"

这里，sd[a-z] 表示所有以 sd 开头的磁盘设备（如 sda、sdb 等）。您可以根据需要调整设备匹配模式。3. 重新加载 udev 规则：

sudo udevadm control --reload-rules

4. 应用新规则：

sudo udevadm trigger

磁盘容量

KWDB 推荐使用 SSD 或者 NVME 设备，尽量避免使用共享存储，确保至少 500 IOPS 和 30MB/s 处理效率。 KWDB 系统本身占用磁盘较小（<1GB），实际需求取决于业务量和开启的功能。

磁盘需求量可通过以下公式预估：

1、 压缩前空间：总存储空间=设备数量单台设备每天写入行数分区天数总分区数(行宽/1024/1024+15/64/分片可存储的最大数据行数/500/1000)/1024，单位为 GB。

2、压缩后空间：总存储空间=设备数量单台设备每天写入行数分区天数总分区数(行宽/1024/1024/压缩比+15/64/分片可存储的最大数据行数/500/1000)/1024，单位为 GB。

其中，分区天数取决于时序表的分区时间范围（PARTITION INTERVAL <interval>）设置。KWDB 默认每 10 天进行一次分区，分区天数的值即为 10，如果建表时将分区时间范围设置为 1mon, 则对应的分区天数为 30。

总分区数取决于表的生命周期参数 RETENTIONS <keep_duration> 和分区时间范围（PARTITION INTERVAL <interval>）设置，例如，如果将表的生命周期设置为 10 天，分区天数使用默认值 10 天，则总分区数为 1。如果没有设置生命周期参数和分区时间，则总分区数取决于业务周期。例如，如果需要存储一年的数据，总分区数将为 37。

行宽为每行数据所有列占用空间的字节总数，各数据列所占用字节数如下：

分片可存储的最大数据行数为实时参数 ts.blocks_per_shard.max_limit 和 ts.rows_per_block.max_limit 的乘积，默认值为 1000000。

压缩比通常大于等于 10，实际压缩比取决于用户数据重复度，重复度越高，压缩比越高，重复度越低，压缩比越低。

假设某项目有 1000 台设备，每台设备每天写入行数为 1000 行，分区天数采用默认值 10，表的生命周期设置为 30 天，每行数据占用的总字节数为 913，分片可存储的最大数据行数为 5000，压缩比为 58，则压缩前的空间预计为 10001000103(913/1024/1024+15/64/1000/10)/1024≈26 GB，压缩后占用的空间预计为 10001000103(913/1024/1024/58+15/64/1000/10)/1024≈1.1 GB。

以下假设列出了不同规模数据库推荐配置的参数值和预计占用的压缩分区空间和活跃未压缩分区空间的合计大小：

• 表内有 20 个数据列；

• 每行数据的总宽度为 500 字节；

• 保存数据时间 3 年；

• 部署方式为单节点部署，如果是集群部署，预估空间时应乘以集群副本数；

• 压缩比为 10:1。

√ 小型规模

√ 中型规模

√ 大型规模

网络与时钟

网络会影响 KWDB 的业务通信和时钟的表现。因此应检查以下内容：

网络带宽

KWDB 需要足够的网络带宽来满足节点间数据通信需求。当因带宽不足引发策略性丢包、通信过长时，会影响节点心跳、业务重试等问题，从而降低集群稳定性和性能。建议集群内使用万兆网卡保证足够的网络带宽。

网络抖动

KWDB 在集群模式下依赖时钟保证数据一致性，在节点时钟波动超过 500ms 时会产生异常。因此必须安装对时服务，并通过低网络抖动(jitter)来降低时钟波动。例如 ，如果使用 NTP 网络对时，为保证 NTP 在当前集群网络下的时钟波动不超过 500ms，在保证本地网络抖动较低的基础上，还可以通过如下方式保证时钟准确性：

1. 选择更合适的稳定的时钟源

2. 根据各节点的网络状态和性能，调整 NTP 服务器的权重

3. 选择较稳定或精度较高的的对时协议（如 NTP4 或 PTP）

4. 提高时间同步频率，使用 iburst 和调整 imnpoll maxpoll 选项

网络时延

KWDB 在集群模式下如果多节点间延迟达到 100ms 以上会处于不可用状态，建议保证各节点延迟在 20ms 以下

TCP 参数

KWDB 在集群模式下需要全对称高速网络来保证数据迁移和数据广播。当前版本下，KWDB 会使用基于 tcp 的 grpc 协议进行数据传递。因此，必要情况下，集群内对系统 tcp 参数进行优化，都可以提高 KWDB 的性能与稳定性。例如，修改以下 Linux 内核 TCP 参数：

# TCP 缓冲区大小net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216
# TCP 窗口自动调谐net.ipv4.tcp_window_scaling = 1
# TCP 内存设置net.ipv4.tcp_mem = 50576 64768 98152
# TCP 高效传输net.ipv4.tcp_moderate_rcvbuf = 1net.core.netdev_max_backlog = 250000
# TCP 快速打开net.ipv4.tcp_fastopen = 3

在使用 4.9 及以上版本的 Linux 内核时，应打开 BBR 来提高网络性能.

#网络队列调度net.core.default_qdisc = fq
#TCP拥塞算法net.ipv4.tcp_congestion_control = bbr

或者选用 6.8 及以上版本的 Linux 内核，通过内核默认集成的 TCP 并发连接优化，获得更好的 TCP 性能， 点击参阅

安全性

非安全模式的集群存在严重的安全风险：

• 集群对所有客户端都是开放的，允许访问集群中任意节点的 IP 地址。

• 所有用户都可以在无需密码的情况下访问集群。

• 任何用户都可以以 root 用户身份访问集群，并对所有数据进行读写操作。

• 缺乏网络加密和认证机制，使得数据传输容易受到威胁。

因此，KWDB 强烈建议在部署时采用安全模式，通过 TLS 加密技术验证节点和客户端的身份，并对节点与客户端之间的数据传输进行加密，以有效防范未经授权的访问和数据篡改。