鍍金池/ 問答/PHP  數(shù)據(jù)庫/ Mysql億級數(shù)據(jù)如何設(shè)計分表？

Mysql億級數(shù)據(jù)如何設(shè)計分表？

現(xiàn)在有一張閱讀獎勵log表大概億級數(shù)據(jù)(存儲大小50G)
表結(jié)構(gòu)，id,num(閱讀獎勵次數(shù))，uid(用戶id)，acid(文章id),ac_url(文章路徑),atime,channel(渠道)
現(xiàn)在這張表有三個常用查詢語句
1.使用uid來查詢這個用戶的累積閱讀次數(shù)sum(num)
2.使用atime查詢時間范圍內(nèi)累積閱讀獎勵次數(shù)sum(num)
3.使用uid+atime查詢累積閱讀獎勵次數(shù)sum(num)
現(xiàn)在以上查詢已經(jīng)很慢了，想請問分表或分區(qū)如何操作？
如果按照每天分表2和3的時間范圍查詢豈不是每次都要聯(lián)合查詢？
如果按照用戶id后四位分表那只提升了1查詢的效率吧？時間查詢還是聯(lián)合查詢

還有舊數(shù)據(jù)是如何最快速度寫入到分表里的等等，不勝感激！

真心求教如何解決問題。感謝?！

回答
編輯回答
凹凸曼
  1. 使用MySQL中間件分表 (可以按月分表) (不是比較好的解決方案)
  2. 建議使用分布式數(shù)據(jù)庫 例如TiDB 或者阿里云的商用分布式數(shù)據(jù)庫
2017年1月20日 08:08
編輯回答
殘淚

為啥不是直接增加兩個表記錄sum(num)? 一個是根據(jù)uid一個根據(jù)atime, 按道理這種日志式的數(shù)據(jù)寫(只有create沒有update)的次數(shù)會遠遠小于查的次數(shù), 更何況是每個查詢都sum, 相當(dāng)于是每個查詢都要迭代完整個result.

如果強行按你現(xiàn)有的方案的話只能二選一咯, 這個按歷史調(diào)用次數(shù)及成本分析下就ok了

2018年2月17日 11:24
編輯回答
來守候

分表的話，我之前是按照 uid % 50 取模（和hash一個意思）。比如：table_0/table_1.../table_49
這樣的缺點就是按時間查詢費勁一點。
具體按時間分表，還是按uid分表，主要看那個查詢要多一點。

另外，數(shù)據(jù)量都上億了，為什么還考慮mysql呢？可以換ElasticSearch之類的吧。
如果經(jīng)常查詢匯總數(shù)據(jù)，也可以定時自動先把數(shù)據(jù)匯總到一個表里，便于查詢。

2018年2月10日 16:06
編輯回答
安若晴

統(tǒng)計類的功能，對實時性和準(zhǔn)確性要求不是特別高，建議新建匯總表，晚上定時做增量數(shù)據(jù)的匯總更新，通過預(yù)計算解決性能的問題。

2017年2月8日 15:19
編輯回答
還吻

  • 根據(jù)uid哈希后（或如你所說后四位）分表；支持1，3的查詢

    • 優(yōu)勢：并發(fā)：根據(jù)uid分表，將并發(fā)負載平攤至各表；如果按時間分表，那并發(fā)問題無法解決
  • 2的查詢由上表，每日定時匯總，單獨計入一個表（或分表，按月等）
如上面同學(xué)所說，TIDB也行。
2018年3月20日 14:10