針對nosql相關(guān)的論文,nosql技術(shù)

大數(shù)據(jù)時代數(shù)據(jù)管理方式研究

大數(shù)據(jù)時代數(shù)據(jù)管理方式研究

成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比城東網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式城東網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋城東地區(qū)。費用合理售后完善，10余年實體公司更值得信賴。

1數(shù)據(jù)管理技術(shù)的回顧

數(shù)據(jù)管理技術(shù)主要經(jīng)歷了人工管理階段、文件系統(tǒng)階段和數(shù)據(jù)庫系統(tǒng)階段。隨著數(shù)據(jù)應用領(lǐng)域的不斷擴展，數(shù)據(jù)管理所處的環(huán)境也越來越復雜，目前廣泛流行的數(shù)據(jù)庫技術(shù)開始暴露出許多弱點，面臨著許多新的挑戰(zhàn)。

1.1 人工管理階段

20 世紀 50 年代中期，計算機主要用于科學計算。當時沒有磁盤等直接存取設備，只有紙帶、卡片、磁帶等外存，也沒有操作系統(tǒng)和管理數(shù)據(jù)的專門軟件。該階段管理的數(shù)據(jù)不保存、由應用程序管理數(shù)據(jù)、數(shù)據(jù)不共享和數(shù)據(jù)不具有獨立性等特點。

1.2 文件系統(tǒng)階段

20 世紀 50 年代后期到 60 年代中期，隨著計算機硬件和軟件的發(fā)展，磁盤、磁鼓等直接存取設備開始普及，這一時期的數(shù)據(jù)處理系統(tǒng)是把計算機中的數(shù)據(jù)組織成相互獨立的被命名的數(shù)據(jù)文件，并可按文件的名字來進行訪問，對文件中的記錄進行存取的數(shù)據(jù)管理技術(shù)。數(shù)據(jù)可以長期保存在計算機外存上，可以對數(shù)據(jù)進行反復處理，并支持文件的查詢、修改、插入和刪除等操作。其數(shù)據(jù)面向特定的應用程序，因此，數(shù)據(jù)共享性、獨立性差，且冗余度大，管理和維護的代價也很大。

1.3數(shù)據(jù)庫階段

20 世紀 60 年代后期以來，計算機性能得到進一步提高，更重要的是出現(xiàn)了大容量磁盤，存儲容量大大增加且價格下降。在此基礎上，才有可能克服文件系統(tǒng)管理數(shù)據(jù)時的不足，而滿足和解決實際應用中多個用戶、多個應用程序共享數(shù)據(jù)的要求，從而使數(shù)據(jù)能為盡可能多的應用程序服務，這就出現(xiàn)了數(shù)據(jù)庫這樣的數(shù)據(jù)管理技術(shù)。數(shù)據(jù)庫的特點是數(shù)據(jù)不再只針對某一個特定的應用，而是面向全組織，具有整體的結(jié)構(gòu)性，共享性高，冗余度減小，具有一定的程序與數(shù)據(jù)之間的獨立性，并且對數(shù)據(jù)進行統(tǒng)一的控制。

2大數(shù)據(jù)時代的數(shù)據(jù)管理技術(shù)

大數(shù)據(jù)（big data），或稱巨量資料，指的是所涉及的資料量規(guī)模巨大到無法透過目前主流軟件工具，在合理時間內(nèi)達到擷取、管理、處理、并整理成為幫助企業(yè)經(jīng)營決策更積極目的的資訊。大數(shù)據(jù)有 3 個 V,一是大量化（Volume），數(shù)據(jù)量是持續(xù)快速增加的，從 TB級別，躍升到 PB 級別；二是多樣化（Variety），數(shù)據(jù)類型多樣化，結(jié)構(gòu)化數(shù)據(jù)已被視為小菜一碟，圖片、音頻、視頻等非結(jié)構(gòu)化數(shù)據(jù)正以傳統(tǒng)結(jié)構(gòu)化數(shù)據(jù)增長的兩倍速快速創(chuàng)建；三是快速化 （Velocity），數(shù)據(jù)生成速度快，也就需要快速的處理能力，因此，產(chǎn)生了“1 秒定律”,就是說一般要在秒級時間范圍內(nèi)給出分析結(jié)果，時間太長就失去價值了，這個速度要求是大數(shù)據(jù)處理技術(shù)和傳統(tǒng)的數(shù)據(jù)挖掘技術(shù)最大的區(qū)別。

2.1 關(guān)系型數(shù)據(jù)庫（RDBMS）

20 世紀 70 年代初，IBM 工程師 Codd 發(fā)表了著名的論文“A Relational Model of Data for Large Shared DataBanks”,標志著關(guān)系數(shù)據(jù)庫時代來臨。關(guān)系數(shù)據(jù)庫的理論基礎是關(guān)系模型，是借助于集合代數(shù)等數(shù)學概念和方法來處理數(shù)據(jù)庫中的數(shù)據(jù)，現(xiàn)實世界中的實體以及實體之間的聯(lián)系非常容易用關(guān)系模型來表示。容易理解的模型、容易掌握的查詢語言、高效的優(yōu)化器、成熟的技術(shù)和產(chǎn)品，使得關(guān)系數(shù)據(jù)庫占據(jù)了數(shù)據(jù)庫市場的絕對的統(tǒng)治地位。隨著互聯(lián)網(wǎng) web2.0 網(wǎng)站的興起，半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的大量涌現(xiàn)，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應付 web2.0 網(wǎng)站特別是超大規(guī)模和高并發(fā)的 SNS（全稱 Social Networking Services,即社會性網(wǎng)絡服務） 類型的 web2.0 純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題。

