碎碎唸

我看服貿

幫大家用自由經濟的角度,來看看新光三越在中國被坑殺的例子好了~

我非常不喜歡大家用「台商在中國被坑殺」這個理由,來當做反服貿的理由,因為商人天性就是計算風險而不是閃避風險的,商人是在種種的計算下,在有相對應的報酬下,自然會去冒險,所以用「怕被坑殺」這理由去跟商人講為什麼要反服貿,這是自己講話給自己聽,而不是跟對方在對話。

世界不是繞著懦夫轉的,而是繞著喜愛風險的創業家在走的,若少了冒險的風氣,那台灣的未來就危險了。

想當商人的我,當然是(從一萬英尺高的概念上看下來)是支持自由貿易、支持西進的,但在「現實」上我仍是「反服貿的」。

為什麼呢?因為在細節的實作上,政府實在是談的太糟了,台商在中國會被坑殺是為什麼?是因為「中國法規的不穩定」及「中共政策的不穩定」所造成的,今天中國要吸引外資就開放產業,等那天反抗企業的母國,就用政府的力量在行政司法上去對抗民間企業。 但企業是否是真的無力去跟中共對抗嗎?錯,在國際上仍有商務仲裁的機制、有 WTO 的爭議處理機制,有國家間互相角力的機制,可以去保護企業。

但在「服貿」協議中,馬英九完全的出賣台灣,明知道中共會用台灣不是國家的方式否決掉上面的幾個機制,那麼,在談判時為什麼沒有把這問題拿出來討論?即使中共不承認台灣是個國家,但仍是可以在條約中寫入協商條款、保護台灣企業的權益。

而不是如今天寫的「服貿內的條款若要修改只能放寬」,這一條一寫下去,台灣政府跟中共談判的空間全沒有了,那天要打貿易戰也打不起來,因為台灣自己就把自己的條約修改空間、談判空間限死了。

這樣的「服貿」能說政府有用心去談而不是賣台嗎?能不反嗎?

ref: 北京新光投資130億 吳家擬認賠出場

典範

這篇寫的真好,在國外渡過我二十歲的歲月,三十歲回到台灣來,發覺,台灣人最缺的就是一個典範跟一個夢想。

台灣的年輕人活的很沒未來,常做一些很短期的事,像是一年換一次手機,一年就出國一次去玩,工作收入有個四五萬一個月好像就很滿足了。

這些,我不會去怪這些年輕人,因為台灣這個社會讓年輕人沒有了夢想,把手機的錢存下來又怎樣,什麼都還是買不起,買車買房都無望,還是今朝有酒今朝醉吧,比別人多努力兩成又怎樣,生活又不會過比較好,反而還比較慘。

我在美國單身的歲月裡,一年可以存下四成的薪水,工作了兩三年後,存下的錢在考慮要怎麼花,看是現金買部BMW M3圓夢、買個公寓省下房租、或投資做生意中做選擇,生活是一日比一日好。

回來台灣後發現,台灣年輕人最缺的,其實是生命上的導師、一個可以遵從的典範,一個長你十多歲,一個你一直努力,就可以達到他的境界的目標。

Ronald 是1.5代移民的香港人 30 歲幹到了 Director of Engineering ,Mak是日裔第一代移民 X-Window 中有他的名字,雖然英語不是他的母語,還是帶了 80 人,後來還跑去做了 Sims 3 ,Maidu 聯合國科學家的兒子,19歲大學畢業,30歲初頭時在兩年內在印度開了家公司,在舊金山生了小孩,還在 U of Chicago 拿 MBA,Stu 超級技術強人,幫我開了一輩子的眼界。

這些人是我工作的同事,長我五到十歲,讓我知道,只要有目標,忍耐得了寂默苦修,有一天我也可以達到他們的境界。

但是台灣的年輕人就沒什麼典範可以學習了,電視雜誌上報導的,多是六七十歲的大老,要不然就是官二代富二代;看這些人的故事,怎麼看都沒什麼好學的,反正再怎麼努力,你爺爺也不會變成姓蔣的,你無法去複製他們的成功經驗。

台灣因為市場結構問題,要打入既有商業體系的,都只能靠「關係」,我這幾年下來,碰上創業成功的,多是做吃的,因為只有做吃的不用靠關係可以直接面對市場。或許就是這樣吧,年輕人就只能學著當個好寶寶,等著接收長輩的蔽蔭。

所以看到陳為廷和林飛帆能幫年輕人立個典範,告訴大家,年輕人還是能改變社會,讓我非常的感動。

蔡坤霖

以下是我的立場。

其實這樣寫很奇怪,為什麼會有人關心我的立場?不過既然臉書是私媒體,我不是公眾人物,也沒領稿費,那就當書寫為自瀆吧。

