MongoDB設(shè)計(jì)命名規(guī)范有哪些，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

目前創(chuàng)新互聯(lián)已為近1000家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機(jī)、網(wǎng)站托管運(yùn)營、企業(yè)網(wǎng)站設(shè)計(jì)、白云網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

1.       庫

1.       庫名全部小寫，禁止使用任何`_`以外的特殊字符，禁止使用數(shù)字打頭的庫名，如：`123_abc`；

2.       庫以文件夾的形式存在，使用特殊字符或其它不規(guī)范的命名方式會(huì)導(dǎo)致命名混亂；

3.       數(shù)據(jù)庫名最多為64字符；

4.       在創(chuàng)建新的庫前應(yīng)盡量評(píng)估該庫的體積、QPS等，提前與DBA討論是應(yīng)該新建一個(gè)庫還是專門為該庫創(chuàng)建一個(gè)新的集群;

某開發(fā)在拿到DBA提供的MongoDB后由于MongoDB的權(quán)限控制比較寬松,導(dǎo)致該業(yè)務(wù)的開發(fā)在創(chuàng)建集合的時(shí)候懶得與DBA討論,而是隨意的將所有集合都創(chuàng)建在一個(gè)庫中,最初并沒有什么問題,因?yàn)闃I(yè)務(wù)的請(qǐng)求量并不大。半年后,該業(yè)務(wù)增長(zhǎng)到了一個(gè)比較大的量級(jí),而此時(shí)開發(fā)人員上線了一個(gè)新的項(xiàng)目,該項(xiàng)目的寫入量很大,大部分都為批量更新,由于所有集合都存放在一個(gè)庫中,這個(gè)新項(xiàng)目的批量更新帶來了頻繁的鎖、I/O平均等。最后開發(fā)配合DBA一起將該庫拆散到了多個(gè)新的庫中,將一庫N集合轉(zhuǎn)換為單庫單集合,性能問題迎刃而解。

2.       集合

1.       集合名全部小寫，禁止使用任何`_`以外的特殊字符，禁止使用數(shù)字打頭的集合名，如：`123_abc`，禁止system打頭; system是系統(tǒng)集合前綴；

2.       集合名稱最多為64字符；

3.       一個(gè)庫中寫入較大的集合會(huì)影響其它集合的讀寫性能，如果業(yè)務(wù)比較繁華的集合在一個(gè)DB中，建議最多80個(gè)集合，同時(shí)也要考慮磁盤I/O的性能；

4.       如果評(píng)估單集合數(shù)據(jù)量較大，可以將一個(gè)大表拆分為多個(gè)小表，然后將每一個(gè)小表存放在獨(dú)立的庫中或者sharding分表；

5.       MongoDB的集合擁有“自動(dòng)清理過期數(shù)據(jù)”的功能，只需在該集合中文檔的時(shí)間字段增加一個(gè)TTL索引即可實(shí)現(xiàn)該功能，但需要注意的是該字段的類型則必須是mongoDate()，一定要結(jié)合實(shí)際業(yè)務(wù)設(shè)計(jì)是否需要；

6.       設(shè)計(jì)輪詢集合---集合是否設(shè)計(jì)為Capped限制集，一定要結(jié)合實(shí)際業(yè)務(wù)設(shè)計(jì)是否需要；

7.       創(chuàng)建集合規(guī)則

不同的業(yè)務(wù)場(chǎng)景是可以配置進(jìn)行不同的配置;