2.2 noSQL數(shù)據(jù)庫

順應時代發(fā)展的需要產(chǎn)生了 noSQL數(shù)據(jù)庫技術(shù)，其主要特點是采用與關(guān)系模型不同的數(shù)據(jù)模型，當前熱門的 noSQL數(shù)據(jù)庫系統(tǒng)可以說是蓬勃發(fā)展、異軍突起，很多公司都熱情追捧之，如：由 Google 公司提出的 Big Table 和 MapReduce 以及 IBM 公司提出的 Lotus Notes 等。不管是那個公司的 noSQL數(shù)據(jù)庫都圍繞著大數(shù)據(jù)的 3 個 V,目的就是解決大數(shù)據(jù)的 3個 V 問題。因此，在設計 noSQL 時往往考慮以下幾個原則，首先，采用橫向擴展的方式，通過并行處理技術(shù)對數(shù)據(jù)進行劃分并進行并行處理，以獲得高速的讀寫速度；其次，解決數(shù)據(jù)類型從以結(jié)構(gòu)化數(shù)據(jù)為主轉(zhuǎn)向結(jié)構(gòu)化、半結(jié)構(gòu)化、非結(jié)構(gòu)化三者的融合的問題；再次，放松對數(shù)據(jù)的 ACID 一致性約束，允許數(shù)據(jù)暫時出現(xiàn)不一致的情況，接受最終一致性；最后，對各個分區(qū)數(shù)據(jù)進行備份（一般是 3 份），應對節(jié)點失敗的狀況等。

對數(shù)據(jù)的應用可以分為分析型應用和操作型應用，分析型應用主要是指對大量數(shù)據(jù)進行分類、聚集、匯總，最后獲得數(shù)據(jù)量相對小的分析結(jié)果；操作型應用主要是指對數(shù)據(jù)進行增加、刪除、修改和查詢以及簡單的匯總操作，涉及的數(shù)據(jù)量一般比較少，事務執(zhí)行時間一般比較短。目前數(shù)據(jù)庫可分為關(guān)系數(shù)據(jù)庫和 noSQL數(shù)據(jù)庫，根據(jù)數(shù)據(jù)應用的要求，再結(jié)合目前數(shù)據(jù)庫的種類，所以目前數(shù)據(jù)庫管理方式主要有以下 4 類。

（1）面向操作型的關(guān)系數(shù)據(jù)庫技術(shù)。

首先，傳統(tǒng)數(shù)據(jù)庫廠商提供的基于行存儲的關(guān)系數(shù)據(jù)庫系統(tǒng)，如 DB2、Oracle、SQL Server 等，以其高度的一致性、精確性、系統(tǒng)可恢復性，在事務處理方面仍然是核心引擎。其次，面向?qū)崟r計算的內(nèi)存數(shù)據(jù)庫系統(tǒng)，如 Hana、Timesten、Altibase 等通過把對數(shù)據(jù)并發(fā)控制、查詢和恢復等操作控制在內(nèi)存內(nèi)部進行，所以獲得了非常高的性能，在很多特定領(lǐng)域如電信、證券、網(wǎng)管等得到普遍應用。另外，以 VoltDB、Clustrix 和NuoDB 為代表的 new SQL 宣稱能夠在保持 ACDI 特性的同時提高了事務處理性能 50 倍 ~60 倍。

（2）面向分析型的關(guān)系數(shù)據(jù)庫技術(shù)。

首先，TeraData 是數(shù)據(jù)倉庫領(lǐng)域的領(lǐng)頭羊，Teradata 在整體上是按 Shared Nothing 架構(gòu)體系進行組織的，定位就是大型數(shù)據(jù)倉庫系統(tǒng)，支持較高的擴展性。其次，面向分析型應用，列存儲數(shù)據(jù)庫的研究形成了另一個重要的潮流。列存儲數(shù)據(jù)庫以其高效的壓縮、更高的 I/O 效率等特點，在分析型應用領(lǐng)域獲得了比行存儲數(shù)據(jù)庫高得多的性能。如：MonetDB 和 Vertica是一個典型的基于列存儲技術(shù)的數(shù)據(jù)庫系統(tǒng)。

（3）面向操作型的 noSQL 技術(shù)。

有些操作型應用不受 ACID 高度一致性約束，但對大數(shù)據(jù)處理需要處理的數(shù)據(jù)量非常大，對速度性能要求也非常高，這樣就必須依靠大規(guī)模集群的并行處理能力來實現(xiàn)數(shù)據(jù)處理，弱一致性或最終一致性就可以了。這時，操作型 noSQL數(shù)據(jù)庫的優(yōu)點就可以發(fā)揮的淋漓盡致了。如，Hbase 一天就可以有超過 200 億個到達硬盤的讀寫操作，實現(xiàn)對大數(shù)據(jù)的處理。另外，noSQL數(shù)據(jù)庫是一個數(shù)據(jù)模型靈活、支持多樣數(shù)據(jù)類型，如對圖數(shù)據(jù)建模、存儲和分析，其性能、擴展性是關(guān)系數(shù)據(jù)庫無法比擬的。

（4）面向分析型的 noSQL 技術(shù)。