我首先要懺悔:從2012以後,我就是個心存逃避的失敗主義者。馬英九上台,我認為,台灣人民已經做了選擇,那就是統一。

既然要統一了,那我心態上可以提早做準備。我尊重台灣的民意,因此也沒想要多反映什麼,只想,啊,以後就當個共產黨治下的民眾吧。反正,我喜歡的東西是類型,如武俠、玄幻之類古代背景,沒有要談什麼高深的東西。

但我內心其實相信,台灣不統一比較好。台灣之所以重要是因為它不是中國的一份子,如果它是中國的一份子,那台灣就不特別了。

這句話很難簡單說明,但從對自己的經濟天賦失望之後,我就轉而將熱情投諸在不能量化的事物上。台灣保有獨立的主權,等於是為華人的政治實踐多了一所學校,畢竟華人作為地球上最龐大的民族,只有這個小小的島是民主的,只有這個小小的島,能夠提供集權之外的另一種可能。

想像需要典範,對現在以及未來的華人而言,台灣就可以是那個典範,前提是台灣值得成為典範。

既然台灣不願意成為這個特例,想要跟中國其他數十個省份一樣,那我接受台灣人民的選擇,所以我不再思考這件事情,只想著如果可以掌握好中國古代背景的類型電影,未來在華人市場應該都有飯吃。

政治與文化的多樣性,台灣可以為華人保存這一小小的孤島。可不可以把台灣像是太平洋上物種歧異度高的一個小島一樣保存下來,進行一點政治體制上的一點研究呢?我在選舉前是這樣想的。

這裡要先說兩點,我認為2012馬英九上台等於統一,和我認為統一之後台灣主體性會消失,並且成為文化上、思想上毫無特色的一個省份,這兩點是近乎宗教的信念,不在此論證由何而來。信者自信,疑者自疑,到處找找有很多說法、很多推測,但尚未發生,所以我沒有證據。

在我心中,台灣如同雅典,雖小,卻體現著罕見而且影響深遠的故事。如同余英時所說:「台灣雖小,但其實它大極了。」

等到未來某個世代的華人決定推翻共產黨時,他們知道他們可以看向哪裡。他們有機會知道,所謂華人不需要民主,是一個被兩千三百萬人證偽的謊言。

然後台灣的民意放棄這件事情了,在2012年,689萬票這樣說。那就算了吧,何必思考呢?再說一次,這是我主觀如同宗教般的解讀,沒有任何依據。

所以大埔,文林苑,我認為都更雖然執行粗糙,但有其必要性;核四,雖然粗糙,但確實能減碳,也高效率,很多議題我都覺得算了。幹麼想這些呢?有那麼多人不在乎政府違憲(是的,我先天上就覺得職業學生出身的馬英九從來沒在乎過憲法),反正遲早就要習慣沒有憲法的生活了不是嗎?

到時候那些可以扭轉歷史的40萬人再來後悔吧,我從來沒投過馬英九,我可沒什麼好後悔,是被拖下水的。

失敗主義、犬儒主義,自作聰明,未戰先退。我很懦弱。我不覺得我可以也必須抵抗689萬票,也不覺得有可能對抗13億。怎麼可能呢?世界上人口最多,最霸道,離我們最近的國家。

吐口水就淹死我們了,拔根毛就脹死我們了。想想怎麼過得好吧,不要太激憤,不然,很可能到時候統一時,會死一票人。

改朝換代,不都要血流成河?我們還看得少嗎?

服貿只是歷史巨輪下的一個小齒輪。之前很多事情,台灣人不吭聲,是的,包括鄭秀玲教授的那些文字,一點屁聲都沒激起,台灣人沒有資格擁有民主,那就順勢而行吧。之後很多事情,也不會吭聲。

到時候,就閉嘴,蘇軾不是說過了嗎?

「夫持法太急者,其鋒不可犯;而其勢未可乘。」

我是個聰明人,蒙田是我的偶像。蘇格拉底拿來意淫就好,不用仿效。

但是我看到,陳為廷和林飛帆,居然能在馬王政爭時攻下立法院!

我想都沒想過!居然還有這招?怎麼還有這樣的招數?從來沒有人攻打立法院呀!為什麼立法院居然可以被攻下來,而且還有人想到要去打下它?而且打下它之後,王金平居然真的不趕走他們?

天哪,還有這一招!我嚇傻了。從沒想過鬥爭、反抗,以為選票就是一切的我被嚇傻了。我以為一切都已經注定好了,提早投降了。他們在實踐中獲得了我想像力之外的智慧與勇氣。我不覺得他們就比我聰明,書就讀得比我好,但他們年紀比我小,用這麼簡單、異想天開的方式,就告訴了全台灣,告訴了全世界。

