用于数据库和可扩展性的容器答案

【问题标题】：Containers for database and scalability用于数据库和可扩展性的容器
【发布时间】：2020-01-27 10:31:24
【问题描述】：

请考虑TiDB 和TiDB Operator 作为此问题的示例。

TiDB

TiDB（“Ti”代表 Titanium）是一个支持混合事务和分析处理 (HTAP) 工作负载的开源 NewSQL 数据库。它与 MySQL 兼容，具有水平可扩展性、强一致性和高可用性。

TiDB 算子

TiDB Operator 在任何支持 Kubernetes 的云环境中自动部署、操作和管理 TiDB 集群。

数据库上线后，大致有两种情况。

在这两种情况下，容器化数据库的哪个组件可以扩展？读取副本？数据库“引擎”本身？持久卷？以上都是？

【问题讨论】：

【解决方案1】：

容器化基础架构抽象存储和计算资源（考虑 k8s 中的 PV 和 Pod），这些资源会随着数据库的扩展而扩展。所以缩放的形式取决于数据库本身。

对于 TiDB，虽然它提供了 MySQL 兼容的 SQL 接口，但它的architecture 与 MySQL 和其他传统关系数据库有很大的不同：

SQL layer(TiDB) 服务于 SQL 查询，并根据计算出的query plan 与存储层交互。它是无状态的，可根据读写查询的需求进行扩展。通常，您横向扩展/向上扩展 SQL 层以获得更多计算资源，用于查询计划计算、连接、聚合和服务更多连接。
Storage layer(TiKV) 负责存储数据并为 SQL 层提供 KV API。 TiKV 最有趣的部分是 Multi-raft replication，存储层会自动将数据拆分成碎片，并均匀地分发到容器中。每个部分都是一个 raft 组，其领导者服务于读取和写入查询。在扩展/扩展时，存储层将自动迁移数据块以平衡负载。因此，横向扩展存储层将为您提供更好的读/写吞吐量和更大的数据容量。

回到问题，问题中提到的所有组成部分都是按比例计算的。服务于 SQL 查询的读/写副本是可以伸缩的，服务于 KV 查询的数据库“引擎”（存储层）可以伸缩，而 PV 也随着存储层的伸缩过程而横向扩展。

【讨论】：

谢谢！假设，数据库连接到 SAN（这种方法的优缺点单独讨论 - wiki.postgresql.org/wiki/Direct_Storage_vs._SAN）；容器也会“扩展”到 SAN 吗？
抱歉回复晚了。我不熟悉 SAN，但根据您的参考，SAN 是另一种形式的远程存储（如果我错了，请纠正我）。基于这种认知，容器仍然可以扩展以提供更多的计算资源，但存储的扩展问题被推到了 SAN 上。