细谈Slick(5)- 学习体会和将来实际应用的一些想法

   通过一段时间的学习和了解以及前面几篇关于Slick的讨论后对Slick这个函数式数据库编程工具有了些具体的了解。回顾我学习Slick的目的,产生了许多想法,觉着应该从实际的工作应用角度把我对Slick目前能够达到的目的以及在现有功能优势和特点下如何进一步改进才能正真符合IT系统对数据库程序编程和运行效率的要求。想通过这篇博客把想法提出来跟大家分享一下,看看是否能够引起大家的共鸣,为我下一步的工作制定一个方向性的框架。

首先谈谈Slick的特点:主体方面Slick为函数式编程模式带来了SQL编程,可以把数据库表当作scala语言中的集合来对待。除了能实现FP的函数组合外又避免了嵌入SQL语句式的数据库编程,而且也实现了类型安全(type safe),可以由编译器(compiler)在编译时来捕捉语法错误。另一方面与同是基于jdbc之上的通用ORM库比较,Slick可以实现更高效率的关系表数据提取。

Slick实现函数组合部分主要分两个层次:一是Query组合:即把多个Query组成一个Query。我看主要是为了把几个数据源(table)join成一个源头,如下:

 1   val q11 = for {
 2     c <- coffees.filter(_.price >  100.0)
 3     s <- suppliers.filter(_.id === c.supID)
 4   } yield (c.id, c.name, s.name)
 5   q11.result.statements.head
 6   //res4: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where (x2."COF_PRICE" > 100.0) and (x3."SUP_ID" = x2."COF_SUP")
 7   
 8   //inner join
 9   val q12 = for {
10     c <- coffees.filter(_.price >  100.0)
11     s <- suppliers if s.id === c.supID
12   } yield (c.id, c.name, s.name)
13   q12.result.statements.head
14   //res12: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where x2."COF_SUP" = x3."SUP_ID"
15   
16   //outter join
17   val q13 = for {
18     c <- coffees.filter(_.price >  100.0)
19     s <- suppliers.filter(_.name === "Acme")
20   } yield (c.id, c.name, s.name)
21   q13.result.statements.head
22   //res6: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where (x2."COF_PRICE" > 100.0) and (x3."SUP_NAME" = 'Acme')

上面的例子里示范了把coffees,suppliers两个Query组合成一个joined Query的几种方法,最终结果就是产生一条joined-table的SQL语句。我们也可以用Slick的Query函数组件(combinator)join来达到同样目的,如下:

1   val q14 = for {
2     (c,s) <- coffees join suppliers on (_.supID === _.id)
3   } yield (c.id, c.name, s.name)
4   q14.result.statements.head
5   //res7: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where x2."COF_SUP" = x3."SUP_ID"

从函数组合角度来讲:所谓Query组合,功能十分有限。这也符合逻辑:因为最终要形成一条SQL语句。这样说吧:把多条分别读取不同源头的Query组合成一条从合并的源头读取数据的SQL语句也说得通,但其它情况如把一条update Query和insert Query组合成一条SQL就不符合逻辑了。倒是Query的函数组件如filter,take,drop,sortBy,groupBy等在函数式编程中还是比较适用的。

另一个层次的组合是DBIOAction组合,主要目的是编排多个独立Query的运算流程:按照一个组合而成的顺序来运算这些Action。也就是按顺序把每条SQL语句发送到数据库去运算。从函数组合的角度解释又可以理解为按需要把多个独立的数据库操作动作组合成一个完整的数据库操作功能。一项功能里的所有动作可以在一个事务处理(transaction processing)里进行运算。从下面的例子里可以看出端倪:

 1  val initSupAction = suppliers.schema.create andThen qInsert3
 2   val createCoffeeAction = coffees.schema.create
 3   val insertCoffeeAction = qInsert zip qInsert2
 4   val initSupAndCoffee = for {
 5     _ <- initSupAction
 6     _ <- createCoffeeAction
 7     (i1,i2) <- insertCoffeeAction
 8   } yield (i1,i2)
 9 
