主頁 > 資料庫 > 聊聊簡單又不簡單的圖上多跳過濾查詢

聊聊簡單又不簡單的圖上多跳過濾查詢

2023-04-14 09:26:12 資料庫

摘要:多跳查詢能力也是一個衡量產品性能非常重要的指標,

本文分享自華為云社區《聊聊超級快的圖上多跳過濾查詢》,作者:弓乙,

在圖資料庫/圖計算領域,多跳查詢是一個非常常用的查詢,通常來說以下型別的查詢都可以算作是多跳過濾查詢:

1.查詢某個用戶的朋友認識的朋友 --二跳指定點label的查詢
2.查詢某個公司的上下游對外投資關系 --N跳指定方向過濾查詢
3.查詢某個公司實際持股股東 --N跳內帶過濾查詢
4.搜索可提供某個零部件的供貨商 --N跳內帶過濾的until查詢
5.局點變更影響分析 --N跳內帶過濾查詢

如下圖,可用3跳查詢得到網訊公司A所有的對外投資機構,

與此同時,多跳查詢能力也是一個衡量產品性能非常重要的指標,比如LDBC(Linked Data Benchmark Council)的互動式查詢場景下就設計了多個考察圖資料庫系統多跳查詢能力的測驗用例,互動式查詢Interactive的Complex Query中有多個用例均為多跳查詢,如下圖是一個查朋友最近發送的訊息的IC2用例,是一個經典的圖上2-hop查詢,

在圖計算的尺度里,多跳過濾某些情況下被稱為k-hop演算法,BFS,DFS演算法,區別僅在于traversal的策略是深度優先還是廣度優先,

而在圖資料庫中一般將多跳過濾看做是需要特殊優化的模式匹配查詢(cypher)或可組合的復合查詢(gremlin),

以下展示常用的圖查詢語言gremlin/cypher的二跳查詢的寫法,結果均為回傳李雷朋友的朋友:

gremlin: g.V('李雷').out('朋友').out('朋友')

 

cypher: match (n)-->(m1:朋友)-->(s1)-->(m2:朋友)-->(s2) where id(n)='李雷' return s2 

這兩個陳述句輕盈又直觀,看起來一切都被解決地如此優雅,

但事實真的如此嗎?

很遺憾,當我們興致勃勃地構圖,將資料匯入圖資料,再使用類似上述陳述句查詢實際業務場景時,你也許會驚訝地發現,也許結果與我們所期待的并不一致,

接下來,我將展開說說為什么使用多跳過濾查詢會比我們想象中的更復雜,了解了圖上遍歷的概念后,我們能把而基于多跳過濾這一特性,我們又能怎么做使得這個重要的查詢又快又流程呢?

功能那些事兒

上面我們介紹了查詢一個用戶朋友的朋友的例子,這里我們假設業務場景是向李雷推薦好友,思路是:向他推薦其好友的好友,但是推薦的好友中不應包含李雷本身的好友,比如圖中小明同時是李雷的一跳好友和二跳好友,這時我們不應向李雷推薦小明,因為她已經是李雷的好友了,

僅僅增加了一個回傳的二跳鄰居不包含一跳鄰居這個條件,讓我們來看下與上面單純的2跳查詢的gremlin和cypher變成什么樣了?

gremlin: 
g.V("李雷").repeat(out("朋友").simplePath().where(without('1hop')).store('1hop')).
times(2)

 

cypher: 
match (a)-[:朋友]->(d) where id(a)='李雷' with a, collect(d) as neighbor
match (a)-[:朋友]-(b)-[:friend]-(c)
where not (c in neighbor)
return c

不知道各位有什么感覺?如果是不熟悉圖查詢語言的朋友們看到這里一定兩眼發黑了吧哈哈,

不用擔心,如果我們靈活使用一些特性,也許事情會變得簡單,比如這是一個GES原生API多跳過濾查詢Path Query的json請求:

