「這是必要的，」她大聲說道，沒有對任何人說。 - 這是必要的！ 這正是它所說的：公司的主要任務是為股東的利益賺取利潤。 好吧，想想吧！ 他們什麼都不怕！
尤利杜波夫《小惡》
看到這樣的標題，你可能已經認定這篇文章要不是愚蠢的，就是挑釁的。 但不要急於下結論：大公司的員工，特別是有國家參與的公司，經常不得不比較不同的平台，包括完全不同的平台 - 例如標題中的平台。
當然，沒有人以這種方式比較 DBMS，因為它們的優點和缺點是眾所周知的。 通常，解決某些應用程式問題的平台需要進行比較。 在本文中，我將使用資料庫範例作為 Habr 讀者第一手熟悉的主題來展示本例中使用的方法。 所以，
動機
當您開始教育計畫或業餘愛好計畫時，選擇平台的動機可能非常多樣化：「這是我最了解的平台」、「我有興趣了解這個」、「這是最好的文件」 .. 。對於商業公司來說，選擇標準是相同的：我需要支付多少錢以及這筆錢我會得到什麼。
自然地，您希望付出更少，得到更多。 但是，您需要決定什麼更重要 - 支付更少或獲得更多，並為每個節點分配權重。 假設高品質的解決方案對我們來說比便宜的解決方案更重要，我們為「成本」節點分配 40% 的權重，為「機會」節點分配 60% 的權重。
在大公司中，情況通常正好相反——成本權重不會低於 50%，甚至可能超過 60%。 在模型範例中，重要的是任何父節點的子節點的總權重必須為 100%。
切削條件
網站 已知約有 500 個資料庫管理系統。 當然，如果您從眾多選項中選擇一個目標平台，您最終可能會得到一篇評論文章，而不是商業項目。 為了減少選擇空間，制定了截止標準，如果平台不符合這些標準，則不予考慮。
截止標準可能與技術特徵有關，例如：
- ACID 保證；
- 關係資料模型；
- SQL語言支援（注意，這與「關係模型」不同）；
- 水平縮放的可能性。
可能有一般標準：
- 在俄羅斯獲得商業支持；
- 開源；
- 該平台在電信和大眾傳播部登記冊中的可用性；
- 該平台在某些評級中的存在（例如，在 db-engines.com 評級的前一百名中）；
- 市場上專家的存在（例如，基於在 hh.ru 網站上的簡歷中搜尋平台名稱的結果）。
畢竟，可能存在企業特定的標準：
- 工作人員是否有專家；
- 與監控系統 X 或備份系統 Y 的兼容性，所有支援均基於此...
最重要的是有一個截止標準清單。 否則，肯定會有一些受到管理階層特別信任的專家（或「專家」）會說「你為什麼不選擇平台Z，我知道它是最好的」。
成本估算
解決方案的成本顯然包括許可證成本、支援成本和設備成本。
如果系統大致相同（例如，Microsoft SQL Server 和 PostgreSQL），那麼為簡單起見，我們可以假設兩種解決方案的裝置數量大致相同。 這將使您不必評估設備，從而節省大量時間和精力。 如果您必須比較完全不同的系統（例如，Oracle 與 Redis），那麼很明顯，為了正確評估，有必要進行規模調整（計算設備數量）。 評估一個不存在的系統的規模是一項非常吃力不討好的任務，因此他們仍然試圖避免這種比較。 這很容易做到：在截止條件下，寫入零資料遺失和關係模型，反之亦然 - 每秒 50 萬個交易的負載。
要評估許可證，只需向供應商或其合作夥伴詢問固定數量內核和固定期限支援的許可證費用就足夠了。 一般來說，公司已經與軟體供應商建立了牢固的關係，如果資料庫營運部門無法自行回答成本問題，那麼一封信就足以獲取此資訊。
不同的供應商可能有不同的授權指標：依核心數量、資料量或節點數量。 備用基地可以是免費的，也可以按照與主基地相同的方式獲得許可。 如果發現指標存在任何差異，您將必須詳細描述模型展位併計算該展位的許可成本。
正確比較的重要一點是相同的支持條件。 例如，Oracle 支援費用每年為許可證價格的 22%，但您無需為 PostgreSQL 支援付費。 這樣比較正確嗎？ 不會，因為無法自行修復的錯誤會產生完全不同的後果：在第一種情況下，支援專家會快速幫助您修復它，但在第二種情況下，存在延遲專案或成品停機的風險制度無限期。
您可以透過三種方式均衡計算條件：
- 在沒有支援的情況下使用 Oracle（實際上這不會發生）。
- 購買 PostgreSQL 支援 - 例如，從 Postgres Professional 購買。
- 考慮與缺乏支持相關的風險。
例如，風險計算可能如下所示：如果發生致命的資料庫故障，系統停機時間將為 1 個工作天。 使用該系統的預期利潤為每年 40 億圖格里克，事故率估計為 1/400，因此缺乏支持的風險估計每年約為 100 億圖格里克。 顯然，「計劃利潤」和「預計事故頻率」都是虛擬值，但有這樣的模型總比沒有好得多。
事實上，該系統可能太重要了，長期停機所帶來的聲譽成本是不可接受的，因此需要支援。 如果允許停機，那麼拒絕支援有時可能是省錢的好方法。
假設經過全部計算，營運平台A 5年的成本為800億MNT，營運平台B的成本為650億MNT，營運平台C的成本為600億MNT。 平台 C 作為獲勝者，在價格上獲得滿分，而平台 A 和 B 獲得的分數則少一些，與價格貴多少倍成正比。 在本例中，分別為 0.75 點和 0.92 點。
機會評估
機會的評估被分為許多組別，其數量僅受評估者的想像力的限制。 最佳選擇似乎是將這些功能劃分為將使用這些功能的團隊； 在我們的範例中，這些人是開發人員、管理員和資訊安全官員。 假設這些函數的權重分佈為 40:40:20。
開發功能包括：
- 易於數據操作；
- 縮放；
- 存在二級索引。
標準列表及其權重非常主觀。 即使解決相同的問題，這些清單、專案權重和答案也會根據團隊的組成而有很大差異。 例如，Facebook 使用 MySQL 來儲存數據，Instagram 則是基於 Cassandra 建置。 這些應用程式的開發人員不太可能填寫此類表格。 人們只能猜測馬克·祖克柏選擇了成熟的關係模型，並為此付出了應用分片的需要，而凱文·斯特羅姆則使用該平台構建了擴展性，犧牲了數據訪問的便利性。
管理職能包括：
- 備份系統功能；
- 易於監控；
- 易於容量管理－磁碟和節點；
- 資料複製能力。
請注意，問題必須以定量的方式提出。 您甚至可以就如何評估特定功能達成一致。 例如，我們嘗試使用 Oracle DBMS 提供的工具範例對備份工具進行評級：
工具
評論
評估
進出口
上傳和載入數據
0.1
開始/結束備份
複製文件
0.3
遠程管理
增量複製能力
0.7
ZDLRA
僅增量複製，最快恢復到點
1.0
如果沒有明確的評價標準，可以請幾位專家給予評分，然後取平均值。
最後簡單羅列一下資訊安全功能：
- 密碼管理策略的可用性；
- 連接外部身份驗證工具（LDAP、Kerberos）的能力；
- 訪問的角色模型；
- 審計能力；
- 磁碟上的資料加密；
- 網路傳輸過程中的加密 (TLS)；
- 來自管理員的資料保護。
性能測試
另外，我想警告不要使用任何不是由您進行的負載測試的結果作為參數。
首先，正在測試的應用程式的資料結構和負載設定檔可能與您要解決的問題有很大不同。 大約10-15年前，資料庫供應商喜歡炫耀在TPC測試中取得的成果，但現在似乎沒有人認真看待這些結果。
其次，系統效能在很大程度上取決於程式碼最初是為什麼平台編寫的以及測試是在什麼設備上進行的。 我看過很多將 Oracle 與 PostgreSQL 進行比較的測試。 結果範圍從一個系統的無條件優越性到另一個系統同樣無條件的優越性。
最後，第三，你不知道誰做了測試。 這兩個資格都很重要，會影響設定作業系統和平台的質量，以及動機，這對測試結果的影響比所有其他因素的總和還要大。
如果性能是關鍵因素，請自行進行測試，最好在配置和維護生產系統的人員的幫助下進行。
導致
最後，所有工作的結果應該是一個電子表格，其中所有估計值都被組合、相乘並相加：
如您所知，透過改變尺度和調整評級，您可以達到任何期望的結果，但這是一個完全不同的故事...
來源： www.habr.com