10   //先选出所有ESPRESSO开头的coffee名称,然后逐个删除
11   val delESAction = (for {
12     ns <- coffees.filter(_.name.startsWith("ESPRESSO")).map(_.name).result
13     _ <- DBIO.seq(ns.map(n => coffees.filter(_.name === n).delete): _*)
14   } yield ()).transactionally
15   //delESAction: slick.dbio.DBIOAction[...
16 
17   //对一个品种价格升10%
18   def raisePriceAction(i: Long, np: Double, pc: Double) =
19     (for(c <- coffees if (c.id === i)) yield c.price).update(np * pc)
20 
21   //对所有价格<100的coffee加价
22   val updatePriceAction = (for {
23     ips <- coffees.filter(_.price < 100.0).map(r => (r.id, r.price)).result
24     _ <- DBIO.seq{ips.map { ip => raisePriceAction(ip._1, ip._2, 110.0)}: _* }
25   } yield()).transactionally
26   //updatePriceAction: slick.dbio.DBIOAction[...

上面例子中delEAction比较典型,具体流程是:第一个Query先过滤出需删除的目标,然后把读出结果输入到下一个步骤。下一个步骤按读取目标逐个组成运算删除动作。整个过程在一个transaction里进行。

这样看来Slick的工作原理大体上是:

   构建Query >>> 组合Query >>> 产生SQL语句 >>> 按流程把SQL语句发给数据库进行运算 >>> 获取结果

完成了上面的叙述后,总觉着好像缺少些什么,是一个资深数据库后台软件程序员的感觉。是了,Slick把jdbc的resultset隐藏起来了。其目的可以理解:这样可以实现语法安全(type safety),才能把SQL编程融入FP编程,即scala集合编程。不过SQL是一种批次处理类型的语言,适合数据读取,而处理数据则有些吃力:因为需要逐条数据进行更新。但是,如果在数据库系统里使用cursor的话,无论编程或者运行效率都会很低,况且有些问题在数据库系统内是无法解决的,如:处理一幅图像,这个必须在前端把图像上载内存后利用前端CPU来运算处理。所以把数据从数据库中载入内存再运算的话能提高处理效率。不过针对一连串数据逐个处理的话,我觉着还是rs.next, rs("price")=10.0这种方式会亲切很多。

另外,如果把所有数据处理操作都以SQL语句发到数据库运算的话就无法利用前端计算资源了。单靠数据库服务器来支持所有运算明显是一种错误的运算结构。现代CPU多核已经是普遍现象,也是发展趋势(连手机都是多核的了)。充分利用前端资源不但能提高单项运算效率,而且通过分担服务器负载,能改善整个网络运算效率。我在想:如果能把数据先载入前端内存的话也许还能通过多线程编程来实现数据处理的并行运算,这也是我学习FP的主要目的。

综合以上分析,如果从一个有多年信息管理系统(MIS)开发经验的程序员需求出发,能在工作中使用FRM是一种崭新的体验。与习惯用的ORM比较,从scala编程表达形式和程序运算方式上都有较大的改善。但以Slick当前所能提供的功能还无法完全满足偏重数据处理(data processing)编程的需要。真希望有心人能在Slick3.1的基础上增加一些特色功能,实现以下目标:

1、增加对resultset row的操作支持:

     a) 增加如row.next、row.addNew、row.update、row.delete这样的功能

     b) 在使用row的字段时还能坚持Slick的type safe优点,像这样:row(r.price)=10.0,避免row("price"), row(1)这样的方式

     c) 用纯代码(pure code)方式来实现row变化(transformation),因为程序需要在多线程环境内运算

2、提供数据处理的并行运算功能:

     a) 同时从多个源头(data tables)读取数据

     b) 对row的tranformation实现并行运算

     c) 并行向数据库发送数据更新SQL语句

我个人也对上面的需求进行了一些调研分析,发现scalaz-stream-fs2是个不错的选择,能实现上面的这些要求。首先fs2是个functional stream library,我们仍然可以在FP模式下编程。我们可以用fs2把resultset截成一串row,然后用streaming来实现这个next功能逐条记录移动。而Stream[ROW]就是一个FP类型,可以保证Stream中间ROW类型值的变形处理(transformation)是纯代码,不会产生副作用。

那么,如果能用fs2来实现上述功能要求的话,我们就可以像下面这样来编程了:

1、用伪代码(sudo code)来表述一个最简单的程序流程:

Stream.run(read(PersonFile))  //读取PersonFile
   .doSomeThing(dataRow)      //处理一条数据,可以是更改,也可以是显示
   .next  (.eof)              //移动一步,重复。或者终结

-Stream.run产生了个数据元,Stream.Source

-read是个数据读取函数,产生的结果类型可能是:Seq[DataRow]

-doSomeThing,是一个datarow transformation函数。就是一个Stream.Pipe

-next, 消耗(consume)当前dataRow

-eof, 消耗(drain)所有dataRow

