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

看板Soft_Job作者 (幻想的魚)時間12年前 (2012/03/17 03:12), 編輯推噓7(7推 0噓 32→)
留言39則, 12人參與, 最新討論串14/26 (看更多)
※ 引述《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
→
03/17 06:54, , 1F
rdb也能做到db1掛點時去存取db2 為何必回exception?
03/17 06:54, 1F
推
03/17 08:00, , 2F
這件事現在的 SQL 也都做的到，跟 NoSQL 有什麼關係呢？
03/17 08:00, 2F
推
03/17 10:37, , 3F
其實我是認為雲端跟不中斷完全是兩回事。
03/17 10:37, 3F
→
03/17 10:37, , 4F
不會因為你用了雲端就自訂不中斷
03/17 10:37, 4F
→
03/17 10:37, , 5F
*自動
03/17 10:37, 5F
→
03/17 10:56, , 6F
雲端會給人很穩不中斷的原因是因為他機器很多. 只要容錯
03/17 10:56, 6F
→
03/17 10:57, , 7F
設計的好,也就不太容易掛點
03/17 10:57, 7F
→
03/17 10:58, , 8F
至於傳統資料庫要db=>db2的作法也是行之有年. 只不過一般
03/17 10:58, 8F
→
03/17 10:59, , 9F
公司單位了不起搞一組backup node就差不多了. 搞太多
03/17 10:59, 9F
→
03/17 10:59, , 10F
根本也養不起. 容錯能力自然不能跟AWS, Google那種幾萬台
03/17 10:59, 10F
→
03/17 11:00, , 11F
機器可以彼此在那邊互相cover的情況無法相提並論
03/17 11:00, 11F
→
03/17 11:27, , 12F
如果要比google, aws...那應該也是跟nonstop比吧
03/17 11:27, 12F
→
03/17 11:29, , 13F
金融單位兩個active site + 1 backup site就很夠了說
03/17 11:29, 13F
→
03/17 11:40, , 14F
別忘了，即使是 AWS 也有掛點紀錄...
03/17 11:40, 14F
→
03/17 11:41, , 15F
當然，跟自己 host比起來，AWS 可能穩定很多，但是這跟不中
03/17 11:41, 15F
→
03/17 11:41, , 16F
斷的理想還是有段落差。
03/17 11:41, 16F
→
03/17 11:41, , 17F
但是我看到很多人說不中斷指的是 server 決不會掛點，我持保
03/17 11:41, 17F
→
03/17 11:41, , 18F
留態度。
03/17 11:41, 18F
推
03/17 11:44, , 19F
拜託~ Facebook 和 Google 都是用 MySQL~
03/17 11:44, 19F
→
03/17 11:46, , 20F
RDB沒那麼不堪... 只是看你會不會用, 會不會調, 會不會改
03/17 11:46, 20F
推
03/17 11:47, , 21F
不中斷要是 failover 機制，至少不會有 SPOF 的問題才是。
03/17 11:47, 21F
→
03/17 11:48, , 22F
在我有限的經驗裡 RDB 是夠威的，只是會轉移到 nosql 算
03/17 11:48, 22F
→
03/17 11:48, , 23F
政治考量。因為舊的那批寫 RDB 相關的人，有太多ooxx的毛病
03/17 11:48, 23F
→
03/17 11:49, , 24F
從 scale 不大時就沒有好好盯，而 scale 大起來後，code 也
03/17 11:49, 24F
→
03/17 11:49, , 25F
多到難以改善地步。只好趁機抽出一部分，藉使用 nosql 的
03/17 11:49, 25F
→
03/17 11:49, , 26F
機會來做一些嚴謹的、有效率的替代方案實作。
03/17 11:49, 26F
推
03/17 12:37, , 27F
Facebook 和 Google 都是用 MySQL ???
03/17 12:37, 27F
→
03/17 13:00, , 28F
要不中斷基本上就看你想花多少錢 AWS全世界各地不只一個點
03/17 13:00, 28F
→
03/17 13:01, , 29F
如果你只放一個點,比如說日本好了,然後遇到311那樣的事件
03/17 13:01, 29F
→
03/17 13:02, , 30F
那要不中斷基本上我想是不可能的.
03/17 13:02, 30F
推
03/17 16:48, , 31F
Facebook還是世界上MySql最大使用客戶無誤
03/17 16:48, 31F
→
03/17 23:32, , 32F
MySQL 只是組成兩個公司系統的一部分，預期早就混合了各種
03/17 23:32, 32F
→
03/17 23:33, , 33F
技術來實做，包括 NoSQL 。如果只選擇一個，NoSQL or SQL 差
03/17 23:33, 33F
→
03/17 23:33, , 34F
在堆疊的難度，只使用 RDB 就看你能不能找到有能力的人，但
03/17 23:33, 34F
→
03/17 23:34, , 35F
NoSQL 的堆疊是相對容易許多。要說有政治因素，各種技術都有
03/17 23:34, 35F
→
03/17 23:38, , 36F
NoSQL也不是萬靈丹, 用這來否定RDB, 是有點怪不是嗎~
03/17 23:38, 36F
→
03/17 23:45, , 37F
我也沒說是萬靈丹，也沒否定 RDB ，只是討論那朵雲怎麼玩 :)
03/17 23:45, 37F
→
03/18 01:19, , 38F
記得 cassandra 就是 FB 開發的
03/18 01:19, 38F
推
03/19 18:35, , 39F
服務不中斷還是要看SLA做到多少 這世上沒有不當機的電腦
03/19 18:35, 39F
‣ 更多 imagefish 的文章
文章代碼(AID): #1FOv2m2o (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 14 之 26 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共26篇)
‣ 更多 imagefish 的文章
文章代碼(AID): #1FOv2m2o (Soft_Job)