{
 "repeat": [{"operator": "outV"}],
 "times": 2,
 "vertices": ["李雷"],
 "strategy":"ShortestPath"
}

假如我們可以把它翻譯為gremlin的寫法的話,它大概是:

g.V('李雷').repeat(out()).times(2).strategy('ShortestPath')

以上的寫法除了strategy('ShortestPath')其他本身就是gremlin已經支持的語法,意為-查詢從李雷出發以ShortestPath為遍歷策略的二跳鄰居,

遍歷策略是什么?

理解遍歷策略是了解多跳過濾的基石,我們這里從圖論里幾個定義展開:

A walk is a finite or infinite sequence of edges which joins a sequence of vertices.[2]
Let G = (V, E, ?) be a graph. A finite walk is a sequence of edges (e1, e2, …, en ? 1) for which there is a sequence of vertices (v1, v2, …, vn) such that ?(ei) = {vi, vi + 1} for i = 1, 2, …, n ? 1. (v1, v2, …, vn) is the vertex sequence of the walk. The walk is closed if v1 = vn, and it is open otherwise. An infinite walk is a sequence of edges of the same type described here, but with no first or last vertex, and a semi-infinite walk (or ray) has a first vertex but no last vertex.
A trail is a walk in which all edges are distinct.[2]
A path is a trail in which all vertices (and therefore also all edges) are distinct

以上應用wiki中對于圖上不同的點集組成的邊集說明,詳情見Path (graph theory) - Wikipedia,

以下,我將幾個相似又不同的概念用四個維度區分開,

以上5個概念均指代在G=(V,E,φ)中,由點V,邊E組成的序列,

上圖中,對于序列a->c->d->f,我們可以將它稱為walk, trail, path,三者都可以,因為該序列的起點a與終點f不同,不屬于對序列要求close狀態circuit和cycle,

而序列a->c->a->c, 我們只能將其歸為walk,因為其不閉合不屬于circuit和cycle,且點有重復(a,c兩個都有重復)不屬于path,邊集有重復(a->c的邊有重復)不屬于trail,

遍歷策略對最終的結果和遍歷效率都有決定性的影響,

這里簡單說明下新增的shortestPath策略:

  • Walk:以圖論中劃定的walk進行圖遍歷:即在traversal的程序中允許經過重復的點和重復的邊,
  • ShortestPath:以shortestPath的規則進行圖遍歷:即在BFS traversal的程序不會遍歷在前面跳數出現過的點,在這種模式下的路徑每個終點到起點都是最短路徑,

BFS與DFS

影響遍歷順序的另一個角度一般我們分為:

  • BFS - Breadth-first search 廣度優先搜索
  • DFS - Depth-first search 深度優先搜索

BFS在圖遍歷時會優先遍歷一個點的所有鄰居,再遍歷其鄰居的鄰居,而DFS會優先遍歷點的鄰居的鄰居,直到到達最深的節點,

我們可以設定一個batchSize,表示在進行BFS時不遍歷全部的鄰居,而是每層以batchSize的數量進行遍歷,然后再以batchSize的個數遍歷下一層鄰居,

可以推斷出,當batchSize=1時,該BFS約等于DFS的遍歷策略,

性能那些事兒

多跳過濾的性能受很多因素影響,以下總結一些會影響到性能的因素以供參考:

而對于不同規模的圖,多跳過濾查詢的TPS大部分情況下并不取決于圖的點邊規模,而是與圖的密度密切相關,

比如一個二跳查詢,那么TPS就與該圖的二跳鄰居分布強相關,

簡單來講,多跳過濾最終的性能主要受遍歷程序中觸達節點的個數影響,同樣規模的圖,其多跳過濾tps可能相差很大,大部分情況下基準測驗僅提供橫向比較,考驗的是圖資料庫/圖引擎本身的性能指標,有一定參考價值,但仍以實際業務圖表現為主,

經驗上,稀疏的圖性能表現大大好于稠密的圖,

多跳查詢的使用

