前情提要：

政府/企業/學研單位開始使用關聯式資料庫，加上網際網路的流行，讓資料的讀取成為一種共同的需求。從此用料者不再侷限於備料者所能提供的資料格式，開始參與了備料工具的演進方向，使原本以硬體為主的「資料存取標準」，變成以軟體為主的「資料交換標準」。

本文：

關聯式資料庫的出現，使「用料者」滿足了查詢速度的需求並統一了查詢方式，但是由於網際網路促成資料的溝通交換，許多以前覺得還沒那麼急著要建置的資料也一個一個的累積起來。舊的設備還要拿來儲存舊資料的時候，新的專案又買了新的設備儲存新的資料。如果哪天單位的首長/企業的老闆/研究單位的主管決定要把兩個系統的資料庫混成一個、或是看能不能這樣那樣的把幾個資料庫接在一起用，那就頭大了。RDBMS是一個要先有個關聯架構才能快速調閱資料的東西，但是也正因為這樣的關聯式架構，讓資料的更新變得要花些時間下去處理，來確保新的資料都能依照這樣的相關性放到資料庫裡適當的位置。這樣正確性的要求在同一個資料庫系統裡面或許還算合理，但是如果系統不只一個，想要查詢的資料又需要藉由系統之間相同的某個欄位來作關聯，那系統和系統之間就不只是正確性的問題而已，還得要求不同系統之間裡同時間同一種資料都要一模一樣才行。想當然耳，資料的更新就要花更多的時間，來確保所有系統間同一種資料都一模一樣了。更麻煩的是，資料在進行更新的時候如果有使用者剛好要查詢這筆資料，系統就會因為不知道該給舊的資料還是給新的資料，得要等一陣子確定資料對了才會把新資料呈現給使用者看到。

如果是絕對不能出差錯的資料，等個幾秒沒看到電腦的反應似乎也還算合理可接受。但是如果是個隨時都在變動的超大型資料庫都用RDBMS來作資料的存取，例如使用臉書時按個讚都要等5秒確定資料庫內容已經更新才有反應，那還不如先讓我知道資料庫系統已經接到按讚的指令，等個5秒之後再去更新資料庫系統的內容讓對方也知道知道我已經按讚了。基於這樣「當下不用太正確但是要先給我一個交代而且記得要把東西趕快改對」的需求，許多的NoSQL資料庫因應而生，主打擴充性、即時反應以外，資料可以分散在不同的系統，而且不用整個資料庫都定義關聯式架構。

這是「備料者」的第四階段演進。即時反應成為主流，儲存的資料可以散佈在許多機器上面，而且因為這樣讓更多人可以一起使用資料庫，讓更多的資料可以儲存在分散世界各地相互連結的同一群主機資料系統下，提供更多樣性的服務。也因為這樣即時且廣布的特性，誘使更多人使用這種資料基礎下所開發的不同服務，進而產生更多的使用者行為資料，像是某類的使用者買了什麼東西，或是某個人對某類文章一定會按讚之類的。雲端計算和NoSQL緊密的結合，讓「用料者」得以發揮更多的創意，組合運用「備料者」所提供的多樣化數據，達成許多意想不到的功能，間接造成使用者行為資料的暴增，形成另一種多樣化的數據，促成了big data的潮流。

這下「用料者」有了NoSQL這種工具，應該如虎添翼，什麼神奇的東西都可以生出來了吧？事情其實沒這麼簡單。因為所謂「NoSQL這種工具」，不是單純的一種工具。他不只代表了好幾種的工具，而且是好幾種沒有標準、甚至架構都不一樣的工具啊！這就像是一個台灣人想要去印度各地接觸真正的在地文化所以想學「印度語」，結果發現印度語竟然超過二十種、而且各種語言幾乎都不一樣的令人崩潰。

