2012-11-07 18 views
1

我已經獲得了構建應用程序原型的任務。我沒有任何代碼然而,正如我已經拿出瞭解決方案概念似乎在最好的臭豆腐......在WPF應用程序中加載大量Azure blob數據

問題:

解決由該做的東西不同天青項目存儲在Azure SQL db-s中的大量數據。幾乎所有發生的操作都會在blob存儲中創建一個gzipped日誌文件。所以這是每個日誌條目一個.gz文件。

我們還應該有一個小桌面(WPF)應用程序,應該可以讀取,篩選和排序這些日誌文件。

我完全沒有影響記錄如何完成,所以這是無法改變的東西來解決這個問題。

,我已經想出了(概念)可能的解決方案:

1:

  • 連接到Blob存儲
  • 打開容器
  • 讀/下載blob(帶應用過濾器)
  • 解壓縮.gz文件
  • 讀取和顯示

這樣做的問題在於,根據過濾器上,這可能意味着一大堆的數據下載的(這是慢),並處理(這也不會是很活潑的)。我真的不能看到這是一個可用的應用程序。

2:

  • 創建將運行一個WCF或REST服務
  • 服務將採取過濾PARAMS和其他的東西,並與數據返回一個XML/JSON文件Web角色,處理將在雲上完成

使用這種方法,如果存在很多這些文件,我是否會遇到解壓縮這些文件的問題(它是否會佔用存儲/計算實例上的額外空間,其中t他的服務正在運行)。

編輯:我的意思是過濾器是限制日期和嚴重性(信息,警告,錯誤)的結果。 .gz文件保存在一個很容易的結構中,我不會通過查看文件本身進行過濾。

3:

  • 一些其他的優雅和簡單的解決方案,我不知道

我還需要使應用程序實時更新顯示的日誌的一些方法時間,我想這需要重複請求blob存儲/服務。


這不是那些「給我代碼」問題之一。我正在尋找有關最佳實踐的建議,或尋找類似問題的類似解決方案。我也知道這可能是其中一個「沒有人正確回答」的問題,因爲人們對問題的解決方法不同,但我有一些時間來構建原型,所以我會嘗試不同的東西,並且我會選擇正確的回答,這將是一個展示瞭解決方案的方法,或者是讓我朝着正確方向發展的解決方案,即使在我實際構建和測試之前需要一些時間。

+0

我也不清楚。 「每個日誌條目一個.gz文件」有一個主日誌?如果您打算通過不查看這些.gz文件進行過濾,那麼您如何過濾? – Paparazzi

+0

應用程序將調用類似Logger.Log(嚴重性,「消息」)。對於這些調用中的每一個,都會創建一個文件名爲「severity-date.gz」的新文件(名稱中包含更多數據,但在這種情況下不起作用)。 – Pinetree

+0

對我仍然不清楚。你是說你單獨過濾.gz文件名嗎?所以你不能控制Logger應用程序?您是否可以控制對Logger.Log的調用? – Paparazzi

回答

1

據我所知,Azure Blob存儲中有一組日誌文件,它們以特定方式格式化(gzip)並且要顯示它們。

這些文件有多大?你是否在日誌文件中顯示每一條信息?

假設如果這是一個日誌文件,它是靜態的和歷史的......這意味着一旦創建了log/gzip文件,它就不能被改變(一旦它在博客存儲上出來,你就不會更新gzip文件)。只有新的文件,可以生成...

一個解決方案


爲什麼不創建一個輔助角色/工作流程,定期熄滅掃描Blob存儲,並建立一個持久「數據庫」,讓你可以顯示。關於這一點的好處是,您不會將解壓縮/業務邏輯解壓縮到WPF應用程序或UI中。

1)我將有工作者角色掃描Azure的Blob存儲日誌文件 2)有某種機制來追蹤哪些地方處理和當前的「狀態」也許是最後一次gzip文件 的UTC日期3)執行工作角色中的所有日誌文件的解壓/解壓操作 4)讓工作角色將內容放置在SQL數據庫,Azure表存儲或分佈式緩存中以便訪問 5)可以通過REST服務(ASP.NET Web API/Node.js等)

如果需要擴展此功能,則可以添加更多內容,例如,將其作爲工作運行以重新執行給定時間內的所有日誌文件(全部刷新)。我不知道你的數據的大小,所以我不確定這是否可行。

好的是,如果您需要縮放工作(通宵),您可以啓動2,3,6個工作角色......提取內容,將結果傳遞給Service Bus或Storage Queue會插入SQL,Cache等進行訪問。

+0