a.       如果是讀多寫少的表在創(chuàng)建時(shí)我們可以盡量將 page size 設(shè)置的比較小，比如 16KB，如果表數(shù)據(jù)量不太大(

"internal_page_max=16KB，leaf_page_max=16KB，leaf_value_max=8KB，os_cache_max=1GB"

b.       如果這個(gè)讀多寫少的表數(shù)據(jù)量比較大，可以為其設(shè)置一個(gè)壓縮算法，例如：

"block_compressor=zlib，internal_page_max=16KB，leaf_page_max=16KB，leaf_value_max=8KB"

c.       注意：該zlib壓縮算法不要使用，對(duì)cpu消耗特別大，如果使用snapp消耗20% cpu，而且使用zlib能消耗90%cpu，甚至100%

d.       如果是寫多讀少的表，可以將 leaf_page_max 設(shè)置到 1MB，并開啟壓縮算法，也可以為其制定操作系統(tǒng)層面 page cache 大小的os_cache_max 值，讓它不會(huì)占用太多的 page cache 內(nèi)存，防止影響讀操作；

e.       案例

db.createCollection(

   "logs",

   { storageEngine: { wiredTiger: {configString: "internal_page_max=16KB,leaf_page_max=16KB,leaf_value_max=8KB,os_cache_max=1GB" } } }

)

f.       說明

讀多寫少的表

internal_page_max=16KB   默認(rèn)為4KB

leaf_page_max=16KB       默認(rèn)為32KB

leaf_value_max=8KB       默認(rèn)為64MB

os_cache_max=1GB         默認(rèn)為0

讀多寫少的表  而且數(shù)據(jù)量比較大

block_compressor=zlib    默認(rèn)為snappy

internal_page_max=16KB   默認(rèn)為4KB

leaf_page_max=16KB       默認(rèn)為32KB

leaf_value_max=8KB       默認(rèn)為64MB

3.       文檔

1.       文檔中的key禁止使用任何`_`以外的特殊字符；

2.       盡量將同樣類型的文檔存放在一個(gè)集合中，將不同類型的文檔分散在不同的集合中；相同類型的文檔能夠大幅度提高索引利用率，如果文檔混雜存放則可能會(huì)出現(xiàn)查詢經(jīng)常需要全表掃描的情況；

3.       禁止使用_id，如：向_id中寫入自定義內(nèi)容；

某業(yè)務(wù)的MongoDB在放量后出現(xiàn)嚴(yán)重的寫入性能問題,大致為:寫入達(dá)到300/s的時(shí)候IO跑滿,排查中發(fā)現(xiàn),該業(yè)務(wù)在設(shè)計(jì)的時(shí)候?yàn)榱朔奖? 而將_id中寫入了無序的類似md5的數(shù)據(jù)。MongoDB的表與InnoDB相似,都是索引組織表,數(shù)據(jù)內(nèi)容跟在主鍵后,而_id是MongoDB中的默認(rèn)主鍵,一旦_id的值為非自增,當(dāng)數(shù)據(jù)量達(dá)到一定程度之后,每一次寫入都可能導(dǎo)致主鍵的二叉樹大幅度調(diào)整,這將是一個(gè)代價(jià)極大的寫入, 所以寫入就會(huì)隨著數(shù)據(jù)量的增大而下降,所以一定不要在_id中寫入自定義的內(nèi)容。

4.       盡量不要讓數(shù)組字段成為查詢條件

某業(yè)務(wù)在一個(gè)表的數(shù)組字段上創(chuàng)建了一個(gè)索引,創(chuàng)建完畢之后發(fā)現(xiàn)表體積增大了很多很多,排查發(fā)現(xiàn)是由于索引體積的大幅度增大導(dǎo)致在MongoDB中,如果為一個(gè)數(shù)組字段添加索引,那么MongoDB會(huì)主動(dòng)為這個(gè)數(shù)組中的所有元素依次添加獨(dú)立索引,例如: 為數(shù)組字段{a:[x,y,z]}添加索引{a:1},實(shí)際上添加的索引為:

{a:[x:1]}

{a:[y:1]}

{a:[z:1]}

該業(yè)務(wù)的數(shù)組字段中有11個(gè)元素,那么等于一次創(chuàng)建了11條索引,這是索引體積大幅度增大的根本原因。另外,如果組合索引中存在數(shù)組字段,那么MongoDB會(huì)為每一個(gè)元素與其它字段的組合創(chuàng)建一個(gè)獨(dú)立的索引,例如: 為數(shù)組字段{a:[x,y,z]}和{b:qqq}添加索引{a:1,b:1},實(shí)際上添加的索引為:

{a:[x:1],b:1}

{a:[y:1],b:1}

