新奇的編程方式,改變你對(duì)編碼的認(rèn)知默認(rèn)
并發(fā)
示例語言:ANI, Plaid
有些編程語言是默認(rèn)情況下并發(fā)的誓斥,也就是說只洒,每行代碼都是并行執(zhí)行的。
例如劳坑,假設(shè)你寫了三行代碼毕谴,A,B和C:
A;
B;
C;
在大多數(shù)編程語言中距芬,A先執(zhí)行涝开,然后執(zhí)行B,最后執(zhí)行C框仔。在像ANI這樣的語言中舀武,A,B和C都將同時(shí)執(zhí)行离斩。
ANI中代碼行之間的控制流或排序银舱,僅僅是代碼行之間顯式依賴關(guān)系的副作用。例如跛梗,如果B引用了A中定義的變量寻馏,則A和C將同時(shí)執(zhí)行,而B只會(huì)在A完成后執(zhí)行核偿。
以下是ANI中的“Hello World”示例:
"Hello, World!" ->std.out
"Goodbye, World!" ->std.out
這兩行代碼并行執(zhí)行诚欠,因此它們可以在控制臺(tái)中以任何順序結(jié)束。
現(xiàn)實(shí)中發(fā)生是有順序的宪祥,如何控制聂薪? 通過加鎖控制
如:
s = [string\];
"Hello, World!" ->s;
\s ->std.out;
第一行聲明一個(gè)“鎖存(latch)”(鎖存器有點(diǎn)像變量),調(diào)用 s它包含一個(gè)字符串; 第二行將文本賦值 "Hello, World!"給s; 第三行“解鎖” s并將內(nèi)容發(fā)送給std.out蝗羊。在這里藏澳,您可以看到ANI的隱式程序排序:由于每行都依賴于前一行,因此此代碼將按寫入的順序執(zhí)行耀找。
Apache Ignite 2.4.0 發(fā)布翔悠,內(nèi)存數(shù)據(jù)組織平臺(tái)
https://ignite.apache.org/download.cgi
memory-centric distributed database, caching, and processing platform
for transactional, analytical, and streaming workloads,
delivering in-memory speeds at petabyte scale
牛逼的不行了,無所不能
Is Ignite an in-memory database?
Yes
Is Ignite an in-memory data grid?
Yes
Is Ignite a distributed cache?
Yes
Is Ignite a distributed database?
Yes
Is Ignite an SQL database?
Not full
Is Ignite a disk or memory-only storage?
Both
Is Ignite a NoSQL database?
Not exactly
Is Ignite a transactional database?
Not fully
Is Ignite a multi-model database?
Yes
Is Ignite a key-value store?
Yes
功能多野芒,nosql總線蓄愁,內(nèi)存計(jì)算是個(gè)框什么都可以往里裝。hadoop狞悲,spark解決了大數(shù)據(jù)存儲(chǔ)問題撮抓,但沒解決大數(shù)據(jù)計(jì)算痛點(diǎn),多功能分布式內(nèi)存計(jì)算是趨勢(shì)摇锋。從官網(wǎng)的下圖可以看出ignite有數(shù)據(jù)網(wǎng)格丹拯,計(jì)算網(wǎng)格站超,服務(wù)網(wǎng)格,sql網(wǎng)格乖酬,數(shù)據(jù)結(jié)構(gòu)死相,流計(jì)算,文件系統(tǒng)咬像,高級(jí)集群等模塊算撮,都是放在內(nèi)存操作,我想主要追求的是能快速分析處理數(shù)據(jù)县昂,實(shí)時(shí)內(nèi)存應(yīng)用肮柜,不像hadoop基于硬盤文件,發(fā)個(gè)命令下去七芭,等喝完茶才有結(jié)果素挽。
對(duì)于結(jié)構(gòu)化數(shù)據(jù)處理,MB級(jí)用excel,pandas,sqlite,access,GB級(jí)用mysql,oracle,sql server,postgresql狸驳,TB級(jí)用mongodb,greenplum缩赛,PB級(jí)用hadoop,spark,EB級(jí)自己想辦法耙箍。數(shù)據(jù)量越大操作起來越費(fèi)勁越費(fèi)時(shí),只適合事后慢慢分析酥馍,從spark開始內(nèi)存計(jì)算就是為了解決太費(fèi)時(shí)問題辩昆,Apache Beam也延續(xù)了這種趨勢(shì),ignite主要內(nèi)存功能強(qiáng)大旨袒,更方便適用汁针,用內(nèi)存來聚合數(shù)據(jù)源,處理數(shù)據(jù)砚尽。隨著時(shí)間的推移施无,移動(dòng)互聯(lián)網(wǎng)物聯(lián)網(wǎng)的使用,數(shù)據(jù)會(huì)成指數(shù)增長(zhǎng)必孤,不上大內(nèi)存根本跑不快猾骡,服務(wù)器內(nèi)存價(jià)格只會(huì)越來越便宜,內(nèi)存計(jì)算只會(huì)越來越流行敷搪。
特性介紹
https://www.zybuluo.com/liyuj/note/293596
超高性能鍵值存儲(chǔ)數(shù)據(jù)庫 Anna
Anna 是伯克利 RISE 實(shí)驗(yàn)室推出的鍵值存儲(chǔ)數(shù)據(jù)庫兴想,也是一個(gè)具備驚人的存取速度、超強(qiáng)的伸縮性和優(yōu)秀的一致性的 KVS赡勘。
Anna 的性能和伸縮性主要?dú)w功于它的完全無協(xié)調(diào)機(jī)制嫂便,節(jié)點(diǎn)工作進(jìn)程有 90% 的工作負(fù)載是在處理請(qǐng)求,而其他大部分系統(tǒng)(如 Masstree 和英特爾的 TBB)只有不到 10% 的時(shí)間在處理請(qǐng)求闸与,它們其余的 90% 時(shí)間花在了等待協(xié)調(diào)上毙替。不僅如此曼振,其他系統(tǒng)因?yàn)槭褂昧斯蚕韮?nèi)存,還會(huì)出現(xiàn)處理器緩存擊穿問題蔚龙。
Anna 不僅速度快冰评,在一致性方面也達(dá)到了很高的水準(zhǔn)。多年前木羹,他們發(fā)布的事務(wù)協(xié)議 HATs 就已表明甲雅,無協(xié)調(diào)的分布式一致性和事務(wù)隔離性存在很大的提升空間,包括級(jí)聯(lián)一致性和讀提交事務(wù)級(jí)別坑填。Anna 將 Bloom 的單格子組合設(shè)計(jì)模式移植到了 C++ 中抛人,是第一個(gè)實(shí)現(xiàn)了上述所有級(jí)別一致性的系統(tǒng)。當(dāng)然脐瑰,也是因?yàn)樵O(shè)計(jì)上的簡(jiǎn)潔妖枚,才能達(dá)到如此快的速度。
Bedrock
基于 Anna 開發(fā)一個(gè)新的擴(kuò)展系統(tǒng)苍在,叫作 Bedrock绝页。Bedrock 運(yùn)行在云端,提供了無需人工干預(yù)寂恬、低成本的鍵值存儲(chǔ)方案续誉,而且是開源的。
無協(xié)調(diào) actor 模型的伸縮性
在無協(xié)調(diào) actor 模型中初肉,每個(gè) actor 對(duì)應(yīng)一個(gè)線程酷鸦,對(duì)任何一個(gè)共享狀態(tài)都有自己的一份私有拷貝,并通過異步廣播將更新通知給其他 actor牙咏。在多核服務(wù)器上臼隔,這種模型比傳統(tǒng)的共享內(nèi)存模型的性能要高出一個(gè)數(shù)量級(jí)。
一個(gè)對(duì)比實(shí)驗(yàn)妄壶,將 Anna 與其他基于共享內(nèi)存的 TBB摔握、Masstree 和自己實(shí)現(xiàn)的一個(gè)鍵值存儲(chǔ)系統(tǒng)(姑且把它叫作“Ideal”)進(jìn)行了對(duì)比。他們?cè)?AWS 的 m4.16xlarge 實(shí)例上運(yùn)行實(shí)驗(yàn)盯拱,每個(gè)實(shí)例配備了 32 核的 CPU盒发。實(shí)驗(yàn)中使用了 1 百萬個(gè)鍵值對(duì),鍵的大小為 8 字節(jié)狡逢,值的大小為 1KB宁舰。在實(shí)驗(yàn)過程中,他們基于 zipfian 分布和各種系數(shù)生成不同的壓力負(fù)載奢浑,模擬不同層次的沖突蛮艰。
在第一次實(shí)驗(yàn)中,他們對(duì)比了 Anna 與 TBB雀彼、Masstree 和 Ideal 在單臺(tái)服務(wù)器上的吞吐量壤蚜。他們逐漸增加線程數(shù)量即寡,直到達(dá)到服務(wù)器 CPU 核數(shù)的上限,并觀察它們的吞吐量袜刷。
在高并發(fā)情況下聪富,線程數(shù)與吞吐量的變化關(guān)系,其中 zipf 系數(shù)為 4
在高并發(fā)情況下著蟹,CPU 時(shí)間的使用情況墩蔓。CPU 時(shí)間被分為 5 類:處理請(qǐng)求(RH)、原子指令(AI)萧豆、合并格子(LM)奸披、廣播(M)和其他。最右邊一欄是 L1 緩存擊穿數(shù)量(CM)涮雷。
從圖中可以看出阵面,在這樣的負(fù)載壓力下,TBB 和 Masstree 幾乎失去了并行能力洪鸭。因?yàn)榇蟛糠质歉虏僮餮ⅲ槍?duì)同一個(gè)鍵值的并行更新操作會(huì)被串行化,它們需要同步機(jī)制來防止多個(gè)線程同時(shí)更新同一個(gè)鍵值卿嘲。因此颂斜,隨著線程數(shù)量的增加,它們性能也只能趨于平緩拾枣。Ideal 雖然比 TBB 和 Masstree 的性能高出 6 倍,但相比 Anna盒让,還是差了很多梅肤。盡管它沒有使用同步機(jī)制,但在多個(gè)線程修改共享內(nèi)存地址時(shí)邑茄,仍然存在緩存一致性方面的開銷姨蝴。
相反,在 Anna 中肺缕,更新操作是針對(duì)本地狀態(tài)進(jìn)行的左医,不需要進(jìn)行同步,并定時(shí)通過廣播進(jìn)行變更交換同木。在高并發(fā)情況下浮梢,盡管它的性能仍然受限于其復(fù)制系數(shù),但比基于共享內(nèi)存的系統(tǒng)要好很多彤路。Anna 有 90% 的 CPU 時(shí)間用于處理請(qǐng)求秕硝,花在其他方面的時(shí)間則很少≈拮穑可見远豺,Anna 的無協(xié)調(diào) actor 模型解決了鍵值存儲(chǔ)系統(tǒng)在多核環(huán)境里的伸縮性難題奈偏。
Ref:
https://www.oschina.net/news/94083/six-programming-paradigms-that-will-change-how?from=20180318
https://www.zhihu.com/question/33982387/answer/152497769
https://mp.weixin.qq.com/s/3WmGpZkEuSz-ox_2CPCsqg