高可用性讨论数据库模型-MySQL

Question

能否请您分享有关可伸缩性的见解？

假设我有一个简单的以下MySQL / RDBMS数据库，用于树状讨论：

表格：

• 讨论（ID，URL）
• 评论（id，discussionId，parentCommentId，slug）
• comment_vote（讨论ID，commentId，userId，值）

这个想法是对这个RDBMS结构执行较少频率的写入（与较频繁的读取相反），并在写入重建缓存之后将整个讨论写入某个读取缓存（可能是文档db）中，该存储格式可以提供服务无需进一步处理客户。

• 让我们期望每天有250MB的新数据或每分钟1000个请求（90％的读取）。
• 在comment_vote中，我们应该以某种方式确保针对特定评论，每个用户最多可以有1票。
• 该数据库使用了DiscussionId键进行分片，并且我们的数据库集群具有任意数量的节点

1. /通过这种布局，我们可以走多远？我的意思是，我们这里只有3张桌子。有明显的瓶颈吗？像重建索引一样，在表的每个插入上进行一些表级锁定，...应该具有数百个千兆字节甚至更多个千兆字节？

2. /将文档数据库也用于写入是否更合理，因为例如他们可以为较小的零件处理更好的物理锁定？

3. /还有其他想法/更好的解决方案吗？

非常感谢。

Answer 1

好吧，管理高负载是一项非常全面的任务，因此，例如，您可以尝试https://dba.stackexchange.com/上的运气

最初的想法

1. 您可以尝试将PostgreSQL作为MySQL的更强大替代品
2. 对于类似论坛的记录，基于注释/讨论的DATE值构建PARTITIONING是一个很好的解决方案。因此，您需要添加DATE字段-例如最近的更新，最近的读取等。该值还将帮助您逻辑确定是否需要存档
3. 如果您需要实施快速的全文本搜索，MySQL并不是最好的方法