我不服,我有話要說,我想說的是,公民不服從。

我知道公民不服從,我讀過梭羅,我知道甘地、曼德拉。但剛剛說過,想像需要典範,這兩個年輕人給我了典範,讓我敢想像。然後我發現,我還沒有年輕過,就已經老了。我在沒有天真前,就先世故了,我在還沒思考作戰前,我就先規劃好投降了。

那之前,我以為人生最好是去美國,然後是去中國,離開台灣,離開被自己人放棄主權的悲情島嶼。我好懦弱。

台灣,這個小小的島嶼,從以前就是強權間的遊戲,未來也一直都會是。當中國和平崛起,美國重新調整戰略思維,台灣民意悶不吭聲,我知道,事就這樣成了。

我想像的台灣價值會被一個文革之後失去靈魂的國族吞吃乾淨,文革的火燒乾了中國的血性與道德,焦土之上只剩下消費主義的荊棘可以怒放,然後很快輪到台灣。

但陳為廷和林飛帆讓我知道,事情還有可轉圜的餘地,大聲讓世界知道,我們不服從。畢竟,這句話這天不說,很快就不能說了。

我一向很懦弱,所以我逃避思考,逃避現實,在故事的世界裡面永遠找得到避風港。我以為這樣我就不用害怕。

但這時候我才知道我真正害怕什麼。

我害怕,未來有一雙澄澈的眼睛,看著我,問我說當台灣被統一的時候,我做了什麼。

我知道,我不能聳聳肩,冷笑說:「我怎麼知道,你老子我沒投過國民黨,那不關我的事。」

那關我的事。

高牆與雞蛋之間,雞蛋不可能贏。

但人活著,要有骨氣。不可以什麼都還沒做,就先認輸。

膝蓋還沒好,不能跑、不能久站、不能盤腿坐太久。那找兩天睡在外面吧,未來我可以告訴我的小孩,我那天晚上,看到的夜空很美,很年輕。

最後,我還可以跟我孩子吹噓:「你老爸年輕時超會考試,考上了台大,那裡有個校長叫傅斯年;死過很多人,其中一個人是陳文成;那裡發生過哲學系事件。出過很多敗類,但也發生一些值得記住的事情。還是有些值得驕傲的地方。」

我以身為台灣人為榮,我以身為台大人為榮。

2014/03/25

最後,請讓我打上這行超過四年沒有寫的頭銜:

B93 台大經濟 蔡坤霖 獻給B91鄧之皓

從立法院長王金平談遵守法定程序

紙牌屋

王金平果然是老狐狸,什麼政爭,有他就好看了許多,似乎全中華民國政界講法律的就只有他一人而已。

先是學生佔領國會,行政單位用「國會自主」說國會殿堂歸立法院管,只有院長才可以動用警察權讓警察進入。

王金平就用非開議期間的佔領,是單純行政問題,請行政單位自行處理。

昨日總統要召開府院會議,調停行政跟立法的紛爭。

王金平說,審法條是立院自己的事,跟行政單位無關,沒什麼糾紛,拒絕出席。

今天行政院長跟學生會面,說考慮要逐條審察。

王金平又說,行政院提的解決方案跟立法程序不合。此外,怎麼審是立法單位的事,不容行政單位插嘴。行政單位有問題的,可以自己撤案,從頭再來一次。

這場戲,真的沒王金平不行啊,好好的幫台灣民眾上了一課什麼叫行政、立法、司法三權分立。

而且直把箭頭指准國民黨主席馬英九,因為只有國民黨主席可以要求立委撤回服貿的同意案。

我想當好人

王金平是不是(道德上)的好人我不知道,至少就很多中華文化的標準來看,他不是個好人。但是就法律上來說,他是個守法的好公民,也幫我們守住了法治社會的底限。

在學生佔領立法院的初期,有些人是期望王金平以立法院長的身份,去主張「國會自主權」並且同時不使用「警察權」去趨離學生的。

就此標準來看,王金平不保護學生,是道德上的壞人,但是,因為他什麼都就法律來主張自己的看法,反而讓學生運動有了更強的理論基礎、正當性。

學生運動本來是要求「行政單位跟立法單位要就法定程序來審服貿法案」。

但當學生要求跟總統對話時,總統派出了行政院長來對談,行政院長在自己職權外答應了一些事,我新聞沒看很清楚,印像是學生並沒有嚴詞拒決了行政院長的提案。

這時,學生已自己都踩了自己定下紅線而不自知,好險有王金平這老狐貍在旁,暗助了學生一把,說了行政院長所提的解決方案與法律不合,把大家的攻防,又拉回了「行政單位跟立法單位要就法定程序來審服貿法案」

