长期管理不断增长的数据库(10年后)

Question

我即将完成一个WEB应用程序(PHP + mysql网站门户)，它将缓慢地开始，比如上传少量图片和在主数据库表中插入几行，但不久之后，在几年内，我期望它在某一时刻稳步增长，甚至逻辑上增长。

根据我的Excel计算，在某个时候，数据库表数据+索引(innoDB)将使托管图片的大小增长10倍，但在开始时则相反。

因此，基本上，我的门户托管图片(比如说，中等大小的jpegs )，并使用MySql InnoDB数据库表。

我对各位管理员和专业人士的问题是关于我的MySql数据库的。

我事先在想，这样我就不会措手不及了：

当我的数据库将增长更多，甚至得到1.2TB、2TB或more....how时，我能处理吗？我可以说是在2台或更多的专用机器上分割它吗，这样搜索仍将是快速的，并从这个大型数据库获取数据吗？或者我应该做一个服务器，用很多便宜的7200 rpm sata把它抽出来吗？或者是什么可以解决一个不断增长的数据库。

这个web应用程序的第一个配置是一个VPS主机，它有一个4 4ghz处理器，3GB的ram和2x60 GB的SSD 1。

谢谢你的回答，

Answer 1

以下是一些一般性建议..。

• 不要将图像本身存储在数据库中(不清楚这是否是您的计划)。这会给你带来巨大的缩放问题。如果必须的话，可以将它们存储在文件系统或非关系数据库中。
• 数据库应该是一个独立于应用程序的服务器。
• 理想情况下，您应该有足够的RAM来保存您的工作数据集。确保预先调优数据库(innodb_buffer_pool_size、innodb_log_file_size等)。
• 将mysql数据放在最快的磁盘上。SSD或10k+ SATA/SAS。确保RAID控制器有电池备份和写缓存。
• RAID-10用于mysql数据卷。
• 将mysql的binlog(可能还包括中继日志和innodb事务日志)放在单独的RAID数组中，RAID-1应该可以。
• 有一个用于只读查询的从服务器，以从主服务器获得一些负载.您的应用程序将不得不区分RW和RO查询。在那个奴隶上设置“read_only=1”以防止不幸的事故。
• 随着数据集的增长，您可能需要考虑跨多个服务器进行水平切分。MySQL没有为此提供机制，所以您的应用程序需要这样做。
• 您没有理由不能拥有一个2TB数据库，但是对于不适合缓冲池的数据，您可能会发现性能是不可接受的。
• 不要在索引上过分。除了主索引之外的其他索引还会引入额外的开销(并不是说您应该没有)。可能有很好的机会使用复合索引(多列)，而不是使用两个单独的索引。

希望这能帮上忙

Answer 2

有句谚语说，过早优化是万恶之源。我的建议是关注新出现的问题，但不要担心长期影响。集中精力保持你的数据库尽可能好，让未来照顾自己。

至于在数据库中存储图像，这里有很多优点和缺点。我在MySQL中做了很多这方面的工作，但是在PostgreSQL上有一些非常好的方面(原子备份ftw!)这一点和一些真正令人讨厌的陷阱(啊，内存使用把基础64-表示的字节重新变成二进制！)所以要小心，注意权衡，并且愿意重新考虑这两种方式。

接下来的一点是，几年后，您的应用程序可能会与现在有所不同。使用模式可能也会有所不同。试图解决你认为有一天你可能会看到的问题是增加复杂性的一个好方法，它将使你明天遇到的实际问题更难解决。

一旦你开始挣扎，对你的选择有一个好的想法是一个好主意。其中包括：

• 垂直缩放，集中在更多的RAM，更快的硬盘驱动器，更强大的服务器等。
• 水平缩放和分片、复制、连接池等。
• 通过某种可以缓存常用数据(如NoSQL db或memcached)的中介进行数据库抽象。

这是你的主要选择。然而，每一个都增加了很大的复杂性，现在不可能知道哪些用例对您的用例有最佳的权衡。

如果你担心短期到中期的扩张，你能做的最重要的一件事就是学习各种选择和工具，并在一个安全和理智的环境中与那些你能做到的东西一起玩。