高頻記賬的非SQL方法？
有誰知道用於高頻會計的非 SQL 資料結構的任何現有技術，無論是客戶端、經紀人還是交易所端？我正在特別考慮將個人交易數據預訂到適當的交易中，並平衡借方和貸方的問題。在我自己的情況下，我將在快速限價訂單簿中或直接相鄰執行此操作，但我可以看到存在這種野獸的其他原因。是的，我同意目前流行的非 ACID nosql 引擎中沒有一個完全適合這項工作。我假設我需要寫這個。
這個問題的一個可用答案可能就像連結到一篇關於大批量交易環境中非 SQL 或 nosql 會計主題的論文一樣簡單——我顯然使用了錯誤的搜尋片語合，因為我我還沒有找到太多。
我正在做的是一個項目，其中包括一個限價訂單簿和分佈式網格或結構中每個節點的記帳。就我而言，交易工具最好被描述為實物期權或實物衍生品，包括一些溫和的外來工具。絕大多數訂單將由機器發起，數據速率看起來很容易在每個節點上達到 60k 交易/秒。（不用寫更長的論文，這可能有助於解釋我這些天在矽谷；這顯然是針對一個新市場，而不是任何現有市場。）參見http://en.wikipedia.org/wiki/ Real_options_valuation如果您之前沒有遇到過實物期權。
部分答案，部分基於迄今為止對該問題的回饋：
專門建構的記帳機制可能是日誌結構的、僅追加的，可能使用非 SQL API 來提高插入速度。引擎本身可能是一個超圖數據庫。如果在多個節點上執行，它需要一種以點對點方式向其他節點提供摘要事務的方法。我越深入研究它，它就越開始看起來像一個分佈式超圖。
在 HFT 世界中，聽起來標準程序仍然是：記錄但不索引交易，做簡單的算術忽略借方和貸方，然後定期將平衡匯總交易綜合到會計 RDBMS 中。批量執行 MTM。關於“簡單的數學和本地日誌記錄”是如何完成的，有什麼人可以說的嗎？我知道 15 年前我們在衍生品世界中是如何做到這一點的，但坦率地說，它和 MTM 既慢又醜，並且涉及 NFS 伺服器、平面文件和 shell 腳本。什麼都沒有改變？;-)
好的，從剛才的搜尋詞中刪除“會計”後我發現了這個問題——乍一看不同的問題，涵蓋了報價和財務數據，但值得一讀——看起來他有一些相同的想法： NoSQL 儲存的使用在金融
- 看起來值得重複我在 google、citeseer 等網站上的搜尋，用“財務”代替“會計”。
複雜事件處理 (CEP) 試圖解決一些相同的問題——我剛剛想到，在相同的搜尋中包含 CEP 可能是富有成效的。我發現的第一件事是這篇（懷疑但幽默的）文章，討論了 CEP 的緩慢吸收和一些 nosql 炒作：http ://www.hftreview.com/pg/blog/darkstar/read/32333/whats-wrong-with-複雜事件處理
我知道這可能是一個幼稚的答案，但是當我開始為個人交易進行數據分析時，我尋找比 SQL 快得多的東西。我用 C++ 程式，我發現 HDF5 是我所有問題的答案
它不是面向會計的，但它的好處是你幾乎可以用它做任何事情，而且速度非常快。雖然有點學習曲線
我不得不認為有很多非常快速、非常優化的專用會計引擎來填補這個角色。
是和不是。我不認為你的容量很大——你只是有一個用於數據庫的企業級伺服器，而不是廉價的低端主機。我在帶有中檔數據庫的 SQL Server 上每秒執行大約 2000 個事務。
核心將是：
- 無論如何，使用消息隊列將前後解耦。
- 從清算/經紀人報告的 FIX 後台連結獲取交易執行。
當更現代的專用、可能是非 SQL 會計引擎的速度可能快幾個數量級時，這似乎是對數據中心馬力的巨大浪費。
有一點不對勁：SQL 具有數據完整性，而 NoSql 經常在編寫時忽略了數據完整性要求。您可以擺脫很多東西缺乏數據完整性的問題，但會計卻不行。
您還錯過了會計是標準化的商品方面。大公司執行 SAP 之類的東西 - 並且希望他們的所有數據都在那裡，無論成本如何。在貿易會計之上升級處理工資單、組織的所有發票等的中央系統並不是浪費時間。
會計是否真的需要每個交易後台也是一個問題 - 是的，進行合併和檢查，但是會計可以使用綜合平衡摘要。到目前為止，我沒有做很多交易，但每月向我的會計師送出帶有經紀人聲明的 PNL 總計（它直接用於我的每月損益和稅收計算）。即使交易量增加，我也永遠不會做不同的事情 - 但會每天或每小時合併並在內部關聯，但不是為了會計。