Fred's blog

就在幾天前，MongoDB 邁入了 2.2.0 的穩定版本。我們若回頭來看，MongoDB 一直到了 2.0 前後，比起早期版本，已經有長足的進步，並且支援了相當多的功能，也對規模化和資料庫系統管理下了很多功夫。對於大多數的資料庫應用，已經非常適合。 若你對資料庫相關技術有些了解，就會知道，當資料庫的資料發展一定規模程度，或是要確保系統不當機時，我們就需要用到 Master/Slave 的方式去備份和備援，當主要(Master)伺服器出了問題，次要(Slave)伺服器便即時補上，保持系統運作。但是，既然已經有 Master/Slave 機制，是否可以有更多台備援呢？更或者進一步，將讀寫分開在不同伺服器，以分攤流量和系統負載，並加速讀寫速度。而 Replication 就是這樣的機制，可以用來動態同步多台資料庫伺服器的資料，也可以當主要伺服器因故下線時，讓其他伺服器即時替補主要機器的位置。 在 Debian 上設定 MongoDB 的 Replication 相當容易，首先在想要變成主要(Primary)的機器上，打開設定檔(/etc/mongodb.conf)，並為我們的 Replication 群組命名（在 MongoDB 中稱為 ReplSet，一些書籍內翻譯成『複製組』）： replSet = mydb 重新啟動 MongoDB： $ sudo service mongodb restart 使用指令 mongo，進入 MongoDB 命令模式： $ mongo 於 MongoDB 命令模式中執行： # 初使化 replSet rs.initiate(null) # 加入自己的 IP 位置 rs.add("192.168.11.1:27017") 若是回應成功，請先稍待數秒鐘，等伺服器偵測和初使化。然後會發現 MongoDB 的命令提示字元從『SECONDARY』變成『PRIMARY』，此時，代表這台機器已經變成 ReplSet（複製組） 中的主要機器。 同樣的，你可以開始為 ReplSet 加入其他次要的資料庫伺服器： rs.add("192.168.11.2:27017") rs.add("192.168.11.3:27017") rs.add("192....

數個月前開始做一個計劃『AppHouse』，實作如 Google App Engine(GAE) 般的 PaaS，其志在打造自己的 Node.js 雲端軟體平台。然後發現，除了讓雲端服務可以在平台上跑起來外，資料庫管理也必需有個便於使用的機制和規劃，仔細想想，一個沒有資料庫配合的雲端服務，可沒有什麼太大的價值，於是，『DBHouse』便應運而生。 你可以在 github 上找到這個專案： https://github.com/Mandice/node-dbhouse DBHouse 起初的開發目的，是讓使用 AppHouse 架設以及開發自己雲端服務的人，可以很容易存取資料庫。此外，對我們而言更便於管理資料庫資源，面對許多不同的服務，不需要特別為他們開設資料庫權限，亦或是買許多硬體和主機，建立起許多 VM 並做各種安全性規劃。其實，如果把 DBHouse 的用途，想像成 Google 在做的事，就很容易明白：『在 GAE 上你可以使用統一的 Database APIs，存取 Google 提供的資料庫系統(BigTable)。』，同理，我們也是在做同樣的事。 只不過，學 Google 開發自己的一套資料庫太過於困難，不是一個可以達成的目標，所以我們仍然選用 MongoDB 當做 PaaS 的資料庫底層。僅管資料庫不是自己開發的，我們還是可以提供統一的 API，讓開發者存取。統一的 API 有個好處，若能做到當開發者在使用的時候，不需要知道自己在使用什麼資料庫，日後就可以在這 API 之後串接或替換不同的資料庫系統，有很大的彈性可以擴充。 當然，更遠大的目標是希望在一個 Table(Collection) 內，因應不同的欄位需求，而交由不同資料庫處理，更進一步發揮不同資料庫的特色。但是，這夢想遠大，技術上也有很多盲點待討論，所以能不能實現那是另外一回事，至少，短期內在我們的能力範圍和經濟狀況下，暫時無法達成這一步。 雖然 DBHouse 有這樣的初衷和夢一般的計劃，但不代表 DBHouse 一定得和 AppHouse 配合使用，更準確的說，他們本來就是獨立各自發展的專案，各自可獨立運作。說穿了，DBHouse 本身就只是一個 Database API，你可以在 Node.js 裡使用 DBHouse API 去操作自己的 MongoDB（目前只有支...

