为什么数据库比文本文件快?

文本为什么更慢?

文本文件慢的原因,主要在于会多出很多数据类型解析的动作。

举个例子,设想一下把文本“12345" 转成内存二进制整数 12345 的过程:

1. 先设结果的初始值为 0

2. 拆出字符“1”,解析出数值 1,将初值 0 乘以 10 加上这个 1 得到数值 1

3. 再拆出字符“2”,解析出数值 2,把刚才的 1 乘以 10 和这个 2 相加得到数值 12

4. 再拆出字符“3”,解析出数值 3,把刚才的 12 再乘以 10 加上这个 3 得到数值 123

5. …

有些 C 程序员知道用函数 atoi() 可以实现字串到整数的转换,仅仅一句代码,看似非常简单,但其实背后的步骤非常多,CPU 要干很多事才能完成这个动作,耗时并不短。实际过程中还要判断可能出现的非法字符(比如不是数字的字符),比上面描述的步骤还要更复杂得多。

整数还是最简单的数据类型,如果是实数还要处理小数点,字符串解析时要考虑转义字符和引号匹配,日期的解析更是要麻烦得多,因为格式种类太多,2018/1/10 和 10-1-2018 都是常见的合法日期格式,甚至还有 Jan-10 2018 这种,要正确解析,就得尝试用多种格式去匹配,CPU 耗时很严重。

理解了文本慢的原因,也就理解了数据库快的原因。数据库当然不会用文本存储数据,而是采用二进制的形式,这时候已经将数据类型等信息保存好了,读取时不需要再解析数据类型,所以性能更好。

二进制文件会更快

即然文本慢的原因是数据类型的解析,我们如果把数据存成二进制文件,是不是可以获得与数据库一样的性能呢?

答案是肯定的,而且相对数据库,二进制文件的性能更高!

因为数据库通常都要提供数据更新的能力,这就会产生影响性能的因素。

1. 紧凑性与压缩手段

数据库要考虑数据的更新,一般会采用段页式的分块存储,在存储数据时不会把分块完全填满,而会留一小部分空白区用于后续的修改动作。这样,占用的硬盘空间就会比不考虑更新动作的文件更大一点。

因为要更新数据,也很难实现数据压缩。比如把小整数存成较短字节的方案,如果采用了这种方案,一旦这个小整数被改成了大整数,原来的空间就存不下了,就要把后续数据都向后移动,这会使数据更新成本过高,所以一般数据库都不采用压缩手段,而直接根据数据类型分配空间,也会造成空间的浪费,极端情况会出现占用空间大于文本的现象。

而二进制文件则没有这方面的限制,不仅可以将数据紧凑存储,还可以放心地进行压缩从而获得更高的读取性能(减少硬盘时间)。不过数据的压缩率不是越高越好,解压缩需要耗费 CPU 时间,过于追求压缩率会导致 CPU 时间过长反倒影响性能。理想的压缩方案,要在硬盘空间的减少和 CPU 的消耗中取得某种平衡。

2. 事务一致性带来的复杂性

许多商业数据库还会同时支持 OLTP 业务,在读取数据时要提供一致性的能力,这会使访问数据的动作复杂度变大很多。同一条数据,由于其它事务的写操作,可能出现多个备份,在读取时数据库要根据事务的启动时刻找到正确的那一个,这是个非常麻烦的动作,对性能影响很大。而二进制文件则没有这方面的限制。

3. 分段不灵活

数据库按块存储的结构对于分段也不够自由,不能像文件那样可以实施更灵活的并行手段,也会导致数据库的性能表现弱于二进制文件。

4.IO 性能差

数据库普遍还有一个 IO 性能不佳的问题,数据在数据库中运算时性能不错,但某些复杂运算用 SQL 不容易写,要通过口取出来再运算,而这个接口通常都非常慢。实测的情况表明,从数据库中取数的性能经常可能会比从文本文件中取数还慢,相对二进制文件就更差了。

