建站
咨詢
售后
建站咨詢
新聞中心
?作為地球上最堅(jiān)硬的物質(zhì)，鉆石的用途令人驚訝地有限：鋸片、鉆頭、結(jié)婚戒指和其他工業(yè)應(yīng)用。
茂名網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)建站于2013年創(chuàng)立到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。
相比之下，自然界中較軟的金屬之一--鐵，可以被改造成無盡的應(yīng)用：最鋒利的刀片、最高的摩天大樓、最先進(jìn)的汽車, 巨大的輪船，而且很快，如果埃隆-馬斯克是對的，就會有最有效的電動車電池。
換句話說，鐵之所以有令人難以置信的用處，是因?yàn)樗仁莿傂缘挠质侨嵝缘摹?/p>
同樣，數(shù)據(jù)庫只有在既嚴(yán)格又靈活的情況下才對今天的實(shí)時(shí)分析有用。
傳統(tǒng)的數(shù)據(jù)庫，由于其完全靈活的結(jié)構(gòu)，是很脆的。無模式的NoSQL數(shù)據(jù)庫也是如此，它們能夠攝取大量的數(shù)據(jù)，但在從這些數(shù)據(jù)中提取復(fù)雜的見解方面卻很差。
用戶個(gè)性化，自動庫存管理，智能運(yùn)維和其他實(shí)時(shí)用例要求數(shù)據(jù)庫嚴(yán)格執(zhí)行模式，并擁有根據(jù)數(shù)據(jù)本身自動重新定義這些模式的靈活性。這滿足了現(xiàn)代分析的三個(gè)關(guān)鍵要求：
- 支持采集數(shù)據(jù)的規(guī)模和速度
- 支持靈活的模式，可以立即適應(yīng)流式數(shù)據(jù)的多樣性
- 支持快速、復(fù)雜的SQL查詢，需要嚴(yán)格的結(jié)構(gòu)或模式
昨天的模式：堅(jiān)硬而脆弱
經(jīng)典的模式是關(guān)系型數(shù)據(jù)庫表：實(shí)體的行，例如人，以及這些實(shí)體的不同屬性（年齡或性別）的列。通常存儲在SQL語句中，模式還定義了數(shù)據(jù)庫中所有的表以及它們之間的關(guān)系。
傳統(tǒng)上，模式是嚴(yán)格執(zhí)行的。不符合預(yù)定屬性或數(shù)據(jù)類型的輸入數(shù)據(jù)會被數(shù)據(jù)庫自動拒絕，在其位置上存儲一個(gè)空值或完全跳過整個(gè)記錄。改變模式是很困難的，也是很少做的。公司小心翼翼地設(shè)計(jì)他們的ETL數(shù)據(jù)管道，以便與他們的模式保持一致（反之亦然）。
在過去，預(yù)先創(chuàng)建和嚴(yán)格執(zhí)行模式有很好的理由。SQL查詢更容易編寫。它們的運(yùn)行速度也快了很多。最重要的是，嚴(yán)格的模式可以防止由不良或不匹配的數(shù)據(jù)造成的查詢錯(cuò)誤。
然而，嚴(yán)格的、一成不變的模式在今天有著巨大的弊端。首先，現(xiàn)在的數(shù)據(jù)來源和類型比90年代多得多。他們中的許多人不能輕易地適應(yīng)相同的模式結(jié)構(gòu)。最值得注意的是實(shí)時(shí)事件流。流媒體和時(shí)間序列數(shù)據(jù)通常以經(jīng)常變化的半結(jié)構(gòu)化格式到達(dá)。隨著這些格式的改變，模式也必須改變。
其次，隨著業(yè)務(wù)條件的變化，公司不斷需要分析新的數(shù)據(jù)源，運(yùn)行不同類型的分析--或者簡單地更新其數(shù)據(jù)類型或標(biāo)簽。
這里有一個(gè)例子。當(dāng)我在Fackbook的數(shù)據(jù)基礎(chǔ)設(shè)施團(tuán)隊(duì)的時(shí)候，我們參與了一項(xiàng)雄心勃勃的計(jì)劃，名為"花蜜項(xiàng)目 "的用戶群正在爆炸性增長。"花蜜項(xiàng)目 "試圖用一套標(biāo)準(zhǔn)的屬性來記錄每個(gè)用戶的行為。在全球范圍內(nèi)實(shí)現(xiàn)這一模式的標(biāo)準(zhǔn)化，將使我們能夠在全球范圍內(nèi)分析趨勢并發(fā)現(xiàn)異常情況。經(jīng)過許多內(nèi)部辯論，我們的團(tuán)隊(duì)同意在Hadoop中使用一個(gè)名為time_spent的列中的時(shí)間戳來存儲每個(gè)用戶事件，該列的分辨率為一秒。
在 "花蜜項(xiàng)目 "首次亮相后，我們向一組新的應(yīng)用程序開發(fā)人員展示了它。他們問的第一個(gè)問題是"你能把列的花費(fèi)時(shí)間從秒改為毫秒嗎？"換句話說，他們隨口要求我們在Nectar項(xiàng)目推出后重建其模式的一個(gè)基本方面。
ETL管道可以使你所有的數(shù)據(jù)源都在同一個(gè)傳說中的屋頂下（這就是T，代表數(shù)據(jù)轉(zhuǎn)換的意思）。然而，ETL管道的設(shè)置、操作以及隨著數(shù)據(jù)來源和類型的變化而進(jìn)行的手動更新都很耗時(shí)和昂貴。
靈活性的嘗試
嚴(yán)格的、一成不變的模式破壞了靈活性，而今天所有的公司都需要這種靈活性。一些數(shù)據(jù)庫制造商通過使用戶更容易手動修改他們的模式來應(yīng)對這個(gè)問題。不過，這也是一個(gè)沉重的代價(jià)。
使用SQL ALTER-TABLE命令改變模式需要大量的時(shí)間和處理能力，使你的數(shù)據(jù)庫長時(shí)間處于離線狀態(tài)。而且，一旦模式被更新，就很有可能在無意中破壞你的數(shù)據(jù)，使你的數(shù)據(jù)管道癱瘓。
以 PostgreSQL，是流行的交易型數(shù)據(jù)庫，許多公司也用它來做簡單的分析。為了正確攝取當(dāng)今快速變化的事件流，PostgreSQL必須通過SQL中的手動ALTER-TABLE命令來改變其模式。這將鎖定數(shù)據(jù)庫表，并在ALTER-TABLE完成的時(shí)間內(nèi)凍結(jié)所有查詢和交易。據(jù)說，無論你的PostgreSQL表有多大，ALTER-TABLE都需要很長的時(shí)間。它還需要大量的CPU，并造成數(shù)據(jù)錯(cuò)誤和下游應(yīng)用中斷的風(fēng)險(xiǎn)。
NewSQL數(shù)據(jù)庫也面臨同樣的問題。 CockroachDB 承諾在線改變Schema具有零停機(jī)時(shí)間。然而，Cockroach警告說不要一次做超過一個(gè)模式的改變。它也強(qiáng)烈警告不要在交易中改變模式。就像PostgreSQL一樣，CockroachDB的所有模式改變都必須由用戶手動完成。因此，CockroachDB的模式遠(yuǎn)沒有表面上那么靈活。而且，數(shù)據(jù)錯(cuò)誤和數(shù)據(jù)停機(jī)的風(fēng)險(xiǎn)也同樣存在。
NoSQL來拯救？
其他制造商發(fā)布的NoSQL數(shù)據(jù)庫大大放松了模式，或者完全放棄了模式。
這種激進(jìn)的設(shè)計(jì)選擇使NoSQL數(shù)據(jù)庫--文檔數(shù)據(jù)庫、鍵值存儲、面向列的數(shù)據(jù)庫和圖形數(shù)據(jù)庫--非常適合將各種類型的海量數(shù)據(jù)存儲在一起，無論是結(jié)構(gòu)化、半結(jié)構(gòu)化還是多態(tài)化的數(shù)據(jù)。
Data lakes建立在NoSQL數(shù)據(jù)庫（如Hadoop）上的數(shù)據(jù)湖是混合類型的擴(kuò)展數(shù)據(jù)存儲庫的最好例子。NoSQL數(shù)據(jù)庫在檢索大量數(shù)據(jù)和運(yùn)行簡單查詢方面也很迅速。
然而，輕量級/非輕量級模式數(shù)據(jù)庫確實(shí)存在弊端。
雖然查找和簡單的查詢可以是快速和簡單的，但復(fù)雜的嵌套的和必須返回精確答案的查詢往往運(yùn)行緩慢，而且難以創(chuàng)建。這是由于缺乏SQL支持，以及他們傾向于對索引和其他查詢優(yōu)化的支持不力。復(fù)雜的查詢甚至更有可能超時(shí)而不返回結(jié)果，這是因?yàn)镹oSQL的過于寬松的數(shù)據(jù)一致性模型。修復(fù)和重新運(yùn)行查詢是一件浪費(fèi)時(shí)間的麻煩事。而當(dāng)涉及到云計(jì)算和開發(fā)人員時(shí)，這意味著浪費(fèi)金錢。
以作為Hadoop堆棧一部分的Hive分析數(shù)據(jù)庫為例。Hive確實(shí)支持靈活的模式，但很粗略。當(dāng)它遇到不適合整齊地放入現(xiàn)有表格和數(shù)據(jù)庫的半結(jié)構(gòu)化數(shù)據(jù)時(shí)，它只是將數(shù)據(jù)存儲為一個(gè) JSON-like blob，這可以保持?jǐn)?shù)據(jù)的完整性。然而，在查詢時(shí)，Blobs需要首先被反序列化，這是一個(gè)緩慢而低效的過程。
或者采取亞馬遜DynamoDB為例，它使用的是無模式的鍵值存儲。DynamoDB在讀取特定記錄時(shí)速度超快。多記錄查詢往往要慢得多，盡管建立二級索引可以幫助。更大的問題是，DynamoDB不支持任何JOIN或任何其他復(fù)雜查詢。
嚴(yán)格和靈活模式的正確方法
然而，有一個(gè)成功的數(shù)據(jù)庫公式，它融合了NoSQL的靈活可擴(kuò)展性和SQL的準(zhǔn)確性和可靠性，同時(shí)又加入了云原生基礎(chǔ)設(shè)施的低操作簡單性。
Rockset是一個(gè)建立在RocksDB鍵值存儲之上的實(shí)時(shí)分析平臺。像其他NoSQL數(shù)據(jù)庫一樣，Rockset具有高度的可擴(kuò)展性、靈活性和快速寫入數(shù)據(jù)的能力。但與SQL關(guān)系型數(shù)據(jù)庫一樣，Rockset也有嚴(yán)格的模式優(yōu)勢。強(qiáng)數(shù)據(jù)類型和高度的數(shù)據(jù)一致性，再加上我們的自動和高效的 Converged Indexing這些優(yōu)勢與我們的自動和高效的數(shù)據(jù)庫相結(jié)合，確保你的復(fù)雜的SQL查詢是快速的。
Rockset自動生成Schema通過檢查數(shù)據(jù)的字段和數(shù)據(jù)類型，因?yàn)樗谴鎯Φ?。而且Rockset可以處理扔給它的任何類型的數(shù)據(jù)，包括。
- 具有深度嵌套數(shù)組和對象的JSON數(shù)據(jù)，以及混合數(shù)據(jù)類型和稀疏字段
- 實(shí)時(shí)事件流，隨著時(shí)間的推移不斷增加新的字段
- 來自新數(shù)據(jù)源的新數(shù)據(jù)類型
支持無模式攝入和融合索引，使Rockset能夠通過消除對上游數(shù)據(jù)轉(zhuǎn)換的需求來減少數(shù)據(jù)延遲。
Rockset還有其他優(yōu)化功能，以減少存儲成本和加速查詢。對于每條記錄的每一個(gè)字段，Rockset都會存儲數(shù)據(jù)類型。這最大限度地提高了查詢性能和減少了錯(cuò)誤。而且，我們通過一個(gè)叫做字段互換的功能有效地做到了這一點(diǎn)，與無模式的基于JSON的文檔數(shù)據(jù)庫相比，例如，所需的存儲量最多可減少30%。
Rockset使用了一種叫做類型提升的東西來減少查詢的處理時(shí)間。具有相同類型的相鄰項(xiàng)目可以將其類型信息提升到適用于整個(gè)項(xiàng)目集，而不是存儲在列表中的每一個(gè)單獨(dú)的項(xiàng)目。這使得矢量的CPU指令能夠快速處理整個(gè)項(xiàng)目集。這個(gè)實(shí)現(xiàn)--連同我們的 Converged Index?--使Rockset查詢能夠像具有剛性模式的數(shù)據(jù)庫一樣快速運(yùn)行，而不會產(chǎn)生額外的計(jì)算。
一些NoSQL數(shù)據(jù)庫的制造商聲稱只有他們能支持靈活的模式。 這不是真的，而且是Rockset等現(xiàn)代產(chǎn)品正在打破的一個(gè)神話。?
當(dāng)前題目：為什么實(shí)時(shí)分析既需要NoSQL的靈活性，又需要SQL系統(tǒng)的嚴(yán)格模式？
分享鏈接：http://www.5511xx.com/article/ccsjecc.html
