考量 MDN 每日發布文章數量、訂閱者規模和每日活躍使用者數，設計高效的資料儲存和搜尋方案至關重要。文章資料包含文字、圖片等多媒體內容，需要一個能處理結構化、半結構化和非結構化資料的資料模型。同時，為了滿足全球使用者的存取需求，需要設計一個全球雲端架構，並根據不同地區的使用者分佈和峰值使用時間，評估和組態 IOPS 和儲存容量。
安全性
安全性是人工智慧應用設計中的關鍵方面。由於人工智慧模型可能會暴露敏感的資料或邏輯，因此需要採取嚴格的安全措施。
角色基礎存取控制
角色基礎存取控制（RBAC）是一種安全機制，根據使用者的角色授予不同級別的存取許可權。例如，可以為管理員授予高階別的存取許可權，而為普通使用者授予低階別的存取許可權。
敏感性資料保護
敏感性資料保護是指保護敏感的業務邏輯或模型引數等資訊。例如，可以使用加密技術來保護敏感的模型引數。
資料模型設計與搜尋最佳化
資料模型是任何應用程式的基礎，決定了資料的儲存和查詢效率。在本章中，我們將探討如何設計一個適合新聞文章和相關多媒體內容的資料模型，並如何利用向量搜尋和傳統搜尋技術來最佳化查詢效率。
資料型別與儲存
新聞文章通常包含多種型別的資料，包括結構化、非結構化和半結構化資料。結構化資料通常儲存於關聯式資料函式庫中，用於交易和查詢。非結構化資料，如PDF、圖片和影片，通常儲存於物件儲存中，如Amazon S3。半結構化資料，如JSON檔案，允許每個檔案定義自己的結構，適合儲存具有共同和唯一屬性的資料。
資料模型設計
我們的目標是設計一個能夠儲存新聞文章、訂閱者資料、計費資訊等多種型別的資料模型。為簡單起見，本章節將聚焦於新聞文章和相關多媒體內容的資料模型。圖6.1描述了文章集合的資料模型。
文章集合資料模型
文章集合代表了一篇新聞文章，包含建立詳細資訊、標籤和貢獻者等資訊。每篇文章都有一個標題、摘要、HTML和純文字內容，以及相關的多媒體元素，如圖片。
向量嵌入與搜尋
為了完成資料模型，我們需要考慮如何利用向量嵌入來增強搜尋功能。文字嵌入可以實作語義搜尋，而圖片嵌入可以幫助找到相似的圖片。表6.1描述了嵌入模型和向量大小。
| 型別 | 欄位 | 嵌入模型 | 向量大小 |
|---|---|---|---|
| 文字 | 標題 | OpenAI text-embedding-3-large | 1024 |
| 文字 | 摘要 | OpenAI text-embedding-3-large | 1024 |
| 圖片 | 內容 | OpenAI CLIP | 768 |
資料模型最佳化
根據搜尋使用案例，我們需要最佳化資料模型以支援多種搜尋功能。圖6.2展示了更新的資料模型，包括向量搜尋索引和傳統搜尋索引。
向量搜尋索引
向量搜尋索引允許我們利用向量嵌入來實作語義搜尋和圖片相似度搜尋。表6.2描述了向量搜尋索引的定義。
| 集合 | 向量索引 |
|---|---|
| 文章 | semantic_embedding_vix |
| 文章內容嵌入 | content_embedding_vix |
傳統搜尋索引
傳統搜尋索引允許我們利用傳統的查詢語法來實作文字搜尋。表6.3描述了傳統搜尋索引的定義。
| 集合 | 搜尋索引 |
|---|---|
| 文章 | lexical_six |
資料儲存需求評估
在評估資料儲存需求時，需要考慮多個因素，包括資料量、存取模式、峰值使用時間等。MDN 每日發布 100 篇文章，保留最近 5 年的文章，總計約 182,500 篇文章。同時，MDN 有 48 萬名訂閱者和 2400 萬名每日活躍使用者，峰值存取時間為每日 30 分鐘，橫跨三個主要時區。
資料大小估算
每篇文章包含一個 1,024 維度的嵌入（embedding）用於語義搜尋，以及五個 768 維度的嵌入用於影像搜尋，總計約 40 KB 的未壓縮大小。加上標題、摘要、正文（含及不含標記）等欄位，平均每篇文章的未壓縮大小約為 300 KB。五年的文章總計約需 100 GB 的未壓縮儲存空間。使用 MongoDB 的 WiredTiger 壓縮（還有 Snappy、zlib 和 zstd 等壓縮選項），這個大小可以減少到約 50 GB。
資料函式庫叢集組態
MongoDB Atlas 提供兩種主要的叢集型別：複製集（Replica Sets）和分片叢集（Sharded Clusters）。複製集有一個主要節點用於寫入和多個次要節點用於高用性和讀取。分片叢集由多個分片組成，每個分片都是整個資料集的一部分，也是一個複製集。分片叢集可以水平和垂直擴充套件以處理讀取和寫入。
IOPS 需求評估
MDN 是一個低寫入、高讀取的使用案例，每天只新增 100 篇文章，因此對儲存系統的寫入壓力很小。根據 MongoDB Atlas 的儲存和 IOPS 選項，需要根據峰值使用時間和使用者分佈來評估 IOPS 需求。假設每篇文章需要 3 個 IOPS 用於磁碟讀取，則需要根據使用者數量和峰值時間來計算所需的 IOPS。
全球雲端架構設計：MDN 個案研究
在設計全球雲端架構時，瞭解不同地區的使用者需求和流量分佈至關重要。MDN（Mozilla Developer Network）作為一個全球性的開發者社群，需要一個能夠滿足不同地區使用者需求的雲端架構。在本文中，我們將探討如何設計一個全球雲端架構，以滿足 MDN 的需求。
IOPS 需求分析
首先，我們需要分析不同地區的 IOPS（Input/Output Operations Per Second）需求。根據表 6.6，MDN 的全球訂閱者分佈如下：
| 區域 | 訂閱者數量 | IOPS 需求 |
|---|---|---|
| AMER | 9,600,000 | 1,920,000 |
| EMEA | 4,800,000 | 960,000 |
| APAC | 6,000,000 | 1,200,000 |
| LATAM | 3,600,000 | 720,000 |
根據這些資料，我們可以計算出每個區域的 IOPS 需求。例如，AMER 區域需要 1,920,000 IOPS。
Atlas 叢集組態
為了滿足 MDN 的 IOPS 需求，我們需要組態 Atlas 叢集。Atlas 提供了不同的叢集組態選項，包括 M40、M50 和 S40 等。根據 MDN 的需求，我們選擇了 M40 和 S40 叢集組態。
M40 叢集組態提供了 16 GB 的 RAM 和 2 TB 的磁碟空間，足以滿足 MDN 的 IOPS 需求。S40 叢集組態提供了 26,875 的讀取 IOPS，足以滿足 MDN 的搜尋需求。
區域組態
為了滿足不同地區的使用者需求，我們需要在每個區域組態 Atlas 叢集。根據表 6.7，MDN 的全球雲端架構如下：
| 區域 | Atlas 基礎叢集組態 | Atlas 讀取節點 | Atlas 向量搜尋節點 |
|---|---|---|---|
| AMER（主要區域） | M40 | - | S30 |
| EMEA | - | M40 讀取節點 | S30 |
| APAC | - | M40 讀取節點 | S30 |
| LATAM | - | M40 讀取節點 | S30 |
在這個組態中，AMER 區域作為主要區域，使用 M40 叢集組態和 S30 向量搜尋節點。其他區域使用 M40 讀取節點和 S30 向量搜尋節點。
內容解密：
在上述架構中，我們使用了 M40 和 S40 叢集組態。M40 叢集組態提供了 16 GB 的 RAM 和 2 TB 的磁碟空間，足以滿足 MDN 的 IOPS 需求。S40 叢集組態提供了 26,875 的讀取 IOPS，足以滿足 MDN 的搜尋需求。
圖表翻譯：
下圖顯示了 MDN 的全球雲端架構：
graph LR
A[AMER] -->|M40|> B[Atlas 基礎叢集]
A -->|S30|> C[Atlas 向量搜尋節點]
EMEA -->|M40 讀取節點|> D[Atlas 讀取節點]
APAC -->|M40 讀取節點|> D
LATAM -->|M40 讀取節點|> D
D -->|S30|> C
這個圖表顯示了 MDN 的全球雲端架構，包括不同地區的 Atlas 叢集組態和向量搜尋節點。
從商業價值與使用者經驗的雙重角度來看，建構一個高效能、可擴充套件的資料儲存和搜尋系統對 MDN 至關重要。透過分析 MDN 的資料量、存取模式和全球使用者分佈，我們可以發現，結合向量搜尋和傳統搜尋技術，並採用 MongoDB Atlas 的分片叢集和讀取節點策略，能夠有效滿足其低寫入、高讀取的需求。技術限制方面，跨區域資料同步和延遲仍是挑戰，需要持續最佳化同步機制和考慮邊緣快取策略。展望未來，隨著 AI 技術的發展，更精確的語義搜尋和個人化推薦將成為趨勢，MDN 可以探索整合更先進的 AI 模型和向量搜尋技術，例如結合知識圖譜和上下文感知的搜尋，以提升使用者經驗和平臺價值。玄貓認為，MDN 的架構選型展現了其對技術趨勢的敏銳洞察，並為其他高流量、內容驅動的平臺提供了寶貴的參考。