面向分析型應用的 noSQL 技術(shù)主要依賴于Hadoop 分布式計算平臺，Hadoop 是一個分布式計算平臺，以 HDFS 和 Map Reduce 為用戶提供系統(tǒng)底層細節(jié)透明的分布式基礎架構(gòu)?！禜adoop 經(jīng)典實踐染技巧》傳統(tǒng)的數(shù)據(jù)庫廠商 Microsoft,Oracle,SAS,IBM 等紛紛轉(zhuǎn)向 Hadoop 的研究，如微軟公司關(guān)閉 Dryad 系統(tǒng)，全力投入 Map Reduce 的研發(fā)，Oracle 在 2011 年下半年發(fā)布 Big Plan 戰(zhàn)略計劃，全面進軍大數(shù)據(jù)處理領(lǐng)域，IBM 則早已捷足先登“,沃森（Watson）”計算機就是基于 Hadoop 技術(shù)開發(fā)的產(chǎn)物，同時 IBM 發(fā)布了 BigInsights 計劃，基于 Hadoop,Netezza 和 SPSS（統(tǒng)計分析、數(shù)據(jù)挖掘軟件）等技術(shù)和產(chǎn)品構(gòu)建大數(shù)據(jù)分析處理的技術(shù)框架。同時也涌現(xiàn)出一批新公司來研究Hadoop 技術(shù)，如 Cloudera、MapRKarmashpere 等。

3數(shù)據(jù)管理方式的展望

通過以上分析，可以看出關(guān)系數(shù)據(jù)庫的 ACID 強調(diào)數(shù)據(jù)一致性通常指關(guān)聯(lián)數(shù)據(jù)之間的邏輯關(guān)系是否正確和完整，而對于很多互聯(lián)網(wǎng)應用來說，對這一致性和隔離性的要求可以降低，而可用性的要求則更為明顯，此時就可以采用 noSQL 的兩種弱一致性的理論 BASE 和 CAP.關(guān)系數(shù)據(jù)庫和 noSQL數(shù)據(jù)庫并不是想到對立的矛盾體，而是可以相互補充的，根據(jù)不同需求使用不同的技術(shù)，甚至二者可以共同存在，互不影響。最近幾年，以 Spanner 為代表新型數(shù)據(jù)庫的出現(xiàn)，給數(shù)據(jù)庫領(lǐng)域注入新鮮血液，這就是融合了一致性和可用性的 newSQL,這種新型思維方式或許會是未來大數(shù)據(jù)處理方式的發(fā)展方向。

4 結(jié)束語

隨著云計算、物聯(lián)網(wǎng)等的發(fā)展，數(shù)據(jù)呈現(xiàn)爆炸式的增長，人們正被數(shù)據(jù)洪流所包圍，大數(shù)據(jù)的時代已經(jīng)到來。正確利用大數(shù)據(jù)給人們的生活帶來了極大的便利，但與此同時也給傳統(tǒng)的數(shù)據(jù)管理方式帶來了極大的挑戰(zhàn)。

為什么要使用NoSQL？NOSQL的優(yōu)勢

這次的NoSQL專欄系列將先整體介紹NoSQL，然后介紹如何把NoSQL運用到自己的項目中合適的場景中，還會適當?shù)胤治鲆恍┏晒Π咐?，希望有成功使用NoSQL經(jīng)驗的朋友給我提供一些線索和信息。

NoSQL概念隨著web2.0的快速發(fā)展，非關(guān)系型、分布式數(shù)據(jù)存儲得到了快速的發(fā)展，它們不保證關(guān)系數(shù)據(jù)的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個輕量級的關(guān)系數(shù)據(jù)庫的名字。）

NoSQL被我們用得最多的當數(shù)key-value存儲，當然還有其他的文檔型的、列存儲、圖型數(shù)據(jù)庫、xml數(shù)據(jù)庫等。在NoSQL概念提出之前，這些數(shù)據(jù)庫就被用于各種系統(tǒng)當中，但是卻很少用于web互聯(lián)網(wǎng)應用。比如cdb、qdbm、bdb數(shù)據(jù)庫。

傳統(tǒng)關(guān)系數(shù)據(jù)庫的瓶頸

傳統(tǒng)的關(guān)系數(shù)據(jù)庫具有不錯的性能，高穩(wěn)定型，久經(jīng)歷史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯(lián)網(wǎng)領(lǐng)域，MySQL成為了絕對靠前的王者，毫不夸張的說，MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻。

在90年代，一個網(wǎng)站的訪問量一般都不大，用單個數(shù)據(jù)庫完全可以輕松應付。在那個時候，更多的都是靜態(tài)網(wǎng)頁，動態(tài)交互類型的網(wǎng)站不多。

到了最近10年，網(wǎng)站開始快速發(fā)展?；鸨恼搲⒉┛?、sns、微博逐漸引領(lǐng)web領(lǐng)域的潮流。在初期，論壇的流量其實也不大，如果你接觸網(wǎng)絡比較早，你可能還記得那個時候還有文本型存儲的論壇程序，可以想象一般的論壇的流量有多大。

Memcached+MySQL

后來，隨著訪問量的上升，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫的壓力，優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力，但是當訪問量繼續(xù)增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術(shù)產(chǎn)品。

Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發(fā)展了根據(jù)hash算法來進行多臺Memcached緩存服務的擴展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。當時，如果你去面試，你說你有Memcached經(jīng)驗，肯定會加分的。

Mysql主從讀寫分離

由于數(shù)據(jù)庫的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫的讀取壓力。讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負，大部分網(wǎng)站開始使用主從復制技術(shù)來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網(wǎng)站標配了。

分表分庫隨著web2.0的繼續(xù)高速發(fā)展，在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會出現(xiàn)嚴重的鎖問題，大量的高并發(fā)MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長的擴展問題。這個時候，分表分庫成了一個熱門技術(shù)，是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題。也就在這個時候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術(shù)實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯(lián)網(wǎng)幾乎沒有成功案例，性能也不能滿足互聯(lián)網(wǎng)的要求，只是在高可靠性上提供了非常大的保證。

MySQL的擴展性瓶頸

