Category: Web

網頁技術

Posted on
by

之前在研究相關的 RDF Store 時，讀到 Christian Becker 所作的一篇測試報告。他利用 DBpedia 的資料，塞進幾個不同的 RDF stores 中作效能測試。測試的資料庫包含 OpenLink Virtuoso Open-Source Edition、SDB Beta 1 與 OpenRDF Sesame 2.0。

根據他的測試報告，OpenLink Virtuoso 的效能之傑出，而且只稍微做了設定調整，讓我不經想拿來測試一番。

DBpedia 的資料來源取於 Wikipedia，概念是從 Wikipedia 的文章中萃取出結構性的資訊 (structured information)，並開放下載使用。因此你可取得上百萬件 Wikipedia 中描述的人、事、物的後設資料。

Christian 測試的資料庫包含 DBpedia 的 infobox templates, geo-coordinates 與 Wikipedia 外部連結。資料總數超過一萬六千筆。依據 Christian Becke 的數據，Virtuoso 載入一千五百萬 triples 大約只需兩小時而已，速度與其他的資料庫比起來快上幾倍。而查詢的速度，除了只對 Subject 進行的查詢比其他的方案慢之外，稍微複雜的 SPARQL 速度都遠比其他的方案快多了。

OpenLink Software 的 Virtuoso Universal Server 是一個相當複雜 (但有趣) 的軟體，他的核心基本是資料庫與中介軟體，混合提供各種功能，包含 ORDBMS, SQL (RDBMS), XML, RDF, Web Server 與檔案伺服器。單一的軟體包含了各種功能，配合底層使用的 OpenLink Data Spaces，你可以介接大量不同的第三方資料庫，再提供網頁或 Web Services 以便界接其他的軟體。甚至你可以將其他資料庫或檔案，轉成 RDF，因此可以當作 Federated database system 來用。

適用領域包含企業的知識庫系統、或者是 Semantic Web。功能如此強大的資料庫，操作也不特別容易，專案提供了完整文件，引出來要超過兩千頁啊啊。

Posted on
by

週二出席 Tossug 聚會的時候，來了一位英國來的外國朋友。由於外國朋友雖然來了台灣八九個月，但是尚未學會中文。在辨識中文字上有很大的困難，而且很難自行透過查字典的方式學習。

他分享了一個線上字典網站，叫 N 詞酷 (nciku.com)，這網站居然整合了線上手寫辨識，就算不知道怎麼發音，也可以試著繪出中文字，系統會自動辨識。對外國朋友實在方便！

據聞是整合了北京書同文公司巧筆系統，辨識率不差呢。John Pasden 為 Nciku 做了一些有趣的辨識率測試。


Source: John Pasden, nciku

Posted on
by

剛剛試著查找一些 GAE 的相關應用資訊的時候，在 App Gallery 上看到幾個還算不錯的好玩網站，其中不少 Twitter 類似或使用 Twitter 資料的網站 (因為 twitter 越來越難用了?)

如果你還不知道 GAE 是甚麼，不妨花幾分鐘聽一下 Google 在 Campfire One 的簡短說明，其中 Guido van Rossum (Python 的作者, Google App Engine 成員之一) 也給了一段演講

Campfire One: Introducing Google App Engine (pt. 1)

Campfire One: Introducing Google App Engine (pt. 2)

Campfire One: Introducing Google App Engine (pt. 4)

Campfire One: Introducing Google App Engine (pt. 5)

Campfire One: Introducing Google App Engine (pt. 6)

Posted on
by

長久以來，一直為了一個小小的資料庫系統尋找適合的解決方案。這個系統的基本概念是要建立一個可以大量收集與處理 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，是下一個研究方向。