合理使用數(shù)據(jù)庫

當(dāng)你需要ACID屬性來維護(hù)數(shù)據(jù)間的關(guān)系時，可以用關(guān)系型數(shù)據(jù)庫。對于其他的數(shù)據(jù)存儲，需要考慮更合適的工具。適用于在系統(tǒng)架構(gòu)中引入新數(shù)據(jù)或數(shù)據(jù)結(jié)構(gòu)時。在選擇最合適的存儲工具時，要考慮數(shù)據(jù)量、存儲空間響應(yīng)時間的要求、關(guān)系以及其他多種因素。
RDBMS提供了最好的事務(wù)完整性，但相對于其他存儲選擇，這種數(shù)據(jù)庫很難擴(kuò)愚且擴(kuò)展成本高，可用性低。為數(shù)據(jù)選擇正確的存儲工具。不要因?yàn)槟懔?xí)慣用數(shù)據(jù)庫訪問數(shù)據(jù)，就總用關(guān)系數(shù)據(jù)庫存儲數(shù)據(jù)。

關(guān)系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)(如Oraclei和MYSQL)是以EdgarF.Codd于1970年發(fā)布的論文“大型共享數(shù)據(jù)庫數(shù)據(jù)的關(guān)系模型”(“ARelationalModelofDataforLargeSharedDataBanks”)中的關(guān)系模型為基礎(chǔ)的。大多數(shù)RDBMS對于存儲數(shù)據(jù)有兩大好處。第一個好處是利用ACID屬性確保了事務(wù)完整性，關(guān)于ACID的定義，請參閱表2-1。第二個好處在于表內(nèi)和表間的關(guān)系型結(jié)構(gòu)。為了最小化數(shù)據(jù)冗余，提高事務(wù)的處理能力，大多數(shù)聯(lián)機(jī)事務(wù)處理理(OLTP)系統(tǒng)中的表都被規(guī)范化為第三范式即表中的所有記錄都有相同的字段，所有非主關(guān)鍵字的字段都不能只依賴于組合關(guān)鍵字的一部分，所有非主關(guān)鍵字字段必須依賴于主關(guān)鍵字。
表中的每一列數(shù)據(jù)都要依賴于表中的其他列數(shù)據(jù)。表之間的關(guān)系通常以外鍵表示。雖然使用RDBMS有這兩點(diǎn)好處，但它們也是限制了擴(kuò)展性的原因。為了確保ACID屬性，擴(kuò)展RDBMS比擴(kuò)展其他數(shù)據(jù)存儲難得多。為了在具有多個節(jié)點(diǎn)的RDBMS集群(如MYSQLNDB)中確保數(shù)據(jù)致性，要采用同步復(fù)制的功能才能保證所有數(shù)據(jù)在提交時被寫入多個節(jié)點(diǎn)。采用OracleRAC，會有一個中央數(shù)據(jù)庫，但是數(shù)據(jù)庫域的所有權(quán)卻是所有節(jié)點(diǎn)共享的。因此，對于寫請求，要把數(shù)據(jù)所有權(quán)轉(zhuǎn)移到相應(yīng)的節(jié)點(diǎn)，而對于讀請求，則要依次從請求者發(fā)送到主節(jié)點(diǎn)，再從主節(jié)點(diǎn)發(fā)送到擁有要讀的數(shù)據(jù)的節(jié)點(diǎn)，再從它發(fā)回到請求者。最終，你會受到同步復(fù)制數(shù)據(jù)的節(jié)點(diǎn)數(shù)或它們的地理位置的限制。
RDBMS中表內(nèi)和表間的關(guān)系結(jié)構(gòu)使得很難對數(shù)據(jù)庫進(jìn)行分片或分區(qū)操作。關(guān)于把工作分發(fā)到多臺機(jī)器上的原則。在把表拆分到多個數(shù)據(jù)庫的應(yīng)用中，原來在單一數(shù)據(jù)中連接兩個表的簡單査詢就要被轉(zhuǎn)換成兩個查詢來連接數(shù)據(jù)。
總而言之，只有要求事務(wù)完整性或數(shù)據(jù)間有關(guān)系的數(shù)據(jù)，才需要使用RDBMS。既不要求數(shù)據(jù)間的關(guān)系，也不要求事務(wù)完整性的數(shù)據(jù)，最好采用其他的存儲系統(tǒng)。我們來簡單討論幾個可用的解決方案，以及如何用它們代替數(shù)據(jù)庫，以達(dá)到更好的、性價比更高的、擴(kuò)展性更高的效果種常常被忽略的存儲系統(tǒng)是文件系統(tǒng)。也許這是一種簡單的存儲方式，因?yàn)榇蠖鄶?shù)程序員最初編程時，訪問的都是文件而不是數(shù)據(jù)庫中的數(shù)據(jù)。一旦我們學(xué)會了在數(shù)據(jù)庫中存儲或獲取數(shù)據(jù)，就再也不用文件。文件系統(tǒng)已經(jīng)發(fā)展很久了，而且許多文件系統(tǒng)是專門為處理非常大量的文件和數(shù)據(jù)而設(shè)計的。
這些文件系統(tǒng)包括GoogleFileSystem(GFS)、Mogilefs和Ceph等。如果你的系統(tǒng)是“一次寫，多次讀”的，那么文件系統(tǒng)是個很好的選擇。換句話說，如果不會發(fā)生讀寫沖突，不需要維護(hù)大量的數(shù)據(jù)關(guān)系，并不真正需要用到數(shù)據(jù)庫事務(wù)，那么采用文件系統(tǒng)才是最好的選擇。另一種存儲策略叫做NOSQL。這一類存儲技術(shù)通常被劃分為鍵一值存儲、可擴(kuò)展記錄存儲和文檔存儲。關(guān)于這種技術(shù)分類，并沒有統(tǒng)一的標(biāo)準(zhǔn)，很多技術(shù)可以被分到多個種類中。在下面的介紹中，我們加入了一些技術(shù)的示例，但不要把它們當(dāng)做最終的解釋。考慮到這些項(xiàng)目發(fā)展的速度，那么將來這種分類很可能更加模糊。
鍵一值存儲技術(shù)包括Memcached、TokyoTyrant和Voldemort。這些產(chǎn)品中的數(shù)據(jù)都有一個鍵一值索引存儲在內(nèi)存中。有些產(chǎn)品能夠把健值異步復(fù)制。通過簡化的數(shù)據(jù)存儲模型和鍵一值對，這類產(chǎn)品能夠提供很高寫人硬盤永久存儲。有些產(chǎn)品會在節(jié)點(diǎn)間進(jìn)行同步復(fù)制，而有的則進(jìn)行的可擴(kuò)展性和性能，但在能存儲什么數(shù)據(jù)方面具有很大的限制。此外，依賴同步復(fù)制的鍵一值數(shù)據(jù)存儲仍然具有與RDBMS集群一樣的限制，即在節(jié)點(diǎn)數(shù)量和地理位置方面的限制。
可擴(kuò)展記錄存儲技術(shù)包括Google公司專有的BigTable和Facebook公司的(現(xiàn)在已經(jīng)是開源的)Cassandra。這些產(chǎn)品采用的是可以拆分到節(jié)點(diǎn)的行列數(shù)據(jù)模型?？梢愿鶕?jù)主鍵對行進(jìn)行拆分或分片，再對列進(jìn)行分組，存放到不同的節(jié)點(diǎn)上。這種擴(kuò)展方法與展示的AKF擴(kuò)展立方中的X軸和Y軸拆分方法相似，X軸拆分是讀取數(shù)據(jù)副本，Y軸是根據(jù)支持的服務(wù)來分割表。在這些產(chǎn)品中，行分片是自動執(zhí)行的，但是列拆分則需要用戶定義，與在RDBMS中的操作類似。這些產(chǎn)品使用的是異步復(fù)制，最終能達(dá)到一致性。這意味著，也許幾毫秒或幾小時后，最終所有節(jié)點(diǎn)上的數(shù)據(jù)將是一致的。
文檔存儲技術(shù)包括COUCHDB、亞馬遜的Simpledb和雅虎的PNUTS。這種技術(shù)采用的數(shù)據(jù)模型雖然被稱為“文檔”，但其實(shí)稱為多索引對象模型更確切。這些多索引對象(或者說“文檔”)可以聚集到多索引對象的集合(通常稱為“城”)中，然后可以對這比值合成情由查詢。文檔存儲技術(shù)不支持ACID屬性，相反地，它們采用的是異步復(fù)制方法，最終能使數(shù)據(jù)達(dá)到一致。
NOSQL解決方案把對象和實(shí)體之間的關(guān)系限制到了最少。正是因?yàn)闇p少了關(guān)系，所以能夠把系統(tǒng)分發(fā)到多個節(jié)點(diǎn)上，在維持事務(wù)完整性和解決讀寫沖突的同時，實(shí)現(xiàn)了更大的可擴(kuò)展性。
通常情況下，我們都需要對系統(tǒng)的可擴(kuò)展性和靈活性進(jìn)行權(quán)衡，在讀過前面的介紹之后，也許你已經(jīng)有了決定。數(shù)據(jù)實(shí)體之間的關(guān)系是進(jìn)行衡量的關(guān)鍵，隨著關(guān)系增多，靈活性會增加。靈活性增加，會使成本增加，可擴(kuò)展性降低。從擴(kuò)展系統(tǒng)的成本(和限制)與數(shù)據(jù)實(shí)體之間的關(guān)系程度這兩個方面對比了RDBMS、NOSQL和文件系統(tǒng)這三種解決方案。圖4-2則從靈活性和系統(tǒng)允許使用的關(guān)系程度兩方面進(jìn)行了對比。結(jié)果很顯然，關(guān)系帶來了靈活性，但降低了可擴(kuò)展性。正因如此，我們不想濫用關(guān)系數(shù)據(jù)庫，而是要采用適合任何的工具，使系統(tǒng)得到更大的擴(kuò)展性。
在這個原則中，我們要介紹的另一種數(shù)據(jù)存儲方法是Goge的Mapreduce方法リ。簡而言之，Mapreduce方法具有兩個功能，即Map和Reduce。Map功能的輸入是一個鍵一值對，生成一個中間鍵一值對。輸入的鍵可能是一個文檔名或者指向文檔中的某一段的指針。值可能是文檔中的所有文字。Map功能的輸出將輸入到Reduce功能，該功能使用個程序?qū)ξ淖趾臀淖侄畏纸M，并且把值添加到一個列表中。這是個不算復(fù)雜的程序，根據(jù)鍵對數(shù)據(jù)進(jìn)行排序和分組。這種技術(shù)大的好處是能夠把非常大的數(shù)據(jù)集的計算分發(fā)到許多服務(wù)器上。
Apache的Hadoop則是采用兩種存儲方法的組合的一個實(shí)例。它采用了Google的Mapreduce技術(shù)和GoogleFileSystem，這兩種方法前面都介紹過。Hadoop既是具有高可擴(kuò)展性的文件系統(tǒng)，又能夠分布式地存儲和獲取數(shù)據(jù)。
許多替代數(shù)據(jù)庫的數(shù)據(jù)存儲方法，那么在決定選擇哪種方法時，應(yīng)該考慮數(shù)據(jù)的哪些特征呢?與存儲方法有很多選擇一樣，需要考慮的數(shù)據(jù)特征也有很多。最重要的幾個是數(shù)據(jù)元素間的關(guān)聯(lián)程度，解決方案的發(fā)展速度以及數(shù)據(jù)的讀寫比例(可能還有數(shù)據(jù)是否更新)。最后，我們關(guān)心的是如何把數(shù)據(jù)變現(xiàn)(換句話說，是否有利可圖)，因?yàn)槲覀儾幌胱屪约旱南到y(tǒng)成本超出收益。
成本和開發(fā)時間。例如，假設(shè)把一個涉及用戶、付款、采購等信息的事務(wù)存儲在一個鍵一值存儲中，然后在采購報告內(nèi)體現(xiàn)其中的信息片段，想象一下有多么困難吧。雖然你可以采用文件系統(tǒng)或者NOSQL存儲方法實(shí)現(xiàn)它，但向用戶交付結(jié)果需要的開發(fā)投入和時間成本都很高。
預(yù)期的增長速度非常重要，原因很多。最終，這個增長速度會影響系統(tǒng)的成本和客戶響應(yīng)時間。如果數(shù)據(jù)實(shí)體間需要高度的聯(lián)系，那么我們可能需要利用所有的硬件和處理能力來支持單一的整合數(shù)據(jù)庫，促使我們把數(shù)據(jù)庫拆分成多個實(shí)例。
讀寫比例非常重要，因?yàn)樗兄谖覀兝斫庑枰裁礃拥南到y(tǒng)。只寫一次而讀多次的數(shù)據(jù)可以采用文件系統(tǒng)外加某種應(yīng)用、文件或?qū)ο缶彺?。圖像就是采用文件系統(tǒng)進(jìn)行存儲的典型例子。寫過之后需要更新的數(shù)據(jù)，或者具有很高寫讀比例的數(shù)據(jù)，最好采用NOSQL存儲或RDBMS。這些需要考慮的因素構(gòu)成了另一個立方體，分別用X軸、Y軸和Z軸表示了這三個因素。隨著這三個因素的值增加，最終解決方案的成本也會增加。如果我們要求系統(tǒng)間有高度的關(guān)聯(lián)、高速增長、能夠解決讀寫沖突，那么最好采用幾個較小的RDBMS系統(tǒng)，這樣在開發(fā)、系統(tǒng)維護(hù)甚至數(shù)據(jù)庫許可方面的成本可能相對較高。如果增長速度較慢，規(guī)模較小，但是關(guān)系很多需要解決讀寫沖突，那么可以使用單個的大型數(shù)據(jù)庫(具有高可用性的集群)。
如果數(shù)據(jù)間的關(guān)系不是非常多，那么在任何水平的讀寫沖突和幾乎任何水平的增長速度下，都可以使用NOSQL存儲技術(shù)。這里，我們再次看到了關(guān)系對成本和復(fù)雜度的影響程度，我們將在第8章中探討這個主題。采用NOSQL技術(shù)的成本較低。最后，如果數(shù)據(jù)關(guān)系不多，不關(guān)心讀寫沖突，那么可以采用成本更低的文件系統(tǒng)。
我們必須理解網(wǎng)站制作數(shù)據(jù)的貨幣價值，因?yàn)樵S多公司在艱難起步時期都經(jīng)歷過，用A級存儲免費(fèi)存放TB級的用戶數(shù)據(jù)，很快就會把資金消耗完。較好的方法是分層存儲數(shù)據(jù)，根據(jù)訪問日期，不停地把較老的數(shù)據(jù)下推到較便宜的訪問較慢的存儲媒體上。這種情況叫做成本一數(shù)據(jù)價值的困境，即隨著時間流逝，數(shù)據(jù)價值會降低，但是保存數(shù)據(jù)的成本會增加。

當(dāng)前文章：合理使用數(shù)據(jù)庫
鏈接分享：http://www.muchs.cn/news31/150531.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、微信公眾號、網(wǎng)站策劃、自適應(yīng)網(wǎng)站、網(wǎng)站排名、用戶體驗(yàn)

廣告

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