标签：数据压缩

共 5 篇相关文章

IT 累计浏览 1,525

资源包的设计

这篇讲的是游戏资源包设计中的工程实践与权衡。作者从“如何把资源打包并高效更新”这一核心问题出发，指出了当前直接使用通用压缩格式（如zip）的普遍做法，以及为应对资源引用关系、大量文件检索等需求而采用自定义格式（如MPQ、AssetBundle）的趋势，其中对文件名进行hash索引是关键一步。然而，文章敏锐地指出，hash冲突是这类设计中不容回避的问题，并以Unity的AssetBundle在冲突时直接放弃打包为例，说明了现有方案的缺陷。作者随后提出了一种简单有效的“加盐二次hash”方案：在打包时若发现hash冲突，便引入一个可确定的salt值重新计算，从而在运行时能唯一区分原文件，且强调了正确加盐（如将salt作为hash seed或循环XOR）的重要性，避免了简单拼接导致的二次冲突。此外，文章还涵盖了资源包间的引用需依赖间接索引而非单纯hash值，以及patch更新可设计为保留完整索引的增量包、并定期生成基准全量包的策略。最后，作者将打包工具类比为git，需要实现初始化、文件追踪、版本打包与diff生成等版本管理功能。整体方案兼顾了理论基础与工程落地，对处理游戏资源管理的复杂性提供了清晰的思路。

IT 累计浏览 1,903

关于Cookie长度的思考

这篇讲的是如何在有限的存储空间（比如浏览器的Cookie）里“挤”下更多信息。作者从一个常见的问题出发：如何让存储的数据变得更小？文章没有停留在理论上，而是直接列举了我们熟悉的“key_len + key + value_len + value”这种存储格式作为分析起点。接着，作者给出了一系列非常具体的“瘦身”技巧：如果字段长度固定，对应的长度标识就能省掉；如果给字段编个号，字段名本身也能缩短；甚至可以完全依赖顺序来定位，连字段名和长度都能一并去除。更巧妙的是处理变长数据和空值的思路。比如，用一个单独的“元字段”来标记哪些值是空的，从而省掉原本用于表示空值的长度字节。文章还提出了一个很实用的“默认值”策略：把频繁出现的值设为默认，不实际存储，仅用极少的位数（如2比特）来标识当前用的是哪个默认值。所有这些优化背后有一个统一的原理：信息并没有丢失，而是巧妙地“藏”进了代码逻辑和预设规则之中。这篇文章就像一位经验丰富的工程师在分享他的存储空间优化心得，把看似简单的数据结构玩出了很多节省空间的花样。

IT 累计浏览 4,503

开源压缩算法Zopfli介绍

这篇讲的是谷歌近期推出的一款名为Zopfli的开源压缩算法。它本身是一款deflate格式的兼容性压缩器，灵感来源于WebP图像压缩中的无损压缩技术优化，因此能与广泛使用的zlib、gzip完全兼容，这意味着几乎所有浏览器和解压工具都能直接处理Zopfli生成的数据。文章重点剖析了Zopfli的两个核心特点：一是压缩性能，其输出文件比gzip 9压缩的结果小约3.7%到8.3%；二是压缩速度，比gzip 9慢了81倍。这是一个典型的用时间换空间的权衡。作者指出，这种“高压缩率、解压完全兼容”的特性，使其特别适合Web服务器的数据存储与分发。虽然单个文件压缩率的提升看似不大，但在海量数据的场景下（如大型网站、CDN），由此带来的带宽与存储成本节约将非常可观。文章末尾还附上了简要的命令行用法，方便读者快速上手测试。

IT 累计浏览 5,224

Fastbit中的bitmap索引算法

这篇讲的是开源数据处理库 Fastbit 的核心索引技术——bitmap 索引算法的实现。文章从 Fastbit 按列存储的特点出发，详细剖析了其索引类清晰的派生结构，并重点介绍了几种基础 bitmap 索引算法的设计思路。作者从最直观的 relic（等值编码）讲起，它为每个不同值建立一个独立的 bitvector。随后引出其变形 bin（分桶编码），将值域划分为不相交区间。更巧妙的是 range 和 mesa 两种算法：range 算法通过累积 bin 的结果来标记“小于某值”，而 mesa 算法则允许区间重叠。这些基础算法构成了 Fastbit 索引的基石。此外，文章还触及了扩展算法 direkte，它与 relic 几乎一致，但为小于最大值的所有值都建立了索引。这些从简单直接到巧妙演进的实现，展示了为满足不同查询需求，在存储与效率间进行的精细权衡。

IT 累计浏览 3,722

PostgreSQL与MySQL的区别

这篇讲的是 MySQL 和 PostgreSQL 这两大数据库该如何选择。作者没有罗列枯燥的特性列表，而是直接切入两者最核心的定位差异：MySQL 为了极高的查询速度和易用性，在功能上做出了取舍；而 PostgreSQL 则忠实于 SQL 标准，提供了更丰富、更严谨的功能，比如复杂的查询、完整的约束和更强的扩展性。文章进一步指出，这种哲学上的不同，直接决定了它们各自最适合的场景。如果你的应用需要处理海量数据、追求极致的读写性能，比如高并发的 Web 应用，MySQL 可能是更直接的选择。反之，如果你从事地理信息系统、数据分析，或者需要处理复杂的数据关系并保证数据的完整性和正确性，PostgreSQL 强大的功能和对标准的坚持会带来巨大优势。最后文章还提到，PostgreSQL 在近年来的版本中性能已有长足进步，而 MySQL 也在通过插件等方式增强功能，但二者底层的设计思想差异依然明确。