為了簡化多跳過濾查詢的表達,我們用一些引數來表達查詢程序,如前面章節介紹過的遍歷策略,batchSize等,

本章我們將一一介紹以下特性引數:

接下來我們以GES的path query(filterquery version2版本)介面來舉例介紹多跳過濾查詢的使用,

該介面支持對多跳過濾查詢,回圈執行遍歷查詢進行加速,可以看做是gremlin的repeat陳述句的擴充表達,例如以下gremlin陳述句:

g.V('1','2').repeat(out()).times(2).emit().dedup()

以下為該介面的2跳/3跳查詢在1億規模圖上的測驗情況,

其中,

  • filterV2 - GES的多跳程序查詢原生介面,該API性能最佳,TPS與延遲表現優異,
  • Cypher - GES的cypher查詢(較老版本),
  • Neo4j - Neo4j community 4.2.3版本cypher,
  • gremlin - GES的gremlin,未在圖中體現,實際性能最差,故未做對比,

請求樣例1

POST /ges/v1.0/{projectId}/graphs/{graphName}/action?action_id=path-query
{
"repeat": [{"operator": "outV"}
],
"emit": true,
"times": 2,
"vertices": [
 "1","2"
]
}

以上請求等價于gremlin陳述句:

g.V('1','2').repeat(out()).times(2).emit().dedup()####

特性引數簡要說明

速查引數表

filterV2的引數過于復雜,需要花一定的時間去理解?請看下面總結出的速查表,幫助您快速使用repeat模式:

PS:strategy策略的說明查看下方

emit模式

emit是一個filtered query引數中對其他各個引數影響最大的引數,我們將其定義為,是否輸出query程序中的點,其含義也與gremlin中的emit一致,

下面將介紹,在不同模式下emit的表現形式:

上圖中,假定我們從點a出發,執行filtered khop query的查詢,

strategy

圖遍歷程序中使用的策略,目前可選:ShortestPath和Walk,

  • Walk:以圖論中劃定的walk進行圖遍歷:即在traversal的程序中允許經過重復的點和重復的邊,
  • ShortestPath:以shortestPath的規則進行圖遍歷:即在BFS traversal的程序不會遍歷在前面跳數出現過的點,在這種模式下的路徑每個終點到起點都是最短路徑,

上圖中,假定我們從點a出發,執行query的4跳查詢,

Walk: a->c->a->b, a->c->a->c, a->c->d->f, a->c->d->c

ShortestPath: a->c->d->f

簡單查詢

1. 查詢從a出發的第三跳鄰居

使用gremlin查詢:

g.V('a').out().out().out()
g.V('a').repeat(out()).times(3)

以上兩種寫法是等效的,結果為點f,路徑為a->c->d->f,

對應在API引數為:

{
 "repeat": [
 {
 "operator": "outV"
 }
 ],
 "emit": false,
 "times": 3,
 "vertices": [
 "a"
 ]
}

2. 查詢從a出發的三跳內鄰居

使用gremlin查詢:

g.V('a').repeat(out()).times(3).emit()

結果為b,c,d,e,f,

對應在API引數為:

{
 "repeat": [
 {
 "operator": "outV"
 }
 ],
 "emit": true,
 "times": 3,
 "vertices": [
 "a"
 ]
}

組合模式說明

emit+strategy

1. 查詢第三跳鄰居

