【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
前一段时间，在给客户导出瓦片数据作为提交成果。最终导出了512x512，总共8级，这大约已经是100万比例尺的水平，接近数据最高分辨率了。虽然数据量不是很大，但文件很小很碎，经过优化处理之后，一个瓦片只有几k，而且，由于地球大面积是海洋，而海洋的部分的显示效果都是一样的，也就是说，70%数量的瓦片都是一样的，我在想，这么多重复的内容都是冗余啊，有没有可能把这些瓦片都归结成同一个，这样，文件数量可以至少减少到原先的一半以下。有人跟我说，MBTiles格式可能可以实现，我就去查了一下。
https://github.com/mapbox/mbtiles-spec
这个是mapbox给出的数据格式说明，这是一种基于Sqlite数据库，将地图栅格（也可以是矢量或三维模型）瓦片存储为二进制字段，通过对应的xyz属性数据快速调用和查找，返回给客户端的。根据Sqlite的作者所说，通过数据库访问文件，要比直接访问磁盘文件速度快上35%，当然，我忘了是不是基于ssd了。当然我有更好的加快访问速度的方式，比如映射内存虚拟磁盘，将所有数据存放于内存，根本不用去考虑做缓存的问题。
但在阅读这个说明的时候，发现他们只是将磁盘中的内容直接写入的数据库，并没有对数据进行重复校验，也没有对重复的瓦片进行合并和映射。我觉得，如果是我来实现，我会增加一个md5的字段，如果重复，则不将重复文件写入，而是写入一个重复标识，并将之前重复内容的xyz信息写入其中。这样，重复的文件就只有一个，剩下的都是转向了。但是，在数据库中的转向是没法实现的，最终还是要在提供服务的时候进行识别，判断二进制字段是实际的文件还是转向标识。这无疑增加了处理请求的复杂度，而且，每次请求都需要判断，虽然不是很复杂。相对来说，我们将数据完全写入，不去考虑是否重复，用文件冗余的代价来换取这种判断则是以空间换取时间。
实际上，我们做设计，很多时候都是在做这类权衡和取舍。速度慢，于是有了缓存，数据大，于是有了分页。技术的实现思路并不一定说要怎样，如果你的环境能承受，分表分库就根本没必要去考虑，先实现了再说。对于现在这个问题，数据虽然有冗余，但在现在这个数量级下，成本并不算高，所以，剔除冗余的的收益显然比增加复杂度和处理步骤的代价要小得多。
所以，弄完了的瓦片，直接上吧。
来源：oschina
链接：https://my.oschina.net/rodger/blog/3153377