爲什麼數據庫選型和找對象一樣重要
一、找對象
正常路徑:
- 知己 -> 緣分出現 -> 戀愛[知彼] -> 結婚 -> 2個家庭關係結合(七大姑八大姨) -> 生娃 -> 帶娃 -> 七年之癢 -> 愉快的共度一生
錯誤後果:
- 1、家庭不和睦
- 2、影響小孩成長
-
3、離婚
- 生無可戀
- 財產分割
- [娃]的成長、撫養問題等
- 家庭關係處理
- 4、再婚
二、數據庫選型
正常路徑:
- 評估 -> [技術磨合] -> 研發 -> 上線 -> 迭代維護期
錯誤後果:
-
1、研發、維護、軟件、硬件成本增加,
- 性能問題
- 線下輸出, 某些開源協議導致的軟件分發風險
- 架構遷就數據庫, 導致開發週期變長、軟件|硬件|維護成本增加
-
2、影響業務, 營收、客戶數,
- 如果出現異常, 導致業務受到影響
-
3、企業形象
- 穩定性、安全問題、數據泄露等問題...
三、誰爲數據庫選型負責
- 開發者?
- DBA?
- 架構師?
- 技術總監?
- CTO?
- 技術委員會?
怎麼選型?
四、選型中最容易踩到的幾個坑
- 大公司用什麼我就用什麼, 沒大錯.
- 用熟不用生.
- 統一技術棧, 一個庫解決一切.
五、在什麼時間點選型?
架構設計階段
六、架構設計階段有哪些能確定|預判的指標?
一定不完整, 請各位自行補充
1、技術指標
1、業務類別(在線事務處理、離線分析、實時分析、混合業務)
2、業務場景
3、數據量
4、業務場景相關性能指標(併發、qps、rt)
5、行業合規訴求
6、開發語言
7、應用級功能訴求(圖像識別, 分詞搜索, GIS, 用戶畫像, 化學分析, 多維搜索, ...)
8、各種場景的工業標準性能指標(tpcc tpch tpcds)
9、可用性
10、可靠性
11、安全
12、一致性要求
13、擴展性要求
14、容災要求
15、可恢復的目標範圍要求
16、恢復耗時要求
2、商務指標
1、業界成功案例
2、使用這個產品時的開發週期
3、使用這個產品時的開發人力投入成本
4、使用這個產品時的項目it投入成本
5、數據庫軟件license成本(不同輸出形式下的成本和風險)
6、數據庫運維人力投入成本
7、[雲產品成本]
3、生態指標
1、發展趨勢(全球趨勢、本土趨勢: 谷歌搜索趨勢、stackoverflow趨勢、招聘數量)
2、活躍度(bug響應速度, 修復速度. 小版本發佈頻率. 大版本發佈頻率. 提交數.)
3、培訓公司數量、規模(全球、本土)
4、學習成本(有數據庫基礎到達中級水平需要多長時間)
5、服務公司數量、規模(全球、本土)
6、雲廠商數量、規模
7、數據庫廠商數量、規模
8、社區規模(人數、內容、活動、流量)
9、市場份額
七、建立DB畫像庫
建議定期更新數據
數據庫種類
一定不完整, 請各位自行補充
- 緩存
- 關係
- 離線倉庫
- 在線倉庫
- nosql
- 時序
- 圖
- GIS
- ...
畫像庫
一定不完整, 請各位自行補充
- pg,
- mysql,
- oracle,
- greenplum,
- polardb o,
- adb pg,
- redis,
- hbase,
- mongo,
- timescaledb,
- agensgraph,
- edgedb,
- postgis,
- ... ...
八、數據庫產品很多, 怎麼做到深度分析?
1、內部技術專家
- 建議技術棧多元化, 提高技術競爭力.
2、聘請外部技術顧問
- 推薦, 沒屁股, 比較公正
3、外部參考資源
- 權威行業報告
九、建立評估模型
類似招標書，建立評估模型。
1、技術分
2、商務分
3、生態分