3/23 補注:剛看完了行政院長到現場的對談,原來行政院長當場什麼也沒答應,而學生也把底線抓的很好, 一直是都要求行政院就自己的職權來撤回法案。所以王金平只是補一刀而已

野蠻時代

為什麼我們要看議事規範、要去就法律攻防,因為我們要避免回到今天的狀況,避免回到野蠻時代。

兩百年前,法國國會是議員有爭論,就是拔劍決鬥,但人家還是走過了那個階段,現在都是就議事規範來較競,不是再用武力對決,所以人家國會會有那種一講二十個小時,就為了阻擾法案通過。野蠻嗎?總比拔劍決鬥文明多了。

今天為什麼服貿的審議會讓那麼多人走上街頭,就是因為我們的國會往回走到了野蠻時期,主席可以跑到廁所門口,獨自宣佈表決通過,如果這樣子人民都還可以忍受,下次就是睡夢中就通過,或者行政單位直接執行,事後再補程序就好。

這種事情若還能接受,那就離獨裁不遠了

消基會抽查預付卡100%違規設使用期限,NCC:將要求業者改善

這是鬧劇嗎?兩邊都是笑話。

電信公司給預付卡一個門號跟維持一個門號是有成本的,為什麼 NCC 可以要求業者要無限期的維持一個沒有使用中的門號,設使用期限或者是有每月低消本來就是很合理的事,中華民國政府的 “行政單位NCC” 竟然可笑的定了這種 “規定” 出來。

更可笑的是, NCC 自己定的 “規定” ,卻連自己都不去強制遵守,要求業者遵循規定。

「上下交相賊」,上個求個美名所以定個便民的規範,但是卻不去執行,把責任推給商家,真是好個「儒家社會」啊

消基會抽查預付卡100%違規設使用期限,NCC:將要求業者改善 消基會抽查國內11件預付卡商品,發現100%都違反規定設有使用期限,應記載資訊也沒有完整詳細說明,NCC表示將進行查核,督促業者依規定落實改善。

文/蘇文彬 | 2014-03-14發表

消基會抽查11件電信預付卡商品,發現全部違反國內電信禮券定型化契約規定設定使用期限。

消基會調查電信業者推出的預付卡發現,預付卡雖然免綁約,且提供消費者控制通話費,但都訂有使用時間限制。對此NCC表示,電信儲值卡不應限制使用期限,將督促業者改善。

消基會這次一共抽查11件預付卡商品,其中7件為金額儲值型,4件為計量型上網儲值卡,並依據「電信商品或服務禮券定型化契約應記載及不得記載事項」不應限制用戶使用期限的規定,檢視抽查的預付卡服務內容說明是否有違反法律規定的情形。抽查的預付卡銷售商包括遠傳、台灣大哥大、中華電信、威寶、亞太、家樂福、7-Eleven等。

結果卻發現抽查的預付卡商品全部都設有使用期限,用戶每次儲值需在一定的時間內使用,業者通常限制為180天,上網儲值卡更只有30天,用戶在期限內再次儲值才能再展延180天或30天。

消基會指出,抽查的預付卡100%違反規定,並非消費者儲值後就能一直使用到儲值金額用完為止。一般購買禮券不因只消費部份金額,就被要求將剩餘金額在一定期限內消費完,但電信儲值卡卻有使用期限,除非再次儲值才能延後使用,但儲值金額用不完還要消費者再儲值才能繼續使用並不合理,且違反規定。

預付卡儲值金額若在時限內未使用完,部份電信業者可以申請退費,但部份業者規定只能辦理移轉,將預付卡內剩餘金額轉移到同一家業者月租費門號帳上,若用戶超過6個月沒有申辦轉移,剩餘儲值金額會保留,但會收取保管費直到扣完為止。

除了使用期限,消基會也發現其他資訊,例如業者名稱、地址、發售編號、履約保證、餘額處理方式、遣失處理等資訊在包裝或業者官網上說明不夠明確。

消基會表示,「電信商品或服務禮券定型化契約應記載及不得記載事項」在2007年通過,該年6月消基會首次抽查即100%違反規定設定用戶使用期限,今年再再次調查仍是100%違反規定,部份業者甚至規定屆期金額歸零,NCC應加強督導業者,消費者選擇儲值卡也應注意業者相關規定。

對於消基會抽查預付卡結果,NCC回應,依電信禮券定型化契約規定,逾期未使用完的傳輸量,用戶沒有特別聲明,應自動用以折抵通話費。消費者購買預付卡為不記名的禮券商品服務,依規定不得限制使用期限,NCC將會督促業者落實規定改善。

從壓力測試回想到一些老故事

最近壓力測試因為 戶政系統 的原因,上了幾天的新聞,講到壓力測試,就想到我這輩子職場上的一個恥辱,把一個產品搞倒的紀錄。

