我需要专家的建议。
对于我的聊天应用程序，我使用 MYSQL。由于我有结构化消息，所以我选择了 mysql。现在我关心的是可扩展性和吞吐量。
我花时间分析 DynamoDB 的可扩展性和吞吐量。这听起来不错，因为它可以处理任何规模，但我关心的是每行的定价和数据限制。我很困惑是否应该迁移到 DynamoDB，因为我们明确预测在不久的将来会交换大量消息。我们希望在不停机的情况下处理任意数量的读写。
我不太熟悉 MYSQL 应该如何扩展。我现在了解使用一致性哈希的分片概念，但从未实施过。我正在寻找一种解决方案，我们不必手动管理可扩展性，就像根据我现在的理解，如果我要对 MYSQL 进行分片，我必须将请求定向到受人尊敬的分片。
考虑到我的担忧，有人可以建议我是否应该迁移到 DynamoDB，或者您是否可以向我解释一下如何完美地扩展 MYSQL，而无需太多的手动交互和任何停机时间。 对于更多上下文，我们在 kuberenetes 上运行我们的应用程序，并愿意将 MYSQL 也放在 kuberenetes 上，但由于我对 MYSQL 可扩展性不太熟悉，不确定这里什么是最好的。
在达到 mysql 的容量极限之前，你可能会先达到存储引擎的极限。
对于 Innodb，使用默认的 16Kb 块大小，即每个文件 64Tb。这是相当多的数据。但是 Innodb 可以在单个文件中存储多个表（默认配置）每个文件一张表，并且可以跨多个文件对一张表进行分区。您可以在这些之间进行转换（尽管移动大块数据需要时间）。
如果您谈论的是 PB 级的数据，那么您需要的帮助不仅仅是这里的一些问答。聘请专业顾问。
我们希望在没有任何停机时间的情况下处理任意数量的读取和写入
这是可用性问题，而不是容量问题。 DynamoDB 并不是解决这个问题的灵丹妙药。确保您理解 CAP 定理并进行复制；您至少需要一个热副本，并考虑使用 ProxySQL 或类似的工具来管理路由。
....并参阅https://serverfault.com/questions/384686/can-you-help-me-with-my-capacity-planning
您真正担心的只是 DynamoDB 的项目（行）大小限制。但是，如果您在 DynamoDB 中正确建模数据，您就可以轻松克服这一挑战。
例如，这将是选择错误的数据模型
| PK | 留言 |
|---|---|
| 聊天ID123 | [消息1,消息2,消息3...] |
这将是一个更好的方法，它提供了更小的项目，但也增强了查询的灵活性。 PK | SK |消息 ---|---|--- 聊天ID123 |味精#msg1 |留言内容 聊天ID123 |味精#msg2 |留言内容 聊天ID123 |味精#msg3 |留言内容