我談一點個人的見解吧。
成都創(chuàng)新互聯(lián)長期為成百上千客戶提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊從業(yè)經(jīng)驗10年,關(guān)注不同地域、不同群體,并針對不同對象提供差異化的產(chǎn)品和服務(wù);打造開放共贏平臺,與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為同仁企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計、做網(wǎng)站,同仁網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
記得之前看過一篇帖子,講的是可能我們所說的非關(guān)系型數(shù)據(jù)庫是我們翻譯錯了。年代久遠(yuǎn),找不到原貼了,但是大概說的是非關(guān)系型數(shù)據(jù)庫的名字叫Not Only Sql,我們簡化過來就叫NoSql,所以看著就像是非關(guān)系型數(shù)據(jù)庫,然后我們再顧名思義,就是數(shù)據(jù)之間沒有關(guān)系的數(shù)據(jù)庫,這個理解我不贊同。
如果從名字上來看,我覺得可以叫做不僅僅是關(guān)系型的數(shù)據(jù)庫,更為恰當(dāng),當(dāng)然,我們也不能否認(rèn),這類數(shù)據(jù)庫確實在數(shù)據(jù)關(guān)聯(lián)之間更為自由,約束條件更少,(甚至沒有),但是這并不能阻擋它的發(fā)展,以“鍵值對”為基礎(chǔ)的NoSql在性能上可以說是碾壓對手,大家都知道NoSql不需要經(jīng)過Sql層的解析的,相比關(guān)系型數(shù)據(jù)庫數(shù)據(jù)之間的高耦合性,這讓它具有更高的平行擴(kuò)展性,當(dāng)然這方面你需要去看一下相關(guān)的知識,高耦合低聚合等等概念需要理解一下。
大概就是我的理解了吧,關(guān)系型數(shù)據(jù)庫就不用說了吧,我們常常用到,現(xiàn)在的主流數(shù)據(jù)庫我們也都在接觸,大到Oracle,小到Sqlite,相信你也比較熟悉,這些數(shù)據(jù)庫都是支持事務(wù)和相當(dāng)復(fù)雜的查詢的,往往我們一條查詢語句可以上百行(一子句一行)甚至上千行,這些都是NoSql做不到的,(注意我說的是一條查詢語句),事務(wù)這個概念我也不多提了,這個網(wǎng)上就太多了,如果涉及到高并發(fā)之類的,可以多線程+事務(wù),效率更高一些。
最后再補(bǔ)兩句,好像現(xiàn)在的NoSql數(shù)據(jù)庫的發(fā)展趨勢很微妙,描述在往一些關(guān)系型數(shù)據(jù)庫的基礎(chǔ)模型延伸。
nosql適合存儲非結(jié)構(gòu)化數(shù)據(jù)嗎
基本含義NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,是一項全新的數(shù)據(jù)庫革命性運動,早期就有人提出,發(fā)展至2009年趨勢越發(fā)高漲
物聯(lián)網(wǎng)時代的大數(shù)據(jù)策略
互聯(lián)網(wǎng)時代,PC、Pad、智能手機(jī)等設(shè)備無處不在,數(shù)以億計的用戶通過微博、微信、SNS、博客等途徑產(chǎn)生大量的自媒體數(shù)據(jù),電商、新聞類網(wǎng)站、搜索引擎每時每刻都在記錄著豐富的用戶行為信息,海量的數(shù)據(jù)促進(jìn)了云計算,分布式技術(shù)的發(fā)展,而這些技術(shù)反過來不僅推動了Web和移動互聯(lián)網(wǎng)的革新,也推動了物聯(lián)網(wǎng)的飛速前進(jìn)?,F(xiàn)在,我們正逐漸邁入物聯(lián)網(wǎng)時代,實現(xiàn)萬物互聯(lián)的愿景,如果說之前人是信息生產(chǎn)的主體,那么或許不久的將來設(shè)備將成為主角,它們將源源不斷地產(chǎn)生與人相關(guān)的衣食住行信息,這些信息會通過云計算、數(shù)據(jù)挖掘等技術(shù)實現(xiàn)價值的升華從而為用戶提供更優(yōu)質(zhì)、貼心的服務(wù)。那么物聯(lián)網(wǎng)時代會產(chǎn)生什么樣的數(shù)據(jù),應(yīng)該采用什么樣的大數(shù)據(jù)策略呢?
THINKstrategies 的總經(jīng)理 Jeff Kaplan 在自己的博文《 當(dāng)物聯(lián)網(wǎng)遇見大數(shù)據(jù) 》中寫道:
“你不能使用現(xiàn)在的策略,因為可以被捕獲、管理并利用的數(shù)據(jù)將更加多樣化,同時用例也會更加豐富。附加到各種設(shè)備和對象上的傳感器會產(chǎn)生各種類型的數(shù)據(jù)。這些數(shù)據(jù)將會用于各種響應(yīng)式的、主動的或者 創(chuàng)造性的目的 。IT部門的任務(wù)就是與業(yè)務(wù)部門一起工作,完全理解物聯(lián)網(wǎng)方面的用例,然后尋找滿足業(yè)務(wù)需求的技術(shù)。特別是,IT部門必須識別出最優(yōu)的分析平臺和工具,讓業(yè)務(wù)用戶能夠獲取到需要的數(shù)據(jù),分析數(shù)據(jù)的含義并快速地做出響應(yīng)?!?/p>
Gartner公司的副總裁、著名分析師 Joe Skorupa 認(rèn)為:
“分布在世界各地的物聯(lián)網(wǎng)設(shè)備將產(chǎn)生大量的輸入數(shù)據(jù),將所有的數(shù)據(jù)傳送到一個位置進(jìn)行處理無論從技術(shù)上還是從經(jīng)濟(jì)上都是無法實現(xiàn)的。最近的趨勢——將應(yīng)用程序集中起來以便于降低成本并增強(qiáng)安全性——并不適合物聯(lián)網(wǎng)。組織必須將數(shù)據(jù)集中到多個分布式的小型數(shù)據(jù)中心中,在此對數(shù)據(jù)進(jìn)行初步的處理并發(fā)送到一個中心站點進(jìn)行額外的處理。數(shù)據(jù)中心管理員需要在這些區(qū)域部署更加具有前瞻性的容量以滿足業(yè)務(wù)發(fā)展的需要?!?/p>
Patrick McFadin則在自己的博文《 物聯(lián)網(wǎng):數(shù)據(jù)都去了哪里? 》中闡述了一個具體的數(shù)據(jù)策略解決方案。他認(rèn)為整個過程可以分為三個階段:產(chǎn)生數(shù)據(jù)并通過Internet傳遞、中央系統(tǒng)收集并組織數(shù)據(jù)、持續(xù)的數(shù)據(jù)分析與使用。
第一階段需要決定數(shù)據(jù)創(chuàng)建的標(biāo)準(zhǔn)以及如何通過網(wǎng)絡(luò)進(jìn)行傳遞。Patrick McFadin認(rèn)為可以通過HTTP、MQTT和CoAP三種常用的標(biāo)準(zhǔn)協(xié)議傳遞數(shù)據(jù)。HTTP通用程度高,但是它的頭中包含大量冗余信息,不太適合帶寬比較低的場景。MQTT基于發(fā)布/訂閱模型,新的設(shè)備或者服務(wù)能夠非常容易地連到中央系統(tǒng)上消費消息。另外,它在消息大小上比HTTP更輕量,但是缺點是不包含加密標(biāo)準(zhǔn)。CoAP適合于低功耗、低帶寬的場景,與MQTT的訂閱模式相比它更側(cè)重于一對一的連接。
第二階段則需要根據(jù)設(shè)備、網(wǎng)絡(luò)以及功耗的限制決定是實時地收集數(shù)據(jù)還是在某個時間批量收集,同時還需要決定如何存儲數(shù)據(jù)。如果是實時收集,那么必須要考慮數(shù)據(jù)庫的寫入速度,這對于傳統(tǒng)的數(shù)據(jù)庫而言可能是一個挑戰(zhàn),但是像 Cassandra 這樣的NoSQL數(shù)據(jù)庫卻能夠輕松應(yīng)對。
一旦完成了數(shù)據(jù)的收集與存儲,接下來就是分析了,這才是整個過程最核心的部分。此時需要考慮需要何時使用分析結(jié)果,是否需要立即或近乎實時的分析,還是僅僅需要對歷史數(shù)據(jù)進(jìn)行處理。越來越多的人在使用Apache Spark分析大數(shù)據(jù),使用Spark Streaming滿足近乎實時的要求,如果將這些技術(shù)與Cassandra這樣的NoSQL數(shù)據(jù)庫結(jié)合在一起使用,那么開發(fā)者就能夠處理并分析大規(guī)模、快速移動的數(shù)據(jù)集。
那么是不是所有的物聯(lián)網(wǎng)廠商都需要自己去構(gòu)建相關(guān)的數(shù)據(jù)解決方案呢?也不盡然,在云計算的時代大可以利用云服務(wù)提供商的資源,以降低相關(guān)的成本,對小公司或初創(chuàng)公司更是如此。
Mike Kavis最近在自己的博文《 物聯(lián)網(wǎng)將徹底改變你的大數(shù)據(jù)策略 》中闡述了自己的方案,他認(rèn)為:
“在物聯(lián)網(wǎng)時代,面對PB級的數(shù)據(jù),企業(yè)將難以以一己之力完成基礎(chǔ)設(shè)施的建設(shè)。物聯(lián)網(wǎng)所產(chǎn)生的大量數(shù)據(jù)不僅會驅(qū)動現(xiàn)在的數(shù)據(jù)中心發(fā)生根本性的變化,同時也會驅(qū)動相關(guān)企業(yè)采用新的大數(shù)據(jù)策略。由于缺乏相關(guān)技能以及持續(xù)增長的數(shù)據(jù)對基礎(chǔ)設(shè)施采購的需求,企業(yè)將逐步放棄DIY模式,轉(zhuǎn)而使用PaaS和托管的解決方案,借助于數(shù)據(jù)庫即服務(wù)(例如Amazon的Redshift、Hortonworks和Cloudera的企業(yè)級Hadoop)、托管的大數(shù)據(jù)服務(wù)(例如Treasure Data)以及矩陣式的數(shù)據(jù)中心服務(wù)(例如GoGrid)實現(xiàn)自己的物聯(lián)網(wǎng)數(shù)據(jù)分析方案。
總之,物聯(lián)網(wǎng)的價值在于數(shù)據(jù)。企業(yè)對數(shù)據(jù)的分析工作啟動地越快,挖掘出的業(yè)務(wù)價值就越多。而云服務(wù)提供商的目的就是通過加大相關(guān)的投入,消除數(shù)據(jù)收集、管理的風(fēng)險以及復(fù)雜性,讓客戶能夠?qū)W⒂诜治?。?/p>
以上是小編為大家分享的關(guān)于物聯(lián)網(wǎng)時代的大數(shù)據(jù)策略的相關(guān)內(nèi)容,更多信息可以關(guān)注環(huán)球青藤分享更多干貨
什么是NoSQL數(shù)據(jù)庫?從名稱“非SQL”或“非關(guān)系型”衍生而來,這些數(shù)據(jù)庫不使用類似SQL的查詢語言,通常稱為結(jié)構(gòu)化存儲。這些數(shù)據(jù)庫自1960年就已經(jīng)存在,但是直到現(xiàn)在一些大公司(例如Google和Facebook)開始使用它們時,這些數(shù)據(jù)庫才流行起來。該數(shù)據(jù)庫最明顯的優(yōu)勢是擺脫了一組固定的列、連接和類似SQL的查詢語言的限制。有時,NoSQL這個名稱也可能表示“不僅僅SQL”,來確保它們可能支持SQL。 NoSQL數(shù)據(jù)庫使用諸如鍵值、寬列、圖形或文檔之類的數(shù)據(jù)結(jié)構(gòu),并且可以如JSON之類的不同格式存儲。
用于輸出指定的值:
s:property value="%{@cn.csdn.hr.domain.User@Name}"/br/
s:property value="@cn.csdn.hr.domain.User@Name"/Br/!-- 以上兩種方法都可以 --
s:property value="%{@cn.csdn.hr.domain.User@study()}"/
常見的理解及分析
目前流行的、對CAP理論解釋的情形是從同一數(shù)據(jù)在網(wǎng)絡(luò)環(huán)境中的多個副本出發(fā)的。為了保證數(shù)據(jù)不會丟失,在企業(yè)級的數(shù)據(jù)管理方案中,一般必須考慮數(shù)據(jù)的冗余存儲問題,而這應(yīng)該是通過在網(wǎng)絡(luò)上的其他獨立物理存儲節(jié)點上保留另一份、或多份數(shù)據(jù)副本來實現(xiàn)的(如附圖所示)。因為在同一個存儲節(jié)點上的數(shù)據(jù)冗余明顯不能解決單點故障問題,這與通過多節(jié)點集群來提供更好的計算可用性的道理是相同的。
附圖 CAP理論示意圖
其實,不用做嚴(yán)格的證明也可以想見,如附圖的情況,數(shù)據(jù)在節(jié)點A、B、C上保留了三份,如果對節(jié)點A上的數(shù)據(jù)進(jìn)行了修改,然后再讓客戶端通過網(wǎng)絡(luò)對該數(shù)據(jù)進(jìn)行讀取。那么,客戶端的讀取操作什么時候返回呢?
有這樣兩種情況:一種情況是要求節(jié)點A、B、C的三份數(shù)據(jù)完全一致后返回。也就是說,這時從任何一個網(wǎng)絡(luò)節(jié)點讀取的數(shù)據(jù)都是一樣的,這就是所謂的強(qiáng)一致性讀。很明顯,這時數(shù)據(jù)讀取的Latency要高一些(因為要等數(shù)據(jù)在網(wǎng)絡(luò)中的復(fù)制),同時A、B、C三個節(jié)點中任何一個宕機(jī),都會導(dǎo)致數(shù)據(jù)不可用。也就是說,要保證強(qiáng)一致性,網(wǎng)絡(luò)中的副本越多,數(shù)據(jù)的可用性就越差;
另一種情況是,允許讀操作立即返回,容忍B節(jié)點的讀取與A節(jié)點的讀取不一致的情況發(fā)生。這樣一來,可用性顯然得到了提高,網(wǎng)絡(luò)中的副本也可以多一些,唯一得不到保證的是數(shù)據(jù)一致性。當(dāng)然,對寫操作同樣也有多個節(jié)點一致性的情況,在此不再贅述。
可以看出,上述對CAP理論的解釋主要是從網(wǎng)絡(luò)上多個節(jié)點之間的讀寫一致性出發(fā)考慮問題的。而這一點,對于關(guān)系型數(shù)據(jù)庫意味著什么呢?當(dāng)然主要是指通常所說的Standby(關(guān)于分布式事務(wù),涉及到更多考慮,隨后討論)情況。對此,在實踐中我們大多已經(jīng)采取了弱一致性的異步延時同步方案,以提高可用性。這種情況并不存在關(guān)系型數(shù)據(jù)庫為保證C、A而放棄P的情況;而對海量數(shù)據(jù)管理的需求,關(guān)系型數(shù)據(jù)庫擴(kuò)展過程中所遇到的性能瓶頸,似乎也并不是CAP理論中所描述的那種原因造成的。那么,上述流行的說法中所描述的關(guān)系型數(shù)據(jù)庫為保證C、A而犧牲P到底是在指什么呢?
因此,如果根據(jù)現(xiàn)有的大多數(shù)資料對CAP理論的如上解釋,即只將其當(dāng)作分布式系統(tǒng)中多個數(shù)據(jù)副本之間的讀寫一致性問題的通用理論對待,那么就可以得出結(jié)論:CAP既適用于NoSQL數(shù)據(jù)庫,也適用于關(guān)系型數(shù)據(jù)庫。它是NoSQL數(shù)據(jù)庫、關(guān)系型數(shù)據(jù)庫,乃至一切分布式系統(tǒng)在設(shè)計數(shù)據(jù)多個副本之間讀寫一致性問題時需要遵循的共同原則。
更深入的探究:兩種重要的分布式場景
在本文中我們要說的重點與核心是:關(guān)于對CAP理論中一致性C的理解,除了上述數(shù)據(jù)副本之間的讀寫一致性以外,分布式環(huán)境中還有兩種非常重要的場景,如果不對它們進(jìn)行認(rèn)識與討論,就永遠(yuǎn)無法全面地理解CAP,當(dāng)然也就無法根據(jù)CAP做出正確的解釋。但可惜的是,目前為止卻很少有人提及這兩種場景:那就是事務(wù)與關(guān)聯(lián)。
先來看看分布式環(huán)境中的事務(wù)場景。我們知道,在關(guān)系型數(shù)據(jù)庫的事務(wù)操作遵循ACID原則,其中的一致性C,主要是指一個事務(wù)中相關(guān)聯(lián)的數(shù)據(jù)在事務(wù)操作結(jié)束后是一致的。所謂ACID原則,是指在寫入/異動資料的過程中,為保證交易正確可靠所必須具備的四個特性:即原子性(Atomicity,或稱不可分割性)、一致性(Consistency)、隔離性(Isolation,又稱獨立性)和持久性(Durability)。
例如銀行的一個存款交易事務(wù),將導(dǎo)致交易流水表增加一條記錄。同時,必須導(dǎo)致賬戶表余額發(fā)生變化,這兩個操作必須是一個事務(wù)中全部完成,保證相關(guān)數(shù)據(jù)的一致性。而前文解釋的CAP理論中的C是指對一個數(shù)據(jù)多個備份的讀寫一致性。表面上看,這兩者不是一回事,但實際上,卻是本質(zhì)基本相同的事物:數(shù)據(jù)請求會等待多個相關(guān)數(shù)據(jù)操作全部完成才返回。對分布式系統(tǒng)來講,這就是我們通常所說的分布式事務(wù)問題。
眾所周知,分布式事務(wù)一般采用兩階段提交策略來實現(xiàn),這是一個非常耗時的復(fù)雜過程,會嚴(yán)重影響系統(tǒng)效率,在實踐中我們盡量避免使用它。在實踐過程中,如果我們?yōu)榱藬U(kuò)展數(shù)據(jù)容量將數(shù)據(jù)分布式存儲,而事務(wù)的要求又完全不能降低。那么,系統(tǒng)的可用性一定會大大降低,在現(xiàn)實中我們一般都采用對這些數(shù)據(jù)不分散存儲的策略。
當(dāng)然,我們也可以說,最常使用的關(guān)系型數(shù)據(jù)庫,因為這個原因,擴(kuò)展性(分區(qū)可容忍性P)受到了限制,這是完全符合CAP理論的。但同時我們應(yīng)該意識到,這對NoSQL數(shù)據(jù)庫也是一樣的。如果NoSQL數(shù)據(jù)庫也要求嚴(yán)格的分布式事務(wù)功能,情況并不會比關(guān)系型數(shù)據(jù)庫好多少。只是在NoSQL的設(shè)計中,我們往往會弱化甚至去除事務(wù)的功能,該問題才表現(xiàn)得不那么明顯而已。
因此,在擴(kuò)展性問題上,如果要說關(guān)系型數(shù)據(jù)庫是為了保證C、A而犧牲P,在盡量避免分布式事務(wù)這一點上來看,應(yīng)該是正確的。也就是說:關(guān)系型數(shù)據(jù)庫應(yīng)該具有強(qiáng)大的事務(wù)功能,如果分區(qū)擴(kuò)展,可用性就會降低;而NoSQL數(shù)據(jù)庫干脆弱化甚至去除了事務(wù)功能,因此,分區(qū)的可擴(kuò)展性就大大增加了。
再來看看分布式環(huán)境中的關(guān)聯(lián)場景。初看起來,關(guān)系型數(shù)據(jù)庫中常用的多表關(guān)聯(lián)操作與CAP理論就更加不沾邊了。但仔細(xì)考慮,也可以用它來解釋數(shù)據(jù)庫分區(qū)擴(kuò)展對關(guān)聯(lián)所帶來的影響。對一個數(shù)據(jù)庫來講,采用了分區(qū)擴(kuò)展策略來擴(kuò)充容量,數(shù)據(jù)分散存儲了,很顯然多表關(guān)聯(lián)的性能就會下降,因為我們必須在網(wǎng)絡(luò)上進(jìn)行大量的數(shù)據(jù)遷移操作,這與CAP理論中數(shù)據(jù)副本之間的同步操作本質(zhì)上也是相同的。
因此,如果要保證系統(tǒng)的高可用性,需要同時實現(xiàn)強(qiáng)大的多表關(guān)系操作的關(guān)系型數(shù)據(jù)庫在分區(qū)可擴(kuò)展性上就遇到了極大的限制(即使是那些采用了各種優(yōu)秀解決方案的MPP架構(gòu)的關(guān)系型數(shù)據(jù)庫,如TeraData,Netezza等,其水平可擴(kuò)展性也是遠(yuǎn)遠(yuǎn)不如NoSQL數(shù)據(jù)庫的),而NoSQL數(shù)據(jù)庫則干脆在設(shè)計上弱化甚至去除了多表關(guān)聯(lián)操作。那么,從這一點上來理解“NoSQL數(shù)據(jù)庫是為了保證A與P,而犧牲C”的說法,也是可以講得通的。當(dāng)然,我們應(yīng)該理解,關(guān)聯(lián)問題在很多情況下不是并行處理的優(yōu)點所在,這在很大程度上與Amdahl定律相符合。
所以,從事務(wù)與關(guān)聯(lián)的角度來關(guān)系型數(shù)據(jù)庫的分區(qū)可擴(kuò)展性為什么受限的原因是最為清楚的。而NoSQL數(shù)據(jù)庫也正是因為弱化,甚至去除了像事務(wù)與關(guān)聯(lián)(全面地講,其實還有索引等特性)等在分布式環(huán)境中會嚴(yán)重影響系統(tǒng)可用性的功能,才獲得了更好的水平可擴(kuò)展性。
那么,如果將事務(wù)與關(guān)聯(lián)也納入CAP理論中一致性C的范疇的話,問題就很清楚了:關(guān)于“關(guān)系型數(shù)據(jù)庫為了保證一致性C與可用性A,而不得不犧牲分區(qū)可容忍性P”的說法便是正確的了。但關(guān)于“NoSQL選擇了C與P,或者A與P”的說法則是錯誤的,所有的NoSQL數(shù)據(jù)庫在設(shè)計策略的大方向上都是選擇了A與P(雖然對同一數(shù)據(jù)多個副本的讀寫一致性問題的設(shè)計各有不同),從來沒有完全選擇C與P的情況存在。
結(jié)論
現(xiàn)在看來,如果理解CAP理論只是指多個數(shù)據(jù)副本之間讀寫一致性的問題,那么它對關(guān)系型數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫來講是完全一樣的,它只是運行在分布式環(huán)境中的數(shù)據(jù)管理設(shè)施在設(shè)計讀寫一致性問題時需要遵循的一個原則而已,卻并不是NoSQL數(shù)據(jù)庫具有優(yōu)秀的水平可擴(kuò)展性的真正原因。而如果將CAP理論中的一致性C理解為讀寫一致性、事務(wù)與關(guān)聯(lián)操作的綜合,則可以認(rèn)為關(guān)系型數(shù)據(jù)庫選擇了C與A,而NoSQL數(shù)據(jù)庫則全都是選擇了A與P,但并沒有選擇C與P的情況存在。這才是用CAP理論來支持NoSQL數(shù)據(jù)庫設(shè)計正確認(rèn)識。
其實,這種認(rèn)識正好與被廣泛認(rèn)同的NoSQL的另一個理論基礎(chǔ)相吻合,即與ACID對著干的BASE(基本可用性、軟狀態(tài)與最終一致性)。因為BASE的含義正好是指“NoSQL數(shù)據(jù)庫設(shè)計可以通過犧牲一定的數(shù)據(jù)一致性和容錯性來換取高性能的保持甚至提高”,即NoSQL數(shù)據(jù)庫都應(yīng)該是犧牲C來換取P,而不是犧牲A。可用性A正好是所有NoSQL數(shù)據(jù)庫都普遍追求的特性。
網(wǎng)站欄目:nosql含義,nosql的含義
文章網(wǎng)址:http://chinadenli.net/article28/hdoojp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)頁設(shè)計公司、動態(tài)網(wǎng)站、軟件開發(fā)、網(wǎng)站制作、網(wǎng)站排名、搜索引擎優(yōu)化
聲明:本網(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)