2007 年我還在 Rhapsody.com 時,當時我是擔任我們 webservice api 的 QA Lead ,做一個有 40 個內外部客戶的服務的守門員,每一次的產品更新,都要我跑完了數萬個測試,說可以出貨了才可以出貨。

四月時忙完跟 Tivo 的合作案,把系統的負荷量測到及調整到可以服務 500萬線上用戶的量後,另一個團隊又開發了新的 social 網站。

那是 facebook 才上線三年,或者說才對外公開服務的第一年,當所有人都還不知道什麼是社交功能時,rhapsody就已經開發出來社交功能,可以互相推薦音樂清單、可以 follow 別人、還可以自定 avatar

在上線前,我問了我的主管的主管,需不需要對 social web 的上線做測試,當時大主管是說不用。沒想到一上線,這 social web 非常的熱門,一下子就有數萬個用戶從標準的頁面轉換到 social 版去,似乎,一個新的 killer app 就要產生了。

然而才上線兩三天,網站的速度就慢了下來,後來才知道,原來 social web 濫用了我們的一個 GET api ,我們的 GET api 允許一次抓多個 object ,結果 social web 一次一個 request 就抓了 500 object ,一個 object 4k 就好,一次就抓 2MB ,在加上 object serialization 中間所花的記憶體空間,一個 request 就要佔 6MB 以上,一下就把那個年代的 server 打垮了。

就這樣,這個 social web 就下線整修,但不知為什麼,就此沒有再上線過了….

Mongodb vs MySQL/RDBMS

許多人從 RDBMS 跳到 NoSQL 的第一站都是 MongoDB ,所以這一篇,就是特別寫來解釋,為什麼很多人選用 MongoDB ,以及解釋你為什麼不該用 MongoDB 來換掉 RDBMS 。

MongoDB 熱門的理由

MongoDB 熱門的原因是因為他提供了一個可以跟 SQL 相比的 Query Language ,在 NoSQL 不同面向的眾多方案中, MongoDB 所能支援的 AdHoc Query 是沒人能比的, Riak 跟 CouchDB 的 AdHoc Query 也不差,但是 Riak 在跑 MapReduce Query 時是不能透過 index 加速的, CouchDB 則是跟本不支援 index ,所以在這邊 MongoDB 看似 是個很好的 MySQL drop-in replacement

使用 MongoDB 來取代 MySQL ,在初期,看來是學習成本最低,轉換風險最低的解決方案,所以多數商業公司,為了降低風險,在追循潮流一窩風的採用 NoSQL 時,選擇了 MongoDB 這個看似合理且安全的選項。

然而糖衣底下掩蓋的,卻是數不盡的陷井在那。

Trade-Off

技術的選用,往往是一連串的取捨,拿某樣功能去換回了另一項功能,所以,接下來我們就來看看,我們從 MySQL/RDBMS 跳到 MongoDB 去,我們到底是跟魔鬼做了什麼樣的交易,拿了什麼樣的東西,去換回了什麼。

首先,我們先看看我們換出去的是什麼?我們換出去的是 ACID (Atomicity, Consistency, Isolation, Durability) 及 Relational Model

ACID

對絕大多數的應用來說,交易的正確性跟不可否任性,是系統必要的基石, ACID 便是協助達成這一目標的工具之一。

ACID 雖然是一大重要工具,但也不是不能夠取代,像是 CQRS PatternCassandra Summit 有一個很好的講題就是介紹怎麼用 Cassandra 透過 CQRS 來寫一個給銀行用的轉帳系統。

SAGA Pattern 則是另一個在沒有 Transaction 下,來解決多事件互動的 Pattern 。

然而 CQRS 或 SAGA Pattern 都沒有 Transaction 好用,以及廣被眾人所了解,連我自己都只是讀過沒有親身實作過,要做的話,連底層的工具都要自己從頭開始作,或者是要去學一些非常新的工具如 Datomic

因為換出的是 ACID 這樣強大的工具,替代的方案又是高未知的空間,所以許多人最後選擇的替代方案就是 – 頭埋起來假裝沒有問題

而且 MongoDB 本身號稱的 BASE 跟本是 Eventual Inconsistency ,在 Call me maybe: MongoDB 這篇文章中就驗證到,當 Network Partition 發生時,既使 MongoDB 回復寫入成功,但是實際上還是會失敗的,所以就在這種底層實作不可靠下,你上層加什麼工具也是枉然,所以多數人就是假裝沒這回事,想說自己沒這麼倒楣。

Relational Model

Relational Model 是三十年前那次 DB 戰爭中,打敗 Network Model, Hierarchical Model 剩出的王者,在三十年後,再次受到 Document Model 的挑戰,這次的結果如何呢?