{a:[z:1],b:1}

如果一個(gè)組合索引中存在兩個(gè)數(shù)組字段,那么索引的數(shù)量將是兩個(gè)數(shù)組字段中元素的笛卡兒積,所以MongoDB不允許索引中存在一個(gè)以上的數(shù)組字段。

5.       如果字段較大，應(yīng)盡量壓縮存放

某業(yè)務(wù)上線后一直很正常,但在放量3倍之后發(fā)現(xiàn)MongoDB服務(wù)器的網(wǎng)卡流量報(bào)警,IO壓力報(bào)警,排查中發(fā)現(xiàn),該業(yè)務(wù)講一個(gè)超長(zhǎng)的文本字段存放在MongoDB中,而這個(gè)字段的平均體積達(dá)到了7K。在并發(fā)為2000QPS的場(chǎng)景下,每次取出1~20條數(shù)據(jù),導(dǎo)致這個(gè)MongoDB每秒鐘要發(fā)送將近100MB的數(shù)據(jù),而對(duì)于數(shù)據(jù)庫而言,讀寫均為隨機(jī)IO,所以在如此大的數(shù)據(jù)吞吐場(chǎng)景中,IO達(dá)到了報(bào)警閾值。

由于文本是一個(gè)容易壓縮的樣本, 所以我們對(duì)該字段進(jìn)行了壓縮存放,使其平均體積降低到了2K,而解壓在業(yè)務(wù)端進(jìn)行處理,最終將吞吐降低到了20MB/S左右。

如果字段較大且會(huì)成為查詢條件，例如一長(zhǎng)串的url，盡量轉(zhuǎn)成md5后存放

某業(yè)務(wù)上線前進(jìn)行壓力測(cè)試,測(cè)試中發(fā)現(xiàn)某個(gè)場(chǎng)景下的查詢性能不夠理想,排查中發(fā)現(xiàn)該場(chǎng)景的查詢條件類似:{url:xxxx},而url字段中的值大部分都很長(zhǎng)很長(zhǎng),該字段的平均體積達(dá)到了0.5K,在這種情況下索引的體積會(huì)變得很大從而導(dǎo)致雖然請(qǐng)求雖然能夠走索引但效率并不夠理想,于是dba配合業(yè)務(wù)開發(fā)一起對(duì)該場(chǎng)景進(jìn)行優(yōu)化:

1.將該字段的存放的內(nèi)容由真實(shí)的url改為url內(nèi)容md5后的值,字段體積得到了大幅度縮小,固定在了32位

2.查詢時(shí),用戶請(qǐng)求通過url查詢,而此時(shí)程序會(huì)將該url進(jìn)行md5,然后用得到的值進(jìn)行查詢,由于所以體積大幅度縮小,所以查詢速度有了極大的提高,優(yōu)化完畢后再次進(jìn)行壓力測(cè)試,性能達(dá)標(biāo),為之前的6倍。

6.       由于MongoDB是大小寫敏感的，如果字段無需大小寫敏感，為了提高查詢效率應(yīng)盡量存放統(tǒng)一了大小寫后的數(shù)據(jù)，如：全部小寫或?yàn)樵撟侄卧黾右粋€(gè)統(tǒng)一了大小寫的輔助字段；

某業(yè)務(wù)需要根據(jù)字段{a:XxX}來進(jìn)行查詢,在MongoDB中a的值是大小寫敏感的,并且無法配置為忽略大小寫,但該業(yè)務(wù)場(chǎng)景為了滿足查詢需求而需要忽略大小寫,這個(gè)大小寫敏感與否的矛盾導(dǎo)致業(yè)務(wù)需要使用正則來進(jìn)行匹配:{a:/xxx/i},i參數(shù)在正則中表示忽略大小寫,上線后發(fā)現(xiàn), 查詢性能非常低下,在一個(gè)擁有200萬文檔的集合中一次查詢需要消耗2.8~7秒,并發(fā)達(dá)到50QPS的時(shí)候MongoDB實(shí)例所在服務(wù)器的CPU就跑到了973%。

