未來幾周，一個新的開源對象關(guān)系數(shù)據(jù)庫EdgeDB將發(fā)布其首個公開預(yù)覽版。先讓我們了解一下構(gòu)建EdgeDB的原因。
動機
數(shù)據(jù)庫一直是，并將永遠是任何技術(shù)堆棧的決定性部分。在過去的十年中，數(shù)據(jù)庫市場發(fā)生了很多變化。在10年前，沒有MongoDB，沒有云數(shù)據(jù)庫，甚至云本身也是一個相對較新的概念。今天，有大量的數(shù)據(jù)庫解決方案使用非關(guān)系數(shù)據(jù)模型，承諾使數(shù)據(jù)可擴展和對開發(fā)人員友好。
但顯然后半部分變得難以捉摸。NoSQL數(shù)據(jù)庫的文檔使初始無模式原型設(shè)計階段變得簡單，但是隨著時間的推移往往會增加技術(shù)負累。保持總體數(shù)據(jù)和模式一致性以及對無模式數(shù)據(jù)執(zhí)行復(fù)雜分析要比傳統(tǒng)RDBMS難得多。
如果有人為他們的新項目選擇數(shù)據(jù)庫解決方案，他們很可能會選擇一個關(guān)系數(shù)據(jù)庫。因為可預(yù)測的性能，強大的查詢語言以及一致性保證是所有RDBMS在市場上占主導(dǎo)地位的原因，并且在很大程度上不受質(zhì)疑。
然而，關(guān)系數(shù)據(jù)庫是建立在一個數(shù)十年前的模型之上，并且越來越不適合迅速轉(zhuǎn)變的軟件開發(fā)領(lǐng)域。當(dāng)然，PostgreSQL正在不斷地進行改進，提供諸如高級JSON支持，查詢并行化和JIT編譯器等功能，以進一步提高復(fù)雜查詢的性能。但是，應(yīng)用程序與關(guān)系數(shù)據(jù)庫的接口方式?jīng)]有發(fā)生有意義的變化。我們?nèi)匀皇褂镁徛腛RM，與模式遷移較勁，并編寫糟糕的臨時SQL查詢。
對象關(guān)系
大多數(shù)軟件工程師不會考慮表格。我們的編程語言是圍繞類型和對象等更高級別的抽象構(gòu)建的。如果你有兩個對象A和B，并且想引用另一個對象，那么你只需寫Ab = B。為了在關(guān)系數(shù)據(jù)庫中做同樣的事情，你需要處理外鍵，連接，有時還需要處理中間表，本質(zhì)上直接在低得多的抽象層次上工作。
關(guān)系數(shù)據(jù)庫和現(xiàn)代編程語言之間的這種不一致已為人所知，甚至有一個名稱：面向?qū)ο缶幊膛c關(guān)系型數(shù)據(jù)庫間的不一致(object-relational impedance mismatch)。這就是ORM如此受歡迎的原因，以及為什么對GraphQL等技術(shù)有如此多的興趣。這些解決方案的問題在于他們試圖彌合與應(yīng)用方面的差距，要么犧牲底層數(shù)據(jù)庫的表現(xiàn)力，要么實施過度復(fù)雜的映射，這在很大程度上破壞了目的。雖然業(yè)界似乎癡迷于解決規(guī)模問題，但并沒有認真嘗試解決數(shù)據(jù)庫方面的對象關(guān)系不匹配問題。
EdgeDB
EdgeDB是下一代對象關(guān)系數(shù)據(jù)庫。它實現(xiàn)了一個對象圖模型，而不是關(guān)系模型。在這個模型中，數(shù)據(jù)被描述和存儲為強類型對象和關(guān)系，或者它們之間的鏈接。對象和鏈接可以保存屬性：一組命名的標(biāo)量值。這個模型有時被稱為屬性圖模型。
EdgeDB不是圖數(shù)據(jù)庫：數(shù)據(jù)使用關(guān)系數(shù)據(jù)庫技術(shù)存儲和查詢，并且需要嚴(yán)格的模式。
EdgeDB不是一個文檔數(shù)據(jù)庫，但插入，修改和查詢層次化的文檔類數(shù)據(jù)是微不足道的。
EdgeDB不是傳統(tǒng)的對象數(shù)據(jù)庫。盡管“object-relational”中有“object”這個詞，但它不是OOP持久性或封裝的實現(xiàn)。它具有表達式查詢語言EdgeQL，其目標(biāo)是匹配并超越現(xiàn)代SQL功能，如子查詢，高級聚合和窗口函數(shù)。
EdgeDB基于PostgreSQL，并繼承了它的所有優(yōu)勢：可靠性，ACID合規(guī)性和性能。
一個例子
為了讓我們對EdgeDB有一個小小的了解，我們來定義一個簡單的模式，用我們的模式DSL來描述一個基本的類似GitHub的應(yīng)用程序：
# Define a string enumerated type for
# pull request status.
scalar type pr_status extending str:
constraint enum('Open', 'Closed', 'Merged')
# Pull request object type definition.
type PullRequest:
required property title -> str
required property status -> pr_status:
default := 'Open'
# Pull request "author" as a to-one
# link to a User object.
required link author -> User
# Many-to-many relationship with
# different User objects.
link assignees -> User:
cardinality := '**'
type User:
required property name -> str
link followees -> User:
cardinality := '**'
現(xiàn)在讓我們來看看EdgeQL中的一個簡單查詢：
SELECT User {
id,
name,
followees: {
id,
name
}
}
FILTER
User.name = 'Alice';
查詢將返回名稱為“Alice”的所有用戶以及她關(guān)注的所有用戶的列表。數(shù)據(jù)可以以客戶端編程語言中的豐富對象或JSON的形式返回。以下是可比較的SQL查詢的樣子：
SELECT
users.id,
users.name,
array_agg(followees.id) AS followee_ids,
array_agg(followees.name) AS followee_names
FROM
users
LEFT JOIN user_followees ON
user_followees.user_id = users.id
LEFT JOIN users AS followees ON
followees.id = user_followees.followee_id
WHERE
users.name = 'Alice'
GROUP BY
users.id, users.name;
請注意，此SQL查詢效率不高。有經(jīng)驗的開發(fā)人員會重寫它以使用子查詢。另外，要將查詢的結(jié)果作為JSON，需要更多的努力。
下面是一個稍微更高級的EdgeQL查詢示例，它顯示了聚合和反向鏈接導(dǎo)航。
SELECT User {
name,
# Count the number of users who follow this user
# by traversing the "followees" link *backwards*,
# as denoted by '.<'
followed_by_count := count(User.<followees),
# Count the number of users that this user is
# following by traversing the "followees" link
# *forwards*, as denoted by '.>' or simply '.'
follow_count := count(User.followees),
# Get a set of open pull requests that this
# user is the assignee of.
open_prs := User.<assignee[IS PullRequest] {
title
} FILTER .status = 'Open'
};
示例JSON輸出：
[
{
"name": "Alice",
"followed_by_count": 101,
"follow_count": 45,
"open_prs": [
{
"title": "Implement support for window functions."
},
...
]
},
...
]