在上面的圖中,如果按照[簡單查詢1](#1. 查詢從a出發的第三跳鄰居), 將得到點f, c, b,

路徑為a->c->a->b, a->c->d->f, a->c->d->c,

如果,我們只想得到f, 而不希望取到前兩跳已經出現過的點c和b,則需要使用strategy模式中的ShortestPath,ShortestPath模式保證API在traversal的程序中起始點到各點是最短路徑,該模式能夠有效降低多跳查詢中指數增長的查詢量,

gremlin的寫法為:

g.V("a").repeat(out().simplePath().where(without('hops')).store('hops')).times(3).path()

結果為僅為a->c->d->f,

對應在API引數為:

{
 "repeat": [
 {
 "operator": "outV"
 }
 ],
 "emit": false,
 "strategy": "ShortestPath",
 "times": 3,
 "vertices": [
 "a"
 ]
}

emit+until

1.提前終止traversal模式說明

我們以上面的圖來說明該模式,當我們不清楚查詢需要經過多少跳,但希望通過某些條件提前終止遍歷,可以用到until,

如以下兩個問題:

1.得到從a出發N跳內label=book的點,
2.得到從a出發N跳內所有點,停止查詢的條件為遇到label=book的點,

以上問題可以配合emit引數來解決,用gremlin可以寫為:

Q1: g.V('a').repeat(out()).until(hasLabel('book'))
Q2: g.V('a').repeat(out()).until(hasLabel('book')).emit()

與之對應的API為:

{
 "repeat": [
 {
 "operator": "outV"
 }
 ],
 "until": [
 {
 "vertex_filter": {
 "property_filter": {
 "leftvalue": {
            “label_name": ""
 },
 "predicate": "=",
 "rightvalue": {
 "value": "book"
 }
 }
 }
 }
 ],
 "emit": false/true,//這里根據Q1,Q2的情況選擇emit的值,
 "times": 5,
 "vertices": [
 "a"
 ],
 "strategy": "Walk"
}

repeat模式說明

repeat+times

可通過引數repeat+times實作多種形式的多跳過濾及repeat模式過濾,

1.僅多跳過濾

gremlin的寫法為:

g.V("a").repeat(out().in()).times()
或
g.V("a").out().in()

對應在API引數為:

{
 "repeat": [
 {
 "operator": "outV"
 },
 {
 "operator": "inV"
 }
 ],
 "strategy": "Walk",
 "times": 2,
 "vertices": [
 "a"
 ]
}

2.repeat mode

假如我們從點a出發,查詢其帶方向的四跳鄰居,即:

gremlin的寫法為:

g.V('a').repeat(out('user').out().has('age',18)).times(2)
或
g.V('a').out('user').out().has('age',18).out('user').out().has('age',18)

對應在API引數為:

{
 "repeat": [
 {
 "operator": "outV",
 "edge_filter": {
 "property_filter": {
 "leftvalue": {
 "label_name": ""
 },
 "predicate": "=",
 "rightvalue": {
 "value": "user"
 }
 }
 }
 },
 {
 "operator": "outV",
 "vertex_filter": {
 "property_filter": {
 "property_name": {
 "label_name": "age"
 },
 "predicate": "=",
 "rightvalue": {
 "value": "18"
 }
 }
 }
 }
 ],
 "times": 4,
 "emit": false,
 "vertices": [
 "a"
 ]
}

by模式說明

by模式當前支持兩種形式:

  • select+by mode
  • by mode

by mode

該模式可針對輸出的點進行輸出格式上的過濾,回傳的格式形如:

{
 "data": {
 "vertices": [
 {
 "id": "47",
 "label": "user"
 },
 {
 "id": "51",
 "label": "user"
 }
 ]
 }
}

例如針對二跳鄰居,我們可以通過引數by對id,label,property進行過濾:

g.V("a").repeat(out()).times(2).by(id())

轉化為filtered query V2的形式為:

{
 "repeat": [
 {
 "operator": "outV"
 }
 ],
 "times": 2,
 "vertices": [
 "a"
 ],
 "by": [{"id": true}]
}

select + by mode

該模式可任意選擇traverse路徑上經過的N層,但每層只能在by中指定一個輸出,回傳的格式形如:

{
 "select": [
 ["李雷", "小明","小智"],
 ["李雷","韓梅梅", "小智"],
 ["李雷", "韓梅梅", "小霞"]
 ]
}

下面我們來介紹一下select+by模式,如下圖,我們希望回傳李雷的二跳鄰居的路徑情況,

{
 "repeat": [
 {
 "operator": "outV"
 }
 ],
 "times": 2,
 "vertices": [
 "李雷"
 ],
 "by": [{"id": true},{"id": true},{"id": true}],
 "select": ["v0", "v1", "v2"]
}

 

g.V('1').as('v0').both().as('v1').both().as('v2').select('v0','v1','v2').by(id()).select(values)

在上面body體中,我們使用select自帶的隱含層數別名v0, v1, v2,其分別表示用戶輸入的點集第0層-v0, K跳中的第1層-v1, K跳中的第2層-v2,

select中選中的別名與by中指定的格式一一對應,

以上案例輸出格式形如:

{
 "select": [
 ["李雷", "小明","小智"],
 ["李雷","韓梅梅", "小智"],
 ["李雷", "韓梅梅", "小霞"]
 ]
}

當然,我們也可以有更多的更豐富的輸出,比如我們希望將輸入點李雷的id和label都展示在路徑中,并且去掉了中間第一跳的好友小明和韓梅梅,直接顯示李雷及其第二跳好友的關系:

{
 "repeat": [
 {
 "operator": "outV"
 }
 ],
 "times": 2,
 "vertices": [
 "李雷"
 ],
 "by": [{"id": true},{"label": true},{"id": true}],
 "select": ["v0", "v0", "v2"]
}

最終展示結果是對路徑自動去重的,比如在這個例子中,李雷到小智有兩條路徑,中間分別經過好友小明和韓梅梅, 但最終僅顯示了一條,

以上案例輸出格式形如:

{
 "select": [
 ["李雷", "person", "小智"],
 ["李雷", "person", "小霞"]
 ]
}

案例

案例一.好友推薦

我們向李雷推薦好友,思路是:向他推薦其好友的好友,但是推薦的好友中不應包含李雷本身的好友,比如圖中韓梅梅同時是李雷的一跳好友和二跳好友,這時我們不應向李雷推薦韓梅梅,因為她已經是李雷的好友了,

下面將分別展示使用gremlin,cypher和下一代filter query查詢,回傳均為推薦路徑:李雷->李雷好友->推薦好友,

gremlin

gremlin>
g.V("李雷").repeat(out("friend").simplePath().where(without('1hop')).store('1hop')).
times(2).path().by("name").limit(100)
gremlin>
[李雷,小明,小智]
[李雷,韓梅梅,小智]
[李雷,韓梅梅,小霞]

cypher

match (a)-[:friend]->(d) where id(a)='李雷' with a, collect(d) as neighbor
match (a)-[:friend]-(b)-[:friend]-(c)
where not (c in neighbor)
return a.name, b.name, c.name
[
 {
 "row": ["李雷", "小明","小智"],
 "meta": [null, null, null]
 },
 {
 "row": ["李雷","韓梅梅", "小智"],
 "meta": [null, null, null]
 },
 {
 "row": ["李雷", "韓梅梅", "小霞"],
 "meta": [null, null, null]
 }
]

filtered query V2

{
 "repeat": [
 {
 "operator": "outV",
 "edge_filter": {
 "property_filter": {
 "leftvalue": {
 "label_name": "labelName"
 },
 "predicate": "=",
 "rightvalue": {
 "value": "friend"
 }
 }
 }
 }
 ],
 "times": 2,
 "vertices": [
 "李雷"
 ],
 "by": [{"id": true},{"id": true},{"id": true}],
 "select": ["v0", "v1", "v2"]
}
{
 "select": [
 ["李雷", "小明","小智"],
 ["李雷","韓梅梅", "小智"],
 ["李雷", "韓梅梅", "小霞"]
 ]
}

案例二:自環寫法案例

gremlin

gremlin>
g.V("李雷").outE('friend').has('name','xx').otherV().where(out('friend').
(hasId('李雷'))).limit(100)

cypher

match (a:default)-[r1:friend]->(b)-[r2:friend]->(c) where a.mid='李雷' and r1.name='xx' and a=c return id(b) limit 100

reference

LDBC Social Network Benchmark (LDBC SNB)

從零開始學Graph Database(1)- 基礎篇-云社區-華為云

Filtered-query V2(2.3.6)_圖引擎服務 GES_API參考_業務面API_華為云

圖引擎服務GES

 

點擊關注,第一時間了解華為云新鮮技術~

轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/550052.html

標籤:大數據

上一篇:qrtz表初始化腳本_mysql

下一篇:面試題百日百刷-kafka篇(三)

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀:**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題,由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視,實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶,一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀:**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高,采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐,遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀:**滴滴資料通道引擎承載著全公司的資料同步,為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加,資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程,遇到的問題以及今后的規劃。 #1. 背景 資料,對于任何一家互聯網公司來說都是非常重要的資產,公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀:**深耕人工智能領域,致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎,這次獲獎的專案是什么呢?一起來看看詳細報道吧! 近日,由國際計算語言學協會ACL(The Association for Computational Linguistics)舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp? MPP (Massively Parallel Processing),即大規模并行處理,在資料庫非共享集群中,每個節點都有獨立的磁盤存盤系統和記憶體系統,業務資料根據資料庫模型和應用特點劃分到各個節點上,每臺資料節點通過專用網路或者商業通用網路互相連接,彼此協同計算,作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀:**指標體系是什么?如何使用OSM模型和AARRR模型搭建指標體系?如何統一流程、規范化、工具化管理指標體系?本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標,系統化的組織起來,通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索,LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料,可以使用下面的 SQL 陳述句: SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀:**Ceph是國際知名的開源分布式存盤系統,在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統, ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章,這一次主要寫一個嵌套的聚合,例如先對sex集合,再對desc聚合,最后再對age求和,共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by,avg,sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack(ELK)部署

    傻瓜式部署,只需替換IP與用戶 導讀: 現ELK四大組件分別為:Elasticsearch(核心)、logstash(處理)、filebeat(采集)、kibana(可視化) 下載均在https://www.elastic.co/cn/downloads/下tar包,各組件版本最好一致,配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:33:24 more
  • MySQL中binlog備份腳本分享

    關于MySQL的二進制日志(binlog),我們都知道二進制日志(binlog)非常重要,尤其當你需要point to point災難恢復的時侯,所以我們要對其進行備份。關于二進制日志(binlog)的備份,可以基于flush logs方式先切換binlog,然后拷貝&壓縮到到遠程服務器或本地服務器 ......

    uj5u.com 2023-04-20 08:28:06 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:27:27 more
  • 快取與資料庫雙寫一致性幾種策略分析

    本文將對幾種快取與資料庫保證資料一致性的使用方式進行分析。為保證高并發性能,以下分析場景不考慮執行的原子性及加鎖等強一致性要求的場景,僅追求最終一致性。 ......

    uj5u.com 2023-04-20 08:26:48 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:26:35 more
  • 云時代,MySQL到ClickHouse資料同步產品對比推薦

    ClickHouse 在執行分析查詢時的速度優勢很好的彌補了MySQL的不足,但是對于很多開發者和DBA來說,如何將MySQL穩定、高效、簡單的同步到 ClickHouse 卻很困難。本文對比了 NineData、MaterializeMySQL(ClickHouse自帶)、Bifrost 三款產品... ......

    uj5u.com 2023-04-20 08:26:29 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:25:13 more
  • Redis 報”OutOfDirectMemoryError“(堆外記憶體溢位)

    Redis 報錯“OutOfDirectMemoryError(堆外記憶體溢位) ”問題如下: 一、報錯資訊: 使用 Redis 的業務介面 ,產生 OutOfDirectMemoryError(堆外記憶體溢位),如圖: 格式化后的報錯資訊: { "timestamp": "2023-04-17 22: ......

    uj5u.com 2023-04-20 08:24:54 more
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:24:03 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:23:11 more