MongoDB在查詢條件中使用正則的時(shí)候,能夠像普通精確匹配一樣使用索引達(dá)到高效率的查詢,但一旦使用了參數(shù)i來忽略大小寫查詢優(yōu)化器就需要對(duì)每一個(gè)數(shù)據(jù)的大小寫進(jìn)行調(diào)整然后再進(jìn)行匹配,此時(shí)這個(gè)請(qǐng)求就變成了全表掃描,這就是效率低下的根本原因。

對(duì)于這種場(chǎng)景可以采用新建一個(gè)統(tǒng)一了大小的字段,例如全部小寫:假設(shè)原字段為:{a:aAbB},那么為其添加一個(gè)全部為小寫的對(duì)應(yīng)字段:{a_low:aabb}然后通過字段a_low進(jìn)行查詢就能達(dá)到精確匹配,按照該方案改進(jìn)后,該場(chǎng)景的查詢耗時(shí)降低到了2毫秒雖然新增字段導(dǎo)致實(shí)例會(huì)變大一些,但對(duì)于換來性能的大幅度提升還是非常值得的。

7.       不要存放太長(zhǎng)的字符串，如果這個(gè)字段為查詢條件，那么確保該字段的值不超過1KB；

8.       MongoDB的索引僅支持1K以內(nèi)的字段，如果你存入的數(shù)據(jù)長(zhǎng)度超過1K，那么它將無法被索引；

4.       索引

1.       MongoDB 的組合索引使用策略與 MySQL 一致，遵循“最左原則”;

2.       索引名稱長(zhǎng)度不要超過128字符;

3.       應(yīng)盡量綜合評(píng)估查詢場(chǎng)景,通過評(píng)估盡可能的將單列索引并入組合索引以降低所以數(shù)量，結(jié)合1，2點(diǎn);

MongoDB的組合索引規(guī)則和MySQL一樣,都遵循最左原理,假設(shè)一個(gè)組合索引為:{a:1,b:1,c:1},那么以下條件的查詢是可以被用到的:

{a:1}

{a:1,b:2}

{a:1,b:2,c:3}

{}

以下條件的查詢是不能用到索引的:

{b:1}

{b:1:c:2}

{c:2}

另外在設(shè)計(jì)索引的時(shí)候可以通過該原理減少索引的數(shù)目,如果需要通過{a:xxx}或{a:xxx,b:xxx}來進(jìn)行查詢,那么創(chuàng)建索引:

{a:1,b:1}

即可同時(shí)滿足這兩個(gè)查詢場(chǎng)景而無需再單獨(dú)創(chuàng)建{a:1}索引。

4.       在創(chuàng)建組合索引的時(shí)候，應(yīng)評(píng)估索引中包含的字段，盡量將數(shù)據(jù)基數(shù)大(唯一值多的數(shù)據(jù))的字段放在組合索引的前面；

某業(yè)務(wù)某場(chǎng)景下的查詢十分緩慢,大概需要1.7秒左右,需要進(jìn)行調(diào)優(yōu),該場(chǎng)景的查詢和對(duì)應(yīng)索引如下:

查詢:{name:baidu,status:0}

索引:{status:1,name:1}

乍一看沒什么問題,因?yàn)椴樵兒退饕制ヅ?但對(duì)該集合分析后發(fā)現(xiàn)該集合一共有150萬文檔,而status=0的有1499930由于這基本上占了99%的文檔數(shù)目(數(shù)據(jù)基數(shù)很小),所以導(dǎo)致雖然使用了索引,但依然需要從149萬行數(shù)據(jù)中找到name=baidu的數(shù)據(jù)但name字段則有大量不同的數(shù)據(jù)(數(shù)據(jù)基數(shù)很大),所以如果將該組合索引調(diào)整為name在前,該查詢即可先通過name字段抽出較少的數(shù)據(jù),再通過status進(jìn)行過濾,就快了:

{name:1.status:1}調(diào)整后查詢耗時(shí)降低到3~5毫秒。

