產品微服務技術討論
架構需求
Deploy需求
- 依現有方式deploy
- sit、stage、prod
- jenkins
- DB migration在app端控制不需dba
產品微服務資料結構說明
評估方式
- 資料特性
- Transaction
- 維護成本
- 資料量
- 開發成本
- 學習曲線
- 使用比較
資料特性
- 資料欄位多且包含多語系增加資料維度
- 過半數欄位幾乎為非必填欄位，且會增加
- 多對多的狀況多
SQL
- 資料欄位多需拆分多個子表儲存資料
- 欄位建立可能不一定會用到造成空間浪費或疑惑
- 如果將欄位記錄在資料內擇會有較多關聯成本
NoSQL
- 如果選擇寬欄式或文件式NoSQL，欄位較有彈性
- 因為沒有關聯性所以需要依賴app層控制關聯
- 取依賴app層控制schema完整性及差異管理
Transation
- 產品資料非交易計錄所以要transation狀況少
- 更新上大多以文字為主
- 未來可能需要做位控
SQL
- support Transation
NoSQL
- Transation support 差
維護成本
- Shard
- Replica
- Performance Tuning
SQL
- support sharding
- support replica
- 需維護Index、Migration及Profile監控Query品質，資料關聯維度多時就較花時間
NoSQL
- support sharding
- support replica
- 只需建立Index，最差的情況就是Table scan，所以少量資料多關聯時較有利
資料量
- 有效產品數3,000
- 總產品數約20,000
- 總套餐數約77,000
- 未來成長幅度以五倍來看及套餐靈活度來看產品數可能到100,000，套餐數約略400,000
- 假設每個套餐下的選填資料10個語系，即為4,000,000筆
- 假設每個產品下的描述為20個，即為8,000,000筆
- 例：以目前的product_photo來看已有800,000筆，未來要將圖片分語系來看會以倍數成長，product_pkg_lang也是500,000筆，
SQL
- 資料量越多關聯的速度越慢filter要index的數量會越多
- 相關資料關聯起來單一商品可能會有二三倍以上的rows才可以取的所有資料
No SQL
- 資料量越多只要需要filter的欄位有index查找速度會有一定水準
- 直接查詢document本體不需要關聯直接取得大多數資料
開發成本
- Laravel support
- 工程師學習成本
- 技術債
SQL
- Laravel 內建支援ORM
- ORM使用方式不需學習
- 可直接下語法
- 無技術債
NoSQL
- Laravel視狀況需安裝套件才可ORM有些可能沒有
- 一樣是ORM但用法有些許差異需看一下文件
- 可直接下語法
- 技術債為底層資料存取應用情境判斷好，反而可以享受到好處減少開發成本
學習曲線
- 工程師需是否難以學習?
- 工程師是否使用困難?
- 文件完整性
SQL
- 工程師內建SQL知識，下的好壞依工程師個人水平而定
- 工程師透過ORM或直接寫Query都很簡單
- 網路上都有完整的社群及文件
NoSQL
- 需學習新的概念
- 透過ORM使用方式與SQL類似，但進階Query時就需要學習新的Query語法
- 網路上都有完整的社群及文件，只要是普及率高的NoSQL
使用面比較
情境一 商品語系處理
- 一個商品可以有多個描述
- 一個描述可以有N個語系
- 一個描述可以被重覆使用在多個商品及套餐
查詢維度：商品 x Ｎ個描述 X N個語系(有可能變多)
資料量成長維度：N x N x N
目前處理這方面的Table有：
product_detail、product_detail_lang、product_photo、product_photo_lang、
情境二 套餐價格表
- 一個套餐可以有Ｎ個幣別售價
- 每天每個幣別可能會有不同的售價
- 每天會有不同的匯率去更新所有套餐價格
更新維度：N個套餐 x Ｎ個幣別匯率
資料量維度：N x N x 天數
情境三 商品購買規格
- 一個套餐有N個語系
- 每個購買規格欄位也可以有N個語系
- 每個套餐可以自由的加入商品規格
- 每個商品規格有分不同的型態
維度：1套餐 x Ｎ個語系 x N個購買規格 x N個規格語系
資料量維度：N x N x N x N
情境四 位控
- 一個套餐會對應到每天會有不同的"可販售量"
- 每次成立訂單會扣除相對應的數量
- 需驗證購買量 > 可販售量 訂單方可成立