zillion
v0.12.0
Zillion是一種數據建模和分析工具，可以通過簡單的API組合和分析來自多個數據源的數據。 SQL寫道，它是數據頂部的語義層，因此您不必這樣做，並且可以通過SQLalchemy Core輕鬆地將其螺栓固定到現有的數據庫基礎架構上。 Zillion NLP擴展具有對AI驅動的自然語言查詢和倉庫配置的實驗支持。
有Zillion您可以：
警告：該項目處於α國家，可能會發生變化。請仔細測試生產使用情況並報告任何問題。
$ pip install zillion
or
$ pip install zillion[nlp]以下內容旨在快速概述數據倉庫中使用的一些理論和命名Zillion ，如果您對該領域更新，這將很有用。您還可以跳過下面的使用示例或倉庫/數據源創建QuickStart選項。
簡而言之： Zillion為您寫入SQL，並通過非常簡單的API訪問數據：
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)在Zillion中，您的報告請求中將使用兩種主要Fields類型：
Dimensions ：用於標記，分組和過濾的數據的屬性Metrics ：可能沿維度分解的事實和措施一個Field封裝了數據中列的概念。例如，您可能有一個名為“收入”的Field 。該Field可能發生在幾個數據源中，也可能發生在單個數據源中的多個表中。 Zillion了解到所有這些列代表相同的概念，並且可以嘗試使用其中任何一個來滿足要求“收入”的報告。
同樣，有兩種主要的表用於構建您的倉庫：
Dimension Tables ：參考/屬性表僅包含相關維度Metric Tables ：可能包含指標和一些相關維度/屬性的事實表尺寸表通常是靜態的或在行計數方面逐漸增長，並且包含與主鍵相關的屬性。一些常見的示例將是美國郵政編碼或公司/合作夥伴目錄的列表。
公製表通常本質上是更大的交易。一些常見的例子將是網絡請求，電子商務銷售或股票市場價格歷史記錄的記錄。
如果您真的想深入了解尺寸建模，而Birs-across查詢技術則使用了Zillion ，我建議閱讀拉爾夫·金博爾（Ralph Kimball）的數據倉庫書。
總而言之，鑽孔查詢構成一個或多個查詢，以滿足報告要求在特定dimension粒的多個數據源和/或表中可能存在的metrics請求。
Zillion支持靈活的倉庫設置，例如Snowflake或Star Schemas，儘管對此並不挑剔。您可以通過親子譜係來指定表關係，而Zillion也可以根據尺寸表主鍵的存在來推斷可接受的連接。 Zillion目前不支持許多與眾不同的關係，儘管大多數以分析為中心的方案應該能夠通過在需要的情況下添加視圖來解決此問題。
可以將Zillion報告視為兩層運行：
DataSource Layer ：針對倉庫數據源的SQL查詢Combined Layer ：針對數據源層的組合數據的最終SQL查詢組合層只是另一個SQL數據庫（默認情況下是內存的SQLITE），用於將數據源數據連接在一起，並應用一些其他功能，例如匯總，行濾鏡，行限制，排序，樞軸和技術計算。
有多種方法可以快速從本地或遠程文件初始化倉庫：
# Path/link to a CSV, XLSX, XLS, JSON, HTML, or Google Sheet
# This builds a single-table Warehouse for quick/ad-hoc analysis.
url = "https://raw.githubusercontent.com/totalhack/zillion/master/tests/dma_zip.xlsx"
wh = Warehouse . from_data_file ( url , [ "Zip_Code" ]) # Second arg is primary key
# Path/link to a sqlite database
# This can build a single or multi-table Warehouse
url = "https://github.com/totalhack/zillion/blob/master/tests/testdb1?raw=true"
wh = Warehouse . from_db_file ( url )
# Path/link to a WarehouseConfigSchema (or pass a dict)
# This is the recommended production approach!
config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json"
wh = Warehouse ( config = config )千億美元還提供了一個輔助腳本來為現有數據庫boostrap buostrap。請參閱zillion.scripts.bootstrap_datasource_config.py 。 Bootstrap腳本需要一個連接/數據庫URL和輸出文件作為參數。有關更多選項，包括可選的--nlp標誌，請參閱--help輸出，該選項利用OpenAI推斷配置信息，例如列類型，表類型和表格關係。 NLP功能需要安裝NLP擴展名，以及Zillion配置文件中的以下設置：
Zillion的主要目的是針對Warehouse執行報告。在高水平上，您將按照以下方式製定報告：
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "=" , "Partner A" )
]
)
print ( result . df ) # Pandas DataFrame與編寫SQL相比，將尺寸視為SQL語句的組的目標列是有幫助的。將指標視為您正在匯總的列。將標準視為其中的條款。您的標準應用於數據源層SQL查詢。
ReportResult具有熊貓數據框架，其尺寸為索引和指標作為列。
據說有一份grain ，該Report定義了每個指標必須能夠加入的尺寸，以滿足Report要求。 grain是所有維度的組合，包括標准或公制公式中引用的穀物。在上面的示例中， grain將為{date, partner} 。 “收入”和“潛在客戶”都必須能夠加入這些維度，以使本報告成為可能。
這些概念可能需要時間才能沉入，並且顯然會隨數據模型的細節而變化，但是隨著您開始針對數據倉庫進行報告時，您會變得更加熟悉它們。
隨著NLP的擴展， Zillion對您的數據倉庫的自然語言查詢提供了實驗支持。例如：
result = warehouse . execute_text ( "revenue and leads by date last month" )
print ( result . df ) # Pandas DataFrame此NLP功能需要QDRANT（Vector Database）的運行實例，並且在您的Zillion配置文件中設置了以下值：
嵌入將產生並存儲在QDRANT和局部緩存中。矢量數據庫將在您第一次嘗試通過分析倉庫中的所有字段來初始化。此存儲庫的根部提供了一個用於運行QDRANT的示例Docker文件。
您可以控製字段如何嵌入。也就是說，在任何字段的配置中，您可以選擇是將字段從嵌入式或嵌入到該字段的層面上排除的字段。默認情況下所有字段都包含。以下示例將將net_revenue字段排除在嵌入，並將revenue指標請求映射到gross_revenue字段。
{
"name" : "gross_revenue" ,
"type" : "numeric(10,2)" ,
"aggregation" : "sum" ,
"rounding" : 2 ,
"meta" : {
"nlp" : {
// enabled defaults to true
"embedding_text" : "revenue" // str or list of str
}
}
} ,
{
"name" : "net_revenue" ,
"type" : "numeric(10,2)" ,
"aggregation" : "sum" ,
"rounding" : 2 ,
"meta" : {
"nlp" : {
"enabled" : false
}
}
} ,此外，您還可以通過以下倉庫級配置設置排除字段：
{
"meta" : {
"nlp" : {
"field_disabled_patterns" : [
// list of regex patterns to exclude
"rpl_ma_5"
] ,
"field_disabled_groups" : [
// list of "groups" to exclude, assuming you have
// set group value in the field's meta dict.
"No NLP"
]
}
} ,
...
}如果在上述任何一個級別上禁用字段，它將被忽略。這種類型的控件變得有用，因為您的數據模型變得更加複雜，並且您想在可能混淆類似命名字段的情況下指導NLP邏輯。每當您調整哪些字段被排除在外時，您都需要使用Warehouse.init_embeddings上的force_recreate標誌強制嵌入嵌入收集。
注意：此功能還處於起步階段。它的有用性取決於輸入查詢和您的數據模型的質量（即好的字段名稱）！
除了配置Warehouse的結構（將在下面的進一步討論）外， Zillion還具有全局配置來控制某些基本設置。 ZILLION_CONFIG環境VAR可以指向YAML配置文件。有關可以設置哪些值的更多詳細信息，請參見examples/sample_config.yaml 。帶有Zillion_前綴的環境可以覆蓋配置設置（即Zillion_db_url將覆蓋DB_URL）。
可以通過將Zillion配置中的db_url值設置為有效的數據庫連接字符串來配置用於存儲千億美元報告規格的數據庫。默認情況下，使用 /tmp中的sqlite db。
在下面，我們將瀏覽一個簡單的假設銷售數據模型，該模型展示了基本的DataSource和Warehouse配置，然後顯示一些示例報告。數據是一個簡單的SQLITE數據庫，是Zillion測試代碼的一部分。作為參考，該模式如下：
CREATE TABLE partners (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL UNIQUE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE campaigns (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL UNIQUE,
category VARCHAR NOT NULL ,
partner_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE leads (
id INTEGER PRIMARY KEY ,
name VARCHAR NOT NULL ,
campaign_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE sales (
id INTEGER PRIMARY KEY ,
item VARCHAR NOT NULL ,
quantity INTEGER NOT NULL ,
revenue DECIMAL ( 10 , 2 ),
lead_id INTEGER NOT NULL ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);可以通過JSON或YAML配置創建Warehouse ，該配置定義其字段，數據量和表。下面的代碼顯示，如果您有指向JSON/YAML Warehouse配置的指針，則如何在一行代碼中完成。
from zillion import Warehouse
wh = Warehouse ( config = "https://raw.githubusercontent.com/totalhack/zillion/master/examples/example_wh_config.json" )此示例配置在其DataSource connect中使用data_url信息，該信息告訴Zillion ，以動態下載數據並將其連接到SQLITE數據庫中。這對於快速示例或分析很有用，儘管在大多數情況下，您會將連接字符串放在現有數據庫中，就像您在此處看到
Zillion's倉庫配置結構的基礎如下：
Warehouse配置具有以下主要部分：
metrics ：全局度量標準配置的可選列表dimensions ：全局維度尺寸配置的可選列表datasources ：數據源名稱到數據源配置或配置URL的映射DataSource配置具有以下主要部分：
connect ：數據庫連接URL或連接參數的distmetrics ：特定於此數據源的公製配置的可選列表dimensions ：特定於此數據源的尺寸配置的可選列表tables ：將表名稱映射到表配置或配置URL提示：數據源和表配置也可以用指向本地或遠程配置文件的URL替換。
在此示例中，我們的數據庫中的所有四個表都包含在配置中，兩個作為尺寸表，兩個作為度量表。表通過父母的關係：競選活動的合作夥伴並導致銷售。一些表還利用create_fields標誌從列定義從數據源上自動創建Fields 。其他指標和維度是明確定義的。
要查看Init之後此Warehouse的結構，您可以使用print_info方法，該方法顯示所有是數據倉庫一部分的指標，尺寸，表和列：
wh . print_info () # Formatted print of the Warehouse structure有關配置模式的更深入研究，請參閱完整的文檔。
示例：獲得合作夥伴的銷售，潛在客戶和收入：
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" ]
)
print ( result . df )
"""
sales leads revenue
partner_name
Partner A 11 4 165.0
Partner B 2 2 19.0
Partner C 5 1 118.5
"""示例：讓我們限制合作夥伴A並因其廣告系列而分解：
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "campaign_name" ],
criteria = [( "partner_name" , "=" , "Partner A" )]
)
print ( result . df )
"""
sales leads revenue
campaign_name
Campaign 1A 5 2 83
Campaign 2A 6 2 82
"""示例：下面的輸出顯示了每個合作夥伴內活動級別的匯總，以及在合作夥伴和活動級別上的總數。
注意：輸出包含一個特殊字符，以標記添加到結果中的數據幀匯總行。記錄對象包含一些用於自動訪問或過濾匯總的輔助屬性，以及
df_display屬性，該屬性返回結果，返回結果，以友好的顯示值替換為特殊字符。在此處留下的特殊角色以供插圖，但在所有情況下可能並不相同。
from zillion import RollupTypes
result = wh . execute (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" , "campaign_name" ],
rollup = RollupTypes . ALL
)
print ( result . df )
"""
sales leads revenue
partner_name campaign_name
Partner A Campaign 1A 5.0 2.0 83.0
Campaign 2A 6.0 2.0 82.0
� 11.0 4.0 165.0
Partner B Campaign 1B 1.0 1.0 6.0
Campaign 2B 1.0 1.0 13.0
� 2.0 2.0 19.0
Partner C Campaign 1C 5.0 1.0 118.5
� 5.0 1.0 118.5
� � 18.0 7.0 302.5
"""有關支持的匯總行為的更多信息，請參見Report文檔。
示例：保存報告規格（不是數據）：
首先，您必須確保已保存Warehouse ，因為保存的報告範圍範圍為特定的Warehouse ID。要保存Warehouse ，您必須提供指向完整配置的URL。
name = "My Unique Warehouse Name"
config_url = < some url pointing to a complete warehouse config >
wh . save ( name , config_url ) # wh.id is populated after this
spec_id = wh . save_report (
metrics = [ "sales" , "leads" , "revenue" ],
dimensions = [ "partner_name" ]
)注意：如果您從
DataSources列表中構建了python的Warehouse，或以init的configparam on Initdict，那麼當前沒有一種內置方法可以在保存時將完整的配置輸出到文件中以供參考。
示例：從規格ID加載並運行報告：
result = wh . execute_id ( spec_id )這是假設您以前已將此報告ID保存在db_url在Zillion美元配置中指定的數據庫中。
示例：未支撐的穀物
如果您嘗試了不可能的報告，您將獲得UnsupportedGrainException GrainException。下面的報告是不可能的，因為它試圖通過僅存在於子表中的維度來分解潛在客戶指標。一般而言，兒童桌子可以與父母（父母的“兄弟姐妹”）相連，以找到維度，但不能相反。
# Fails with UnsupportedGrainException
result = wh . execute (
metrics = [ "leads" ],
dimensions = [ "sale_id" ]
)有時，您需要類似子查詢的功能才能將一個報告過濾到其他一些結果（可能需要不同的穀物）的結果。千億美元提供了一種簡單的方法，可以通過在not in report標準操作中使用in report或不使用報告。有兩種支持的方法來指定子報告：傳遞報告規格ID或傳遞報告參數的dist。
# Assuming you have saved report 1234 and it has "partner" as a dimension:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "in report" , 1234 )
]
)
# Or with a dict:
result = warehouse . execute (
metrics = [ "revenue" , "leads" ],
dimensions = [ "date" ],
criteria = [
( "date" , ">" , "2020-01-01" ),
( "partner" , "in report" , dict (
metrics = [...],
dimension = [ "partner" ],
criteria = [...]
))
]
) in report是否在not in report使用的標準字段必須是子報告中的一個維度。請注意，子報告是在Report對像初始化時間而不是在execute過程中執行的 - 因此，它們無法使用Report.kill殺死它們。這可能會改變道路。
在上面的示例中，我們的配置包括一個基於公式的指標，稱為“ RPL”，它只是revenue / leads 。 FormulaMetric結合了其他指標和/或維度，以在查詢的組合層處計算新的度量。語法必須匹配您的組合圖層數據庫，該數據庫在我們的示例中是SQLITE。
{
"name" : " rpl " ,
"aggregation" : " mean " ,
"rounding" : 2 ,
"formula" : " {revenue}/{leads} "
}為了方便起見，您不必重複定義核心度量的速率變體的公式指標，而是可以在非格式公制上指定除數公式的配置。例如，假設您有revenue指標，並希望為revenue_per_lead和revenue_per_sale創建變體。您可以按以下方式定義收入指標：
{
"name" : " revenue " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"divisors" : {
"metrics" : [
" leads " ,
" sales "
]
}
}有關配置選項的更多詳細信息，例如覆蓋命名模板，公式模板和舍入，請參見zillion.configs.DivisorsConfigSchema
另一個較小的便利功能是能夠自動生成單個字段配置中不同聚合類型的指標變體，而不是配置文件中的多個字段。例如，假設您的數據中有一個sales列，並希望為sales_mean和sales_sum創建變體。您可以按以下方式定義指標：
{
"name" : " sales " ,
"aggregation" : {
"mean" : {
"type" : " numeric(10,2) " ,
"rounding" : 2
},
"sum" : {
"type" : " integer "
}
}
}由此產生的倉庫將沒有sales指標，而是擁有sales_mean和sales_sum 。請注意，您可以通過在該聚合類型的嵌套設置中指定該設置的生成字段的設置，例如設置自定義名稱。在實踐中，這不是分別定義指標的效率，但有些人可能更喜歡這種方法。
也存在針對FormulaDimension領域的實驗支持。 FormulaDimension只能將其他維度用作其公式的一部分，並且還可以在組合圖層數據庫中進行評估。作為另一個限制，由於在數據源層中評估了這些過濾器，因此無法在報告標準中使用FormulaDimension 。下面的示例假定一個SQLite組合圖層數據庫：
{
"name" : " partner_is_a " ,
"formula" : " {partner_name} = 'Partner A' "
}我們的示例還包括一個度量“銷售”，其價值是通過在查詢數據源層上通過公式計算的。在“ main.sales”表中的“ ID”參數的fields列表中註意以下內容。這些公式在特定DataSource數據庫技術的語法中，在我們的示例中也恰好是SQLITE。
"fields" : [
" sale_id " ,
{ "name" : " sales " , "ds_formula" : " COUNT(DISTINCT sales.id) " }
]我們的示例還自動從線索和銷售表的“創建”列中創建了一些維度。支持自動類型轉換是有限的，但是對於支持的DataSource技術中的日期/日期列列，您可以通過這種方式免費獲得各種維度。
wh.print_info的輸出將顯示添加的尺寸，該維度由每個表中的配置中的可選type_conversion_prefix指定的前綴為“ leds_”或“ sale_”。我們的示例倉庫中的自動生成維度的一些示例包括sale_hour，sale_day_name，sale_month，sale_year等。
作為基礎報告查詢的Where子句中的優化， Zillion將嘗試將轉換應用於標準值而不是列。例如，查詢為my_datetime > '2020-01-01' and my_datetime < '2020-01-02'而不是DATE(my_datetime) == '2020-01-01' ，通常更有效地有效，因為後者可以在許多數據庫技術中預防索引使用。將轉換為值而不是列的能力也隨字段和DataSource技術而變化。
要防止鍵入轉換，請將skip_conversion_fields設置為true在您的DataSource配置上。
有關當前支持的轉換的更多詳細信息，請參見zillion.field.TYPE_ALLOWED_CONVERSIONS and zillion.field.DIALECT_CONVERSIONS 。
您還可以在每個報告請求中定義“臨時”指標。以下是一個示例，它可以隨時創建一個逐步的度量。這些僅存在於報告的範圍內，該名稱不能與任何現有字段衝突：
result = wh . execute (
metrics = [
"leads" ,
{ "formula" : "{revenue}/{leads}" , "name" : "my_rpl" }
],
dimensions = [ "partner_name" ]
)您還可以在每個報告請求中定義“臨時”尺寸。下面是一個示例，該示例創建了一個尺寸，該維度可以在特定維度值上分配。臨時維度是FormulaDimension S的子類，因此具有相同的限制，例如無法將度量作為公式字段。這些僅存在於報告的範圍內，該名稱不能與任何現有字段衝突：
result = wh . execute (
metrics = [ "leads" ],
dimensions = [{ "name" : "partner_is_a" , "formula" : "{partner_name} = 'Partner A'" ]
)Zillion還支持在DataSource或Warehouse init期間在數據庫中的臨時表的創建或同步。此處顯示的表配置的示例。它使用表配置的data_url和if_exists參數來控制SQLite數據庫中遠程CSV的“ main.dma_zip”表的同步和/或創建。在其他數據庫類型中也可以做同樣的事情。
這種方法的潛在性能弊端應該是顯而易見的，尤其是如果您經常初始化倉庫或遠程數據文件很大。通常最好提前同步和創建數據，以便您擁有完整的模式控制，但是在某些情況下，此方法可能非常有用。
警告：請注意不要覆蓋數據庫中的現有表！
可以將多種技術計算應用於指標來計算滾動，累積或等級統計。例如，為了計算收入的5分移動平均值，一個人可能會定義一個新的指標：如下：
{
"name" : " revenue_ma_5 " ,
"type" : " numeric(10,2) " ,
"aggregation" : " sum " ,
"rounding" : 2 ,
"technical" : " mean(5) "
}技術計算是在組合層上計算的，而“聚合”是在數據源層進行的（因此需要在上面定義這兩個）。
有關速記技術字符串如何解析的更多信息，請參見parse_technical_string代碼。有關支持的技術類型的完整列表，請參見zillion.core.TechnicalTypes 。
技術還支持兩種模式：“組”和“全部”。該模式控制如何在數據維度上應用技術計算。在“組”模式下，它計算了最後一個維度的技術，而在“所有”模式中，“所有”模式在所有數據上計算技術，而無需考慮維度。
如果您嘗試在[“ panters_name”，“ date”]類似的數據中進行“庫姆”技術，那麼這一點將變得更加清楚。如果使用“組”模式（在大多數情況下默認）將在每個合作夥伴內在日期範圍內進行累積總和。如果使用“所有”模式，它將在每個數據行中進行累積總和。您可以通過將模式附加到技術字符串上來明確說明該模式：IE“ cumsum：ass ass”或“平均（5）：group”
如果您想避免將敏感的連接信息直接放在DataSource配置中，則可以利用配置變量。在您Zillion YAML配置中，您可以指定DATASOURCE_CONTEXTS部分，如下所示：
DATASOURCE_CONTEXTS :
my_ds_name :
user : user123
pass : goodpassword
host : 127.0.0.1
schema : reporting然後，當讀取名為“ my_ds_name”數據源DataSource配置時，它可以使用此上下文來填充連接URL中的變量：
"datasources" : {
"my_ds_name" : {
"connect" : " mysql+pymysql://{user}:{pass}@{host}/{schema} "
...
}
}在Warehouse INIT上，您可以按名稱指定數據量的默認優先順序。當多個數據源可以滿足報告時，這將發揮作用。列表中較早的DataSources將是更高的優先級。如果您想偏愛將DataSource中的一組更快的匯總表組成的速度，這將很有用。
wh = Warehouse ( config = config , ds_priority = [ "aggr_ds" , "raw_ds" , ...])Zillion's目標是支持SQLalchemy支持的任何數據庫技術（如下圖所示）。那就是當前Zillion支持和測試水平變化。特別是，進行鍵入轉換，數據庫反射和殺死的能力都需要一些數據庫特定的代碼來支持。以下列表總結了已知的支持級別。 SQLalchemy支持的未經測試的數據庫技術可能會有所不同（它可能效果很好，尚未經過測試）。請報告錯誤並幫助添加更多支持！
Sqlalchemy具有許多流行數據庫的連接器。考慮到Zillion操作的簡單性質，支持其中許多的障礙可能很低。
請注意，以上與組合圖層數據庫的數據庫支持不同。目前，那裡只有Sqlite。對於大多數用例，這應該足夠，但是將在道路上增加更多選擇。
如果您打算在多進程方案中運行Zillion ，無論是在一個節點上還是跨多個節點，都有幾件事要考慮：
請注意，您仍然可以在沒有問題的情況下使用默認的SQLite內存中組合db，因為這是在每個報告請求時即時進行的，並且不需要與其他過程或節點的協調/通信。
數十億個Web UI是一個千億美元的演示UI和Web API，還包括一個實驗性Chatgpt插件。有關安裝和項目結構的更多信息，請參見README。請注意，該代碼是測試和拋光劑的燈光，但有望在現代瀏覽器中使用。此刻，ChatGpt插件也很慢，因此目前主要是為了娛樂而不是那麼有用。
可以在此處找到更徹底的文檔。您可以通過仔細閱讀測試目錄或API參考來補充知識。
請參閱貢獻指南以獲取更多信息。如果您正在尋找靈感，添加支持和測試其他數據庫技術將是一個很好的幫助。
