Mysql是幾千萬還是幾億數(shù)據(jù)如何設計數(shù)據(jù) 1億？上億數(shù)據(jù)用什么數(shù)據(jù)什么最適合你的圖書館數(shù)據(jù):關系型數(shù)據(jù):可以參考阿里和JD.COM用mysql集群解決非關系型數(shù)據(jù):。

一次插入300萬，簡單的插入操作。如果數(shù)字足夠大，可能需要很長的寫操作。你可以試著寫300萬條sql語句，在工具中執(zhí)行它們需要多長時間。當然，批量插入可能會很快，但也需要很多時間。這取決于你是否需要改變你的插入順序和你是否需要一個索引。如果需要指數(shù)，那就太可怕了。如果有索引，必須將其刪除，然后在插入完成后重建索引。最好把它附加到頁腳。

本文中的數(shù)據(jù)平臺已經(jīng)迭代了三個版本，從一開始就遇到了很多常見的問題。終于有時間整理了一些完善的文檔，在這里分享給朋友們。實現(xiàn)參考，少走彎路，專注于ES在這個空間的優(yōu)化。目前生產(chǎn)已存儲100億數(shù)據(jù)，性能良好。關于HBase和Hadoop的設計優(yōu)化有很多文章可以參考，就不贅述了。項目背景:在某業(yè)務系統(tǒng)中，部分表的數(shù)據(jù)日交易量超過1億，已按天表示，但業(yè)務受限于日查詢，只能在DB中保存3個月的數(shù)據(jù)(硬件配置高)，數(shù)據(jù)庫共享成本高。

1。數(shù)據(jù)如果量太大，比如幾億，就用oracle，Oracle有幾億的優(yōu)勢。數(shù)據(jù)對于Oracle來說，它比較輕便，不需要太多的優(yōu)化配置，但是安裝麻煩，上手慢。2.數(shù)據(jù)對于大批量，比如幾千萬，用postgresql，號稱Oracle的標桿，處理幾千萬還是可以的數(shù)據(jù)，也很易學易用。3.數(shù)據(jù)的量一般，比如幾百萬，mysql處理數(shù)據(jù)mysql這個級別還是比較快的。

單桌1億？還是一億的整個圖書館？1.首先可以考慮業(yè)務級優(yōu)化，即垂直表拆分。豎表拆分是將一個數(shù)據(jù)數(shù)量較大的表按照某個字段的屬性或者使用頻率拆分成多個表。如果有多種業(yè)務類型，每種業(yè)務類型都列在不同的表中，如表1、表2和表3。如果日常業(yè)務中不需要用到全部數(shù)據(jù)的話，可以按照時間來安排，比如月表。每張表只保留一個月的記錄。

橫向表拆分是將數(shù)據(jù) row按照一個或多個列數(shù)據(jù)的值放入多個獨立的表中，沒有業(yè)務意義。如果按id劃分表，則以09結尾的數(shù)據(jù)分別插入10個表中。也許你要問了，看起來和剛才說的立桌沒什么區(qū)別。只是是否有業(yè)務意義是按照字段的值劃分成表的。其實橫向劃分是最流行的實現(xiàn)方式，通過橫向子庫來實現(xiàn)。也就是剛才說的10個表分布在10個mysql 數(shù)據(jù) libraries中。

看你有什么數(shù)據(jù):關系型數(shù)據(jù):可以參考阿里和JD.COM用mysql集群解決非關系型數(shù)據(jù):用nosql集群解決它，MongoDB，Redis等當然-。這種情況下，學習hadoop，只有這個最合適，圖書館，一定是NoSQL。