數(shù)據(jù)趣文：孫悟空無姓無名的時候，閻王生死簿是怎么寫的呢？

本文轉(zhuǎn)自知乎的同名問答題。題主的問題如下：

今天復習西游記的時候，突然想起來的一個問題。

孫悟空在碰到菩提祖師之前，閻王那里是怎么記載陽壽的呢？

猴子甲，乙，丙？西游記里是否有關于這個問題的記載呢？或者別的傳說里呢？

大數(shù)據(jù)透視《西游記》之妖怪分布

數(shù)據(jù)論《西游記》關系網(wǎng)：豬八戒最主動喜歡別人

下面是知乎網(wǎng)友大海（一位程序員）的回復，我們已征得轉(zhuǎn)載許可。若再次轉(zhuǎn)載，請自行征詢許可。

這個問題讓我對地獄數(shù)據(jù)庫系統(tǒng)（Hell-DBMS )進行了幾點小思考，開個腦洞。

1、生死薄技術上如何實現(xiàn)？廣大生靈在生死薄中的唯一標記是什么？陰間數(shù)據(jù)庫是什么樣一個數(shù)據(jù)庫？

首先，地獄必須有數(shù)據(jù)庫，數(shù)據(jù)量太大了

每個生靈都要有記錄，且必須是實時記錄，要進行數(shù)據(jù)分析。想像一下各種生靈，萬物有靈，大大小小，連螻蟻飛蛾也是命，從單細胞到現(xiàn)代社會的數(shù)據(jù)應該有多大。

數(shù)據(jù)庫的話每個生靈就要有唯一標記。

實名反對說是名字主鍵的，這是基本知識，名字重名怎么辦，數(shù)據(jù)庫原理請重修。

實名反對說是IP地址標記的，IPV4很快就用光的好不好；IPV6貌似在生物歷史長河中也是不夠的，朝生暮死都是生靈，這么多年過去了，這數(shù)據(jù)積累。

把自動生成的唯一ID當主鍵相對還靠譜，但位數(shù)必須相當長，數(shù)據(jù)庫得特別設計，如此大數(shù)據(jù)至少要谷歌技術支持，也許叫地獄歌，SQL -SERVER之類的技術根本頂不住。

搞Hell-DBMS請先看下大技術

• Hoogle File System
• Hoogle Bigtable
• Hoogle MapReduce

對了，《開源海量數(shù)據(jù)庫技術在陰間生死管理系統(tǒng)中的研究與實踐》應該獲得天庭科技進步特等獎的。

其次，查詢效率必須高

查詢效率低的話，閻王還得點支煙等半天結果么，經(jīng)常有上級官員過來查數(shù)據(jù)，玉皇啊，如來啊，即使是阿難、迦葉來也是惹不起的人，用戶不滿意，KPI不行、績效差閻王官位不穩(wěn)的。

業(yè)務量這么大，每天至少插入數(shù)億條新記錄，刪除數(shù)億條記錄，所有善惡狀態(tài)數(shù)據(jù)都要實時記錄，想想要接多少善惡傳感器，信道沖突肯定很難解決，好事壞事用WIFI還是ZIGBEE傳的不清楚，說不定某米會推出家庭善惡智能數(shù)據(jù)處理中心。

生靈死掉之后還要迅速進行大數(shù)據(jù)分析，判定死人到底應該進幾層地獄。數(shù)據(jù)分析慢了奈何橋都要排隊，用戶差評有木有！數(shù)據(jù)粒度非常非常細，死亡時間三更五更都不能差，下了地獄打多少下鐵棍都要精確計算，況且還會有許多異常發(fā)生，有時候要回滾，有可能不小心操作錯了（死而復生應該就是地府回滾，詳細請見《聊齋志異》[1])；有時候要災難恢復，比如孫猴子搗亂引起的災難性數(shù)據(jù)損失；比如用戶投訴問題，憑什么猴子要短命？這種問題只有孫猴子問得出，不僅問得出還直接上門責問，地府的安保工作真的要加強。

對了，像悟空這種異常用戶，Sa恨不得一刪了之有木有？（不懂Sa的IT人士請自行面壁，admin也算sa）

再次，必須能應對瞬時并發(fā)高峰數(shù)據(jù)

戰(zhàn)爭來了，成千上萬的人陣亡；瘟疫了，成千上萬人逝去；滅鼠了，幾萬幾十萬老鼠完蛋；飛機撒農(nóng)藥了，多少修行不夠的小精靈批量完蛋。