在互聯(lián)網(wǎng)，大部分的MySQL都應該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那么很可能你的MySQL設計得有性能問題，需要優(yōu)化了。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應用開發(fā)越來越復雜，也越來越具有技術(shù)挑戰(zhàn)性。分表分庫的規(guī)則把握都是需要經(jīng)驗的。雖然有像淘寶這樣技術(shù)實力強大的公司開發(fā)了透明的中間件層來屏蔽開發(fā)者的復雜性，但是避免不了整個架構(gòu)的復雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更，可能又需要一種新的分庫方式。

MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段，導致數(shù)據(jù)庫表非常的大，在做數(shù)據(jù)庫恢復的時候就導致非常的慢，不容易快速恢復數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變得非常的小。

關(guān)系數(shù)據(jù)庫很強大，但是它并不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術(shù)來實現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當前使用MySQL的開發(fā)人員面臨的問題。

NOSQL的優(yōu)勢易擴展NoSQL數(shù)據(jù)庫種類繁多，但是一個共同的特點都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。數(shù)據(jù)之間無關(guān)系，這樣就非常容易擴展。也無形之間，在架構(gòu)的層面上帶來了可擴展的能力。

大數(shù)據(jù)量，高性能

NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性，數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。

靈活的數(shù)據(jù)模型

NoSQL無需事先為要存儲的數(shù)據(jù)建立字段，隨時可以存儲自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡直就是一個噩夢。這點在大數(shù)據(jù)量的web2.0時代尤其明顯。

高可用NoSQL在不太影響性能的情況，就可以方便的實現(xiàn)高可用的架構(gòu)。比如Cassandra，HBase模型，通過復制模型也能實現(xiàn)高可用。

總結(jié)NoSQL數(shù)據(jù)庫的出現(xiàn)，彌補了關(guān)系數(shù)據(jù)（比如MySQL）在某些方面的不足，在某些方面能極大的節(jié)省開發(fā)成本和維護成本。

MySQL和NoSQL都有各自的特點和使用的應用場景，兩者的緊密結(jié)合將會給web2.0的數(shù)據(jù)庫發(fā)展帶來新的思路。

分布式系統(tǒng)領(lǐng)域有哪些經(jīng)典論文

分布式領(lǐng)域論文譯序

sqlnosql年代記

SMAQ：海量數(shù)據(jù)的存儲計算和查詢

一．google論文系列

1. google系列論文譯序

2. The anatomy of a large-scale hypertextual Web search engine (譯 zz)

3. web search for a planet :the google cluster architecture(譯)

4. GFS：google文件系統(tǒng) (譯)

5. MapReduce: Simplied Data Processing on Large Clusters (譯)

6. Bigtable: A Distributed Storage System for Structured Data (譯)

7. Chubby: The Chubby lock service for loosely-coupled distributed systems (譯)

8. Sawzall:Interpreting the Data--Parallel Analysis with Sawzall (譯 zz)

9. Pregel: A System for Large-Scale Graph Processing (譯)

10. Dremel: Interactive Analysis of WebScale Datasets(譯zz)

11. Percolator: Large-scale Incremental Processing Using Distributed Transactions and Notifications(譯zz)

12. MegaStore: Providing Scalable, Highly Available Storage for Interactive Services(譯zz)

13. Case Study GFS: Evolution on Fast-forward (譯)

14. Google File System II: Dawn of the Multiplying Master Nodes

15. Tenzing - A SQL Implementation on the MapReduce Framework (譯)

16. F1-The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business

17. Elmo: Building a Globally Distributed, Highly Available Database

18. PowerDrill：Processing a Trillion Cells per Mouse Click

19. Google-Wide Profiling:A Continuous Profiling Infrastructure for Data Centers

20. Spanner: Google’s Globally-Distributed Database(譯zz)

21. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure(筆記)

22. Omega: flexible, scalable schedulers for large compute clusters

23. CPI2: CPU performance isolation for shared compute clusters

24. Photon: Fault-tolerant and Scalable Joining of Continuous Data Streams(譯)

25. F1: A Distributed SQL Database That Scales

26. MillWheel: Fault-Tolerant Stream Processing at Internet Scale(譯)

27. B4: Experience with a Globally-Deployed Software Defined WAN

28. The Datacenter as a Computer

29. Google brain-Building High-level Features Using Large Scale Unsupervised Learning

30. Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing(譯zz)

31. Large-scale cluster management at Google with Borg

google系列論文翻譯集(合集)

二．分布式理論系列

00. Appraising Two Decades of Distributed Computing Theory Research

0. 分布式理論系列譯序

1. A brief history of Consensus_ 2PC and Transaction Commit (譯)

2. 拜占庭將軍問題 (譯) --Leslie Lamport

3. Impossibility of distributed consensus with one faulty process (譯)

4. Leases：租約機制 (譯)

5. Time Clocks and the Ordering of Events in a Distributed System(譯) --Leslie Lamport

6. 關(guān)于Paxos的歷史

7. The Part Time Parliament (譯 zz) --Leslie Lamport

8. How to Build a Highly Available System Using Consensus(譯)

9. Paxos Made Simple (譯) --Leslie Lamport

10. Paxos Made Live - An Engineering Perspective(譯)

11. 2 Phase Commit(譯)

12. Consensus on Transaction Commit(譯) --Jim Gray Leslie Lamport

13. Why Do Computers Stop and What Can Be Done About It?(譯) --Jim Gray

14. On Designing and Deploying Internet-Scale Services(譯) --James Hamilton

15. Single-Message Communication(譯)

16. Implementing fault-tolerant services using the state machine approach

17. Problems, Unsolved Problems and Problems in Concurrency

18. Hints for Computer System Design

19. Self-stabilizing systems in spite of distributed control

