LeviDB項目終結與Benchmark羅生門

初生牛犢不怕虎, 可能聽起來是褒義詞, 說的是新人無所畏懼, 做事不墨守成規, 往往能有意想不到的成績. 但Ta更可能因為缺乏很多必要的基礎與資源而以失敗告終. 我是深深體會到了這一點. 5個月前開個腦洞, 以為這很革命, 那也很革命. 2個月前被指出一堆漏洞, 修修補補之後, 覺得這也沒毛病, 那也沒毛病. 最近一bench, 卧槽, 我要reshape storage產業了?

在我的電腦上, benchmark畫風是這樣的, 我也沒必要編(相信我)

吊打RocksDB N倍的節奏??? 黑人問號臉??? 測試方法可見上一篇專欄文章, 項目可見JimChengLin/levi-db 寫入速度是RocksDB的3-4倍, 讀取速度是8-9倍, 順序刷盤速度相當. (看到這裡並且疑惑的朋友, 你們能幫測下速度嗎?)

然後有一些熱心朋友願意用伺服器幫我測試, 由於我用了CXX14, 很多環境都沒有, 我也不好意思讓他們改動公司的環境. 最後有位華為的朋友, 用Ta的伺服器幫我測試了. 結果卻是這樣的,

./build/levidb8nlevidb_write_bench took 3297 millisecondsnrocksdb_write_bench took 3056 millisecondsnlevidb_read_bench took 1675 millisecondsnrocksdb_read_bench took 1053 millisecondsnlevidb scan 116151215nlevidb_scan_bench took 979 millisecondsnrocksdb scan 116151215nrocksdb_scan_bench took 423 millisecondsnlevidb_write_bench took 3137 millisecondsnrocksdb_write_bench took 3257 millisecondsnlevidb_read_bench took 1696 millisecondsnrocksdb_read_bench took 888 millisecondsnlevidb scan 116151215nlevidb_scan_bench took 853 millisecondsnrocksdb scan 116151215nrocksdb_scan_bench took 460 millisecondsnlevidb_write_bench took 3109 millisecondsnrocksdb_write_bench took 3135 millisecondsnlevidb_read_bench took 1746 millisecondsnrocksdb_read_bench took 935 millisecondsnlevidb scan 116151215nlevidb_scan_bench took 991 millisecondsnrocksdb scan 116151215nrocksdb_scan_bench took 442 millisecondsndone.n

伺服器詳細配置我不知道, levidb反過來又被吊打了. 第一次有了因吹斯聽的主意, 然而為什麼會變成這樣? 這告訴了我一個很嚴酷的事實, levidb並非最優, 甚至只可能在我的機器上表現得不錯. 我沒有足夠的機器去測試不同的場景, 以至於我就像盲人摸象一樣, 東看看西看看, 寫了5個月(應該改動了N萬行代碼)... 一個工業化的產品, 沒有足夠的人力來達成一個團隊去優化與填坑, 那就是異想天開...

我現在腦海里浮現的場景就是<無間道>, "給我一個機會, 我想做個好人". 我覺得我過去的言行很可笑, 做了很多錯誤的決定. 我還有再讀書的機會, 我想我做人應該要再謙卑, 平和點, 然後腳踏實地多學習一些有用的知識, 而不是看些莫名其妙的上古論文, 天天想著reshape什麼鬼的. 我知道知乎上有很多像我一樣的人, 往往有個好點子或者有些小聰明. 我只想說不可能的, 依靠這些小道成功是不可能的.

我說我一直看不起前端畫按鈕和CRUD, 我自己又做出了什麼呢? 我要是在工作的時候專註寫iOS, 怎麼也會有些積累吧. 不說了, 真雞兒丟人. 本專欄也正式終結. 希望各位引以為戒! 腳踏實地不丟人, 像我一樣想著一步登天才是!