0

試想在銀行帳戶上作爲一個圖形數據庫簡單的交易。有了這樣的活動:天青CosmosDB圖的遍歷性能問題

  1. + $ 1000個現金投入。
  2. - $ 10用VISA購買一本書。
  3. + $ 100現金用於銷售舊自行車。
  4. - $ 50現金購買食品雜貨。

在圖形結構,我們可以定義節點作爲交易與性能:

  • ID - 交易ID
  • 時間 - 當交易發生的時間戳記。
  • 增量 - 原因交易 - 使用(+/-)上交易
  • 描述的金額。

然後邊緣將指向之前的事務。我們可以有其他邊緣指向其他帳戶(用於賬戶之間的轉賬),所有者等,但爲了簡單起見,我們有這種結構。

g.addV('transactions').property('id','1').property('time',0).property('delta',1000).property('description','cash input') 
g.addV('transactions').property('id','2').property('time',1).property('delta,-10).property('description','for buying a book by VISA') 
g.V('2').addE('previous').to(g.V('1')) 
g.addV('transactions').property('id','3').property('time',2).property('delta',100).property('description','cash for selling an old bike.') 
g.V('3').addE('previous').to(g.V('2')) 
g.addV('transactions').property('id','4').property('time',3).property('delta',-50).property('description','cash for buying groceries') 
g.V('4').addE('previous').to(g.V('3')) 

我們得到這個賬戶我們只是遍歷從最新交易以前邊緣的當前庫存,直到特定的日期,或一開始,像這樣:

g.V('4').emit().repeat(out('previous')).until(has('time',0)).properties('delta').value().sum() 

==> 1040

這是所有又好又快交易。但這樣做的交易時,大約需要8分鐘,並用更復雜的操作或更多的數據需要花費更長的時間。

在我的測試情況下,我已經設置了一個藍色的宇宙-DB與圖形API和吞吐量2000 RU /秒。

因爲我是相當新的圖形數據庫和查詢,我意識到有可能是這樣做的更快,更好的方式,以及如何優化這一點,我不知道。也許甚至圖形數據庫不是這份工作的正確工具?

我想在這裏實現什麼是合理的快速查詢到的交易,可叉多個賬戶,還有更多的事件。

如何讓這項工作更好?

回答

3

爲什麼不爲每個事務頂點添加一個current屬性?這樣仍然可以保持現在的歷史記錄,同時還可以更快地訪問當前庫存值(在任何給定的時間點)。另外,如果任何事務的值隨後發生變化,則相應地更新所有較新的事務將很容易(但這隻會是一個長時間運行的寫查詢,讀取仍然會很快)。

請記住,在OLTP查詢中擁有如此之多的跳數通常是一個糟糕的主意。

+0

嗨,謝謝你的回答。事實上,這可能是一個解決方案,但有更復雜的查詢,這種解決方案不會很好地工作。兌現結果是我們正在考慮的事情,但首先我想確定這些限制。你會說什麼是在OLTP查詢中合理的跳數?我們能做些什麼來改善這種遍歷速度嗎? – ifxdev

+0

我不確定這是如何在Cosmos-DB中處理的,但我認爲每一跳都會觸發一個新的後端查詢,因此它會快速累加起來。如果我不得不拋出一個數字,我會說保持在50以下(並且分支因數很低,這在你的用例中就是這種情況)。但這只是猜測,你應該更好地嘗試一下。 –