mssql大數(shù)據(jù)解決方案

1、mssql大數(shù)據(jù)解決方案篇一：大數(shù)據(jù)處理方案篇二：數(shù)據(jù)庫解決方案對比分析數(shù)據(jù)庫解決方案對比分析對于互聯(lián)網(wǎng)應用，隨著訪問量的增加，當數(shù)據(jù)庫數(shù)據(jù)量 達到GB以上時將不可避免的面臨數(shù)據(jù)庫性能瓶頸的問題， 因此在數(shù)據(jù)存儲方案的選擇上對應用的性能、后期擴展等方 面將會有很大的影響，下面我將從幾個角度對目前主流的幾 款商用數(shù)據(jù)庫和Dbshards + MySql進行對比，為您的選擇 提供參考。開放性sql server：只能在windows上運行，沒有絲毫的開放 性，操作系統(tǒng)的系統(tǒng)的穩(wěn)定對數(shù)據(jù)庫是十分重要的。 windows9x系列產(chǎn)品是偏重于桌面應用，nt server只適合 中小型企業(yè)。而且windo

2、ws平臺的可靠性，安全性和伸縮性 是非常有限的。它不象unix那樣久經(jīng)考驗，尤其是在處理 大數(shù)據(jù)量的關鍵業(yè)務時。Oracle :能在所有主流平臺上運行。完全支持所有的工 業(yè)標準。采用完全開放策略。可以使客戶選擇最適合的解決方案。對開 發(fā)商全力支持。db2:能在所有主流平臺上運行。最適于海 量數(shù)據(jù)。db2在企業(yè)級的應用最為廣泛,在全球的500家最大 的企業(yè)中，幾乎85%以上用db2數(shù)據(jù)庫服務器,而國內(nèi)到97年 約占5%.Dbshards + MySql：能在所有主流平臺上運行。完全支 持所有的工業(yè)標準。采用完全開放策略?？梢允箍蛻暨x擇最 適合的解決方案。對開發(fā)商全力支持。并行性sql serve

3、r：并行實施和共存模型并不成熟。很難處理 日益增多的用戶數(shù)和數(shù)據(jù)卷。伸縮性有限。Oracle :平行服務器通過使一組結點共享同一簇中的工 作來擴展windownt的能力,提供高可用性和高伸縮性的簇的 解決方案。如果windowsnt不能滿足需要，用戶可以把數(shù)據(jù)庫移到unix中。db2： db2具有很好的并行性。db2把數(shù)據(jù)庫管理擴充到 了并行的、多節(jié)點的環(huán)境.數(shù)據(jù)庫分區(qū)是數(shù)據(jù)庫的一部分，包含自己的數(shù)據(jù)、索引、配 置文件、和事務日志。數(shù)據(jù)庫分區(qū)有時被稱為節(jié)點或數(shù)據(jù)庫 節(jié)點。Dbshards + MySql： Dbshards + MySql 具有優(yōu)秀的并行 性。DbShards將數(shù)據(jù)庫拆分為獨立

4、子節(jié)點，多節(jié)點通過Dbshards形成一個透明的數(shù) 據(jù)庫集群，任何數(shù)據(jù)操作都可在獨立子節(jié)點執(zhí)行也可多節(jié)點 并行，每個操作在更小的子節(jié)點完成，性能更優(yōu)。安全性sql server :沒有獲得任何安全證書。oracle :獲得 最高認證級別的iso標準認證。db2：獲得最高認證級別的 iso標準認證。Dbshards + MySql： GNU寬通用公共許可證 性能sql server：多用戶時性能不佳oracle：性能最高，保 持windowsnt下的tpc-d和tpc-c的世界記錄。db2:適用 于數(shù)據(jù)倉庫和在線事物處理性能較高。Dbshards + MySql： 脫離數(shù)據(jù)庫自身性能限制，通過D

