1. 程式人生 > >億級訂單資料分庫分表的一些想法

億級訂單資料分庫分表的一些想法

前提:

    公司年1億~10億訂單,需要滿足未來3~5年資料儲存。所有物理或效能上的提高都無法滿足業務需求。

思路:

    使用多個庫建立多張表,如1024張表(單庫或少量庫會存在TPS瓶頸),這樣每張表只要儲存約100萬資料。

解決方案:

    1、快速查詢使用者所有訂單資料(單使用者的所有訂單資料在一張表中)

        根據使用者id進行hash得到hash_code,然後根據hash_code%1024定位表名。

    2、(不知道使用者id的情況下)根據訂單id查詢訂單資料

        有人提供方法:建立使用者id與訂單號的對映關係表,通過該表找到使用者id,然後找到表名。如果訂單有100億條,這個對映張也需要儲存100億條資料,同樣存在問題。

訂單號中嵌入使用者id的hash_code,這樣只要提取訂單號中的hash_code就可以根據該hash_code找到表名。

    3、統計各業務線中的訂單資料

        建立業務訂單表,同步訂單資料到業務訂單表中(有時候不是所有業務線都需要統計)。

溝通交流請關注公眾號。

相關推薦

訂單資料分庫一些想法

前提:     公司年1億~10億訂單,需要滿足未來3~5年資料儲存。所有物理或效能上的提高都無法滿足業務需求。 思路:     使用多個庫建立多張表,如1024張表(單庫或少量庫會存在TPS瓶頸),這樣每張表只要儲存約100萬資料。 解決方案:     1、快速查

10訂單系統分庫設計思路

一、背景 隨著公司業務增長,如果每天1000多萬筆訂單的話,3個月將有約10億的訂單量,之前資料庫採用單庫單表的形式已經不滿足於業務需求,資料庫改造迫在眉睫。 二、訂單資料如何劃分 我們可以將訂單資料劃分成兩大型別:分別是熱資料和冷資料。 熱資料:3個月內的訂單資

訂單系統分庫實踐

  背景 原大眾點評的訂單單表早就已經突破兩百G,由於查詢維度較多,即使加了兩個從庫,優化索引,仍然存在很多查詢不理想的情況。去年大量搶購活動的開展,使資料庫達到瓶頸,應用只能通過限速、非同步佇列等對其進行保護;業務需求層出不窮,原有的訂單模型很難滿足業務需求,但是基於原訂單表的D

大規模IM使用者資料分庫之二叉樹分庫

1、起因         網際網路發展帶來來了資料量巨增,單資料無法解決,導致出現了資料庫分庫和分表,其主要目的是為突破單節點資料庫伺服器的 I/O 能力限制,解決資料庫擴充套件性問題。但是分庫和分錶帶來的問題是業務資料的一致性,線性可擴充套件性,管理的複雜性和容錯性帶來了

SpringBoot 2.0 整合sharding-jdbc中介軟體,實現資料分庫

一、水平分割 1、水平分庫 1)、概念: 以欄位為依據,按照一定策略,將一個庫中的資料拆分到多個庫中。 2)、結果 每個庫的結構都

