司马刘的日志

经过一个月的忙碌，DAL 又更新了，内部版本号为 2.3.5。这个版本主要改进以下几点：

协议改进。之前版本的 DAL 使用 php 序列化作为数据传输协议，这是一个历史遗留的问题，因为最早的 DAL 是完全用 php 实现的。现在仔细考虑过后认为 php 序列化肯定不是好的编码格式，首先 php 序列化是文本格式的，并不高效；还有很致命的一点就是 php 对数据类型支持很差。比如：php 不支持 double 类型，如果打算用 java 语言实现一个 DAL 客户端，那么这里无疑是丢失了数据类型信息，所以 php 序列化肯定是不够用的。新的编码格式目标就是高效，并且对数据类型有良好支持。参考了 mysql 数据库协议和 igbinary 序列化格式，最终考虑采用二进制协议。如何支持数据库的多种数据类型呢？我们是这么做的，server 端返回的查询数据是一个表格，表格有表头和表内容，我们在传输表头时就传输了每列的列名和列类型，这里列类型和 JDBC 的数据类型是一致的，表内容全部采用字符串编码，这样可能会多传输一些字节，但是避免了精度问题，因为数字也是用字符串编码的，当然没有精度问题。这样的好处是 DAL 不同的客户端可以根据各自语言特点来解码。协议设计好后先用 php 实现了一个版本的解码器，由于 php 本身性能问题导致 php 版的解码器效率比较低。接下来又用 php 扩展实现了解码器，性能有大幅度提高。在大数据解码方面比 php 序列化快几十倍，比 igbinary 快一点点。

对数据库函数的处理。DAL 需要操作缓存，需要考虑数据库切分，所以不得不分析用户的查询请求。如果用户使用了数据库函数，这个分析就变的异常困难，因为你不知道（很难知道）用户调用的函数中使用了什么函数，涉及到哪些字段。目前的临时解决办法是：只要用户使用了数据库函数，用户就必须显示的指定是否缓存；如果用户这个请求需要辅助表完成，那么 DAL 会强制选择第一个辅助表而不进行任何优化选择（关于辅助表选择优化请看《DAL 最近的一些进展》）。

数据库条目缓存结构调整。以前数据库条目缓存包含了条目的属性和数据两部分信息。很显然，没必要缓存条目的属性，因为条目属性在系统启动时就可以加载，在整个系统运行期间不会改变，没必要每次写到缓存里。缓存数据库条目时所有字段都是按字符串格式存储的，这样做无疑增加了缓存条目的体积，但换来的是保证不会在 server 端丢失数据精度，同时数据格式和协议是一致的，便于操作。

大体就是这些改进，关于 DAL 的介绍可以看超前同学的博客。在这段开发过程中接触了很多开源软件，也浏览过一些源代码，个人认为 php 和 mysql 的源代码质量比较一般，如果打算读开源代码不建议选这两个。

上个月我这个部门走了两个人，我的意思是说现在我这个部门只有一个人。DAL 的研发工作目前是由我一个人负责。一个人做事的弊端就是想法比较局限，代码写了只有自己觉得好不好，也没有别人来评价。不管怎么说，DAL 还是在稳步前进。下面就说说 DAL 目前的一些进展。

1. 选择最优的索引表完成查询。数据分片后为了便于排序和做一些聚合操作，每套分片都建了若干个索引表，有查询请求需要索引表辅助完成的时候，以前是随机选一个可用的索引表，现在引入了一个评分的算法，给每个索引表评分，选得分高的索引表。评分的依据主要是索引的使用情况，大体来说就是有索引比没有索引好，联合索引比单个索引好。目前这个特性在手机之家测试机上运行良好，情绪稳定。
2. 对并发查询请求的优化。在生产机的数据库上经常会看到有同样的 SQL 请求在数据库中执行，DAL 能不能为这种情况做些优化呢？我们想到了这样的办法：每次执行数据库查询的时候记录一个请求执行上下文，当有同样的请求并发到达时，只有严格的第一个到达的请求会查询数据库并将查询结果保存在执行上下文中，其他请求都等待第一个请求完成，然后直接使用上下文中保存的查询结果。当然如果对某个表有更新操作，这个表的所有执行上下文都将被删除，保证数据的一致性。还有如果查询中包含时间函数也不能使用这种优化机制。
3. 编码优化。以前的 DAL 使用 php 序列化编码结构化数据。其实只要稍微想想就知道这肯定是个不好的方式，但是由于历史原因，这种编码方式一直持续到现在。php 反序列化大数据时性能相当差，并且 php 只支持少数几种数据类型，用 php 序列化编码的数据无法跨语言使用。新的编码主要要解决性能问题和数据类型跨语言的问题。这部分工作目前还在进行中，以后会给出结果。

大概就是这些，最后再附几张大学校门图，这也能看出国家正在进步嘛！