5、bshards數(shù)據(jù)拆分技術提 高數(shù)據(jù)I/O性能?？蛻舳酥С旨皯媚Ｊ絪ql server： c/s結構，只支持windows客戶，可以用 ado,dao,oledb,odbc 連接.db2 :跨平臺，多層結構，支持 odbc,jdbc等客戶 Dbshards + MySql：多層次網(wǎng)絡計算，支持多種工業(yè)標準， 可以用odbc,jdbc,oci等網(wǎng)絡客戶連接操作簡便sql server :操作簡單，但只有圖形界面.Oracle :較 復雜，同時提供gui和命令行，在windowsnt和unix下操 作相同db2：操作簡單，同時提供gui和命令行，在windowsnt 和unix下操作相同Dbsh

6、ards + MySql：操作簡單，同時提 供gui和命令行，在windowsnt和unix下操作相同使用風險sql server：完全重寫的代碼，經(jīng)歷了長期的測試，不 斷延遲，許多功能需要時間來證明。并不十分兼容早期產(chǎn)品。 使用需要冒一定風險。Oracle :長時間的開發(fā)經(jīng)驗，完全向下兼容。得到廣泛 的應用。完全沒有風險。db2：在巨型企業(yè)得到廣泛的應用， 向下兼容性好。風險小。Dbshards + MySql：長時間的開 發(fā)經(jīng)驗，完全向下兼容。得到廣泛的應用。風險小。 可擴 展性sql server： sql server版本雜亂，并且微軟公司對其 旗下產(chǎn)品的升級、兼容策略存在很大隱患，因

7、此sql server 擴展性較差。Oracle： Oracle向下兼容，可擴展性強。Dbshards + MySql ： Dbshards 不是數(shù)據(jù)庫，Dbshards 是大數(shù)據(jù)庫拆分工具，當性能出現(xiàn)瓶頸時使用該工具對數(shù)據(jù) 庫進行拆分優(yōu)化從而提升性能，擴展成本低。成本sql server軟件成本：企業(yè)版在30-40萬左右；作為一款商用數(shù)據(jù) 庫軟件，存在很多不同的版本，造成使用者在選擇時的困惑， 并對后期升級造成困難（不同版本互不兼容）；實施成本: 只能在windows平臺下進行實施，當應用存在異構環(huán)境時， 其實施難度將大大提升，甚至會造成額外的實施成本（如為了能在異構環(huán)境中安裝sql ser

8、ver,需要購買虛擬機軟件來 安裝windows平臺），實施局限且成本高；維護成本：sql server作為一款商用軟件，其配套的操 作工具同樣也是商用軟件，因此，其產(chǎn)生的并不僅僅是數(shù)據(jù) 庫自身的成本，還包括了維護數(shù)據(jù)庫所需的工具軟件成本；擴展成本：對于互聯(lián)網(wǎng)應用，尤其是云平臺集成第三方 應用，融合多語言環(huán)境是必須面對的情況，而sql server 對于第三方和多語言的集成和兼容都需要大量商用軟件的 支持，因此在平臺擴展時同樣會造成成本的蔓延。Oracle軟件成本：企業(yè)版在30-40萬左右；實施成本：Oracle維護成本：Oracle是一款龐大而復雜的數(shù)據(jù)庫軟件，操 作復雜、難度高，其對實施、

9、維護人員的要求非常高，也就 造成了實施、維護的人力成本高昂；作為一款商用軟件， 其配套的操作工具同樣也是商用軟件，因此，其產(chǎn)生的并不 僅僅是數(shù)據(jù)庫自身的成本，還包括了維護數(shù)據(jù)庫所需的工具 軟件成本；并且維護人員成本高；擴展成本：Oracle按CPU個數(shù)進行收費；當性能出現(xiàn)瓶 頸需要版本升級或更換、增加硬件時就必須根據(jù)CPU數(shù)量購買Oracle授權（企 業(yè)版一顆CPU授權價格在30-40萬左右，最普通的一臺服務 器CPU數(shù)量在兩顆以上，也就是說每增加一臺服務器Oracle 成本將至少增加60萬以上），成本將成倍增長。db2軟件成本：企業(yè)版在60-70萬左右；實施成本：db2是IBM 一款常用于企