20. Wait-Free Synchronization

21. White Paper Introduction to IEEE 1588 Transparent Clocks

22. Unreliable Failure Detectors for Reliable Distributed Systems

23. Life beyond Distributed Transactions:an Apostate’s Opinion(譯zz)

24. Distributed Snapshots: Determining Global States of a Distributed System --Leslie Lamport

25. Virtual Time and Global States of Distributed Systems

26. Timestamps in Message-Passing Systems That Preserve the Partial Ordering

27. Fundamentals of Distributed Computing:A Practical Tour of Vector Clock Systems

28. Knowledge and Common Knowledge in a Distributed Environment

29. Understanding Failures in Petascale Computers

30. Why Do Internet services fail, and What Can Be Done About It?

31. End-To-End Arguments in System Design

32. Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World

33. The Design Philosophy of the DARPA Internet Protocols(譯zz)

34. Uniform consensus is harder than consensus

35. Paxos made code - Implementing a high throughput Atomic Broadcast

36. RAFT:In Search of an Understandable Consensus Algorithm

分布式理論系列論文翻譯集(合集)

三．數(shù)據(jù)庫理論系列

0. A Relational Model of Data for Large Shared Data Banks --E.F.Codd 1970

1. SEQUEL：A Structured English Query Language 1974

2. Implentation of a Structured English Query Language 1975

3. A System R: Relational Approach to Database Management 1976

4. Granularity of Locks and Degrees of Consistency in a Shared DataBase --Jim Gray 1976

5. Access Path Selection in a RDBMS 1979

6. The Transaction Concept:Virtues and Limitations --Jim Gray

7. 2pc-2階段提交：Notes on Data Base Operating Systems --Jim Gray

8. 3pc-3階段提交：NONBLOCKING COMMIT PROTOCOLS

9. MVCC：Multiversion Concurrency Control-Theory and Algorithms --1983

10. ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging-1992

11. A Comparison of the Byzantine Agreement Problem and the Transaction Commit Problem --Jim Gray

12. A Formal Model of Crash Recovery in a Distributed System - Skeen, D. Stonebraker

13. What Goes Around Comes Around - Michael Stonebraker, Joseph M. Hellerstein

14. Anatomy of a Database System -Joseph M. Hellerstein, Michael Stonebraker

15. Architecture of a Database System(譯zz) -Joseph M. Hellerstein, Michael Stonebraker, James Hamilton

四．大規(guī)模存儲與計算(NoSql理論系列)

0. Towards Robust Distributed Systems：Brewer's 2000 PODC key notes

1. CAP理論

2. Harvest, Yield, and Scalable Tolerant Systems

3. 關(guān)于CAP

4. BASE模型：BASE an Acid Alternative

5. 最終一致性

6. 可擴展性設計模式

7. 可伸縮性原則

8. NoSql生態(tài)系統(tǒng)

9. scalability-availability-stability-patterns

10. The 5 Minute Rule and the 5 Byte Rule (譯)

11. The Five-Minute Rule Ten Years Later and Other Computer Storage Rules of Thumb

12. The Five-Minute Rule 20 Years Later(and How Flash Memory Changes the Rules)

13. 關(guān)于MapReduce的爭論

14. MapReduce：一個巨大的倒退

15. MapReduce：一個巨大的倒退(II)

16. MapReduce和并行數(shù)據(jù)庫，朋友還是敵人？(zz)

17. MapReduce and Parallel DBMSs-Friends or Foes (譯)

18. MapReduce:A Flexible Data Processing Tool (譯)

19. A Comparision of Approaches to Large-Scale Data Analysis (譯)

20. MapReduce Hold不??？(zz)

21. Beyond MapReduce：圖計算概覽

22. Map-Reduce-Merge: simplified relational data processing on large clusters

23. MapReduce Online

24. Graph Twiddling in a MapReduce World

25. Spark: Cluster Computing with Working Sets

26. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing

27. Big Data Lambda Architecture

28. The 8 Requirements of Real-Time Stream Processing

29. The Log: What every software engineer should know about real-time data's unifying abstraction

30. Lessons from Giant-Scale Services

五．基本算法和數(shù)據(jù)結(jié)構(gòu)

1. 大數(shù)據(jù)量，海量數(shù)據(jù)處理方法總結(jié)

2. 大數(shù)據(jù)量，海量數(shù)據(jù)處理方法總結(jié)(續(xù))

3. Consistent Hashing And Random Trees

4. Merkle Trees

5. Scalable Bloom Filters

6. Introduction to Distributed Hash Tables

7. B-Trees and Relational Database Systems

8. The log-structured merge-tree (譯)

9. lock free data structure

10. Data Structures for Spatial Database

11. Gossip

12. lock free algorithm

13. The Graph Traversal Pattern

六．基本系統(tǒng)和實踐經(jīng)驗

1. MySQL索引背后的數(shù)據(jù)結(jié)構(gòu)及算法原理

2. Dynamo: Amazon’s Highly Available Key-value Store (譯zz)

3. Cassandra - A Decentralized Structured Storage System (譯zz)

4. PNUTS: Yahoo!’s Hosted Data Serving Platform (譯zz)

5. Yahoo!的分布式數(shù)據(jù)平臺PNUTS簡介及感悟(zz)

6. LevelDB：一個快速輕量級的key-value存儲庫(譯)

7. LevelDB理論基礎

8. LevelDB：實現(xiàn)(譯)

9. LevelDB SSTable格式詳解

10. LevelDB Bloom Filter實現(xiàn)

11. Sawzall原理與應用

12. Storm原理與實現(xiàn)

13. Designs, Lessons and Advice from Building Large Distributed Systems --Jeff Dean