2、多源头并行读取:

buildPar(read(age.between(0,10))  //构建并行运算
  .with(read(age.between(11,20)) 
  .with(read(age.between(21,50))
  .runPar                         //开始多源头并行读取
  .doSomeThing(dataRow)           //处理一条数据
  .next (.eof)                    //移动一步,重复。或者终结

*我在想:如果doSomeThing是个图片显示(rendering)函数的话,显示满页带相片的个人资料网页是不是会快点?毕竟是并发的I/O

2、并行处理:

Stream.run(read(PersonFile))      //读取PersonFile
  .doPar(dataRow; next)           //多线程并行处理数据,包括了dataRow移动

如果把doPar的类型制成fs2的Stream[F,Stream[F,DataRow]]类型就可以实现并行运算了。对dataRow的消耗(consume)应该包括在运算内

3、多源头并行处理:

buildPar(read(age.between(0,10))  //构建并行运算
  .with(read(age.between(11,20)) 
  .with(read(age.between(21,50))
  .runPar                         //开始并行读取
  .doPar(dataRow,next)            //多线程并行处理数据,包括了dataRow移动

上面这些伪代码描述主要是一些运算框架。也就是说我把fs2作为一种数据处理运算的架构。这样的话上面那个doSomeThing就是实现dataRow transformation的地方了,而且必须在类型上、状态转变方式上符合fs2的要求。

可能在下面一段时间里我就会按照自己的理解和想法用scalaz-stream-fs2+Slick来开发一个开源的FunDA(Functional Data Access)函数组件库(combinator library)分享给scala数据库编程的朋友使用。希望无论在开发过程中或者将来的使用中都能得到有共同志愿朋友的参与和帮助。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

关于闪回区溢出导致的数据hang(r11笔记第12天)

对于Oracle数据库的闪回区的设置,之前和一个同事和讨论过,总体来说有一些不同的意见。 首先这个闪回区是一个逻辑的概念,闪回区的大小不会严格依赖于磁盘空间的情...

34513
来自专栏程序猿DD

来自95后的天池中间件大赛总结

天池中间件大赛的初赛在今早终于正式结束了,公众号停更了一个月,主要原因就是博主的空余时间几乎全花在这个比赛上,第一赛季结束,做下参赛总结,总的来说,收获不小。

2366
来自专栏熊二哥

快速入门系列--TSQL-01基础概念

    作为一名程序员,对于SQL的使用算是基础中的基础,虽然也写了很多年的SQL,但常常还是记不清一些常见的命令,故而通过一篇博文巩固相关的记忆,并把T-SQ...

1928
来自专栏程序员的诗和远方

20180803_ARTS_week06

这个是个比较不好的解法,就是像题目介绍里面那样先把这个『之』字形给做出来,然后再逐行读成字符串,但是通过这个比较好帮助我们理解这个题目。

841
来自专栏更流畅、简洁的软件开发方式

【自然框架】之“元数据”的威力

定义       元数据最本质、最抽象的定义为:data about data (关于数据的数据)。它是一种广泛存在的现象,在许多领域有其具体的定义和应用。  ...

1868
来自专栏Spark学习技巧

大数据查询——HBase读写设计与实践

作者 | 汪婷编辑 | Vincent导语:本文介绍的项目主要解决 check 和 opinion2 张历史数据表(历史数据是指当业务发生过程中的完整中间流程和...

2389
来自专栏点滴积累

geotrellis使用(二十六)实现海量空间数据的搜索处理查看

目录 前言 前台实现 后台实现 总结 一、前言        看到这个题目有人肯定会说这有什么可写的,最简单的我只要用文件系统一个个查找、打开就可以实现,再高级...

3426
来自专栏程序人生

谈谈FRP和Observable(一)

Observable是方兴未艾的FRP(Functional Reactive Programming)革命里最引人注目的一把火炬。FRP发展了也有两年多了,至...

4577
来自专栏Albert陈凯

Hbase二级索引

二级索引与索引Join是多数业务系统要求存储引擎提供的基本特性,RDBMS早已支持,NOSQL阵营也在摸索着符合自身特点的最佳解决方案。这篇文章会以Hbase做...

3454
来自专栏架构师之路

用uid分库,uname上的查询怎么办?

1分钟系列 【缘起】 用户中心是几乎每一个公司必备的基础服务,用户注册、登录、信息查询与修改都离不开用户中心。 当数据量越来越大时,需要多用户中心进行水平切分。...

3454

扫码关注云+社区