5.       在數(shù)據(jù)量較大的時(shí)候，MongoDB 索引的創(chuàng)建是一個(gè)緩慢的過程，所以應(yīng)當(dāng)在上前線或數(shù)據(jù)量變得很大前盡量評(píng)估，按需創(chuàng)建會(huì)用到的索引；

6.       MongoDB 支持 TTL 索引，該索引能夠按你的需要自動(dòng)刪除XXX秒之前的數(shù)據(jù)并會(huì)盡量選擇在業(yè)務(wù)低峰期執(zhí)行刪除操作；看業(yè)務(wù)是否需要這一類型索引；

7.       如果你存放的數(shù)據(jù)是地理位置信息，比如：經(jīng)緯度數(shù)據(jù)。那么可以在該字段上添加 MongoDB 支持的地理索引：2d 及2dsphere，但他們是不同的，混用會(huì)導(dǎo)致結(jié)果不準(zhǔn)確；

2d：只能用于點(diǎn)對(duì)點(diǎn)索引，適用于平面地圖和時(shí)間連續(xù)的數(shù)據(jù)，比如非常適用于游戲地圖【2dsphere：允許指定點(diǎn)、線和多邊形。適用于地球表面類型的地圖(球體) 】如果在球體表面創(chuàng)建2d索引，則會(huì)導(dǎo)致極點(diǎn)附近出現(xiàn)大量扭曲變形，最終導(dǎo)致結(jié)果不準(zhǔn)確；

8.       MongoDB 的全文索引目前仍然處于“實(shí)驗(yàn)”階段，性能并不夠理想，當(dāng)前不建議使用；

9.       從 MongoDB2.4開始，支持索引的 ICP 功能，可以通過其合理減少索引數(shù)量；

從 MongoDB2.4開始，組合索引能夠被更有效的利用，如：

索引{x:1,y:1,z:1}可以被查詢{x:1,z:1}所利用如果x字段的數(shù)據(jù)基數(shù)很大，而該條件匹配到的數(shù)據(jù)有很少，在這種情況下無需專門添加{x:1,z:1}索引，索引{x:1,y:1,z:1}即可帶來理想的性能但需要注意的是，ICP 性能并沒有原生的連續(xù)的組合索引效率好，如果發(fā)現(xiàn)效率不佳那么還是需要添加單獨(dú)的{x:1,z:1}索引；

10.   創(chuàng)建索引要在后臺(tái)創(chuàng)建，避免阻塞業(yè)務(wù)正常DML和查詢

db.works.createIndex({plan:1,trainingpoints:1,cmsOrder:1,stateValue:1},{background:true})

a.       添加唯一索引

db.bodys.createIndex({user:1,date:-1},{unique:true,background:true}) 唯一索引  3.2以下必須這樣加唯一索引；

b.       添加帶有數(shù)組好其他列的索引

db.antis.createIndex({"action.last":1,refe_type:1,_id:1},{background:true})

其中action.last是數(shù)組

c.       TTL索引，字段create_date，180天后自動(dòng)清理數(shù)據(jù)

db.orders.createIndex({"create_date":1},{"expireAfterSeconds":15552000})

d.       案例說明

創(chuàng)建位置和狀態(tài)索引，為了能快速處理“某地未處理訂單”查詢，這是一個(gè)多條件的查詢，所以是一個(gè)復(fù)合索引，

status字段放在前面，因?yàn)槎鄶?shù)的查詢都會(huì)依賴狀態(tài)字段

db.order.createIndex({"status":1, "delivery.city":1,"delivery.address":1})

在這個(gè)Demo里，還有一種加快查詢速度的方法就是，創(chuàng)建一個(gè)只包含指定狀態(tài)的一個(gè)Partial Indexes索引。

比如status必須為delivering 才加入到索引中，有效控制索引的大小，加快查詢速度。

db.order.createIndex({"delivery.city":1,"delivery.address":1},{partialFilterExpression:{'status':{$eq:"delivering"}}})

e.        

11.   創(chuàng)建索引建議：先做等值查詢，在做排序，在做范圍查詢。

5.       實(shí)踐操作性能

