工作需求:
儲存: mysql
資料量: 每月100w~500w
現狀: 當前儲存沒有問題，單月查詢在總表2000w之內，索引優化好，能支撐現有業務
需求:業務比較穩定後業務方有跨月查詢的需求，折中估計每月250w資料，查詢12月，資料量為3000w，單錶資料量突破經驗值2000w常規的索引優化左襟見拙
分析: 分表是是不可行，當前跨月的報表分析結果主要為乙個複雜的查詢，全量聚合操作+子查詢。落地一張聚合表，可以探索但，前端報表篩選條件涉及到各個維度，存在儲存最粗粒度的資料就要犧牲前端篩選條件，是不能接受，存最細單錶已預估一年量為3000w，傳統的調優引數，mysql儲存已經到了天花板，加記憶體和機械硬碟換固態硬碟?成本太高，不能接受，快取層思考，預估一些使用者的查詢行為，比如只允許按季度查詢?這樣按照季度分割槽，可行，但限制了報表分析能力，可接受但總是糜爛著工程師的妥協。思考過後，能不能從傳統的資料庫轉向分布式大資料的儲存方案，例如mycat, hive, hbase, impala。
思考: 傳統資料庫因為有著資料量小查詢快，而且具備強一致性的鎖機制和事務機制，分析本需求，報表只是單純的供查詢，０事務，不存在加鎖增刪改操作，因為之前使用mycat的經驗，坑比較多，比如count函式會出現多個分片的結果，所以目標鎖定為hive，hive的表結構可以和mysql表結構相似，使用也較sql比較相似。
待解決的問題
壓測是否滿足查詢的效能問題，跨月資料量已３年資料量預估最大值進行
財務資料比較敏感，hive的許可權問題，打算對相關金額做統一的加密儲存，需要考慮在加密前後進行聚合操作，比如sum運算元據前後一致性問題
壓測資料
可以看到，我們模擬了三年的資料量，且月資料量為1000w，全量資料４億多，進行壓力測試。測試結果很喜人，測試效果如下
壓測結果
資料量複雜查詢耗時
資料量為6000w，月份為６個月
４～１０s
資料量4億多，月份為36個月
1分鐘左右
注:此結果是在presto 20個節點下的集群，且無任務阻塞下進行
如上面壓力測試所得，在月資料大大高於真實業務資料量的情況下，耗時還是可以接受的，由此可見，選擇hive可行
資料脫敏加密
大家都知道，財務資料的金額比較敏感，且hive許可權這一塊沒有很好的評估，所以針對金額進行加密處理，且加密之後在進行一些sum操作的時候，加密前和加密後能保持經過加密和解密之後保持乙個可逆性。
考慮金額加或者減，或者乘除乙個係數(比較簡單也比較容易操作)
進行加密演算法加密
加密演算法加密示例如下:
加密演算法:aes_encrypt, 解密演算法: aes_decrypt
轉換函式:hex, 轉換函式逆向:unhex。
新建一張如下測試表
create table `tb_finance_encrypt_test` (
`goods_id` bigint(20) unsigned not null auto_increment,
`cost` decimal(11,2) not null default '0.00',
`cost_encrypt` char(64) not null default '',
primary key (`goods_id`)
) engine=innodb auto_increment=5 default charset=utf8;
# 插入測試資料
insert into `test`.`tb_finance_encrypt_test` ( `cost`,`cost_encrypt`) values
('100000',hex(aes_encrypt(100000, 'liuyifan3'))),
('30.53',hex(aes_encrypt(30.53, 'liuyifan3'))),
('400000000.82',hex(aes_encrypt(400000000.82, 'liuyifan3'))),
('2.82',hex(aes_encrypt(2.82, 'liuyifan3'))),
('3',hex(aes_encrypt(3, 'liuyifan3'))),
('6.78',hex(aes_encrypt(6.78, 'liuyifan3')));
為什麼用轉換函式hex，其上可以看出，經過轉換後的cost，可以一直保持在乙個32位字串的格式，便於儲存，aes_encrypt函式返回的是一串二進位制的資料，也可以直接儲存，可存為blob型別。
聚合測試
select sum(cost), sum(aes_decrypt(unhex(cost_encrypt), 'liuyifan3')) from `test`.`tb_finance_encrypt_test`;至此資料加密功能要已經解決。補充說明，上面用的函式mysql都自帶，hive中我們的客戶端是用presto進行訪問hive，原生的presto版本不支援上面提到的加密函式和轉換函式。但擴充套件起來也是相當方便。也可以採用四則運算乘以乙個偏移量的操作。
總結:對資料事物要求不高，加鎖要求不高，這種直接和頁面進行報表展現的資料量超過2000w的建議直接上hive
資料安全的思考不僅可以加密脫敏，也可以混如一些干擾資料，這些干擾資料在解密後可以進行條件的過濾
presto是個好東西，用起來
Sqlserver 高併發和大資料儲存方案
隨著使用者的日益遞增，日活和峰值的暴漲，資料庫處理效能面臨著巨大的挑戰。下面分享下對實際10萬 峰值的平台的資料庫優化方案。與大家一起討論，互相學習提高！案例 遊戲平台.1 解決高併發 當客戶端連線數達到峰值的時候，服務端對連線的維護與處理這裡暫時不做討論。當多個寫請求到資料庫的時候，這時候需要對多...
大資料儲存
主流資料庫 1 mysql 以前是sun公司的產品，後被甲骨文公司收購，開源 2 oracel 成本較高，100w左右 3 db2 成本較高，100w左右 4 nosql 非關係性資料庫，基本都是key value結構 很多門戶 都使用mysql，例如 雅虎，資料庫的主從備份，是處於負載均衡範疇。資...
大資料儲存綜述
san 金融電信級別，高成本的儲存方式，涉及到光纖和各類高階裝置，可靠性和效能都很高，除了貴和運維成本高，基本都是好處。檔案儲存 nas，網路儲存，用於多主機共享資料。物件儲存 跟自己開發的應用程式打交道，如網盤。分布式鍵值系統 分布式鍵值系統用於儲存關係簡單的半結構化資料。典型的分布式鍵值系統有a...