我在mysql中有url表,它只有两个字段id和varchar(255)用于url.目前有超过5000万网址,我的老板刚刚给出了关于我们当前项目扩展的线索,这将导致在该网址表中添加更多网址,并且预计在该网址中间的数字大约为1.5亿.明年.

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

我还想明确表示这个表不是一个繁忙的表,并且在momen上没有太多查询所以我只是想节省磁盘空间,更重要的是我希望探索短文本压缩的新想法及其在mysql中存储

但是将来该表也可以被大量访问,因此在时间到来之前更好地优化表.

我工作了很多,将URL更改为数字形式并使用BIGINT存储,但因为它有64位的限制,所以它没有很好地工作.同样是BIT数据类型的问题,也强加了64位的限制.

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

更重要的是,由于url的长度可变,所以我也试图节省小url的磁盘空间,所以我不想给出固定长度的列类型.

我也研究了一些文本压缩算法,如smaz和Huffman压缩算法,但不太相信,因为他们使用某种字典词,但我正在寻找一个干净的方法.

而且我不想使用二进制数据类型,因为它也需要太多像varchars一样的空格.

解决方法:

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

话虽如此,我建议使用字典算法来压缩URL和短字符串,但是使用url缩短服务所使用的技术的混合,比如使用AZ az 0-9组合三个单词来替换大字典单词,你会得到比可用组合更多的组合字62 X 62 X 62.

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