需要做一个存储，不断增长的大小

每当你接近完整时，启动一个新的MySQL服务器。 根据所需信息的date重写客户端软件以访问正确的MySQL服务器。

当然，你需要有可以用datestamp分区的数据。 需要跨越服务器的查询将不得不查询每个查询并合并结果。 join将是困难的。 但是，考虑到你想要无限存储，你必须在别处妥协。 你不能有无限的存储空间，仍然使用MySQL。

这适用于存储日志或其他存档数据的任何数据库，这些数据可累积但不会更改。 这样的数据也很容易通过datestamp进行分区。

这是Twitter最初使用的scheme。 他们有一台MySQL服务器来归档旧推文; 当它填满时，他们开始了一个新的服务器。 search“一切用户X曾经推送过”发送查询到每个服务器开始与最新的和服务器存储在创build帐户时的档案结束。 所有的旧服务器都设置了只读副本。 尽可能多地完成他们必须处理的查询量。 因此，系统可以在两个方向上扩展：向上扩展（移动到下一个服务器以获得更多空间）并向外扩展（为更多负载添加更多副本）。

然而，你最终会发现，关系数据库是一个可怕的select，用于存储日志或其他存档数据，但不会改变。 每次插入多行涉及到locking会降低进程的速度，如果可以保证所有的数据都是“一次写入”，则会造成浪费。

Twitter最终转移到其他存储技术，你会发现你也想这样做。 您将需要select一个通过添加更多机器来构build无限增长的系统。 然后系统跟踪哪些机器保存哪些数据，并且即使您将查询发送到主节点，也find正确的结果。 这样的系统包括：MongoDB，Hbase，CouchDB，我觉得Riak。

如果你的数据不能很容易地分区，这个答案不会帮助你。 在这种情况下，您需要考虑为现有系统添加更多的存储空间。 将大量磁盘添加到SAN并将其连接到计算机是一种解决scheme。

我会在这里大吃一惊，并假设你并不是真的有兴趣把存储连接到几个不同的物理机器，正如你的问题所指出的那样，而只是希望能够在单个主机上增加存储解决scheme您的存储需求增长。

如果是这样的话，我build议你仔细看看ZFS 。 它是专门devise用来处理这种情况（除其他外），它是一个通用的文件系统。

有一个Linux实现 ，不幸的是在某些使用场景下仍然会遇到打嗝 ，或者如果您更喜欢稳定稳定的文件，可以将文件托pipe在FreeBSD主机上，并通过NFS或SMB共享，​​甚至运行数据库在FreeBSD系统上。 我没有看到你指定的操作系统，但是你提到的MySQL并且更喜欢开源的解决scheme就是指向* nix。 主要的警告是，你真的想要去64位，并有很多的ZFS的内存真的很高兴，但今天不应该像历史上那么多的关注。

在ZFS上，你使用的是所谓的zpools，它基本上就像你可能认为的文件系统一样。 每个zpool由一个或多个vdevs组成，每个vdevs又由一个或多个物理（或逻辑）设备组成。 在整个zpool中，您可以创buildZFS术语中称为文件系统（可单独安装的层次结构）的内容。 通过向新的或现有的vdev添加额外的物理设备，文件系统将自动提供，并将使用获得的附加存储容量（如果有的话;例如，如果将镜像设备添加到vdev，则不会获得额外的存储空间获得冗余）。 添加设备是一个完全透明的在线操作; 因此，如果存储设备本身是可热插拔的，则可以构build在容量升级期间具有零停机时间的存储解决scheme。

你可以考虑使用LVM作为文件系统，但它意味着修改你的文件系统，这可能是至关重要的。 很好的解释在这里： https ： //wiki.ubuntu.com/Lvm

如果你在一个不间断的，永不停歇的洪水中每小时得到千兆字节，那么deviseselect是有限的。 您可能会考虑在一台将数据提供给MySQL数据库的机器上排队所有新数据。 通过这种方式，您可以closuresMySQL数据库进行维护：添加磁盘，连接到新的SAN等等。

队列机器会给你尽可能多的维护时间，因为它可以保存数据，但要记住，当它重新连接到MySQL服务器时，它将需要赶上。 例如，您可能会发现，如果使用队列机器来存储4小时的积压，则可能需要8个小时来清空积压到MySQL服务器; 它现在做了两倍的INSERT。

提示：如果您构build了这样一个队列机器，您会发现设置一个监视仪表板可以帮助您logging批量在被推送到MySQL服务器之前等待的时间。 等待时间统计将帮助您pipe理系统。 例如，如果您绘制了7天的尾随数据，则90分位数值将是总体健康状况的良好指标。 当这个值很高时，提醒。 有什么不对 您可能会绘制每周数据的90百分位数; 这会让你看到你是否随着时间的推移变得更好或更糟。