14. Challenges in Building Large-Scale Information Retrieval Systems --Jeff Dean

15. Experiences with MapReduce, an Abstraction for Large-Scale Computation --Jeff Dean

16. Taming Service Variability,Building Worldwide Systems,and Scaling Deep Learning --Jeff Dean

17. Large-Scale Data and Computation:Challenges and Opportunitis --Jeff Dean

18. Achieving Rapid Response Times in Large Online Services --Jeff Dean

19. The Tail at Scale(譯) --Jeff Dean Luiz André Barroso

20. How To Design A Good API and Why it Matters

21. Event-Based Systems:Architect's Dream or Developer's Nightmare?

22. Autopilot: Automatic Data Center Management

七．其他輔助系統(tǒng)

1. The ganglia distributed monitoring system:design, implementation, and experience

2. Chukwa: A large-scale monitoring system

3. Scribe : a way to aggregate data and why not, to directly fill the HDFS?

4. Benchmarking Cloud Serving Systems with YCSB

5. Dynamo Dremel ZooKeeper Hive 簡述

八. Hadoop相關(guān)

0. Hadoop Reading List

1. The Hadoop Distributed File System(譯)

2. HDFS scalability:the limits to growth(譯)

3. Name-node memory size estimates and optimization proposal.

4. HBase Architecture(譯)

5. HFile：A Block-Indexed File Format to Store Sorted Key-Value Pairs

6. HFile V2

7. Hive - A Warehousing Solution Over a Map-Reduce Framework

8. Hive – A Petabyte Scale Data Warehouse Using Hadoop

轉(zhuǎn)載請注明作者：phylips@bmy 2011-4-30

求SQL數(shù)據(jù)庫論文

ORACLE中SQL查詢優(yōu)化研究

摘 要 數(shù)據(jù)庫性能問題一直是決策者及技術(shù)人員共同關(guān)注的焦點，影響數(shù)據(jù)庫性能的一個重要因素就是SQL查詢語句的低效率。論文首先分析了導致SQL查詢語句性能低下的四個常見原因以及SQL調(diào)優(yōu)的一般步驟，然后分別針對如何降低I/O操作、在查詢語句中如何避免對查詢結(jié)果的高成本操作以及在多表連接時如何提高查詢效率進行了分析。

關(guān)鍵詞 ORACLE；SQL；優(yōu)化；連接

1 引言

隨著網(wǎng)絡應用不斷發(fā)展，系統(tǒng)性能已越來越引起決策者的重視。影響系統(tǒng)性能的因素很多，低效的SQL語句就是其中一個不可忽視的重要原因。論文首先分析導致SQL性能低下的常見原因，然后分析SQL調(diào)優(yōu)應遵循的一般步驟，最后從如何降低I/O、避免對查詢結(jié)果的高成本操作和多表連接中如何提高SQL性能進行了研究。鑒于目前ORACLE在數(shù)據(jù)庫市場上的主導地位，論文將只針對ORACLE進行討論。

2 影響SQL性能的原因

影響SQL性能的因素很多，如初始化參數(shù)設置不合理、導入了不準確的系統(tǒng)及模式統(tǒng)計數(shù)據(jù)從而影響優(yōu)化程序(CBO)的正確判斷等，這些往往和DBA密切相關(guān)。純粹從SQL語句出發(fā)，筆者認為影響SQL性能不外乎以下四個重要原因：

(1)在大記錄集上進行高成本操作，如使用了引起排序的謂詞等。

(2)過多的I/O操作(含物理I/O與邏輯I/O)，最典型的就是未建立恰當?shù)乃饕瑢е聦Σ樵儽磉M行全表掃描。

(3)處理了太多的無用記錄，如在多表連接時過濾條件位置不當導致中間結(jié)果集包含了太多的無用記錄。

(4)未充分利用數(shù)據(jù)庫提供的功能，如查詢的并行化處理等。

第(4)個原因處理起來相對簡單。論文將針對前三個原因論述如何提高SQL查詢語句的性能。

3 SQL優(yōu)化的一般步驟

SQL優(yōu)化一般需經(jīng)過發(fā)現(xiàn)問題、分析問題、提出解決措施、應用措施、測試性能幾個步驟，如圖1所示?！鞍l(fā)現(xiàn)問題就是解決問題的一半”，因此在SQL調(diào)優(yōu)過程中，定位問題SQL是非常重要的一步，一般可借助于ORACLE自帶的性能優(yōu)化工具如STATSPACK、TKPROF、AUTOTRACE等輔助用戶進行，同時還應該重視動態(tài)性能視圖如V$SQL、V$MYSTAT、V$SYSSTAT等的研究。

圖1 SQL優(yōu)化的一般步驟

4 SQL語句的優(yōu)化

4.1 優(yōu)化排序操作

排序的成本十分高昂，當在查詢語句中使用了引起結(jié)果集排序的謂詞時，SQL性能必然受到影響。

4.1.1 排序過程分析

當待排序數(shù)據(jù)集不是太大時，服務器在內(nèi)存(排序區(qū))完成排序操作，如果排序需要更多的內(nèi)存空間，服務器將進行如下處理：

(1) 將數(shù)據(jù)分成多個小的集合，對每一集合進行排序。

(2) 服務器向磁盤申請臨時空間，將排好序的中間結(jié)果寫入臨時段，再對另外的集合進行排序。

(3) 在所有的集合均排好序后，服務器再將它們進行合并得到最終的結(jié)果，如果排序區(qū)尺寸太小，合并無法一次完成時，將分多次進行。

從上述分析可知，排序是一種十分昂貴的操作，它消耗大量的CPU時間和內(nèi)存，觸發(fā)磁盤分頁和交換操作，因此只要有可能，我們就應該在SQL語句中盡量避免排序操作。

