回覆列表
  • 1 # 小小創意手工

    日活都百萬了,那麼我估算一下場景

    資料存量較大,一般來講這個總使用者量至少千萬級別資料增量不少(包括業務資料和日誌資料)訪問壓力也有一定量對於資料探勘和分析應該有很大需求,需要滿足精細化運營需求效能、吞吐等都有一定要求

    建議使用TiDB即可

    TiDB 是 PingCAP 公司自主設計、研發的開源分散式關係型資料庫,是一款同時支援線上事務處理與線上分析處理 (Hybrid Transactional and Analytical Processing, HTAP)的融合型分散式資料庫產品,具備水平擴容或者縮容、金融級高可用、實時 HTAP、雲原生的分散式資料庫、相容 MySQL 5.7 協議和 MySQL 生態等重要特性。目標是為使用者提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、資料規模較大等各種應用場景。

    五大核心特性:

    一鍵水平擴容或者縮容得益於 TiDB 儲存計算分離的架構的設計,可按需對計算、儲存分別進行線上擴容或者縮容,擴容或者縮容過程中對應用、運維人員透明。金融級高可用資料採用多副本儲存,資料副本通過 Multi-Raft 協議同步事務日誌,多數派寫入成功事務才能提交,確保資料強一致性且少數副本發生故障時不影響資料的可用性。可按需配置副本地理位置、副本數量等策略滿足不同容災級別的要求。實時 HTAP提供行儲存引擎 TiKV、列儲存引擎 TiFlash 兩款儲存引擎,TiFlash 通過 Multi-Raft Learner 協議實時從 TiKV 複製資料,確保行儲存引擎 TiKV 和列儲存引擎 TiFlash 之間的資料強一致。TiKV、TiFlash 可按需部署在不同的機器,解決 HTAP 資源隔離的問題。雲原生的分散式資料庫專為雲而設計的分散式資料庫,通過 TiDB Operator 可在公有云、私有云、混合雲中實現部署工具化、自動化。相容 MySQL 5.7 協議和 MySQL 生態相容 MySQL 5.7 協議、MySQL 常用的功能、MySQL 生態,應用無需或者修改少量程式碼即可從 MySQL 遷移到 TiDB。提供豐富的資料遷移工具幫助應用便捷完成資料遷移。

  • 2 # 猿問

    以mysql為列:

    1:支撐高併發系統,一定會涉及事務,所以資料庫引擎必選innodb,innodb支援事務,事務級別根據業務而定,如果業務資料一致性要求很高,事務就開啟序列化級別,這樣就完全隔離事務,但是會導致鎖資源競爭加劇。mysql的效能有一定的降低。

    2:讀寫分離,資料庫分成主庫和從庫,主庫負責寫資料,叢庫負責讀資料。注意主從資料庫資料一致性問題。

    3:冷熱資料分離,美團,餓了麼部分設計採用冷熱資料分離,拿訂單來說,已送達訂單,主要的業務場景就是查詢,越往前的資料查詢的概率就越低。這就是冷資料。正在交易的訂單就是熱資料,需要時時查詢和更新。對於冷資料,可以放到redis快取。這樣會增加查詢效率。

    4:資料表設計,充分利用索引查詢。業務sql避免返回無用的行和列,禁止使用select *查詢,查詢的時候加limit,儘可能返回滿足要求的行。對於複雜的sql,考慮拆分sql,拆分sql有一個好處,重複查詢的sql,第二次查詢會放到mysql的緩衝區,避免重複操作磁碟,提高訪問的效能。

    5:分庫分表。比如業務資料按月分等。一定程度緩解增刪改查的壓力。

  • 3 # 唸經姐姐

    這個問題的需求不夠明確,主要是業務方面。

    比如是一個百萬日活的IM系統。

    則百萬日活的,假定有1000萬用戶的系統,用MYSQL基本可以不用分庫分表(可以採用讀寫分離)。

    主要是快取系統的設計,常見的比如redis,可以使用者全快取在redis中,只有使用者更改時才回寫(回寫也可以先寫快取,再非同步刷入庫中)。這樣的設計,就使用者表而言,基本是沒有多少負載的。

    真正複雜的是業務本身,比如是一個論壇,可能一天的新貼,回覆等會產生巨量的資料。或是一個電商系統,商品,訂單等。這些沒有資料量都無法評估。

    只是總體來看,用MYSQL(讀寫分離,分表設計)+快取 是夠用了。

  • 4 # 此生唯一

    之前做過一個每天訪問量達到800w的系統,簡單說下自己的見解!

    資料庫層面,一般無外乎是主從複製,讀寫分離,分庫分表這些東西!

    1,從單臺數據庫效能來看,單個mysql例項最大連線數為16384,就是說在同一時間最多能容納那麼多的訪問量,同時受伺服器CPU,記憶體,硬碟等的影響,但是在實際應用中能達到2000就不錯了!

    需要使用druid等資料庫監控中介軟體,實時的監控資料庫連線,sql效率等各種指標,在達到瓶頸之前找到辦法,show status;這個指令也可以方便的檢視資料庫例項的各項指標

    單臺數據庫例項配置最優化是保證整個資料庫叢集最優化的基本保證!

    分庫分表的思想很簡單,比如單表1億的資料量,查詢效率很低,如果使用8庫1024表拆分,每張表中的資料不會超過10萬,對資料庫來說不存在任何瓶頸,就算總資料量達到100億,單表的查詢也不會慢!

    拆分的策略通常以某個全域性唯一的業務主鍵使用某種方式(比如hash取模,按月份等等)進行分庫分表的計算!

    那麼問題來了,全域性唯一的欄位怎麼獲取?普通的資料庫主鍵自增,uuid等不再合適,可以使用redis,zookeeper等獲取全域性唯一的id,具體可參見之前的其他回答!

    問題:分庫分表之後存在跨庫join的問題,通常的解決方式為1,儘量使用分庫分表主鍵能保證在同一庫,同一型別的表中進行連線查詢,2,增加專門的查詢庫:將常用的資料欄位冗餘到查詢庫中,方便連線查詢和常用欄位的快速查詢;

    4,sql優化:最基本的條件查詢,count,分組等使用索引欄位等避免全域性查詢,避免null值判斷,避免使用not in,避免無效的like語句,避免查詢的時候使用函式操作等等!

    5,像秒殺系統等這種瞬時高併發,最好藉助快取系統來完成!

    總而言之,資料庫是整個應用系統當中最核心,也是最容易出問題的地方,做好監控,提前預防才能保證系統訪問量的增長!

  • 中秋節和大豐收的關聯?
  • Oppo find x2適合當禮物嗎,顏值怎麼樣?