小编Pau*_*cod的帖子

是否存在S3缩放的已知限制？有没有人有这么多的同时读取或写入,桶开始返回错误？我对写入比读取更感兴趣,因为S3可能会针对读取进行优化.

我的网站偶尔会有相当可预测的流量突发,吞吐量比平常增加100倍.例如,我们将在电视节目中亮相,我预计在演出后的一小时内,我将获得比正常情况多100倍的流量.

我的理解是MySQL(InnoDB)通常将我的数据保存在一堆不同的地方:

• RAM缓冲区
• commitlog
• 二进制日志
• 实际表格
• 以上所有地方都在我的DB奴隶上

考虑到我在EC2节点上并且大多数东西都经过相同的网络管道(文件系统是网络连接的),这太"耐用"了.此外,驱动器速度很慢.数据价值不高,我宁愿少花几分钟的数据丢失,而不是在人群到来时很可能发生中断.

在这些流量突发期间,我希望只有在我负担得起的情况下才能完成所有这些I/O. 我想尽可能多地保留在RAM中(与一小时内触摸的数据大小相比,我有相当大的RAM空间).如果缓冲区变得稀缺,或者I/O通道没有过载,那么我确定,我希望将事务转到commitlog或二进制日志以发送给slave.如果且仅当I/O通道没有过载时,我想回写实际的表.

换句话说,我希望MySQL/InnoDB使用"回写"缓存算法而不是"直写"缓存算法.我可以说服它这样做吗？

如果这是不可能的,我对一般的MySQL写性能优化技巧感兴趣.大多数文档都是关于优化读取性能的,但是当我收到大量用户时,我正在为所有用户创建帐户,因此这是一个繁重的工作量.

UUID通常是36个字符.