通过比较,我们看到二进制文件相对数据库有很多优势。但在实际应用中却很少使用,这是为什么呢?

原因在于文件(包括二进制文件)最大的缺点:可计算性太差

数据不是存起来就完事儿,要使用才能产生价值,本质上就是计算。我们知道数据库不仅能存储,还能计算,不仅能算还挺方便,使用 SQL 这种专门的数据库计算语言处理数据很方便,分组汇总、关联计算简单一句就能搞定。而文件却不具备这样的能力,要计算文件数据还要借助其他编程语言完成,实现难度很大。像大部分应用都在采用的 Java,由于缺少相应的结构化数据计算类库,要实现 SQL 式的集合运算代码量很大,简单的分组汇总也要写几十行,更别提复杂一些的计算了。

除了可计算性,还需要有一套相对通用的二进制文件的存储方式,如适合的压缩算法、有效的分段方案等。业界在方面并没有标准(相对来讲文本文件就通用得多了),这些工作如果每次都要从头来做,那经常就不如直接使用数据库来的方便了。

开源 SPL 提供可计算的通用二进制文件

有了开源 SPL,就可以利用二进制文件的高性能了。

开源 SPL 提供了通用的二进制文件存储方式,以及基于这些文件的计算能力,从而可以充分发挥二进制文件的优势,高效完成数据处理。

SPL 的二进制文件

集文件

集文件是 SPL 提供的基础二进制数据格式,不仅采用了压缩技术(占用空间更小读取更快),存储了数据类型(无需解析数据类型读取更快),还支持可追加数据的倍增分段机制,利用分段策略很容易实现并行计算,进一步提升计算性能。

SPL 将文本转换成集文件非常简单:


A

1

=file("data.btx").export@b(file("data.txt").cursor@t())

通过游标 cursor 流式读取文本内容并写出成二进制集文件 data.btx,其中选项 @b 代表生成二进制文件。如果针对已有二进制文件进行追加写入,增加一个选项 @a 即可,即:

=file("data.btx").export@ab(file("data.txt").cursor@t())

生成的二进制文件天然具备上述讨论的优良特性,比如倍增分段技术,即将数据进行分块存储,并行计算的时候直接基于分块数据计算会很方便,但是要考虑数据追加的问题,SPL 设计了一种倍增分块的方案,保证数据可以不断追加的同时分块还可以顺利完成。当然这些对应用人员来讲都是透明的,直接使用就好。取某个分段数据很简单:

=file("data.btx").cursor@b(;23:100) //表示取100段中的第23段。

组表

组表是 SPL 提供列存、索引机制的文件存储格式,在参与计算的列数(字段)较少时列存会有巨大优势。组表除了支持列存,实现了 minmax 索引外,还支持倍增分段机制,这样不仅能享受到列存的优势,也更容易并行提升计算性能。

组表的生成和使用:


A

B

1

=file("data.ctx")

=file("date.btx")

2

=A1.create(…)

=A2.append(B1.cursor@b())

3

=A1.open()


4

=A3.cursor(…;;4:10)


5

=A4.fetch(1)


和集文件不同,组表需要事先创建后才能追加数据(A2 创建,B2 追加数据)创建时要先指明数据结构(A2 中的…部分),这有点类似数据库中的表需要先 CREATE TABLE。A4 类似前面产生了不同分段的游标,注意要多写一个分号。组表创建时会缺省使用列存,读取时在参数中(A4 中的…)写上用到的字段名,就能利用列存优势减少读取量了。

SPL 除了提供高效的二进制文件存储,还有很多其他特性方便数据处理。

基于二进制文件直接计算

SPL 提供了完备的计算能力,基于二进制文件,通过 SPL 敏捷语法和高性能算法就可以高效实现数据处理,不仅写的简单,运算效率也更高。

比如常见的 TOPN 与组内 TOPN 计算:


A


1

=file(“data.ctx”).create().cursor()