10、業(yè)應用的數(shù)據(jù)倉庫 軟件，操作復雜、難度高。其對實施、維護人員的要求非常高，也就造成了實施、 維護的人力成本高昂；維護成本：db2作為一款商用軟件， 其配套的操作工具同樣也是商用軟件，因此。其產(chǎn)生的并不僅僅是數(shù)據(jù)庫自身的成本，還包括了維護 數(shù)據(jù)庫所需的工具軟件成本；并且維護人員成本高；擴展成本：IBM在設計db2時專門為其配套一款商用工 具PB，因此其在擴展時需要特定專業(yè)人才方可實施，有一定局限（中國PB程序員 屬于小眾群體，比較少），擴展成本較高。Dbshards + MySql軟件成本：一套40萬；實施成本：dbShards更低；是一個數(shù)據(jù)庫拆分工具，具有數(shù)據(jù)庫無關性， 因此實施成本維護成本

11、：作為一款工具具有友好的操作、管理界面， 同時安久具有專業(yè)的售后服務團隊，維護成本更可控；擴展成本：作為一款工具軟件，其主要作用是拆分數(shù)據(jù) 庫，提高數(shù)據(jù)訪問性能，并不會隨著數(shù)據(jù)庫的增加而增加，這樣從整體上降低了擴 展的成本。兼容性sql server：面對復雜應用，需要多數(shù)據(jù)庫集成時，集 成能力弱。篇三：mysql性能優(yōu)化解決方案MySQL數(shù)據(jù)庫性能優(yōu)化Renhao 20XX/11/301.資源管理平臺數(shù)據(jù)庫操作系統(tǒng)Red Hat Enterprise Linux Server releaseELF 32-bit LSB executable, Intel 80386, version 1 ,

12、 for GNU/Linux , dynamically linked , for GNU/Linux , stripped32位Linux服務器，單獨作為MySQL服務器使用。MySQL系統(tǒng)使用的是，最新的較之老版本有了大幅改進。主要 體現(xiàn)在以下幾個方面：1）默認存儲引擎更改為InnoDBInnoDB作為成熟、高效的事務引擎，目前已經(jīng)廣泛使用， 但之前的版本默認引擎均為MylSAM,此次終于將默認數(shù)據(jù)庫 存儲引擎改為InnoDB，并且引進了 Innodb plugin。此次 更新對數(shù)據(jù)庫的好處是顯而易見的：InnoDB的數(shù)據(jù)恢復時間 從過去的一個甚至幾個小時，縮短到幾分鐘。InnoDB Pl

13、ugin 支持數(shù)據(jù)壓縮存儲，節(jié)約存儲，提高內(nèi)存命中率，并且支持 adaptive flush checkpoint,可以在某些場合避免數(shù)據(jù)庫 出現(xiàn)突發(fā)性能瓶頸。Multi Rollback Segments ： 原來 InnoDB 只有一個 Segment，同時只支持1023的并發(fā)?，F(xiàn)已擴充到128個 Segments,從而解決了高并發(fā)的限制。2）多核性能提升Metadata Locking Framework 替換 LOCK_open mutex ， 使得及過去版本在多核心處理器上的性能瓶頸得到解決。3）制功能加強過去的異步復制方式意味著極端情況下的數(shù)據(jù)風險，將 首次支持半同步在MySQL的

14、高可用方案中將產(chǎn)生更多更加可 靠的方案。4）增強表分區(qū)功能MySQL的分區(qū)更易于使用的增強功能，以及TRUNCATE PARTITION命令都可以為管理和維護數(shù)據(jù)庫節(jié)省大量的時 間，并且具有更加靈活高效的分區(qū)方式。CPU系統(tǒng)所用CPU是單個4核CPU。對于CPU密集的負載， MySQL通常從更快的CPU中獲益，而不是更多CPU。的架構 對多CPU的擴展性不好，并且MySQL不能在多個CPU上并行 地運行某個查詢，因此在對于單個CPU進行密集的查詢時， CPU速度限制了響應時間。為了實現(xiàn)低延遲，即快速響應時 間，需要快速的CPU，因為單個查詢只能使用一個CPU。值 得注意的是，在多核心處理器上的