有生靈死亡必須要登記并把流程向前推進，這是典型的移動應用，無數(shù)的勾魂小鬼在短時間內(nèi)飛速趕到現(xiàn)場，管它是掃二維碼還是近場通訊技術NFC，反正無數(shù)小鬼同時用移動客戶端向Hell-DBMS系統(tǒng)上傳數(shù)據(jù)，App必須友好，后臺必須能頂住，不能學12307-1總是掉鏈子，12307-1掉了鏈子還能罵它：“去死！Go to Hell!”，Hell-DBMS可怎么罵才好。所以呢：

關鍵時刻，服務器不能卡住，數(shù)據(jù)庫性不能下降，生死薄必須實時更新。

最后，必須有大數(shù)據(jù)分析和預測技術

陰間有諦聽，可以通過”聽“，得到過去數(shù)據(jù)和未來的數(shù)據(jù)，這明顯是大數(shù)據(jù)和云結合的杰作。為什么是聽呢？因為陰間數(shù)據(jù)庫已經(jīng)把數(shù)據(jù)語音化了，用定向波束直接送到諦聽耳邊，電磁監(jiān)聽根本沒有效果，幾乎不可能泄密。定向波束的技術在加大功率后可同時用于在陰間跳廣場舞的某些亡靈們。

2、孫猴子在陰間里刪除數(shù)據(jù)，怎么刪除的？后來如何？

結論1： 猴子要刪除數(shù)據(jù)，應該是從界面刪除的，沒什么高技術，純粹的社會工程而已。

巨型數(shù)據(jù)庫，大數(shù)據(jù)數(shù)據(jù)庫一定是分解得比較細的，刪除的話至少是多表級聯(lián)刪除，直接從主表DELETE 未免要引發(fā)異常，再說孫猴子不是計算機專業(yè)的，應該是用金箍棒頂著小鬼的頂梁門，脅迫他用超級用戶進去，選擇界面的刪除功能搞定的。

我猜陰間數(shù)據(jù)庫刪除要左右各一個小鬼，持閻王發(fā)的優(yōu)盾，同時輸入口令。

孫猴子反正克隆能力強，變出幾個分身分別逼住就能搞定。
這個BUG系統(tǒng)必須要改進。

所以這是正常刪除，刪除之后，輪回系統(tǒng)并沒有完全混亂，只影響了一部分數(shù)據(jù)。

即使給孫猴子開個CONSOLE，他也記不住命令，猴急猴急，抓耳撓腮，他最多會點點鼠標。

結論2：陰間數(shù)據(jù)庫有強勁的災難恢復功能

話說，猴子完全低估了程序員們的實力。海量數(shù)據(jù)庫都有強大的異地容災備份功能，數(shù)據(jù)應該是備在最安全的雷音寺（第三方），所有操作均有LOG。在西方以如來為首的專家團指導下（具體操作應該是負責安全保衛(wèi)的天王，成就歸于領導），數(shù)據(jù)迅速恢復，猴子們根本沒有得到永生，在西方如來團隊的支持下數(shù)據(jù)迅速恢復，猴子家族應該死還是死。

孫猴子自己么，雖然罪過不小，但是他會鬧，能力還強。為了和諧天庭管理層還是為他做了特殊標記，在數(shù)據(jù)庫里加上一個TAG，設定為神仙級，計算壽命但不設定界限，有異常情況直接發(fā)出系統(tǒng)警報，和 RuLai -SkyNet All-in System系統(tǒng)聯(lián)動，確保一方平安。

應 @王政 童鞋要求，必須放參考文獻：

0 、《Big Data Application Platform for Hell》[J] InHell Hell-SCI收錄
1、《論Paxos算法在陰間生死管理系統(tǒng)中的應用與優(yōu)化》[J] 陰間信息技術 玉帝元年 第7788卷 核刊
2、《論Consistent Hash在陰間生死管理系統(tǒng)云中的應用》[M]陰間信息技術 玉帝9527年 第125222 核刊
3、 《論超大規(guī)模稠密矩陣在陰間生死管理系統(tǒng)中的理論研究》[C] 信息技術陰間應用大會 9528
4、 《論孟婆湯在陰間生死管理系統(tǒng)庫存管理當中的管理流程》 [J] 陰間食品與營養(yǎng) VOL 2241554
5、《論牛頭馬面陰間勾人大隊的管理電子化》[J] 陰間數(shù)字化城管研究 VOL15486488789
6、《論天庭-西天-陰間點對點技術在陰間辦公自動化中的實現(xiàn)》 [J] 陰間實用軟件增刊。

End.

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。