Icon Piggydb
#189 datomic   datomic     2 years ago (owner) Document
  • (entity, attribute, value, time) called datoms
  • 持久化单位是segment,每个segment有一个UUID
  • 索引使用Covering index,也即索引中包含了实际的数据
  • 索引使用类BTree结构,最多三层,root,dir,segments
  • segment是一组datoms,平均大小50k左右,存1k-2w个datoms,会做压缩
  • 有五种索引,EAVT, AEVT, VAET, AVET, Log index
  • 每种索引可以分成三部分,历史索引,当前索引,内存索引
  • (transactor)数据先写入log index,再写入内存index,然后聚合并广播给所有的peer
  • 所有的peer在新建连接时都会根据log重建内存索引
  • Peer and transactor communication is push-based,推模式,从peer读数据时,不经过transactor,只返回peer最后知道的
  • 查询时,涉及到多种索引merge
  • 旧的segment需要定期进行删除,根据实际情况,比如一周删一次
  • datomic支持外部cache(memcache),库本身也有内部cache
  • cache的单位是segment,里面包含一组datom,有一个好处是,客户端可以执行以给one-by-one的查询操作,如果是传统db,就要进行n次交互,对于datomic,只是n次内存访问
  • datomic提供强一致语义,但是实际写入是最终一致的(后面其实依赖的基本都是最终一致系统,如riak,cassandra)
  • 强一致语义的保证应该是transactor和peer来做到的,事务结束后,通知peer,数据已经修改,但数据可能还不可用(unavailable),要依赖底层的最终一致系统结束
  • transactor挂掉时,peer可以选择读现有数据,也可以选择block,直到transactor可用
  • 免费版transactor是个单点,transactor和peer之间是长连接,且是推模式,当peer与transactor之间连接不可用时,由peer自己选择是否牺牲一致性保证读高可用
  • 事务:写先写到transactor,它本身是个单点,先写log,再向后端写入(写够quorum),结束后通知所有连接的peer数据已经更新,然后返回客户端,结束该次事务(不会节点太多或者慢节点问题?)
http://basho.com/wp-content/uploads/2014/02/Rf_A6mq_Z.png
个人看法:
  1. 可能不太适合做为主要的数据存储(因为单点transactor),比较适合结合底层NoSQL,形成一个ACID(datalog)层,用户可以同时使用下面的NoSQL和Datomic形成的ACID层。