Sharding-JDBC資料分庫實踐(水平分

摘要 範圍(range)分表也需要確切(precise)分表策略,這點很重要。 確切分表根據分表字段確定資料落在哪一個庫。 範圍分

[NewLife.XCode]分庫(百資料儲存)

NewLife.XCode是一個有15年曆史的開源資料中介軟體,支援netcore/net45/net40,由新生命團隊(2002~2019)開發完成並維護至今,以下簡稱XCode。 整個系列教程會大量結合示例程式碼和執行日誌來進行深入分析,蘊含多年開發經驗於其中,代表作有百億級大資料實時計算專案。 開源

超實用的mysql分庫策略,輕鬆解決資料問題

    一、分庫分表的背景 在資料爆炸的年代,單表資料達到千萬級別,甚至過億的量,都是很常見的情景。這時候再對資料庫進行操作就是非常吃力的事情了,select個半天都出不來資料,這時候業務已經難以維繫。不得已,分庫分表提上日程,我們的目的很簡單,減小資料庫的壓力,縮短表的操作時間。 &n

訂單分庫方案設計(大資料)

原創文章,轉載註明出處 一、兩種方案分庫分表  一般業界,對訂單資料的分庫分表,筆者瞭解,有兩類思路:按照訂單號來切分、按照使用者id來切分。 方案一、按照訂單號來做hash分散訂單資料      把訂單號看作是一個字串,做hash,分散到多個伺服器去。      具體到

全量資料同步與資料校驗實踐——應對百量級分庫異構庫遷移

在一家發展中的公司搬磚,正好遇到分庫分表,資料遷移的需求比較多,就入坑了。最近有個系統重構,一直做資料重構、遷移、校驗等工作,基本能覆蓋資料遷移的各個基本點,所以趁機整理一下。 資料同步的場景是:資料庫拆分、資料冗餘、資料表重構。 資料重構服務主要包括:全量

分庫實戰總結(萬字乾貨,實戰覆盤)

微信搜尋【阿丸筆記】,關注Java/MySQL/中介軟體各系列原創實戰筆記,乾貨滿滿。   分庫分表的文章網上非常多,但是大多內容比較零散,以講解知識點為主,沒有完整地說明一個大表的切分、新架構設計、上線的完整過程。 因此,我結合去年做的一個大型分庫分表專案,來複盤一下完整的分庫分表從架構設計

資料庫分庫(sharding)系列(五) 一種支援自由規劃無須資料遷移和修改路由程式碼的Sharding擴容方案(轉)...

作為一種資料儲存層面上的水平伸縮解決方案,資料庫Sharding技術由來已久,很多海量資料系統在其發展演進的歷程中都曾經歷過分庫分表的Sharding改造階段。簡單地說,Sharding就是將原來單一資料庫按照一定的規則進行切分,把資料分散到多臺物理機(我們稱之為Shard)上儲存,從

資料庫分庫 sharding 系列 五 一種支援自由規劃無須資料遷移和修改路由程式碼的Sharding擴容方案

分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!        

資料庫分庫——擴容無須資料遷移的分片演算法

擴容無須資料遷移的分片演算法 常見的分庫分表方案大都用主鍵mod一個數(如分為8個庫,則 id % 8 根據餘數決定落到哪個分片)。此種方案中,如果要拓展資料庫將是十分複雜的事情(例如拓展為10個,則程式碼需要改為 id % 10 之前的舊資料也要做遷移)。我們希望有一種支援自由規劃無須資料遷移和修

海量資料分庫技術演進,最佳實踐

每個優秀的程式設計師和架構師都應該掌握分庫分表,移動網際網路時代,海量的使用者每天產生海量的數量 使用者表 訂單表 交易流水錶 以支付寶使用者為例,8億;微信使用者更是10億。訂單表更誇張,比如美團外賣,每天都是幾千萬的訂單。淘寶的歷史訂單總量應該百億,甚至千億級別,

時序資料分庫

這裡的時序資料泛指一切隨時間推移而不斷增長的資料,比如通話記錄、銀行交易記錄等。 對於資料庫來講,時序資料並沒有什麼特殊性,可以和普通資料一樣放在資料表中。不過,因為不斷增長,積累時間較長後,這種資料的量常常都會很大。一個物理表的資料量太大時,就會影響查詢和計算的效能。

MySQL訂單分庫多維度查詢

以訂單表為例, 按照使用者ID mod 64 分成 64個數據庫. 按照使用者的維度查詢很快,因為最終的查詢落在一臺伺服器上. 但是如果按照商戶的維度查詢,則代價非常高. 需要查詢全部64臺伺服器. 在分頁的情況下,更加惡化. 比如某個商戶查詢第10頁的資料(按照訂單的建立時間).需要在每臺數據庫伺服器上查詢

資料庫水平分庫後的資料頁查詢解決方案

原始碼在這 核心程式碼在這 需要結合這個目錄下的檔案才可以看的大概 所有的測試程式碼在test模組下 測試結果在底部: 2018-11-06更: 走過路過可以給個star嘛,原先的github刪了,重新開始,看著我那小小的star數,emmmmm…說下最近吧,最

MySQL分庫——保持資料一致性

MySQL處理大規模業務資料的方案一般都是分庫分表.最開始一般都選擇垂直拆分.比如電商網站,可能按照家電,圖書,母嬰等商品分類進行拆分.這樣做的好處是拆分簡單,並且沒有破壞資料庫事務.但是隨著業務的增長,比如圖書分類的訂單資料表已經到達了10個T的規模.就需要考慮做水平拆分了.把邏輯上一個表的資料,分別存放到

分散式資料層中介軟體詳解:如何實現分庫+動態資料來源+讀寫分離

優知學院 2018-10-13 12:10:20   分散式資料層中介軟體: 1.簡介: 分散式資料訪問層中介軟體,旨在為供一個通用資料訪問層服務,支援MySQL動態資料來源、讀寫分離、分散式唯一主鍵生成器、分庫分表、動態化配置等功能,並且支援從客戶端角度對