Relational Model 的好處是可以透過正規化,減少資料的重複、提高資料的一致性,以及透過 SQL ,除了 AdHoc Query 外,還可以對多個 Table 進行 Joined Query,這個是 MongoDB / Document Model 所做不到的。

那這個特性重要嗎?我想透過一個例子就可以很簡單的介紹 Relational Model 的強大,跟 Document Model 在應用上會碰到的問題。

Relational Model Example

我們公司是做人肉搜索的,對於同一個人 / email 來說,我們會有很多來自不同來源的 metadata ,今天假設是兩個來源好了。

在 RDBMS 中,就是開兩個 Table ,各自記錄不同來源來的資料

| TableA        | Email         | likes      |
| ------------- |---------------| -----------|
|               | billg@ms.com  |  1600      |


| TableB        | Email         | tweets     |
| ------------- |---------------| -----------|
|               | billg@ms.com  |  9999      |

在 Document Model 可能就是用一個 Document 如

{
    email: "billg@ms.com",
    likes: 1600,
    tweets: 9999
}

在 Query 時,前者要一個 join 才可以取回關於這個 email 的所有資料,後者則是一個 lookup ,自然後者的效率較好,而且同樣可以對不同的欄位下 Query 條件。

然而,既然要用 NoSQL 就要玩 BIG DATA ,所以我們把問題修改一下,我們從兩個來源,分別拿到十億筆 email 的 likes 數,跟十億筆 email 的 tweets 數,我們想把這些資料寫到 DB 去再拿回來用。

用 RDBMS 自然是輕鬆愉快,兩個檔案輪流打開,一筆筆的加到 DB 中,DBMS對這種簡單的寫入可以做到 10,000 insert / sec 沒問題,大概 55 分鐘就可以做完了。

但是 MongoDB 呢?因為兩個屬性都是在同一個 Document 上,所以要馬是先把十億筆 (email, likes) ,先寫到 MongoDB 中,再下十億筆 Read + Update 把 Document 讀回來再加上 tweets ,如果很不幸你的 Document Id 不是 email ,那就是要下十億筆 Search + Update ,不管怎麼算,都不是太漂亮。

另一個作法是,你先把兩個十億筆的資料在本機的記億體中做 join ,然後再寫到 MongoDB 去,ㄜ… 這樣搞你不覺得累嗎?這麼小的應用問題就要自己動手刻程式碼,而且 前面我們不是說 big data 嗎?如果資料不是十億筆而是一百億筆,你放不進記億體中,那你要先用 radix sort 寫到 file system 再讀回來嗎?

然後你忙了這麼多後, MongoDB 給你的,因為 global write lock ,還是一樣是 10,000 insert /sec ,然後因為 MongoDB 實作的問題,如果你的 Document 有 indexed field ,那麼寫到兩百萬筆後會越寫越慢,這問題在成熟的 DB 上是沒有的。

我想,這個小例子就說明了 Relational Model 的強大之處及 Document Model 弱的地方,當你要既有的資料新增欄位時, Relational Model 是可以很簡單的增加一個 column 或 table 就做到,在 MongoDB 上,則是要跳過重重關卡才可以達成。

在軟體需求不穩定時,或常有變更時 Relational Model 對變革的適應能力,較 Document Model 高出許多。

MongoDB 的長處

在交換出 ACID對Model 對變革的適應能力 後,我們從 MongoDB 到底換回來了什麼呢?

  • cluster 帶來的更多的儲存空間
  • cluster 帶來的更 scalable read operation.
  • 在某個資料大小下,一個非常快速的 index

前兩個長處就不用多談了,Opensource RDBMS的長處並不在這塊,跟從一開始就要做 cluster 的 MongoDB 是沒得比的,MongoDB 目前已有超過 100 node 的單一 cluster。

第三個先略過不說,等說完結論再回來說

結論

我們看完了 Trade-off 後,我們要來思考一下,我們這個交易到底划不划算?

對我來說,我們換出了 ACID 跟 對Model 對變革的適應能力 後,我們換回來的僅僅只有 Scalable storage & scalable read , 就我看來,這是一筆極差的交易,因為這個換回來的東西大多只能應用在一塊很小的地方,一個需要大量儲空間、一個需要大量讀取能力的應用,而且後者還可以被 cache 所取代。

前面講的 在某個資料大小下,一個非常快速的 index 就是指這個應用範圍, Navigenics 的 Dick Wall 就講過,他曾用 MongoDB 用來儲存要配對的 DNA Sequence ,他的資料大小,剛好是大到無法用 Redis 放在記億體中,但是 index 的大小剛好是可以透過 MongoDB 全部放在記億體中,剩餘的資料則是存在硬碟上,就這麼剛好透過 MongoDB ,在下複雜 Query 時,他的搜尋速度可以達到 MySQL 方案的一百倍。

