• <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 肥仔 閱讀(951) 評論(0)  編輯 收藏 引用 所屬分類: 數據庫

            国产ww久久久久久久久久| 少妇熟女久久综合网色欲| 午夜久久久久久禁播电影| 亚洲精品乱码久久久久久不卡| 99久久婷婷国产一区二区| 久久精品www| 国产伊人久久| 日本高清无卡码一区二区久久 | 无码人妻少妇久久中文字幕蜜桃| 亚洲欧美成人久久综合中文网| 亚洲国产小视频精品久久久三级 | 精品久久无码中文字幕| 2021久久精品国产99国产精品| 成人资源影音先锋久久资源网| 狠狠狠色丁香婷婷综合久久五月| 精品精品国产自在久久高清| 蜜桃麻豆www久久| 国产精品熟女福利久久AV| 开心久久婷婷综合中文字幕| 亚洲狠狠婷婷综合久久久久 | 一本久久a久久精品亚洲| 国产V综合V亚洲欧美久久| 99热精品久久只有精品| 久久久久久久精品成人热色戒| 久久久亚洲欧洲日产国码二区| 日本道色综合久久影院| 模特私拍国产精品久久| 久久天天躁狠狠躁夜夜96流白浆| 久久综合综合久久97色| 精品国产乱码久久久久软件| 国产精品一区二区久久精品| 亚洲国产天堂久久综合| 国产精品久久精品| 日韩AV毛片精品久久久| 久久精品免费一区二区三区| 久久成人国产精品免费软件| 91秦先生久久久久久久| 蜜臀久久99精品久久久久久小说 | 久久亚洲熟女cc98cm| 99久久国产综合精品五月天喷水| 中文字幕久久久久人妻|