我在mysql中有一个url表,它只有两个字段id和varchar(255)作为url。目前那里有超过5000万个url,我的老板刚刚给了我关于我们当前项目扩展的线索,这将导致更多的url被添加到该url表中,预计明年年中将达到1.5亿左右。
目前数据库大小约为6 6GB,因此我可以放心地说,如果事情保持不变,那么它将超过20 6GB,这是不好的。因此,我正在考虑一些解决方案,可以减少url存储的磁盘空间。
我还想说明一下,这个表并不是一个繁忙的表,目前也没有太多的查询,所以我只是希望节省磁盘空间,更重要的是,我希望探索短文本压缩及其在mysql中存储的新想法
但在将来,该表也可能会被大量访问,因此最好在时机到来之前对表进行优化。
我花了相当多的时间将url转换成数字形式,并使用BIGINT存储,但由于它有64位的限制,所以它的效果不是很好。位数据类型也有同样的问题,并且也有64位的限制。
我将BIGINT转换为数字形式的想法基本上是因为8字节BIGINT存储19个数字,所以如果每个数字指向所有可能字符的字符集中的一个字符,那么如果所有字符都在1-10之间,那么它可以在8个字节中存储19个字符,但在现实世界中,有52个英语字符和10个数字加一些符号,所以它大约是100个字符集。所以,在最坏的情况下,BIGINT仍然可以指向6个字符,是的,这不是最终的裁决,它仍然需要一些练习来确切地知道每个数字指向它是10+数字、30+数字还是80+数字,但你已经大致了解我在想什么了。
更重要的是,由于url是可变长度的,所以我也在努力节省小url的磁盘空间,所以我不想给出固定长度的列类型。
我还研究了一些文本压缩算法,如smaz和Huffman压缩算法,但不是很确信,因为它们使用了某种字典单词,但我正在寻找一种干净的方法。
我不想使用二进制数据类型,因为它也会占用太多的空间,比如字节中的varchars。
发布于 2011-09-13 16:59:17
如果你正在寻找128位整数,那么你可以使用二进制( 16 ),这里的16是字节。您可以将它扩展到64字节(512位),这样它就不会比bit数据类型占用更多的空间。你可以说二进制数据类型是位数据类型的扩展,但它是字符串的变体。
话虽如此,我还是建议使用字典算法来压缩url和短字符串,但与url缩短服务使用的技术相结合,如使用A-Z z0-9三个单词的组合来替换大字典单词,您将拥有比可用单词62X62X62更多的组合。
虽然我不确定你会达到什么程度的压缩,但是用这种方式实现url压缩是个不错的主意。
https://stackoverflow.com/questions/7391839
复制相似问题