1.       索引中的-1和1是不一樣的，一個(gè)是逆序，一個(gè)是正序，應(yīng)當(dāng)根據(jù)自己的業(yè)務(wù)場(chǎng)景建立適合的索引排序，需要注意的是{a:1,b:-1} 和 {a:-1,b:1}是一樣的；

2.       在開發(fā)業(yè)務(wù)的時(shí)候盡量檢查自己的程序性能,可以使用explain() 函數(shù)檢查你的查詢執(zhí)行詳情，另外 hint() 函數(shù)相當(dāng)于 MySQL 中的force index()；

3.       查詢中的某些 $ 操作符可能會(huì)導(dǎo)致性能低下，如 $ne，$not，$exists，$nin，$or，盡量在業(yè)務(wù)中不要使用

a.       $exist：因?yàn)樗缮⒌奈臋n結(jié)構(gòu)導(dǎo)致查詢必須遍歷每一個(gè)文檔

b.       $ne：如果當(dāng)取反的值為大多數(shù)，則會(huì)掃描整個(gè)索引

c.       $not：可能會(huì)導(dǎo)致查詢優(yōu)化器不知道應(yīng)當(dāng)使用哪個(gè)索引，所以會(huì)經(jīng)常退化為全表掃描

d.       $nin：全表掃描

e.       $or：有多少個(gè)條件就會(huì)查詢多少次，最后合并結(jié)果集，所以盡可能的使用 $in

4.       如果你結(jié)合體積大小/文檔數(shù)固定，那么建議創(chuàng)建 capped（封頂）集合，這種集合的寫入性能非常高并無需專門清理老舊數(shù)據(jù)，需要注意的是 capped 表不支持r emove() 和update()；

5.       在寫入數(shù)據(jù)的時(shí)候，如果你需要實(shí)現(xiàn)類似 MySQL 中INSERT INTO ON DUPLICATE KEY UPDATE 的功能，那么可以選擇 upsert() 函數(shù)；

db.analytice.update(

{"url":"/blog"},

{"$inc":{"visits":1}},

true

)

第3個(gè)參數(shù)表示，這是upsert

6.       不要一次取出太多的數(shù)據(jù)進(jìn)行排序，MongoDB 目前支持對(duì)32MB以內(nèi)的結(jié)果集進(jìn)行排序，如果需要排序，那么請(qǐng)盡量限制結(jié)果集中的數(shù)據(jù)量；

7.       MongoDB 的聚合框架非常好用，能夠通過簡(jiǎn)單的語法實(shí)現(xiàn)復(fù)雜的統(tǒng)計(jì)查詢，并且性能也不錯(cuò)；

8.       如果需要清理掉一個(gè)集合中的所有數(shù)據(jù)，那么 remove() 的性能是非常低下的，該場(chǎng)景下應(yīng)當(dāng)使用 drop()；

remove() 是逐行操作，所以在刪除大量數(shù)據(jù)的時(shí)候性能很差；

9.       寫入大量數(shù)據(jù)的時(shí)候可以選擇使用 batchInsert，但目前MongoDB 每一次能夠接受的最大消息長(zhǎng)度為48MB，如果超出48MB，將會(huì)被自動(dòng)拆分為多個(gè)48MB的消息;

10.   在使用數(shù)組字段做為查詢條件的時(shí)候，將于覆蓋索引無緣;

這是因?yàn)閿?shù)組是保存在索引中的，即便將數(shù)組字段從需要返回的字段中剔除，這樣的索引仍然無法覆蓋查詢；

11.   在查詢中如果有范圍條件,那么盡量和定值條件放在一起進(jìn)行過濾,并在創(chuàng)建索引的時(shí)候?qū)⒍ㄖ挡樵冏侄畏旁诜秶樵冏侄吻?

關(guān)于MongoDB設(shè)計(jì)命名規(guī)范有哪些問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

新聞名稱：MongoDB設(shè)計(jì)命名規(guī)范有哪些
分享地址：http://chinadenli.net/article16/ihiigg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、微信小程序、營銷型網(wǎng)站建設(shè)、搜索引擎優(yōu)化、軟件開發(fā)、定制開發(fā)

廣告

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