4.1.2 SQL中引起排序的操作

SQL查詢語句中引起排序的操作大致有：ORDER BY 和GROUP BY 從句；DISTINCT修飾符；UNION、INTERSECT、MINUS集合操作符；多表連接時的排序合并連接(SORT MERGE JOIN)等。

4.1.3 如何避免排序

1)建立恰當?shù)乃饕?/p>

對經(jīng)常進行排序和連接操作的字段建立索引。在建立索引后，當服務器向這些字段發(fā)出排序請求時，將直接引用索引而不進行排序操作；當進行等值連接查詢操作時，若建立連接的字段未建立索引，服務器進行的是排序合并連接(SORT MERGE JOIN)，連接操作的過程如下：

對進行連接的兩個或多個表分別進行全掃描；

對每一個表中的行集分別進行全排序；

合并排序結(jié)果。

如果建立連接的字段已建立索引，服務器進行嵌套循環(huán)連接(NESTED LOOP JOINS)，該連接方式不需要任何排序，其過程如下：

對驅(qū)動表進行全表掃描；

對返回的每一行利用連接字段值實施索引惟一掃描；

利用從索引掃描中返回的ROWID值在從表中定位記錄；

合并主、從表中的匹配記錄。

因此，建立索引可避免多數(shù)排序操作。

2)用UNIION ALL替換UNION

UNION在進行表鏈接后會篩選掉重復的記錄，所以在表鏈接后會對所產(chǎn)生的結(jié)果集進行排序運算，刪除重復的記錄再返回結(jié)果。大部分應用中是不會產(chǎn)生重復記錄的，最常見的是過程表與歷史表UNION 。因此，采用UNION ALL操作符替代UNION，因為UNION ALL操作只是簡單的將兩個結(jié)果合并后就返回。

4.2 優(yōu)化I/O

過多的I/O操作會占用CPU時間、消耗大量內(nèi)存和占用過多的栓鎖，因此有必要對SQL的I/O進行優(yōu)化。優(yōu)化I/O的最有效方式就是用索引掃描代替全表掃描。

4.2.1 應用基于函數(shù)的索引

基于函數(shù)的索引(FUNCTION BASED INDEX，簡記為FBI)提供了索引計算列并在查詢中使用這些索引的能力。FBI的實質(zhì)是對查詢所需中間結(jié)果進行預處理。如果一個FBI與查詢語句中的內(nèi)嵌函數(shù)完全匹配，CBO在生成查詢計劃時，將自動啟用索引范圍掃描(INDEX RANGE SCAN)替換全表掃描(FULL TABLE SCAN)。考察下面的代碼段并用AUTOTRACE觀察創(chuàng)建FBI前后執(zhí)行計劃的變化。

select * from emp where upper(ename)=’SCOTT’

創(chuàng)建FBI前，很明顯是全表掃描。

Execution Plan

……

1 0 TABLE ACCESS (FULL) OF 'EMPLOYEES' (Cost=2 Card=1 Bytes=22)

idleCREATE INDEX EMP_UPPER_FIRST_NAME ON EMPLOYEES(UPPER(FIRST_NAME))；

索引已創(chuàng)建。

再次運行相同查詢，

Execution Plan

……

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'EMPLOYEES' (Cost=1 Card=1 Bytes=22)

2 1 INDEX (RANGE SCAN) OF 'EMP_UPPER_FIRST_NAME' (NON-UNIQUE) (Cost=1 Card=1)

這一簡單的例子充分說明了FBI在SQL查詢優(yōu)化中的作用。FBI所用的函數(shù)可以是用戶自己創(chuàng)建的函數(shù)，該函數(shù)越復雜，基于該函數(shù)創(chuàng)建FBI對SQL查詢性能的優(yōu)化作用越明顯。

4.2.2 應用物化視圖和查詢重寫

物化視圖是一個預計算結(jié)果集，其中通常包含聚集與多表連接等復雜操作。數(shù)據(jù)庫自動維護物化視圖，且隨用戶的要求進行刷新。查詢重寫機制就是用數(shù)據(jù)庫中的替代對象(如物化視圖)將用戶提交的查詢重寫為完全不同但功能等價的查詢。查詢重寫對用戶透明，用戶完全按常規(guī)編寫訪問數(shù)據(jù)庫的查詢語句，優(yōu)化程序(CBO)自動決定是否對用戶提交的查詢進行重寫。查詢重寫是提高查詢性能的一種非常有效的方法，尤其是在數(shù)據(jù)倉庫環(huán)境中針對匯總、多表連接以及其它高成本的操作方面。

下面以一個非常簡單的例子來演示物化視圖和查詢重寫在優(yōu)化SQL查詢性能方面的作用。

select dept.deptno，dept.dname，count(*)

from emp，dept

where emp.deptno=dept.deptno

group by dept.deptno，dept.dname

查詢計劃及主要統(tǒng)計數(shù)據(jù)如下：

執(zhí)行計劃：

-----------------------------------------

……

2 1 HASH JOIN (Cost=5 Card=14 Bytes=224)

3 2 TABLE ACCESS (FULL) OF 'DEPT' (Cost=2 Card=4 Bytes=52)

4 2 TABLE ACCESS (FULL) OF 'EMP' (Cost=2 Card=14 Bytes=42)

主要統(tǒng)計數(shù)據(jù)：

-----------------------------------------

305 recursive calls

46 consistent gets

創(chuàng)建物化視圖EMP_DEPT：

create materialized view emp_dept build immediate

refresh on demand

enable query rewrite

as

select dept.deptno，dept.dname，count(*)