是的,我有一個gzip文件,用於在雲應用程序中發生的每個日誌條目。 雖然我喜歡有一個數據庫和訪問的想法,但我認爲這不是一個現在可行的解決方案。此外,日誌必須是最近在應用程序,所以如果這個工作人員角色跑了一天一次或兩次填充數據庫,我仍然會在客戶端中得到陳舊的數據。 – Pinetree

+0

如果您需要它們並更新SQL表/ Azure存儲,則角色可以每1秒鐘ping /查找更新。這可能是非常實時的處理它。我懷疑你的應用程序每秒都在創建日誌文件zip。請記住,從UI應用程序訪問日誌時,您將產生交易成本......此外,它極大地限制了您解決方案的可伸縮性,以表面原始日誌文件(想象要按時間或跨越多個日誌文件執行查詢......你要做什麼?實時解壓10個日誌文件,處理查詢並渲染UI?)。 –

+0

原來,可能會將日誌數據保存到數據庫中的工作者角色也是一個選項,儘管不是第一個選項,所以這裏是+1。 – Pinetree

1

簡單地存儲斑點是不夠的。您要過濾的元數據應該存儲在其他可以輕鬆篩選和檢索所有元數據的位置。所以,我認爲你應該分成2個問題是:

A.如何有效地列出所有「的gzip」與他們的元數據,以及如何 爲了可以申請我對這些的gzip一個過濾器,以顯示他們在我的客戶 申請。

解決方案

  • 斑點:清單斑點是緩慢和過濾是不可能的(你可以在每月或每週或用戶或容器組......但是這不過濾)。
  • 表存儲:非常快,但搜索速度慢(僅對PK和RK進行索引)
  • SQL Azure:您可以創建一個包含「gzips」列表以及一些其他元數據(如創建gzip,何時,總大小......)。使用存儲過程有一些很好的指標,你可以讓搜索速度非常快,但是SQL Azure是不是最靈活的解決方案
  • Lucene.NET:有適用於Windows Azure中AzureDirectory這使得它能夠在使用Lucene.NET你應用。這是一個超快速的搜索引擎,可以讓你索引你的「文件」(元數據),這將是完美的篩選和返回「的gzip」

更新列表:既然你只對日期進行篩選和嚴重程度,你應該檢查Blob和表的選項:

  • 斑點:您可以爲每個日期+嚴重性容器(20121107低,20121107介質,20121107高...)。假設每個數據+嚴重性沒有太多的斑點,則可以直接從容器中直接列出斑點。您可能在這裏遇到的唯一問題是用戶需要查看上週(7天)內嚴重程度較高的所有項目。這意味着您需要在7個容器中列出blob。
  • 表:即使您說表格存儲或數據庫不是一個選項,請考慮表格存儲。使用分區和行鍵可以很容易地以一種可擴展的方式進行過濾(還可以使用CompareTo來獲取一系列項目(例如11月1日至7日之間的所有記錄)。表格存儲中完全可以複製數據。在Table Storage實體中包含來自gzip的一些數據,以便在WPF應用程序中顯示它(過濾後要顯示的最重要的信息)。這意味着只需在用戶打開/雙擊時處理blob點擊在WPF應用程序

B.我如何在我的應用程序顯示一個「壓縮」的記錄(雙擊後例如搜索結果)

解決方案

  • 連接到從WPF應用程序的存儲賬號,下載文件,將它解壓縮和顯示。這意味着您需要將存儲帳戶存儲在WPF應用程序中(或使用SAS或容器策略),並且如果您決定在存儲文件的後端中更改某些內容,則還需要更改WPF應用程序。
  • 連接到一個Web角色。此Web角色從blob存儲中獲取blob,將其解壓縮並通過線路發送(或將其壓縮以便加速傳輸)。如果你是如何存儲的文件有新的變化,你只需要更新Web角色
+0

那麼,「過濾器」可能是一個錯誤的術語,但我會通過日期和日誌級別(信息,警告,錯誤)來限制結果,我將編輯該問題以使其清晰。 blob文件的結構方式不應該是真正的問題。當我回答Bart Czernicki時,db(表或SQL)可能不是一個選項。至於第二部分,我希望能夠在列表中顯示一些數據,而不僅僅是選擇一個blob。 BTW +1在這裏lucene。我有點喜歡這個想法,並且一定會研究它。 – Pinetree

+0

經過一番思考之後,我是否真的需要lucene,如果我按日期和嚴重程度進行篩選,基本上只是按預期構建文件名並檢查它是否存在。 – Pinetree

+0

我會更新我的答案。 –

相關問題