長久以來，一直為了一個小小的資料庫系統尋找適合的解決方案。這個系統的基本概念是要建立一個可以大量收集與處理 Metadata 的資料模型。由於這只是一個 Pet Project，在無法額外投資建立叢集系統的狀況下，只能試著用一些簡單的方式來實做。

這個資料庫的用途是可利用透過各式 Metadata 所組成的 Facts 進行推論。稍早的實驗，已經可以有效率的進行基本的前推式(Forward-chaining)與回溯式(Backward-chaining)的混合式推導來取出有意義的「knowledge」。

我的資料形式都是 subject-predicate-object 表示的 RDF Triples (RDF: Concepts and Abstract Syntax)，原本是專注在可以處理 RDF 的 Triplestore，但大部份的開放原碼後端資料庫都還是使用 RDBMS，加上冗贅的 RDF/XML 資料交換格式，速度上實在難以令人忍受。而 ORDBMS 又需要使用不少的計算資源 (記憶體 :-/ ) 才能順利執行。

於是，策略性的將系統設計為 Controlled vocabulary，後端採用飛速的 SQlite。以速度來說，在有 VFS 快取下，從兩千餘萬筆資料中取出十筆的時間大約是 150ms。這種速度在使用上是毫無問題的，但如此一來毫無 Scalability 可言。問題之一是寫入的速度並不快，而且寫入過程資料庫便被鎖住，別說同時寫入，就是取用也是一個大問題。

於是，試著找一些可行的方案，如以 BigTable 為基礎的 Apache HBase, Hypertable，或是 Document-oriented database 類型的各式解決方案，如以 Erlang 開發的 Apache CouchDB, 基於 Facebook Thrift 架構的 ThruDB, Ruby 開發的 StrokeDB, 或 Java 為基礎的 FeatherDB。這些資料庫具備分散式且容錯的設計，而且都適合塞 schema-free 的資料。唯一的問題是你還是得自己架設一堆伺服器，才是「正」分散式、容錯設計。

直到最近 Google App Engine (視訊說明) 推出正式的服務租用價格，由於費用極為便宜，我便開始認真考慮是否可以把資料庫移到網路公司所提供的 Platform-as-a-Service。

Google App Engine 提供的是以 Python 語言為基礎網站應用軟體開發環境，其中提供 Datastore API，是基於 BigTable 上所開發，以提供了所謂 Scalable data-backed。另外一個價格與功能相仿便是 Amazon SimpleDB (但是 GAE 的硬碟儲存費用便宜多了)。這兩組服務所提供的都不是標準的 SQL 語法，而是特定的 API 搭配特製的查詢語法，Datastore 是 GQL, SimpleDB 則設計了自己的 query language.自然，網路上已經出現了根據此 document-oriented database 與 RDBMS 的交相論戰，如 Ryan Park 所寫的 Top 10 Reasons to Avoid the SimpleDB Hype 與 Yurii Rashkovskii (StrokeDB 的作者) 的回覆 Top 10 Reasons to Avoid Document Databases FUD。

對我而言，我並不需要 RDBMS 的特色，key-value 的資料庫形式已經可以滿足我的要求。問題在於系統是否可以處理我的需求，根據 High Scalability Todd Hoff 的文章指出，GAE 的 Datastore API 似乎有些速度上的問題、以及 Application Quotas 的限制，如此還必須實際再深入研究軟體的設計方式。而 Amazon SimpleDB 尚處於 Limited Beta 的狀態，因此還不能進行實際的評估。此外，目前這些方法還無法做 Path queries，是下一個研究方向。