这周抽空研究了一下Nathan的那篇CAP的blog# Java - 爪哇娇娃
p*3
1 楼
Immutable, pre-compute for query, 不知道为什么还有种加上idempotent的冲动.
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
感觉思路不错,很多地方好像太适合。
好像immutable是个大的原则,就像concurrent hashmap一下。以前是一个vector
clock然后merge, 现在打上个时间戳倒是immutable了,但是在business logic level
还是得merge啊,不是啥玩意打个time stamp就解决了,business level上conflict了
就是conflict了,要merge了还是得merge, Partition了以后不同的地方只能得到不同
的部分immutable的entry再merge,就不consistent了。
Available只是写,读操作没提啊。
batch level建立在hadoop上,也就是hadoop有啥CAP上的限制,这个System就有上限制
,这层都没提.
很好的思想是real time level + batch level,感觉还是稀里糊涂的
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
感觉思路不错,很多地方好像太适合。
好像immutable是个大的原则,就像concurrent hashmap一下。以前是一个vector
clock然后merge, 现在打上个时间戳倒是immutable了,但是在business logic level
还是得merge啊,不是啥玩意打个time stamp就解决了,business level上conflict了
就是conflict了,要merge了还是得merge, Partition了以后不同的地方只能得到不同
的部分immutable的entry再merge,就不consistent了。
Available只是写,读操作没提啊。
batch level建立在hadoop上,也就是hadoop有啥CAP上的限制,这个System就有上限制
,这层都没提.
很好的思想是real time level + batch level,感觉还是稀里糊涂的