Orckestra C1 - 決定使用SQL的臨界點是什麼？

我已經構建並部署Orckestra C1網站和真正愛的框架。最後一個網站是C1 XML的內容混合體，以及一些SQL DB調用來獲取某些精選頁面上的客戶端數據。這工作完美。網站快速且易於維護。Orckestra C1 - 決定使用SQL的臨界點是什麼？

現在，我期待用C1來替換舊的ASP內置的網站，但它有一組不同的數據問題。想象一個帶有1000個小部件的小部件站點，其中每個項目可能與20-30個其他數據點（連接表）有關係。與數據一起，每個小部件可能具有20-30個相關圖像。這可能會在服務器上產生20,000到30,000張圖像。在每天的基礎上，該網站每天可能會有600位獨立訪問者。將會有~20個核心頁面，但其中一些核心頁面將是動態內容以動態地顯示小部件的一些變化。從管理員的角度來看，他們會做CRUD操作和其他維護工作，我希望通過C1控制檯或自定義管理界面來實現這一點。

我的問題：什麼是引爆點運行SQL migration tool從XML轉移到SQL進行Orckestra C1？我們正在嘗試查看是否真的需要爲Azure上的SQL付費以估算運行此站點的每月成本。

有什麼最佳實踐（案例研究）人們有與C1的經驗，以確保他們的網站不會陷入XML數據文件或圖像陷入困境？內存使用情況，磁盤IO或CPU？在擴展的C1 XML數據文件上發佈任何基準標記？

謝謝。

來源

2017-06-09 NerdBrick

拇指規則是，一個沒有

顯著量連續寫入的數據類型或
數據存儲/被寫入到相當頻繁不超過20-30 MB

可以在基於XML的數據存儲，只要你想運行。

要理順這些參數，還必須看到，在如何將XML數據存儲中實際在實際工作中

來查詢數據類型，將整個XML文件必須在內存
添加/刪除/更新加載一個數據類型的實例，整個文件必須重新在磁盤上
寫你不能索引特定領域，讓你執行經常在巨大的數據集，運行速度更快某些查詢。想象一下桌面掃描，就在內存中。

所以，第一點意味着只要你有足夠的記憶你就沒事了。我已經經歷了從xml到sql的內存消耗減少50％，所以如果內存比sql server更昂貴，那麼切換。

第二點就是說，如果你正在做的任何類型的訪問者跟蹤和行爲到您的數據存儲你就必須不斷磁盤活動由於整個XML文件被改寫所有的時間。這可以通過依靠諸如KeenIO之類的專用服務來進行，而不是依賴於C1數據類型來進行跟蹤。

第三和最後一個點觸摸關於同一問題作爲第二;大數據集在xml-datastore上不能很好地擴展。如果它的數據類型不是經常更新的，可以通過實現自己的專用緩存和查找表來克服 - 想想CQRS。

所以總結起來

您可以在不經常更改但查詢所有的時間巨大的數據集的方式實現簡單CQRS模式一起走。這可以存儲在內存中或使用類似Redis的東西。
將不斷更新的重構部件（如日誌記錄和跟蹤）轉換爲不依賴於C1數據類型的專用服務。
通過這些小調整，您可以繼續在xml-store上運行很長時間，即使是擁有大量內容的大型網站也是如此。

來源

2017-06-12 13:11:44

XmlDataProvider具有寫入緩衝區，確保更新的大量突發不會等待文件寫入。文件更新排隊，每秒更改一次的XML文件被保存。所以只要文件大小不夠大，你可以對數據類型進行非常密集的數據更新。「要查詢數據類型，必須將整個xml文件加載到內存中」 - 在第一次查詢時會發生一次。值得注意。 – mawtex

寫入緩衝區不會最小化需要寫入磁盤的數據量，因此最終會降低x個磁盤操作的成本。 –

緩衝區將收集在1000毫秒內完成的所有更新，然後執行1次磁盤寫入操作 - 我想說的是在1000毫秒內發生2+變化的磁盤活動最小化（與每次更改的序列化相比）。消息是，你實際上可以做非常激烈的更新。 XML的限制主要與數據的大小有關。 – mawtex

Orckestra C1 - 決定使用SQL的臨界點是什麼？

回答

相關問題