2

=A1.groups(;top(10,amount))

金额在前 10 名的订单

3

=A1.groups(area;top(10,amount))

每个地区金额在前 10 名的订单

SPL 还提供了丰富的计算类库,常规与复杂计算用 SPL 实现都很简单。


A

B

1

=T("/data/scores.btx")


2

=A1.select(CLASS==10)

过滤

3

=A1.groups(CLASS;min(English),max(Chinese),sum(Math))

分组汇总

4

=A1.sort(CLASS:-1)

排序

5

=T("/data/students.btx").keys(SID)


6

=A1.join(STUID,A5,SNAME)

关联

7

=A6.derive(English+ Chinese+ Math:TOTLE)

追加列

对于文件计算,SPL 还提供了相当 SQL92 标准的 SQL 支持,对于熟悉使用 SQL 的人员可以直接使用 SQL 查询文件(文本、二进制都可以):

$select * from d:/Orders.btx where Client in ('TAS','KBRO','PNS')

复杂些的 with 都支持:

$select t.Client, t.s, ct.Name, ct.address from
(select Client ,sum(amount) s from d:/Orders.btx group by Client) t
left join ClientTable ct on t.Client=ct.Client

SPL 的敏捷语法和过程计算还非常适合完成复杂计算,比如基于股票记录计算某只股票最长连涨天数 可以这样写:


A

1

=T("/data/stock.btx")

2

=A1.group@i(price<price[-1]).max(~.len())-1

再比如,根据用户登录记录列出每个用户最近一次登录间隔:


A


1

=T(“/data/ulogin.btx”)


2

=A1.groups(uid;top(2,-logtime))

最后2个登录记录

3

=A2.new(uid,#2(1).logtime-#2(2).logtime:interval)

计算间隔

不仅如此,SPL 还对接多样性数据源,想到想不到的都支持。

更进一步,SPL 还可以进行多源混合计算,特别适合完成 T+0 查询。二进制文件适合存储不再修改的大量历史数据,而少量实时可能修改的热数据仍然存储在数据库中,如果要全量查询就要跨文件和数据库查询,这时就可以利用 SPL 的跨源计算能力和数据路由功能,根据计算需求选择对应的数据源以及跨数据源混合计算。如冷热数据分离后,基于 SPL 进行冷热数据混查,同时对上层应用透明,实现 T+0 查询。

可集成

在集成性方面,SPL 提供了标准 JDBC 和 ODBC 接口供应用调用。特别地,对于 Java 应用可以将 SPL 作为嵌入引擎集成到应用中,使得应用本身就具备基于文件的强计算能力。

JDBC 调用 SPL 代码示例:

…
Class.forName("com.esproc.jdbc.InternalDriver");

Connection conn =DriverManager.getConnection("jdbc:esproc:local://");

CallableStatement st = conn.prepareCall("{call splscript(?, ?)}");

st.setObject(1, 3000);

st.setObject(2, 5000);

ResultSet result=st.execute();
…

SPL 是解释执行的,天然支持热切换,这对 Java 体系下的应用是重大利好。基于 SPL 的数据计算逻辑编写、修改和运维都不需要重启,实时生效,开发运维更加便捷。

SPL 不仅直接提供了高效的二进制文件存储,还提供了强大的文件计算能力,在诸多对性能要求较高的分析型场景下可以发挥巨大效力,是数据库很好的替代。

以下是广告时间

对润乾产品感兴趣的小伙伴,一定要知道软件还能这样卖哟性价比还不过瘾? 欢迎加入好多乾计划。
这里可以低价购买软件产品,让已经亲民的价格更加便宜!
这里可以销售产品获取佣金,赚满钱包成为土豪不再是梦!
这里还可以推荐分享抢红包,每次都是好几块钱的巨款哟!
来吧,现在就加入,拿起手机扫码,开始乾包之旅



嗯,还不太了解好多乾?
猛戳这里
玩转好多乾