關於選擇真正快速的 DBMS 的建議
我正在開發一個項目，該項目對正在傳輸的數據進行實時監控，並記錄是否存在各種類型的錯誤等。CRUD 操作是實時的。我們最初計劃使用 PostgreSQL，但我們面臨的問題是，即使稍微調整一下，PostgreSQL 也不夠快，無法處理實時 CRUD 操作；MySQL 和其他大人物也是如此。SQLite 的執行速度比它們快很多，但是當數據庫大小達到幾百 MB 時，它很快就幾乎死了。另一個限制是監控是通過網路完成的。
是否有任何數據庫可以處理如此快速的操作？還是我應該選擇 NoSQL 數據庫？
編輯（關於設計）：
設計已盡可能標準化。儲存的數據幾乎是相互獨立的，所以連接很少。另外，我說“幾百 MB”只是作為參考。我們使用的實際數據庫大小為數 GB。每秒插入並檢索大量數據。
談到 PostgreSQL，在我對數據執行的測試中，它花費的時間是 SQLite 的 5-7 倍。
編輯（關於速度）：
我想提一個可能發生的最壞情況。
假設主應用程序正在 10 個實例（或 PC）上使用。它們都與中央 DBMS 互動並將數據插入其中。現在，每個應用程序都將有許多執行緒對實時傳輸的數據進行一些操作。該應用程序會報告流媒體中是否存在錯誤數據。而且由於數據是在數據包級別進行分析的，因此一秒鐘內可能會發生很多錯誤。根據一些非常基本的計算，最壞的情況可能需要每個實例每秒約 3k 行的插入率，每行有大約 8-10 個關聯的列。我在我的機器（4GB ram，QuadCore）上測試了這樣的測試，並且 SQLite 能夠在大約 1 秒內通過網路完成此操作。我稍微調整了 PostgreSQL，它在大約 5 秒內完成了同樣的工作（我承認我沒有對它進行很多優化，因為我不是 DBMS 領域的專家）。但瓶頸是隨著 SQLite 中數據庫大小的增大而出現的；插入看似繼續幾乎沒問題，但讀取需要很多時間。我自己用 3gb 的數據庫大小對其進行了測試。
我們主要關心的是插入，在最壞的情況下，每個應用實例約為 3k，平均情況下，每個實例的插入約為 500-1k。
如果您無法擴展主要的 RDBMS，那麼您的數據庫設計（包括索引、查詢等）或硬體是錯誤的。平台的選擇幾乎無關緊要。
就是這麼簡單。特別是當您提到“幾百兆字節”這意味著低容量時（我的意思是每秒幾十次寫入）
如果您真的想在數據庫中進行快速事務，請確保正確處理數據庫。例如，當談到 Oracle 時，很容易讓它處理 30.000 tps。通過一些細微的調整，它可以降低到每秒只有幾千筆交易。
對於一個非常好的展示，請查看OLTP 性能 - 解析的麻煩 這一切都歸結為防止額外的工作、盡可能頻繁地重用連接、準備語句和綁定變數。這樣做，您的數據庫可以以最佳方式執行和擴展，假設您的儲存可以處理負載。