Database 用于数据库和可伸缩性的容器

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

TiDB

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

TiDB操作员

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

一旦数据库处于活动状态，通常有两种情况

只读查询的比率非常高

非常高的写入查询率

---

在这两种情况下，集装箱化数据库的哪个组件可以扩展？读取副本？数据库“引擎”本身？持久卷？所有这些？

集装箱化基础设施抽象了存储和计算资源 （考虑k8s中的

PV

和

Pod

），这些资源随着数据库的扩展而扩展。因此，缩放的形式取决于数据库本身

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

• （TiDB）服务于SQL查询，并根据计算出的数据与存储层交互。它是无状态的，可以根据需要扩展读写查询。通常，您可以扩展SQL层以获得更多的计算资源，用于查询计划计算、连接、聚合和服务更多连接
• （）负责存储数据并为SQL层提供KV API。TiKV最有趣的部分是多筏复制，存储层会自动将数据分割成若干块，并将它们均匀地分布到容器中。每个片段都是一个木筏组，其负责人负责读写查询。在伸缩时，存储层将自动迁移数据块以平衡负载。因此，扩展存储层将为您提供更好的读/写吞吐量和更大的数据容量

---

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

谢谢！假设数据库连接到SAN（此方法的优点或缺点另作讨论-）；容器是否也会“扩展”到SAN？很抱歉，响应太晚。我不熟悉SAN，但根据您的介绍，SAN是另一种远程存储形式（如果我错了，请纠正我）。基于这种认识，容器仍然可以扩展以提供更多的计算资源，但存储的扩展问题被推到了SAN上。