雖然 NodeJS 的模組和開發資源相當多，但相關文件卻非常不足或是不完整，多半文獻都只著重於基礎的使用和片斷的說明，如果不去看原始程式碼，使用 NodeJS 來完成實用的網站，會有很大的困難度。對於已經有過 Web 開發經驗的人，轉換使用 NodeJS 不免也需要花一番功夫，過去經驗中許多的常用的功能，都仍要一一花大量時間嘗試才得以解決。而這樣的情況，對於開發者來說相當的糟，也是很多人重新再評估是否使用 NodeJS 的重點因素之一。有道是『一人得道，雞犬升天』，因此筆者未來將嘗試將自己的實際經驗，寫成一篇篇重點功能實作的文章和隨 Copy 即用的範例，減少其他人浪費同樣的時間再摸索。 開發一個 Web 應用程式，最重要的莫過於資料庫的使用，過去 PHP 有 MySQL 當最佳夥伴，而現在 NodeJS 有 MongoDB 做最佳的組合。MongoDB 是 NoSQL 的代表之一，其採用 JSON/BSON 當做資料儲存和溝通的格式，亦使用 JavaScript 做為 Server-side 的執行程序語言（相當於傳統 RDBMS 的預儲程序），一切設計和習慣與 NodeJS 搭配使用起來，簡直絕配。若你對 MongoDB 的一些基本操作有疑問，可以先參考舊文『 MongoDB 快速筆記 』。 使用 MongoDB MongoDB 擁有 NoSQL 的普遍特色，不用預先定義 Schema，所有的 database 和 collection（相當於傳統 RDBMS 的 Table），都會在新增資料後，自動被建立，我們只要專注於使用 NodeJS 操作資料庫即可。 要在 NodeJS 裡使用 MongoDB，可以安裝 mongodb native driver，若透過 npm 來安裝： npm install mongodb 然後可以使用 NodeJS 建立 MongoDB connection pool ，做一些基礎的操作： var mongodb = require('mongodb'); var mongodbServer = new mongodb.Server('localhost', 27017, { auto_reconnect: true, poolSize: 10 }); var db = n...

這幾年 Web Service 的龐大需求，對資料庫的要求是快速且吞吐量大，因此業界開始流行 NoSQL，它省略最花時間的資料庫操作和複雜的結構，用最合人類使用需求的方式在儲存資料，其帶來的好處，當然就是能提供極速的反應和龐大的資料吞吐量。目前最廣為人知的就是 BigTable，Google 提供全世界快速搜尋和各種線上服務，靠的就是這 NoSQL Database。 其實 NoSQL Database 的選擇非常多，但本文只是記錄 MongoDB 的操作筆記，因此就不詳述。 有興趣的人，可以去查閱網路上更多的資料。 選擇 Database： use my_database 利用 root 新增 Database 的管理帳號： # 切換到 my_database use my_database # 先用 root 帳號認證 db.getSisterDB("admin").auth("root", "rootpassword"); # 新增 frankie 帳號 db.addUser("frankie", "fredpassword"); 新增 Database 的管理帳號： # 切換到 my_database use my_database # 先用 frankie 帳號認證 db.auth("frankie", "fredpassword"); # 新增 zombie 帳號 db.addUser("zombie", "zombiepassword"); 插入新增資料（Insert）： # 插入一筆新資料到 users Collection （相當於傳統 SQL 裡的 Table 角色） db.users.insert({ username: "fred", password: "12345678" }) # 含當前時間 db.users.insert({ username: "fred", password: "12345678", created: new Timestamp() }) 查詢...