然而,真正 big data 的應用,如 log storage & analysis ,MongoDB 是無法達到對 write operation 的需求的。 MongoDB 能適用的問題空間實在太小,而且既使你目前的需求是在 MongoDB 能達到的範圍內,但需求一變化,就長到 MongoDB 無法承擔的空間去了。

這也是我未來不會採用 MongoDB 的原因,在小量資料時,我會用 PostgreSQL / MySQL ,在資料量大時,會用 Postgres + Cassandra + ElasticSearch

附注

既然我說 MongoDB 的這筆交易不是個好交易,那什麼是好交易呢?

我覺得 Cassandra 這個就是個好交易,我們拿 ACID, AdHoc Query 出去換。是的我們把 AdHoc Query 都拿出去換掉了,換回來的是一次只能問兩個問題的 Query ,而且這兩個問題還是在 Table Design 時就要決定的。

但我們換回來的是幾乎無上限的 Read & Write operation 能力 ,在Netflix 的測試中,Cassandra 單一節點可以有 10,000 rw/sec ,然後一路隨著增加到 288 個節點,每加一個點可以增加 10,000 rw/sec 。

這個才是我說的好交易,因為這個特殊能力,是其它解決方案都辦不到的;雖然說我們交易掉了 ACID & AdHoc Query ,但是透過適當的 Table Design , Cassandra 的特性剛好可以用來解決 Big Data 中 log storage & analysis 這個大部份人需要解決的問題。

Mongodb - Schemaless

我覺得大家對 MongoDB 誤解最大的地方就是 schemaless , schemaless 應該是個大問題才對,不知道為什麼世人都跟 billg 一樣,把問題當做優點來看。

Schemaless 的優點

Schemaless 不是沒有優點的,在搭配上動態語言時, Schemaless 是個很好用的功能,不用設定 mapping configuration ,直接就可以打 item?.some_collections[0]?.city 就這樣一路對一個物件逛下去,不用為了新增一個欄位就要去改 mapping configuration 然後跑 db migration。

然而,這個特點,只有用在有 safe navigation 的動態語言上,才能享受到這些好處,要不然還是處處都要寫 null check ,要不然就會因為讀到前一版的 item 缺少某個欄位,而噴出了 NullPointerException。

Schemaless 與靜態語言

在靜態語言中使用 Schemaless DB 時,schemaless 的好處就消失怠盡了,像是我們公司是用 Morphia 來寫 Model & DAO 的,若是要新增一個欄位,免不了是要去更新 Model class 然後重新 compile & deploy 才能加上一個欄位的。

相較於使用 Schemaful DB ,我們省下的,只有跑 DB Migration 的時間,當然,若是你有個超大的 DB ,那這省下的 off-line maintenance downtime 也可是很驚人的,但是,並不是所有的 db migration 都是要把整個系統下線才能跑的,大多數的 db migration 都是會把系統設計成(對DB)向後相容的,所以不用把整個系統啦下線就可以跑。

對DB向後相容的 Application / 向前相容的 Schema :這邊指的是,先不要更新 Application ,先把 DB Migration 跑完,把資料庫的資料跟Schema更新完後,才把新版的 Application 上線。所以在某段時間內,是舊版的 Application 對著新版的 Schema 在跑的。

Schemaless 的問題

許多大系統用 Schemaless DB 的原因是因為不想因為跑 DB Migration 把整個系統下線,所以就用 Schemaless 的系統來避開這問題。

但是我想說的是,這誤會可大了,就像前面講的在 Schemaful DB 中,向前相容的 Schema 變動,是不用把系統下線就可以跑的,只有向前不相容的,才要跑 Offline DB Migration 或 Online Data Conversion.

Online Data Conversion 指的是,因為前後 Schema 不相容,所以開一個新的 Table 給新版本的物件用,每次讀取一個物件時,先去檢查是否已存在新的 Table 中,若沒有,則是從舊的 Table 讀出來,把格式更新,再存到新的 Table 中。

如此一來,就不用下線也可以把前後格式不相容的的 DB 更新。

前文所說的 db migration & online data conversion 就是 schemaless DB 的大問題,除非你是 ,Model 一次就設計好,可以用一輩子,要不然不跑 db migration ,在你的 DB 中,必然會存在著 V1, V2,V3…Vn 版本的物件。

不跑 db migration ,那就表示你要維護可以對 V1, V2, V3….Vn 存取的 Model class ,你可能有一個 db item 一整年沒被讀取到,但是一年後突然用到,你要怎樣保證還讀的回來呢??