from emp，dept

where emp.deptno=dept.deptno

group by dept.deptno，dept.dname

/

再次執(zhí)行查詢，執(zhí)行計劃及主要統(tǒng)計數(shù)據(jù)如下：

執(zhí)行計劃：

-------------------------------------

……

1 0 TABLE ACCESS (FULL) OF 'EMP_DEPT' (Cost=2 Card=327 Bytes=11445)

主要統(tǒng)計數(shù)據(jù)：

------------------------------------

79 recursive calls

28 consistent gets

可見，在建立物化視圖之前，首先執(zhí)行兩個表的全表掃描，然后進行HASH連接，再進行分組排序和選擇操作；而建立物化視圖后，CBO自動將上述復雜操作轉(zhuǎn)換為對物化視圖EMP_DEPT的全掃描，相關(guān)的統(tǒng)計數(shù)據(jù)也有了很大的改善，遞歸調(diào)用(RECURSIVE CALLS)由305降到79，邏輯I/O(CONSISTENT GETS)由46降為28。

4.2.3 將頻繁訪問的小表讀入CACHE

邏輯I/O總是快于物理I/O。如果數(shù)據(jù)庫中存在被應用程序頻繁訪問的小表，可將這些表強行讀入KEEP池，從而避免物理I/O的發(fā)生。

4.3 多表連接優(yōu)化

最能體現(xiàn)查詢復雜性的就是多表連接，多表連接操作往往要耗費大量的CPU時間和內(nèi)存，因此多表連接查詢性能優(yōu)化往往是SQL優(yōu)化的重點與難點。

4.3.1 消除外部連接

通過消除外部連接，不僅使得到的查詢更易于讀取，而且性能也經(jīng)常可以得到改善。一般的思路是，有以下形式的查詢：

SELECT …，OUTER_JOINED_TABLE.COLUMN

FROM SOME_TABLE，OUTER_JOINED_TO_TABLE

WHERE …=OUTER_JOINED_TO_TABLE(+)

可轉(zhuǎn)換為如下形式的查詢：

SELECT …，(SELECT COLUMN FROM OUTER_ JOINED_TO_TABLE WHERE …)FROM SOME_TABLE；

4.3.2 謂詞前推，優(yōu)化中間結(jié)果

多表連接的性能低下多數(shù)是因為連接操作與過濾操作的次序不合理，大多數(shù)用戶在編寫多表連接查詢時，總是先進行連接操作再應用過濾條件，這導致服務器做了太多的無用功。針對這類問題，其優(yōu)化思路就是盡可能將過濾謂詞前推，使不符合條件的記錄提前被篩選掉，只對符合條件的少數(shù)記錄進行連接處理，這樣可成倍的提高SQL查詢效能。

標準連接查詢?nèi)缦拢?/p>

Select a.prod_name，sum(b.sale_quant)，

sum(c.sale_quant)，sum(d.sale_quant)

From product a，tele_sale b，online_sale c，store_sale d

Where a.prod_id=b.prod_id and a.prod_id=c.prod_id

and a.prod_id=d.prod_id And a.order_datesysdate-90

Group by a.prod_id；

啟用內(nèi)嵌視圖，且將條件a.order_datesysdate-90前移，優(yōu)化后代碼如下：

Select a.prod_name，b.tele_sale_sum，c.online_sale_sum，d.store_sale_sum From product a，

(select sum(sal_quant) tele_sale_sum from product，tele_sale

Where product.order_datesysdate-90 and product.prod_id =tele_sale.prod_id) b，

(select sum(sal_quant) online_sale_sum

from product，tele_sale

Where product.order_datesysdate-90 and product.prod_id =online_sale.prod_id) c，

(select sum(sal_quant) store_sale_sum

from product，store_sale

Where product.order_datesysdate-90 and product.prod_id =store_sale.prod_id) d，

Where a.prod_id=b.prod_id and

a.prod_id=c.prod_id and a.prod_id=d.prod_id；

5 結(jié)束語

SQL語言在數(shù)據(jù)庫應用中占有非常重要的地位，其性能的優(yōu)劣直接影響著整個信息系統(tǒng)的可用性。論文從影響SQL性能的最主要的三個方面入手，分析了如何優(yōu)化SQL查詢的I/O、避免高成本的排序操作和優(yōu)化多表連接。需要強調(diào)的一點是，理解SQL語句所解決的問題比SQL調(diào)優(yōu)本身更重要，因此SQL調(diào)優(yōu)需要系統(tǒng)分析人員、開發(fā)人員和數(shù)據(jù)庫管理員密切協(xié)作。

參考文獻

[1]Thomas Kyte.Effective Oracle by Design：Design and Build High-performance Oracle Application[M]，The McGral- Hill Companies，Inc，2003

[2]Kevin Loney，George Koch，Oracle 9i：The Complete Reference[M]，The McGral-Hill Companies，Inc，2002

[3] Oracle9i SQL Reference release 2(9.2)[OL/M]，2002.10. http：//

[4] Oracle9i Data Warehousing Guide release 2(9.2) [OL/M]，2002.03. http：//

[5]Alexey Danchenkov，Donald Burleson，Oracle Tuning：The Definitive Reference[OL/M]，Rampant Techpress，2006.

[6] Oracle9i Database Concepts release 2(9.2) [OL/M]，2002.08. http：//

[7] Oracle9i supplied plsql packages and types reference release 2(9.2) [OL/M]，2002.12. http：// technology/

本文名稱：針對nosql相關(guān)的論文,nosql技術(shù)
地址分享：http://muchs.cn/article22/phiecc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設計公司、小程序開發(fā)、App開發(fā)、面包屑導航、服務器托管、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)