• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            woaidongmao

            文章均收錄自他人博客,但不喜標題前加-[轉貼],因其丑陋,見諒!~
            隨筆 - 1469, 文章 - 0, 評論 - 661, 引用 - 0
            數據加載中……

            一個表有100億條記錄,如何優化

            我們的數據庫還在設計階段。
            我們預計數據量將會很大,
            一年的時間里,一張表,就會產生100億條數據,

            表結構,如下
            id,userid,createddate,
            等等
            正常情況下,100億條記錄如果都存在一個表里,
            那么如果通過userid來查尋一定很慢。

            所以,請教各位
            在查詢的性能優化上,
            表結構,數據庫結構,
            有什么好的建議,
            mysql實現,是否合適?

            提示,業務需求中的一個特性是:
            每個用戶都有一個userid
            用戶只會查自己的數據,不會查看別人的數據。

            謝謝各位。

            ===========================================================================

            所有的優化都包含兩方面,技術的優化和需求的優化。
            單表100億肯定不是一個好做法。即使每條只有1k,總的也差不多有10T,再考慮到備份,更復雜了。mysql單表也不支持10T數據。
            有一個辦法,是根據日期創建新的表插入數據。
            另外在需求優化方面,可以是只查詢近期的數據,那樣速度最快。如果要查詢歷史數據,就單獨做一個接口。

             

            ===========================================================================

            我很好奇什么應用能在一年達到100億的數據?還要用MySQL

            簡單的優化方法是分兩個表存儲,最近一段時間(如3個月)放在一個表里,其他放在歷史表里,一般只查詢第一個表。

            ===========================================================================

            從硬件入手可以采取

            1
            、最簡單的提升性能的方法就是提升硬件,增加硬件的投入效果立竿見影,不過這個主要是是投資方的可接受成本問題了。一般的來說從硬件方面的投資主要是購買大型機RS9000,購買磁盤柜(同時也是高可用的需要),增大內存。這些都可以提升系統的速度。
            2
            從軟件方面來說首先應該盡量使用64位的數據庫,同時數據庫應當建立在裸設備上。
            3
            對于億級別的數據通常是歷史數據,而百萬以及千萬級別的數據通常是交易數據,這兩種確實有很大區別,歷史數據多為了讀取,交易數據通常是可修改的,在建立索引的時候要考慮插入的問題。
            4
            通常有表分區功能的數據庫就不需要在設計上進行分表設計,只有在數據庫系統不提供該功能的時候才會采用分表設計。分區要建立在不同的磁盤上以提升IO性能。

            從軟件架構和業務層面
            1.
            使用SNA進行緩存如:memcached sina memcachedb
            2.ORMapping
            (如hibernate)的session緩存和線程級別緩存;
            3.
            使用領域模型驅動的分析設計方法分析業務;
            這里關鍵是"領域模型驅動設計",因為性能之所以優化,而不是提升,是因為總有一天優化不下去;只有領域逐漸清晰才可能使系統具有伸縮性;

             

            ===========================================================================

               100億條記錄如果都存在一個表里,這樣的速度mysql肯定是要被摒棄,就算oracle也吃不消這樣的數據量,你這一張表就吃掉Ndbf。建議把表結構分拆吧,比如說你查詢可以做一個聯合查詢接口或視圖,該視圖可以通過多張users表演化而來,先前的user表被拆分成若干表,對常用用戶的表單獨處理,對不常用的用戶會定時通過程序進行數據轉移,當然oracle的索引是少不了的,不過從根本上看這么大的數據量的表設計就有問題,或許從整個項目的構架上去考慮,重新設計才能正確解決這張表的性能問題。

            ===========================================================================

            樓上的回答都可以參考一下
            如果在mysql上只是提供查詢功能,是否可以這樣:
            建立總表,存放歷史所有數據,再根據時間,比如2個月或者1個月一個表建立分表,如果只查詢某個人的信息的話,查詢分表就好了,要是進行統計的話,對總表進行操作,看情況增加緩存功能

            ===========================================================================

            100億數據量大了,mysql單表好支持不了都少。如果不拆分數據,只能用分區來存儲了,查詢的優化就不說了。

            ===========================================================================

            分表吧...你看你的100y數據是否都需要查詢或者調用..如果對查詢不是很高...可以做bigfile放棄數據庫存貯..靠文件流和偏移量讀取..

            ===========================================================================

            mysql不合適,數據太大了!考慮一下創建物理索引

            ===========================================================================

            兄弟,你只有做分表了.你可分成10000張表,把數據拆分開,平均放到這些表中,這樣每張表相當于100萬條數據,我想應該很快的.分表的具體方法我們可以再討論

            ===========================================================================

            Mysql一張表有100億才很快的話 oracle早就關門了
            oracle
            100億也吃不消的
            你可以分到多張表里 比如按月來分

            ===========================================================================

            只能分拆表

             

            posted on 2009-06-09 13:23 肥仔 閱讀(944) 評論(0)  編輯 收藏 引用 所屬分類: 數據庫

            99久久国产精品免费一区二区| 久久精品国产久精国产果冻传媒| 久久精品天天中文字幕人妻| 人妻少妇久久中文字幕| 99精品久久久久中文字幕| 97久久综合精品久久久综合| 久久久久久久亚洲精品| 久久精品中文字幕大胸| 久久久青草青青亚洲国产免观| 久久播电影网| 国产精品久久国产精品99盘 | 性欧美丰满熟妇XXXX性久久久| 久久国产亚洲精品无码| 欧美麻豆久久久久久中文| 久久精品夜夜夜夜夜久久| 久久久久亚洲av毛片大| 久久国产亚洲高清观看| 久久久精品国产Sm最大网站| 一本一本久久a久久综合精品蜜桃| 中文字幕成人精品久久不卡| 精品多毛少妇人妻AV免费久久| 国产高潮国产高潮久久久91 | 一本大道久久东京热无码AV| 久久人人爽人人爽人人片AV不| 久久97久久97精品免视看| 久久精品中文騷妇女内射| 久久久久18| 久久精品人妻一区二区三区| 九九久久自然熟的香蕉图片| 97久久国产综合精品女不卡 | 伊人色综合久久天天网| 久久电影网| 久久av免费天堂小草播放| 久久99国产精品一区二区| 国产成人精品免费久久久久| 亚洲国产精品高清久久久| 综合久久国产九一剧情麻豆| 国产免费久久精品99re丫y| 青草久久久国产线免观| 伊人色综合久久天天网| 久久天天躁狠狠躁夜夜躁2014|