Mnesia：優點和區別
與主要的 SQL 數據庫實現相比，Mnesia 有哪些優勢以及與它們有何不同？
我可以使用數據庫來保存大量數據而不會顯著降低性能嗎？
很抱歉參加聚會遲到了。:) 這是我的答案，基於自 1996 年以來使用 Mnesia 以及自 1988 年以來使用的各種其他數據庫技術。
Mnesia 和 MySQL 確實是不同的野獸，哪一個是最好的很大程度上取決於您打算如何使用它。
如果您的應用程序是用 Erlang 編寫的，Mnesia 允許您將數據儲存在與應用程序相同的記憶體空間中，這意味著您可以在幾微秒內快速獲取單個數據對象。這在 MySQL 中是不可能的，因為您的應用程序和數據庫將在記憶體中分開。Mnesia 可以做到這一點並且仍然健壯的原因是 Erlang 在語言級別實現了記憶體“保護”。
總體而言，SQL 數據庫傾向於吞吐量而不是延遲，而在延遲方面，Mnesia+Erlang 通常表現出色。你需要決定哪一個對你來說最重要。正如上面文件中所說，Mnesia 的目標應用程序是電信交換應用程序，例如呼叫建立的響應時間要求約為 20 毫秒。這實質上意味著您只能在數據位於共享記憶體中時從數據庫中讀取數據，但會避免在每次呼叫設置的基礎上寫入持久儲存。OTOH，這些應用程序實際上不需要臨時查詢支持，並且不使用非常大的數據集。已經做了一些工作來擴展 Mnesia 對其他領域的適用性，但這不是 Erlang/OTP 開發團隊的優先事項。Mnesia 就是這樣，並且很可能會保持這種狀態。
在上面比較 Mnesia 和 MySQL 的速度的連結中，需要記住它在 eJabberd 中，如果它是 MySQL，它執行在單個伺服器上，如果它是 Mnesia，則執行一個完全複製的數據庫 - 大型 eJabberd 集群可以有多達10 個或更多 erlang 節點（因此，10 個或更多 Mnesia 副本）。從冗餘的角度來看，這是相當荒謬和昂貴的，Mnesia 絕不會強迫你這樣做。它顯然會在每個節點上提供極快的讀取，但寫入會非常昂貴。我讀過的幾個比較最終將分佈式 Mnesia 與單節點 MySQL 進行了比較。如果 MySQL 不需要冗餘，那麼 Mnesia 也不需要冗餘。Mnesia 在讓您選擇複製模式方面非常靈活，並且數據位置對應用程序是透明的。
Mnesia 也不限於每個表 2 GB（儘管特定的儲存選項是）。我所知道的最大的 Mnesia 數據庫在（64 位）RAM+磁碟中有大約 600 GB 的數據——儘管我不推薦這樣做。不過，對於現代硬體來說，任何高達 10-20 GB 的東西都應該是完全可以的，但是完全跳過 disc_only_copies 並使用 disc_copies - 如果必須的話，購買更多的 RAM。在使用分片支持（mnesia_frag）之前，我會三思而後行——它有效，但很少值得麻煩。
Mnesia 和 MySQL 之間最大的區別可能是 SQL 本身：Mnesia 並沒有真正具有可比性的功能。QLC 對 ad-hoc 查詢提供了一些支持，但它與 SQL 不在同一個級別，查詢優化的級別也不相同。在工具和供應方面，MySQL 也很出色，如果您需要分析，毫無疑問您應該選擇哪一個（即不是 Mnesia）。
查看 Mnesia 的最佳方式是作為 Erlang 語言的擴展。它使數據觸手可及，非常適合資料結構和訪問模式眾所周知的小型數據集。出於這個目的，使用 MySQL 和使用 Mnesia 做 MySQL 最適合的事情一樣不舒服。
大多數應用程序介於兩者之間，這就是它成為判斷的地方。你很可能最終會同時使用這兩個…
從文件中：
Mnesia 是一個分佈式數據庫管理系統，適用於電信應用程序和其他需要連續執行和軟實時屬性的 Erlang 應用程序。它是開放電信平台 (OTP) 的一部分，OTP 是用於建構電信應用的控制系統平台。
特別是在許多不間斷系統中要求的非常高水平的容錯能力，以及對 DBMS 與應用程序在同一地址空間中執行的要求，導致我們實施了一個全新的 DBMS。稱為Mnesia。Mnesia 是用程式語言 Erlang 實現的，並且與 Erlang 緊密相連，它提供了實現容錯電信系統所必需的功能。Mnesia 是專為工業電信應用而設計的多使用者分佈式 DBMS，用符號程式語言 Erlang 編寫，這也是預期的目標語言。Mnesia 試圖解決典型電信系統所需的所有數據管理問題，它具有許多傳統數據庫中通常不具備的功能。
在電信應用中，有與傳統 DBMS 提供的功能不同的需求。現在用 Erlang 語言實現的應用程序需要多種特性的混合，而傳統的 DBMS 通常無法滿足這些特性。Mnesia 在設計時考慮了以下要求：
快速實時鍵/值查找
以運維為主的複雜非實時查詢
分佈式應用帶來的分佈式數據
高容錯性
動態重新配置
複雜對象
Mnesia 與大多數其他 DBMS 的不同之處在於，它的設計考慮了電信應用程序的典型數據管理問題。因此，Mnesia 將傳統數據庫中的許多概念（例如事務和查詢）與電信應用程序的數據管理系統中的概念相結合，例如非常快速的實時操作、可配置的容錯程度（通過複製）和在不停止或掛起系統的情況下重新配置系統。Mnesia 也很有趣，因為它與程式語言 Erlang 緊密耦合，因此幾乎將 Erlang 變成了一種數據庫程式語言。這有很多好處，最重要的是 DBMS 使用的數據格式和程式語言使用的數據格式之間的阻抗不匹配，
與使用內部 Mnesia 相比，使用某些 *SQL 數據庫時，ejabberd 消耗的計算資源更少。當您有許多並髮使用者（例如，超過 1000 個）時，您可能對該主題感興趣。由於很少有並髮使用者，ejabberd 的 CPU 消耗可以忽略不計，因此小型伺服器的管理員不需要設置外部 SQL 伺服器和數據庫。
CouchDB v. Mnesia、V. MySQL和其他 Mnesia 主題：
立即想到的一個見解是，雖然對我來說如何為 MySQL 建構數據是顯而易見的，但對於 Mnesia 和對於 CouchDB，我仍然不完全確定最好的方法。現在，這裡有幾個比較明顯的點：
‘record’ 有一個 ’numplays’ 欄位，它顯然表明它已經播放了多少次。這在 MySQL 中很好，但是如果我只是將此欄位合併到 CouchDB 的文件中，那麼每次這個數字發生變化時，我都會在數據庫中獲得文件的完整副本，這似乎非常低效。
MySQL 中記錄、標籤和它們之間的連結表的三表佈局（如果不清楚，請參閱腳本）（至少對我而言）顯然是正確的解決方案，但是有很多可能的方法來做到這一點在 Mnesia 和 CouchDB 中，我發現我沒有直覺的答案。
簡而言之，它是為非常特定的目的而設計的，並且似乎經過精心設計以適應該目的。沒有一個數據庫可以抽像地與另一個數據庫進行比較。只有通過使用需求，才能引出可通約性要素。