The Art of Readable Code && High Performance Comments

雖然聽過,也摸了一陣子的 NoSQL,除非真有機器與 data 在手上,還是難有進境。最近拿 AWS DynamoDB 打了些功能,解公司前人的 MongoDB 遺產,也開始念 Professional NoSQL,終於有些感覺。簡單紀錄想法:

關於 NoSQL

  1. 有人說資料量到 TB  層級後,才要考慮 NoSQL Solution,在此之前 (調教良好的) RDBMS 表現都不差。然而大多企業的業務資料不超出此範圍,因此我認為關鍵在於:
    1. 刻意收錄過多資料,分析各資料項的重要性
    2. 交叉比對既有資料,分析各資料項間的關聯性
  2. NoSQL 本質與 RDBMS 的 DB Engine 相當接近 (hot spot, lock / MVCC, sharding, I/O threads, journal);又因為 Join 可造
  3. 成 Temp table,而複雜 index & join 時對 query plan 的選擇帶來困難,因此 NoSQL 會以語法或功能限制避過這兩類狀況。
  4. RDBMS 為 query 提供 Transaction,但 NoSQL 可能只保證 atomic document write;針對不同環境,可以選用下列手法:
    1. 使用 Transactional RDBMS 處理這類的營運資料
    2. Denormalize Table 使同次操作僅改變單一 document
    3. 實作 Journal-like operation,例如 2-Phase Commits
    4. 利用 conditional update

DynamoDB vs. MongoDB
這兩者本質雖天差地遠,但因為使用情境類似,還是很常被對比;簡單整理作為 Lv1 初學者的想法:

  • DynamoDB 是 AWS 提供的 Managed SaaS:
    • Key-Value Store,有 Secondary Index 可用要謝主隆恩;query (by index) 效能比 scan (table scan) 高 (scan 常頂著 throughput 在跑)
    • 使用 IAM 控管權限
    • 單一文件上限 64kb,超過建議放 S3;單 Table 無上限
    • SSD-based, low I/O latency
    • 使用空間、費用可預測,維護成本低
    • 容易 scaling : API 可以直接調 throughput ,搭配 cloudwatch 做 autoscaling 超輕鬆,但要慎選 hash key
    • 與其他服務 (Data pipeline, EMR) 整合完整
    • 沒有 import / export / snapshot 等功能;只能透過其他服務自幹
    • 建表時要定義所有 index (primary / secondary),之後無法更改,只能建新表再倒資料
  • MongoDB 是由 10gen 維護的 Project:
    • Document Store,使用 BSON (JSON 的擴展,容許 binary data 與 ISODate 等型別) 格式
    • 自帶權限系統
    • Index 相對自由,可以等建表後再加;對 array 的 index 會被展開,紀錄其下所有 element 更是方便 (參閱 Multi-key index)
    • 第三方套件,舉凡 Wrapper / Adaptor、備份還原、監視,一應俱全
    • 單一文件上限 16MB,會超過可以考慮使用 GridFS;db, collection 無上限 (但 fs 可能有)
    • DB 參數比 MySQL 少很多,容易調整
    • scaling 相對麻煩:
      • 規模小時怕 overkill,帳單太超越
      • 規模中大時 replica 效益遞減,sharding 效益依賴 shard key
    • 在 AWS EC2 運作底價不低:
      • 建議運作下限是三台主機,Primary + Secondary + Arbiter
      • EBS 的 throughput 不佳,且有偶發卡 I/O 的缺陷:
        • RAID 10/EBS 對後者有幫助,前者幫助不大。
          在以 volume snapshot 為主要備份手段的環境中會成為 anti-pattern。好在 MongoDB 自帶 failover and scaling,要整合 AWS 服務並不困難。
        • Ephemeral storage 表現不差,在讀寫分離的場合用作 replica secondary 算稱職。
        • Provisioned IOPS EBS 與 SSD (hi1 / hs2) 好大台,算是終極選擇 (讓最有錢的公司來滿足最挑剔的用戶,且已用盡所有最佳化手法)
      • MongoDB 是記憶體殺手,會積極將 index 甚至 document 都塞進 memory;因此小台 instance 跑起來不是太順

我手邊的舊有系統是跑在 MongoDB 上頭,而公司目前無資金壓力;因此在移轉進 VPC 時會暫先沿用。要是有人對 profiling 有興趣,我再來寫 script;預定針對 DynamoDB / MongoDB 對 scaling (throughput / sharding) 、讀寫比例、hash key / shard key 品質等狀況分層。

發表迴響

分類

%d 位部落客按了讚: