url文本压缩（不缩短）并存储在mysql中答案

【问题标题】：url text compression (not shortening) and storing in mysqlurl文本压缩（不缩短）并存储在mysql中
【发布时间】：2011-09-12 17:50:55
【问题描述】：

我在 mysql 中有 url 表，其中只有两个字段 id 和 varchar(255) 用于 url。目前那里有超过 5000 万个 url，我的老板刚刚给出了我关于扩展我们当前项目的线索，这将导致更多的 url 被添加到该 url 表中，预计数字在中期大约 1.5 亿明年。

目前数据库大小约为 6GB，所以我可以肯定地说，如果事情保持不变，那么它将超过 20GB，这是不好的。因此，我正在考虑一些可以减少 url 存储磁盘空间的解决方案。

我也想明确一下，这个表不是一个繁忙的表，目前没有太多的查询，所以我只是想节省磁盘空间，更重要的是我想探索短文本的新想法压缩及其在mysql中的存储

但是将来该表也可以被大量访问，因此最好在时间到来之前优化该表。

我做了很多工作来将 url 更改为数字形式并使用 BIGINT 进行存储，但由于它有 64 位的限制，因此效果不佳。同样是 BIT 数据类型的问题，也有 64 位的限制。

我转换为数字形式的想法基本上是 8 字节 BIGINT 存储 19 个数字，因此如果每个数字指向所有可能字符的字符集中的一个字符，那么如果所有字符的范围为 1-，它可以在 8 个字节中存储 19 个字符10，但在现实世界的场景中，有 52 个英文字符和 10 个数字加上很少的符号，所以它大约有 100 个字符集。所以，在最坏的情况下，BIGINT 仍然可以指向 6 个字符，是的，它不是最终判决，它仍然需要一些锻炼才能确切知道每个数字指向它是 10+ 数字或 30+ 数字或 80+ 数字，但你有差不多知道我在想什么。

更重要的一点是，由于 url 是可变长度的，所以我也在尝试节省小 url 的磁盘空间，所以我不想给出固定长度的列类型。

我还研究了一些文本压缩算法，例如 smaz 和 Huffman 压缩算法，但不太相信，因为它们使用某种字典单词，但我正在寻找一种干净的方法。

而且我不想使用二进制数据类型，因为它也占用太多空间，例如 varchars 字节。

【问题讨论】：

长度 255 对于 url 可能不够
我记得使用 20 GB 任何东西 的想法完全是科幻小说。但今天？即使是磁盘空间不足十倍的低端消费类 PC，也可能无法购买。这真的是对程序员时间的一种经济高效的利用吗？
你似乎误解了 varchar 的作用。
刚刚编辑了这个问题，以明确将来可能需要查询该表。因此，最好保持有效的形式。现在，请不要建议我添加索引，但我现在只想弄清楚存储效率。
@ajreal 我了解 varchars .. 但也许我在某个地方错了，所以请您详细说明一下吗？

标签： mysql url text compression

【解决方案1】：

另一个尝试的想法可能是识别常见的字符串并用位图表示它们。例如，有两个位表示协议（http、https、ftp 或其他），另一个位表示域是否以“wwww”开头，两位表示域是否以“.com”结尾，“. org"、".edu" 或其他内容。您必须对您的数据进行一些分析，看看这些是否有意义，以及您是否可以识别任何其他常见的字符串。

如果您有很多指向同一个站点的 URL，您还可以考虑将表拆分为两个不同的表，一个包含域，另一个包含域相对路径（以及查询字符串和片段 ID，如果存在））。您将拥有一个链接表，其中包含 URL 的 id、域的 id 和路径的 id，并且您将使用连接三个表的视图替换原始 URL 表。域表不必局限于域，您可以包含尽可能多的 URL（例如，“http://stackoverflow.com/questions”）。这不需要太多的代码来实现，并且具有仍然可读的优点。你的数字编码可能更有效，一旦你弄清楚了，你就必须分析你的数据，看看哪一个更有意义。

【讨论】：

【解决方案2】：

如果您正在寻找 128 位整数，那么您可以使用 binary(16) 这里 16 是字节。您可以将其扩展到 64 字节（512 位），因此它不会占用比位数据类型更多的空间。您可以说二进制数据类型是 BIT 数据类型的扩展，但它的字符串变体。

话虽如此，我会建议使用字典算法来压缩 URL 和短字符串，但要结合使用 url 缩短服务所使用的技术，例如使用 A-Z a-z 0-9 三个单词的组合来替换大字典单词，你会有更多组合可用字数大于 62 X 62 X 62。

虽然我不确定你会达到什么级别的压缩，但以这种方式实现 url 压缩并不是一个坏主意。

【讨论】：