幸好大部分的NoSQL都有提供一些簡單的API可以使用。所謂的API就像是觀光客用的字典，查詢的方法很容易學，前提是你要會認頁碼、而且知道什麼時候要翻到哪一頁。簡單的說，就是使用者跟電腦說我要這樣那樣的資料/結果，請你幫我找出來/算出來。在網際網路的世界，API最常被設計成使用REST語法進行查詢，而系統回應時也大概脫離不了使用JSON或是XML這兩種資料交換格式來告訴使用者答案是什麼。至於REST的語法、JSON和XML的結構等等Wikipedia上面都說得很清楚，這裡就不多說。使用API或許不是個理想的解決方案，但是一般使用上來說也算是可以接受的了。

「備料者」在不同的NoSQL資料庫需要使用不同的資料交換格式，那open data要用NoSQL來更新發布資料的話，該怎麼作？難不成同一組資料所有的NoSQL資料庫種類都來建一套系統？也不是。前面說的NoSQL資料庫使用方法幾乎都不一樣，卻也大致可以分成key-value、document、column(big table)和graph四大門派，各門派各自的存取速度和資料關聯性也都有所差異。其中graph database是最特別的門派，因為它雖然可以擴充、資料可以分散在不同系統，但是卻可以保有資料的一致性。這個特色讓資料需要具備一致性的open data有了可以前進的方向。另外，要說NoSQL沒有資料交換標準其實是不公平的，因為所有林林總總的NoSQL資料庫中、graph database這個門派裡，有一個叫做RDF的國際資料交換標準、而且還有SPARQL這個標準查詢語言可以使用。(是說所有的NoSQL中也只有這個交換標準就是了。)

事實上，RDF資料標準在網際網路之父Sir Timothy John Berners-Lee所倡導的open data五個星等中，是明確且唯一一個在四星級以上的資料中被建議使用的標準。RDF最特別的地方，在於他是唯一一個在open data的「備料者」和big data 「用料者」之間都能看到的國際標準NoSQL資料類別，而且各種門派的NoSQL資料庫，看來也開始可以容納RDF格式的資料並提供SPARQL進行查詢，甚至有分散式的NoSQL資料庫除了可以載入外來RDF資料、用自己的語言進行查詢以外，還可以在自己的記憶體裡產生RDF資料、間接使用SPARQL語法快速查詢自己的資料庫內容。

雖然國內政府單位鮮少生產四星級以上的RDF資料，但在技術上產生四星級以上的open data要採用RDF標準這件事應該是沒有疑慮才對。即使不是按照RDF的格式產生的資料，也至少要可以用D2RQ等等的工具將RDBMS變成虛擬的RDF資料庫讓SPARQL可以查詢(雖然這樣會限制資料的擴充性)。至於未來台灣的open data能釋出多少有趣的資訊，big data陣營又能使用這樣的open data產生怎樣的應用，以這個談論平台要討論的內容來說目前還不算清楚的新知。這邊能聊的，也只好暫時停在「備料者」和「用料者」之間如何相互促成資訊科技的發展，來當作一個資料科技的片段回顧。

最後，這次的「新知」主題雖然表面上看來和GIS沒太大關聯，但以當下的GIS應用程式重視即時反應和大量資料處理的特性來說，卻又顯得息息相關。接下來的GIS最新技術會往哪個方向發展雖然沒幾個人敢下定論，但是以歷史的軌跡來看必然和系統反應效率還有內容如何更貼近使用者有關。這邊能作到的，就是貢獻一些時間，以庶民的觀點提供資料標準的發展而已，希望藉此讓大家在探索新技術時，能夠有個過去的軌跡可以依循。

後記：
雖說NoSQL是為了突破RDBMS的限制所發展出來的，但是雲端時代的RDBMS也是有在進步的。目前看來誰贏誰輸還不清楚，而且似乎可以相互合作呢！有興趣的人可以參考Google拍攝的這個有趣的SQL/NoSQL(假裝)辯論影片。