DDIA閱讀紀錄(5) – 第二章續:初探Graph Data Model大觀園

(進度:loc 1327 – 1668,昨天沒能抽空出來寫,因此這是兩天各讀個20分鐘左右的量。希望以後可以盡量避免這個情形)

從這個段落開始,本章堂堂從個人略懂得relational model與document-based model進入Graph data model。作者手先帶讀者認識上圖的範例,接著用PostgreSQL的語法示範這樣的資料在relational資料庫中可能會長什麼樣子,再引領讀者思考我們可以「問」這dataset的問題,例如:哪些人出生在英國但目前住在美國。透過這樣的思考練習,很快就會發現,雖然我們可以把這樣的資料在relational database裡表述出來,但query會非常難寫。以上例來說,透過「within」表現的從屬「美國」的「地區」關係很難預先說有多少層,這代表很難預先知道到底要寫幾個join,雖然有些資料庫現在有recursive join這種超魔幻的東西,但 … 就太魔幻了。在這基礎下,本章開始介紹Cypher QL與neo4jSPARQL與Triple-Stores,以及因為異曲同工之妙而常被放在一起討論的RDF和semantic web。

因為我過去從來沒接觸過這種database,整個段落讀來讓我覺得眼界大開。雖然沒有實際用過,但我還蠻喜歡triple stores的概念的:不刻意區分vertices與edges,而是把一切都編為"subject-predicate-object"的三元組。因此,Cypher QL在撰寫時會需要考量到條件式放的是vertices還是edge,SPARQL可以不用考慮這件事。當然,實用起來我會不會還持同樣意見就是未知數了。

段落的最後作者花了一整頁的篇幅解釋Graph data model與前面提過已經凋零的network model的不同。雖然概念上同樣都是表現graph,但兩者的實際資料結構差異使。總結起來個人覺得最關鍵的差異有二:其一,network model真的把資料存儲成巢狀結構,因此要存取entities的唯一方法就是真的去巡覽整個graph;但Graph data model並沒有這個限制,必要的時候甚至可以用直接的index來存取各entities。其二:network model因為這樣的設計,只能用imperative query language而非像graph data model有很好的declarative query language可以使用。對於QL方面的差異,我想network model如果活得夠久搞不好能獲得解決,但也有可能先天上的限制讓它無法這麼做就是了。

下一段的標題是「The foundation: Datalog」,又是一個完全沒看過的東東,令人期待。

發表留言

Please log in using one of these methods to post your comment:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.