15、性能有了很大的提升。另 外，MySQL在64位架構上工作得更好，比32位架構更能有 效地使用大量內(nèi)存。盡管本系統(tǒng)使用的是32位操作系統(tǒng)，CPU運行在32位 模式下，但它仍支持64位計算。(cat /proc/cpuinfo | grep flags | grep lm | wc -l)磁盤空間系統(tǒng)的磁盤空間目前沒有壓力。內(nèi)存內(nèi)存總大小為4G，只供操作系統(tǒng)和數(shù)據(jù)庫使用。數(shù)據(jù)庫的表和文件數(shù)據(jù)庫addb共有339張表：其中InnoDB表303張， MyISAM 表 34 張，MEMORY 表 2 張。InnoDB數(shù)據(jù)文件ibdata1大小為30138MB，一周后 ibdata1大小為30234MB，

16、MyISAM數(shù)據(jù)文件(包括表結構、 索引及數(shù)據(jù)）總大小約為1642MB，一周后約為1639MB。可 以看出，數(shù)據(jù)庫的數(shù)據(jù)量較穩(wěn)定，InnoDB數(shù)據(jù)文件增加了約 106MB，總大小一周內(nèi)沒有大的變化。MylSAM表中，值得注 意的是表terminalalarm_bak，該表總大小約為1623MB，占 整個MyISAM表總大小比重近99%。二進制日志單個文件大小為1GB，二進制日志文件總大 小接近20GB。數(shù)據(jù)分布情況服務器某時間點非精確值：觀察系統(tǒng)中數(shù)據(jù)量很大且未進行表分區(qū)的InnoDB表 adrotateresultdetail_fail 的數(shù)據(jù)量達到 4 千萬， createTime 列是

17、datatime 類型。且有索引，意味著存在以該列為查詢條件或關聯(lián)條件查 詢的需求，因此可以在該列上以自然月份進行表分區(qū)。terminalalarm的數(shù)據(jù)量也突破千萬，AlarmTime列是 datatime類型，且有索引，意味著存在以該列為查詢條件或關聯(lián)條件查詢的需 求，因此可以在該列上以自然月份進行表分區(qū)。在事件 ev_terminalalarm中會查詢該表，若進行表分區(qū)，也能一定 程度上提高事件的執(zhí)行效率。terminalalarminfo表僅自增列有索引，主要用于存儲 數(shù)據(jù)，可不用分區(qū)。Terminallogin表的loginTime列是 datatime類型，且有索引，意味著存在以該

18、列為查詢條件或關聯(lián)條件查詢的需求，因此可以在該 列上以自然月份進行表分區(qū)。adplayinfo_bak表存在多個以INT類型為索引的列，根 據(jù)實際業(yè)務情況選擇查詢頻率高且能以范圍值來分區(qū)的整型列對該表進行 分區(qū)。adrotateresultdetail 的 createTime 列是 datatime 類 型，且有索引，意味著存在以該列為查詢條件或關聯(lián)條件查詢的需求，因此可以在 該列上以自然月份進行表分區(qū)。upfile_bak表僅自增列有索引，若存在查詢或者統(tǒng)計業(yè) 務則可以createTime列進行分區(qū)，若該表沒有查詢方面業(yè)務可不必進行分 區(qū)。除去配置參數(shù)等屬性表，對于數(shù)據(jù)量大且不斷遞增的業(yè) 務數(shù)據(jù)表，最直接的辦法可以按照時間字段進行分區(qū)，或是 根據(jù)查詢業(yè)務來選擇合適的列進行表分區(qū)和創(chuàng)建索引，這樣 能夠有效提高存儲和查詢效率。服務器配置參數(shù)記錄查詢：普通日志log、慢速日志log_slow_queries MySQL有兩種查詢?nèi)罩荆浩胀ㄈ罩竞吐偃罩?，它們都會記錄查詢。普通日志記錄了服務器接收到的每一個查詢， 也包含了沒有被執(zhí)行的查詢，比如因為錯誤而未被執(zhí)行的查 詢，還有一些非查詢事件，比如連接和斷開連接，普通日志 不包含執(zhí)行時間或其他只有在查詢結束之后才能得到的信 息。相反，慢速日志只包含