幾萬年前，孫悟空的一次刪庫跑路...
話說幾萬年前，有一只猴子在大鬧地府刪庫跑路，導(dǎo)致地府幾百年沒緩過勁兒來......
在知乎上冒出這么一個問題：“孫悟空無姓無名的時候，閻王生死簿是怎么寫的呢？”
地獄數(shù)據(jù)庫系統(tǒng)到底是什么樣的？
來自知乎網(wǎng)友大海的回復(fù)：
https://www.zhihu.com/question/29775354/answer/45744415
這個問題讓我對地獄數(shù)據(jù)庫系統(tǒng)（Hell-DBMS )進(jìn)行了幾點(diǎn)小思考，開個腦洞。
首先，地獄必須有數(shù)據(jù)庫，數(shù)據(jù)量太大了。
每個生靈都要有記錄，且必須是實(shí)時記錄，要進(jìn)行數(shù)據(jù)分析。想象一下各種生靈，萬物有靈，大大小小，連螻蟻飛蛾也是命，從單細(xì)胞到現(xiàn)代社會的數(shù)據(jù)應(yīng)該有多大。
數(shù)據(jù)庫的話每個生靈就要有唯一標(biāo)記。實(shí)名反對說是名字主鍵的，這是基本知識，名字重名怎么辦，數(shù)據(jù)庫原理請重修。
實(shí)名反對說是 IP 地址標(biāo)記的，IPV4 很快就用光的好不好；IPV6 貌似在生物歷史長河中也是不夠的，朝生暮死都是生靈，這么多年過去了，這數(shù)據(jù)積累。
把自動生成的唯一 ID 當(dāng)主鍵相對還靠譜，但位數(shù)必須相當(dāng)長，數(shù)據(jù)庫得特別設(shè)計(jì)，如此大數(shù)據(jù)至少要谷歌技術(shù)支持，也許叫地獄歌，SQL-SERVER 之類的技術(shù)根本頂不住。
Hoogle File System
Hoogle Bigtable
Hoogle MapReduce
其次，查詢效率必須高。
查詢效率低的話，閻王還得點(diǎn)支煙等半天結(jié)果么，經(jīng)常有上級官員過來查數(shù)據(jù)，玉皇啊，如來啊，即使是阿難、迦葉來也是惹不起的人，用戶不滿意，KPI 不行、績效差閻王官位不穩(wěn)的。
業(yè)務(wù)量這么大，每天至少插入數(shù)億條新記錄，刪除數(shù)億條記錄，所有善惡狀態(tài)數(shù)據(jù)都要實(shí)時記錄，想想要接多少善惡傳感器，信道沖突肯定很難解決。
好事壞事用 Wi-Fi 還是 Zigbee 傳的不清楚，說不定某米會推出家庭善惡智能數(shù)據(jù)處理中心。
生靈死掉之后還要迅速進(jìn)行大數(shù)據(jù)分析，判定死人到底應(yīng)該進(jìn)幾層地獄。數(shù)據(jù)分析慢了奈何橋都要排隊(duì)，用戶差評有木有！
數(shù)據(jù)粒度非常非常細(xì)，死亡時間三更五更都不能差，下了地獄打多少下鐵棍都要精確計(jì)算，況且還會有許多異常發(fā)生，有時候要回滾，有可能不小心操作錯了（死而復(fù)生應(yīng)該就是地府回滾，詳細(xì)請見《聊齋志異》[1])。
有時候要災(zāi)難恢復(fù)，比如孫猴子搗亂引起的災(zāi)難性數(shù)據(jù)損失；比如用戶投訴問題，憑什么猴子要短命？
這種問題只有孫猴子問得出，不僅問得出還直接上門責(zé)問，地府的安保工作真的要加強(qiáng)。
對了，像悟空這種異常用戶，Sa 恨不得一刪了之有木有？（不懂 Sa 的 IT 人士請自行面壁，Admin 也算 Sa）
再次，必須能應(yīng)對瞬時并發(fā)高峰數(shù)據(jù)。
戰(zhàn)爭來了，成千上萬的人陣亡；瘟疫了，成千上萬人逝去；滅鼠了，幾萬幾十萬老鼠完蛋；飛機(jī)撒農(nóng)藥了，多少修行不夠的小精靈批量完蛋。
有生靈死亡必須要登記并把流程向前推進(jìn)，這是典型的移動應(yīng)用，無數(shù)的勾魂小鬼在短時間內(nèi)飛速趕到現(xiàn)場。
管它是掃二維碼還是近場通訊技術(shù) NFC，反正無數(shù)小鬼同時用移動客戶端向 Hell-DBMS 系統(tǒng)上傳數(shù)據(jù)，App 必須友好，后臺必須能頂住。
不能學(xué) 12307-1 總是掉鏈子，12307-1 掉了鏈子還能罵它：“去死！Go to Hell!”，Hell-DBMS 可怎么罵才好。
所以呢：關(guān)鍵時刻，服務(wù)器不能卡住，數(shù)據(jù)庫性能不能下降，生死薄必須實(shí)時更新。
最后，必須有大數(shù)據(jù)分析和預(yù)測技術(shù)。
陰間有諦聽，可以通過“聽”，得到過去數(shù)據(jù)和未來的數(shù)據(jù)，這明顯是大數(shù)據(jù)和云結(jié)合的杰作。
為什么是聽呢？因?yàn)殛庨g數(shù)據(jù)庫已經(jīng)把數(shù)據(jù)語音化了，用定向波束直接送到諦聽耳邊，電磁監(jiān)聽根本沒有效果，幾乎不可能泄密。定向波束的技術(shù)在加大功率后可同時用于在陰間跳廣場舞的某些亡靈們。
那么孫猴子在陰間里刪除數(shù)據(jù)，怎么刪除的？后來如何？
結(jié)論 1：猴子要刪除數(shù)據(jù)，應(yīng)該是從界面刪除的，沒什么高技術(shù)，純粹的社會工程而已。
巨型數(shù)據(jù)庫，大數(shù)據(jù)數(shù)據(jù)庫一定是分解得比較細(xì)的，刪除的話至少是多表級聯(lián)刪除，直接從主表 DELETE 未免要引發(fā)異常。
再說孫猴子不是計(jì)算機(jī)專業(yè)的，應(yīng)該是用金箍棒頂著小鬼的頂梁門，脅迫他用超級用戶進(jìn)去，選擇界面的刪除功能搞定的。
我猜陰間數(shù)據(jù)庫刪除要左右各一個小鬼，持閻王發(fā)的優(yōu)盾，同時輸入口令。
孫猴子反正克隆能力強(qiáng)，變出幾個分身分別逼住就能搞定。這個 Bug 系統(tǒng)必須要改進(jìn)。
所以這是正常刪除，刪除之后，輪回系統(tǒng)并沒有完全混亂，只影響了一部分?jǐn)?shù)據(jù)。
即使給孫猴子開個 CONSOLE，他也記不住命令，猴急猴急，抓耳撓腮，他最多會點(diǎn)點(diǎn)鼠標(biāo)。
結(jié)論 2：陰間數(shù)據(jù)庫有強(qiáng)勁的災(zāi)難恢復(fù)功能。
話說，猴子完全低估了程序員們的實(shí)力。海量數(shù)據(jù)庫都有強(qiáng)大的異地容災(zāi)備份功能，數(shù)據(jù)應(yīng)該是備在最安全的雷音寺（第三方），所有操作均有 LOG。
在西方以如來為首的專家團(tuán)指導(dǎo)下（具體操作應(yīng)該是負(fù)責(zé)安全保衛(wèi)的天王，成就歸于領(lǐng)導(dǎo)），數(shù)據(jù)迅速恢復(fù)，猴子們根本沒有得到永生，在西方如來團(tuán)隊(duì)的支持下數(shù)據(jù)迅速恢復(fù)，猴子家族應(yīng)該死還是死。
孫猴子自己么，雖然罪過不小，但是他會鬧，能力還強(qiáng)。為了和諧天庭管理層還是為他做了特殊標(biāo)記，在數(shù)據(jù)庫里加上一個 TAG，設(shè)定為神仙級，計(jì)算壽命但不設(shè)定界限，有異常情況直接發(fā)出系統(tǒng)警報，和 RuLai -SkyNet All-in System 系統(tǒng)聯(lián)動，確保一方平安。
參考文獻(xiàn)：
0 、《Big Data Application Platform for Hell》[J] InHell ?Hell-SCI收錄
1、《論P(yáng)axos算法在陰間生死管理系統(tǒng)中的應(yīng)用與優(yōu)化》[J] 陰間信息技術(shù) 玉帝元年 第7788卷 核刊
2、《論Consistent Hash在陰間生死管理系統(tǒng)云中的應(yīng)用》[M]陰間信息技術(shù) 玉帝9527年 第125222 核刊
3、 《論超大規(guī)模稠密矩陣在陰間生死管理系統(tǒng)中的理論研究》[C] 信息技術(shù)陰間應(yīng)用大會 9528
4、 《論孟婆湯在陰間生死管理系統(tǒng)庫存管理當(dāng)中的管理流程》 [J] 陰間食品與營養(yǎng) VOL 2241554
5、《論牛頭馬面陰間勾人大隊(duì)的管理電子化》[J] 陰間數(shù)字化城管研究 VOL15486488789
6、《論天庭-西天-陰間點(diǎn)對點(diǎn)技術(shù)在陰間辦公自動化中的實(shí)現(xiàn)》 [J] 陰間實(shí)用軟件增刊。
地獄數(shù)據(jù)庫是如何設(shè)計(jì)的？
https://www.zhihu.com/question/29775354/answer/287551487
關(guān)于孫悟空無姓無名的時候，閻王生死簿是怎么寫的呢？這個問題，當(dāng)然是 ID 呀，每個東西 New 出來就有個 ID，沒人用 Name 做主鍵的！
悟空道：“胡說！胡說！常言道：‘官差吏差，來人不差。’你快取生死簿子來我看！”十王聞言，即請上殿查看。
悟空執(zhí)著如意棒，徑登森羅殿上，正中間南面坐上。十王即命掌案的判官取出文簿來查。
那判官不敢怠慢，便到司房里，捧出五六簿文書并十類簿子，逐一查看。裸蟲、毛蟲、羽蟲、昆蟲、鱗介之屬，俱無他名。
又看到猴屬之類，原來這猴似人相，不入人名；似裸蟲，不居國界；似走獸，不伏麒麟管；似飛禽，不受鳳凰轄。
另有個簿子，悟空親自檢閱，直到那魂字一千三百五十號上，方注著孫悟空名字，乃天產(chǎn)石猴，該壽三百四十二歲，善終。
悟空道：“我也不記壽數(shù)幾何，且只消了名字便罷！取筆過來！”那判官慌忙捧筆，飽掭濃墨。悟空拿過簿子，把猴屬之類，但有名者，一概勾之！
閻王們只有硬 Copy，但是在硬 Copy 上更改，也會生效，所以應(yīng)該是每天晚上跑 Batch 同步。
你看，原文有告訴你數(shù)據(jù)庫設(shè)計(jì)了，首先他是分類型的，我估計(jì)可能是按照比如生物學(xué)那種樹狀分類，所以我們可以認(rèn)為，生死簿應(yīng)該是樹狀的 NoSQL 存儲，或者實(shí)現(xiàn)了樹狀表，子表的 RMDB。
你仔細(xì)看，孫悟空屬于魂字1350 號，這個魂字，一定是 Namespace 了，然后是自增主鍵，主鍵上標(biāo)有自然信息，名字，類型，年齡，所以，這個主鍵是記錄創(chuàng)建的時候給的，名字確定了，再補(bǔ)而已。
而且，你看孫悟空和其他猴子不在一個猴屬之中，更確定了生死薄是樹狀的存儲結(jié)構(gòu)。
因?yàn)橹麈I記錄上有死亡時間，看起來是每天晚上跑個 Batch，把當(dāng)前時間-出生時間=死亡時間的數(shù)據(jù)篩選出來，送去執(zhí)行部門干掉。觸發(fā)器太麻煩，跑 Batch 拉個報表給黑白無常就可以了。
這個系統(tǒng)有問題，更新的 Batch 不看數(shù)據(jù)是否有篡改就直接更新，這說明數(shù)據(jù)安全性沒有考慮，我給地府推薦 OWASP 項(xiàng)目，用來提高安全性。
我曾和幾個架構(gòu)師聊天聊到這個問題，大家覺得這個主意很有趣，發(fā)起了《我?guī)烷愅踉O(shè)計(jì)表》主題活動，來鍛（qiong）煉（ji）設(shè)（wu）計(jì)（liao）能（xia）力（che）！
我匯總了下 ER 高層設(shè)計(jì)，如下圖：
主要來說，首先有一個字典表，規(guī)定了生物分類（CATE），考慮到每種分類的 UUID 類型應(yīng)該不同。
比如孫悟空屬于的魂字，看上去東西就不多，很可能就是一個 int id，但是如果是蟲子類，東西可能太多，一個 long 都不一定能裝下，可能需要帶編碼的 vchar。
所以給每個 CATE ID 定義一種自增編碼方式，以兼容將來萬一出現(xiàn)機(jī)器人也要死，這樣地府的系統(tǒng)不需要重做。
給予每種 ID 一個表明后綴，這樣可以分表，不用把每種都放在同一個表里。
對于 Transaction 表，每種屬性都有兩個表，一個是已死表，作為歷史數(shù)據(jù)備查；一個是存活表，這樣做到了讀寫分離，增強(qiáng)性能。
每天新增的生物，根據(jù)其自己的 UID 插入表，主鍵寫入速度有保證，這點(diǎn)上，考慮到地府不負(fù)責(zé)出生，我們提供一個 AMQP 高性能 Message Q 來給出生部門，可能是送子觀音來寫入，當(dāng)然也可以提供 Restful API。
同時，每天晚上跑個 Batch，遍歷存活表，將死期是今天的數(shù)據(jù)篩選出來，放入 Dead 表，同時生成報表，交給索命部門，也就是黑白無常做實(shí)際殺死工作。
所以架構(gòu)圖也出來了：
看到這里，我不得不說，程序員們是真的皮....難道不怕被閻王喊去面向地獄編程？
真的有程序員做出了完整的地府后臺管理系統(tǒng)
這不，前段時間，就有這么一個段子火了。某位程序員日有所思，夜有所夢，終于有一天夢見自己見閻王爺了。閻王爺還叫他給生死簿做個后臺管理系統(tǒng)。
還真有程序員把地府后臺管理系統(tǒng)原型做出來了，目前這個項(xiàng)目已經(jīng)在開發(fā)中...
https://github.com/canxin0523/thesixsectorTeam
http://kzgfmo.axshare.cn
用戶登錄：為了避免幾百年前被猴子刪庫這樣的悲劇再度重演，有編制的地府工作人員必須使用賬號密碼登錄才能訪問管理系統(tǒng)。
正文結(jié)束