最常見的做法就是,不去 大幅度 更新 Model ,削足適屨,既使你知道更新 Model 會讓你未來程式更好寫,但是因為不能去更新 Model ,那就只好去調整程式邏輯,癟腳的用不合適的 Model 來做新工作。

而既使你想跑 db migration ,但是因為 schemaless db 跟本不打算支援 db migration ,所以不會內建任何工具來幫助你,你只能很苦命的自己刻 online data conversion 的工具了。

後記

如果你對 DB Migration 的幾種方式有興趣的話,我建議你花一小時,把 Martin Fowler 與 Pramod Sadalage 的 Agile Database Development 聽完

MongoDB - Sharding

Sharding 是一個我非常討厭 MongoDB 的地方,在多台 DB 的解決方案中,免不了要用一個方式來決定那個 object 該放在那台機器上,一個解決方式就是用某個欄位來當 shard key 。

在 MongoDB 中,這個 Shard Key 一決定後就不能改了,然後 MongoDB 會幫你把 object 按 shard key 的值域,平均分配在 n 台機器上。

問題是,平均分派值域並不代表值會是平均非配的,例如 email ,因為姓名是集中在幾個字母上的,所以按值域分派會有 hot spot 產生,a-d 的特別多人,然後 x y z 的沒有人。

在其它的 DB 中,每個 shard 機器所負責的值域是可以讓 dba 去調整的,但 MongoDB 是不行的,所以必然會產生 hot spot 而且你無法去躲開。

有些人會自己去產生 UUID 來當 shard key ,在 MongoDB 2.4 中,則是加入了 hashed shard key 自動幫你把 shard key field 拿去算 hash key 出來當 shard key 用。但是,這還是免不了某些值域是 hot spot 的問題。

既使 MongoDB 能夠平均分派儲存的值域,但是最終我們要看的是,怎麼樣平均分派 read/write operation 。

因為在讀取時,也會發生因為某些原因,讓使用者對某些 object 的存取較其它物件多出 n 倍,所以每個 shard 所負責的值域一定要是 tunable ,要不然遲早一定會出問題。

所以,扔了 MongoDB 吧

QNAP Sucks

是我太多年沒裝機、還是這年頭的機構設計師都是天才?高高興興的把新買的 QNAP TS-212P 打開來,嗯… 好樣的,竟然沒有說明書。

好吧,就自己硬幹了,開始裝第一顆硬碟,右側索好兩顆螺絲後,換鎖左側,好樣的,孔位對不上!那就鎖一側好了。

先插排線,嗯…,怎麼 接頭卡到機板身上別的零件了,那這樣不是變成只能插一顆硬碟。2 Bay 的機種只能用一個是怎樣。

/images/2014-01-26/qnap-1.png

算了,先換另一個位子,先開機起來試用再說。

硬碟換到另一個孔位裝好後,再插一次排線 ,嗯,這次接上去了,換插 SATA 排線,嗯,線好短,應該夠長吧。

結果夠長是夠長拉,可是硬拉到那接頭的上下面是反的,所以又不夠長了。

/images/2014-01-26/qnap-2.png

靠,裝個機碰上三個設計問題是怎樣,浪費我時間

更新:

經過 Google 大神的指引,原來第一顆硬碟是要插到我卡到的地方去的 Orz… 第二顆硬碟,硬拉,線是剛剛好夠長的

http://forum.qnap.com/viewtopic.php?f=11&t=87993

http://i41.tinypic.com/notyf5.jpg

德國人為什麼強大

德國人為什麼強大,沒空看影片的,這邊做個簡述

  1. 德國男人 6:20 就起床,八點半上班,工時八小時,內含午餐一小時,下午四點半下班,就可以回家過家庭生活
  2. 德國人上班時不可以玩手機 fb ,就是認真幹事,沒有休息或發呆的,有空閒就是主動多抓工作來做。
  3. 德國工業還是採學徒制,公司都是做很專門的小事,做到世界第一。雖然沒有明說,但類似日本的終生僱用制,讓員工能夠專心的精進技能。
  4. 德國人對穩定的重視高過個人福利,薪資成長跟 CPI 一樣而已,為了成就團隊,個人可以什麼雜事都幹
  5. 德國女人在小孩三歲前都是全職家庭主婦,一天花四小時在家政上,剩下來時間花在調教小孩,讓小孩及早養成良好的生活習慣。
  6. 德國特有的森林幼稚園,就是把小朋友帶到森林去跟自然環境玩,發揮想像力,自己動手就地取材作玩具。
  7. 德國的小朋友上學,八點上課,下午很早就下課,一週有三天是在中午前就結束。

我的心德是,日德兩大工業國家果然有很多相似的地方,如勤奮重紀律、終生雇用、職人導向,德國還加上了重視家庭生活( 日本男人沒這麼爽 ),但相反的就是女性沒有什麼自主權。