异步事务处理
版主: hci
#3 Re: 异步事务处理
貌似这是两个问题。
1. 为啥重写一个数据库?
大部分编程都是圍繞数据库进行的。现有的数据库不够好用。SQL是个COBOL时代的语言,本质上是一个错误。拨乱反正是我最喜欢干的事情了。再说,我要搞的AGI是以数据库为核心的。不是随便什么数据库,而是能方便做推理的。所以得自己写一个。
2.为什么用clojure?
因为对我而言,产生力最好呀。也不是全用clojure,根据分层混合编程的理念,不同类型的问题用不同层次的语言。下面用C,中间用java,最上层用clojure
1. 为啥重写一个数据库?
大部分编程都是圍繞数据库进行的。现有的数据库不够好用。SQL是个COBOL时代的语言,本质上是一个错误。拨乱反正是我最喜欢干的事情了。再说,我要搞的AGI是以数据库为核心的。不是随便什么数据库,而是能方便做推理的。所以得自己写一个。
2.为什么用clojure?
因为对我而言,产生力最好呀。也不是全用clojure,根据分层混合编程的理念,不同类型的问题用不同层次的语言。下面用C,中间用java,最上层用clojure
#4 Re: 异步事务处理
看了下
有的地方表述不清楚
Asynchronous 的wait 应该是logically blocking 不是physically blocking 你是通过closure future实现的?
有的地方表述不清楚
Asynchronous 的wait 应该是logically blocking 不是physically blocking 你是通过closure future实现的?
急急如丧家之犬
忙忙似漏网之鱼
忙忙似漏网之鱼
#5 Re: 异步事务处理
对呀。用高层的语言,省很多事。
实现这些很简单。
实现这些很简单。
hahan 写了: 2025年 2月 14日 22:51 看了下
有的地方表述不清楚
Asynchronous 的wait 应该是logically blocking 不是physically blocking 你是通过closure future实现的?
#6 Re: 异步事务处理
如果要用这个数据库,我最关心的是transaction可不可靠。并发的时候会不会有冲突。我比较想看你写这方面的内容。
我导师总爱说,一个storage system从开始到稳定要差不多10年时间。很多bug都要慢慢从实践中暴露出来的。这也是为什么数据库新品出头很难。
我现在做的系统,用redis做锁,kafka接journal,然后真正用的数据对象存在s3上。因为被锁的对象是inference context平时最好就是在内存里减少I/O。如果机器A锁着对象,机器B要用,先发消息给A要求其解锁,然后把内容存到s3上,然后B再加锁读进来。但是我这套体系眼前显然没法做到ACID。如果并发多了肯定会有各种数据不一致。如果真要精雕细琢会非常麻烦。要么就不要分布式了直接连一个postgresQL,也可以。其实postgresQL的性能足够我发财了。发不了财主要是自己的问题。
我导师总爱说,一个storage system从开始到稳定要差不多10年时间。很多bug都要慢慢从实践中暴露出来的。这也是为什么数据库新品出头很难。
我现在做的系统,用redis做锁,kafka接journal,然后真正用的数据对象存在s3上。因为被锁的对象是inference context平时最好就是在内存里减少I/O。如果机器A锁着对象,机器B要用,先发消息给A要求其解锁,然后把内容存到s3上,然后B再加锁读进来。但是我这套体系眼前显然没法做到ACID。如果并发多了肯定会有各种数据不一致。如果真要精雕细琢会非常麻烦。要么就不要分布式了直接连一个postgresQL,也可以。其实postgresQL的性能足够我发财了。发不了财主要是自己的问题。
#8 Re: 异步事务处理
你看到的银行用的数据库,很难回过头去再去颠覆他们。因为现在大家同行概念里的数据库,也就是带事务处理的数据库,就是为了解决记账问题诞生的。银行用那个就够了,他们没为啥要换?哪怕换了具体产品,也是同一类技术的产品,比如把IBM db2体系换成hp + oracle体系。开源的那些PostgresQL和MySQL这些,也差不多是同一个时代成长起来的。互联网早期可以容忍不带事务的 MySQL,因为当时所有人都还不成熟,甚至事务这个概念也还没有被市场普遍接受。桌面软件和手机的复杂化又养起来一个sqlite,也是后来慢慢就支持了事务。现在想要出头,最好的办法就是找一个新兴行业,去定义这个行业的数据库应该是怎么样的,然后和行业一同成长。
#9 Re: 异步事务处理
Transaction 绝对可靠。并发不会有冲突。因为只能一个线程写。
Storage system 是LMDB,这是个广泛应用的KV存儲,历史有十几年以上了,用户多如牛毛。
Datalevin 的ACID是由LMDB保证的,Datalevin transaction 与LMDB transaction 一一对应。LMDB用MVCC实现ACID。具体可以看看他在CMU的talk。
LMDB的作者Howard Chu有点大嘴,不符合白人对华裔老实不说话的成见,所以不受待见,但技术上没有什么问题,LMDB是久经考验的了。
Storage system 是LMDB,这是个广泛应用的KV存儲,历史有十几年以上了,用户多如牛毛。
Datalevin 的ACID是由LMDB保证的,Datalevin transaction 与LMDB transaction 一一对应。LMDB用MVCC实现ACID。具体可以看看他在CMU的talk。
LMDB的作者Howard Chu有点大嘴,不符合白人对华裔老实不说话的成见,所以不受待见,但技术上没有什么问题,LMDB是久经考验的了。
wdong 写了: 2025年 2月 15日 09:53 如果要用这个数据库,我最关心的是transaction可不可靠。并发的时候会不会有冲突。我比较想看你写这方面的内容。
我导师总爱说,一个storage system从开始到稳定要差不多10年时间。很多bug都要慢慢从实践中暴露出来的。这也是为什么数据库新品出头很难。
我现在做的系统,用redis做锁,kafka接journal,然后真正用的数据对象存在s3上。因为被锁的对象是inference context平时最好就是在内存里减少I/O。如果机器A锁着对象,机器B要用,先发消息给A要求其解锁,然后把内容存到s3上,然后B再加锁读进来。但是我这套体系眼前显然没法做到ACID。如果并发多了肯定会有各种数据不一致。如果真要精雕细琢会非常麻烦。要么就不要分布式了直接连一个postgresQL,也可以。其实postgresQL的性能足够我发财了。发不了财主要是自己的问题。
上次由 hci 在 2025年 2月 15日 12:36 修改。
原因: 未提供修改原因
原因: 未提供修改原因