Re: [討論] 如果台灣要發展雲端，你覺得該怎麼做？

[imagefish (幻想的魚)]

※ 引述《lgd1008 (lgd1008)》之銘言：
: 其實身為一個軟體的開發者, 我一樣不解的是, 為何需 "強調" 要發展雲端?
: 因為這句話聽在我的耳朵裡, 之所以要強調雲端, 與現有的網站, 網路服務的開發做區隔
: , 是想要強調以連接大量機器, 去解決計算, 或容錯上的一些問題.
: 可是目前這種需求很少, 就算硬是開發了一堆軟體出來, 結果也是會牛頭不對馬嘴. 因為
: 目前適用Map-Reduce, NoSQL的問題, 老實說也只有特定幾個...
: 循序計算起來也很快的東西, 幹麻要 "反而更慢" 的分散/平行計算... 用資料庫做起來
: 也很快的東西, 幹麻要用 "反而更慢" 的 NoSQL...?

  NoSQL有個還不錯的地方是，可以去應用在設計類似DB Cache的東西。

  假設Client端有兩個API可以呼叫，分別是GetItem()和SetItem()好了。

  public object getItem(int ID)
  {
    // query DB and get assigned item
  }

  public bool setItem(int ID, Object object)
  {
    // modify DB's data
  }

  可能原本在RDB的狀況是去某個"指定"的資料庫裏面讀取"指定"的表格然後做一些

  動作。但是這無法去避免一種缺點，就是當該指定的資料庫如果掛掉(電腦燒惹，OS

  當機，網路線塞車..balabala)，那我只好吐回Exception了。


  但是我們可以試著在背後做一些調整，例如用NoSQL去設計一套一種機制，當DB_A掛點

  了，DB_B可以馬上接手工作，這樣可以確保"服務不中斷"。某些狀況下，服務不中斷

  這機制可以給予某些商業行為非常大的誘因的。


  除了"服務不中斷"以外，現存的資料庫系統有個很大的缺點在於必須把某個資料庫安裝

  在某台主機上，所以說如果該主機只有2G空間，那資料庫最多也只能放到2G。

  想想看，既然我們都可以做到上述的DB_A & DB_B互相支援的情況，是否可以試著去做

  到大家資料互相流通，這樣是否可以設計出有無限大空間的資料庫呢?

  這也是非常吸引人的。

  現實生活中很多系統如果背後支撐的機制換成這樣，那會是非常強大的:)


: 難道有人認為 "雲端" 是某種 "萬靈丹"?
: --------
: www.facebook.com/java.tw


  他其實就只是一個"很酷"的構想而已。

  [不中斷的服務] + [無容量限制] 一個虛擬儲存裝置。

  很酷啊!!!!

  這可以讓多少的網路服務變得更為強大阿~

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 114.37.89.24
→ SlimeEditor:rdb也能做到db1掛點時去存取db2 為何必回exception?
推 AlanSung:這件事現在的 SQL 也都做的到，跟 NoSQL 有什麼關係呢？
推 TonyQ:其實我是認為雲端跟不中斷完全是兩回事。
→ TonyQ:不會因為你用了雲端就自訂不中斷
→ TonyQ:                   *自動
→ francej:雲端會給人很穩不中斷的原因是因為他機器很多. 只要容錯
→ francej:設計的好,也就不太容易掛點
→ francej:至於傳統資料庫要db=>db2的作法也是行之有年. 只不過一般
→ francej:公司單位了不起搞一組backup node就差不多了. 搞太多
→ francej:根本也養不起. 容錯能力自然不能跟AWS, Google那種幾萬台
→ francej:機器可以彼此在那邊互相cover的情況無法相提並論
→ SlimeEditor:如果要比google, aws...那應該也是跟nonstop比吧
→ SlimeEditor:金融單位兩個active site + 1 backup site就很夠了說
→ TonyQ:別忘了，即使是 AWS 也有掛點紀錄...
→ TonyQ:當然，跟自己 host比起來，AWS 可能穩定很多，但是這跟不中
→ TonyQ:斷的理想還是有段落差。
→ TonyQ:但是我看到很多人說不中斷指的是 server 決不會掛點，我持保
→ TonyQ:留態度。
推 manlike:拜託~ Facebook 和 Google 都是用 MySQL~
→ manlike:RDB沒那麼不堪... 只是看你會不會用, 會不會調, 會不會改
推 qrtt1:不中斷要是 failover 機制，至少不會有 SPOF 的問題才是。
→ qrtt1:在我有限的經驗裡 RDB 是夠威的，只是會轉移到 nosql 算
→ qrtt1:政治考量。因為舊的那批寫 RDB 相關的人，有太多ooxx的毛病
→ qrtt1:從 scale 不大時就沒有好好盯，而 scale 大起來後，code 也
→ qrtt1:多到難以改善地步。只好趁機抽出一部分，藉使用 nosql 的
→ qrtt1:機會來做一些嚴謹的、有效率的替代方案實作。
推 ledia:Facebook 和 Google 都是用 MySQL ???
→ Hadoop:要不中斷基本上就看你想花多少錢 AWS全世界各地不只一個點
→ Hadoop:如果你只放一個點,比如說日本好了,然後遇到311那樣的事件
→ Hadoop:那要不中斷基本上我想是不可能的.
推 birdychang:Facebook還是世界上MySql最大使用客戶無誤
→ olctw:MySQL 只是組成兩個公司系統的一部分，預期早就混合了各種
→ olctw:技術來實做，包括 NoSQL 。如果只選擇一個，NoSQL or SQL 差
→ olctw:在堆疊的難度，只使用 RDB 就看你能不能找到有能力的人，但
→ olctw:NoSQL 的堆疊是相對容易許多。要說有政治因素，各種技術都有
→ manlike:NoSQL也不是萬靈丹, 用這來否定RDB, 是有點怪不是嗎~
→ olctw:我也沒說是萬靈丹，也沒否定 RDB ，只是討論那朵雲怎麼玩 :)
→ lovdkkkk:記得 cassandra 就是 FB 開發的
推 ihon822:服務不中斷還是要看SLA做到多少 這世上沒有不當機的電腦