自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

過了這么久,我終于看懂了HBase,太不容易了QAQ

大數(shù)據(jù)
在我還不了解分布式和大數(shù)據(jù)的時(shí)候已經(jīng)聽說過HBase了,但對它一直都半知不解,這篇文章來講講吧。

 [[329164]]

前言

在我還不了解分布式和大數(shù)據(jù)的時(shí)候已經(jīng)聽說過HBase了,但對它一直都半知不解,這篇文章來講講吧。

在真實(shí)生活中,最開始聽到這個(gè)詞是我的一場面試,當(dāng)年我還是個(gè)『小垃圾』,現(xiàn)在已經(jīng)是個(gè)『大垃圾』了。

面試官當(dāng)時(shí)給了一個(gè)場景題問我,具體的題目我忘得差不多了,大概就是考試與試題的一個(gè)場景,問我數(shù)據(jù)庫要如何設(shè)計(jì)。

我答了關(guān)系型數(shù)據(jù)庫的設(shè)計(jì)方案,他大概說:這個(gè)場景比較復(fù)雜多變,為什么不考慮一下HBase這種NoSQL的數(shù)據(jù)庫來存儲呢?

我就說:“對對對,可以的” (雖然我當(dāng)時(shí)不知道HBase是什么,但是氣勢一定要有,你們說是不是)

 

最后面試官還是給我發(fā)了offer,但我沒去,原因就是離家太遠(yuǎn)了。

一、介紹HBase

Apache HBase™ is the Hadoop database, a distributed, scalable, big data store.

HBase is a type of "NoSQL" database.

Apache HBase 是 Hadoop 數(shù)據(jù)庫,一個(gè)分布式、可伸縮的大數(shù)據(jù)存儲。

HBase是依賴Hadoop的。為什么HBase能存儲海量的數(shù)據(jù)?因?yàn)镠Base是在HDFS的基礎(chǔ)之上構(gòu)建的,HDFS是分布式文件系統(tǒng)。

二、為什么要用HBase

截至到現(xiàn)在,我已經(jīng)學(xué)了不少的組件了,比如說分布式搜索引擎「Elasticsearch」、分布式文件系統(tǒng)「HDFS」、分布式消息隊(duì)列「Kafka」、緩存數(shù)據(jù)庫「Redis」等等...

能夠處理數(shù)據(jù)的中間件(系統(tǒng)),這些中間件基本都會有持久化的功能。為什么?如果某一個(gè)時(shí)刻掛了,那還在內(nèi)存但還沒處理完的數(shù)據(jù)不就涼了?

Redis有AOF和RDB、Elasticsearch會把數(shù)據(jù)寫到translog然后結(jié)合FileSystemCache將數(shù)據(jù)刷到磁盤中、Kafka本身就是將數(shù)據(jù)順序?qū)懙酱疟P....

這些中間件會實(shí)現(xiàn)持久化(像HDFS和MySQL我們本身就用來存儲數(shù)據(jù)的),為什么我們還要用HBase呢?

雖然沒有什么可比性,但是在學(xué)習(xí)的時(shí)候總會有一個(gè)疑問:「既然已學(xué)過的系統(tǒng)都有類似的功能了,那為啥我還要去學(xué)這個(gè)玩意?」

我是這樣理解的:

  • MySQL?MySQL數(shù)據(jù)庫我們是算用得最多了的吧?但眾所周知,MySQL是單機(jī)的。MySQL能存儲多少數(shù)據(jù),取決于那臺服務(wù)器的硬盤大小。以現(xiàn)在互聯(lián)網(wǎng)的數(shù)據(jù)量,很多時(shí)候MySQL是沒法存儲那么多數(shù)據(jù)的。比如我這邊有個(gè)系統(tǒng),一天就能產(chǎn)生1TB的數(shù)據(jù),這數(shù)據(jù)是不可能存MySQL的。(如此大的量數(shù)據(jù),我們現(xiàn)在的做法是先寫到Kafka,然后落到hive中)
  • Kafka?Kafka我們主要用來處理消息的(解耦異步削峰)。數(shù)據(jù)到Kafka,Kafka會將數(shù)據(jù)持久化到硬盤中,并且Kafka是分布式的(很方便的擴(kuò)展),理論上Kafka可以存儲很大的數(shù)據(jù)。但是Kafka的數(shù)據(jù)我們不會「單獨(dú)」取出來。持久化了的數(shù)據(jù),最常見的用法就是重新設(shè)置offset,做「回溯」操作
  • Redis?Redis是緩存數(shù)據(jù)庫,所有的讀寫都在內(nèi)存中,速度賊快。AOF/RDB存儲的數(shù)據(jù)都會加載到內(nèi)存中,Redis不適合存大量的數(shù)據(jù)(因?yàn)閮?nèi)存太貴了!)。
  • Elasticsearch?Elasticsearch是一個(gè)分布式的搜索引擎,主要用于檢索。理論上Elasticsearch也是可以存儲海量的數(shù)據(jù)(畢竟分布式),我們也可以將數(shù)據(jù)用『索引』來取出來,似乎已經(jīng)是非常完美的中間件了。但是如果我們的數(shù)據(jù)沒有經(jīng)常「檢索」的需求,其實(shí)不必放到Elasticsearch,數(shù)據(jù)寫入Elasticsearch需要分詞,無疑會浪費(fèi)資源。
  • HDFS?顯然HDFS是可以存儲海量的數(shù)據(jù)的,它就是為海量數(shù)據(jù)而生的。它也有明顯的缺點(diǎn):不支持隨機(jī)修改,查詢效率低,對小文件支持不友好。

文中的開頭已經(jīng)說了,HBase是基于HDFS分布式文件系統(tǒng)去構(gòu)建的。換句話說,HBase的數(shù)據(jù)其實(shí)也是存儲在HDFS上的。那肯定有好奇寶寶就會問:HDFS和HBase有啥區(qū)別阿?

HDFS是文件系統(tǒng),而HBase是數(shù)據(jù)庫,其實(shí)也沒啥可比性?!改憧梢园袶Base當(dāng)做是MySQL,把HDFS當(dāng)做是硬盤。HBase只是一個(gè)NoSQL數(shù)據(jù)庫,把數(shù)據(jù)存在HDFS上」。

數(shù)據(jù)庫是一個(gè)以某種有組織的方式存儲的數(shù)據(jù)集合。

扯了這么多,那我們?yōu)樯兑肏Base呢?HBase在HDFS之上提供了高并發(fā)的隨機(jī)寫和支持實(shí)時(shí)查詢,這是HDFS不具備的。

我一直都說在學(xué)習(xí)某一項(xiàng)技術(shù)之前首先要了解它能干什么。如果僅僅看上面的”對比“,我們可以發(fā)現(xiàn)HBase可以以低成本來存儲海量的數(shù)據(jù)并且支持高并發(fā)隨機(jī)寫和實(shí)時(shí)查詢。

但HBase還有一個(gè)特點(diǎn)就是:存儲數(shù)據(jù)的”結(jié)構(gòu)“可以地非常靈活(這個(gè)下面會講到,這里如果沒接觸過HBase的同學(xué)可能不知道什么意思)。

三、入門HBase

聽過HBase的同學(xué)可能都聽過「列式存儲」這個(gè)詞。我最開始的時(shí)候覺得HBase很難理解,就因?yàn)樗@個(gè)「列式存儲」我一直理解不了它為什么是「列式」的。

在網(wǎng)上也有很多的博客去講解什么是「列式」存儲,它們會舉我們現(xiàn)有的數(shù)據(jù)庫,比如MySQL。存儲的結(jié)構(gòu)我們很容易看懂,就是一行一行數(shù)據(jù)嘛。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

轉(zhuǎn)換成所謂的列式存儲是什么樣的呢?

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

可以很簡單的發(fā)現(xiàn),無非就是把每列抽出來,然后關(guān)聯(lián)上Id。這個(gè)叫列式存儲嗎?我在這打個(gè)問號。

轉(zhuǎn)換后的數(shù)據(jù)從我的角度來看,數(shù)據(jù)還是一行一行的。

這樣做有什么好處嗎?很明顯以前我們一行記錄多個(gè)屬性(列),有部分的列是空缺的,但是我們還是需要空間去存儲?,F(xiàn)在把這些列全部拆開,有什么我們就存什么,這樣空間就能被我們充分利用。

這種形式的數(shù)據(jù)更像什么?明顯是Key-Value嘛。那我們該怎么理解HBase所謂的列式存儲和Key-Value結(jié)構(gòu)呢?

3.1 HBase的數(shù)據(jù)模型

在看HBase數(shù)據(jù)模型的時(shí)候,其實(shí)最好還是不要用「關(guān)系型數(shù)據(jù)庫」的知識去理解它。

In HBase, data is stored in tables, which have rows and columns. This is a terminology overlap withrelational databases (RDBMSs), but this is not a helpful analogy.

HBase里邊也有表、行和列的概念。

  • 表沒什么好說的,就是一張表
  • 一行數(shù)據(jù)由一個(gè)行鍵和一個(gè)或多個(gè)相關(guān)的列以及它的值所組成

好了,現(xiàn)在比較抽象了。在HBase里邊,定位一行數(shù)據(jù)會有一個(gè)唯一的值,這個(gè)叫做行鍵(RowKey)。而在HBase的列不是我們在關(guān)系型數(shù)據(jù)庫所想象中的列。

HBase的列(Column)都得歸屬到列族(Column Family)中。在HBase中用列修飾符(Column Qualifier)來標(biāo)識每個(gè)列。

在HBase里邊,先有列族,后有列。

什么是列族?可以簡單理解為:列的屬性類別

什么是列修飾符?先有列族后有列,在列族下用列修飾符來標(biāo)識一列。

還很抽象是不是?來畫個(gè)圖:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

我們再放點(diǎn)具體的值去看看,就更加容易看懂了:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

這張表我們有兩個(gè)列族,分別是UserInfo和OrderInfo。在UserInfo下有兩個(gè)列,分別是UserInfo:name和UserInfo:age,在OrderInfo下有兩個(gè)列,分別是OrderInfo:orderId和OrderInfo:money。

UserInfo:name的值為:UserInfo:age的值為24。OrderInfo:orderId的值為23333。OrderInfo:money的值為30。這些數(shù)據(jù)的主鍵(RowKey)為1

上面的那個(gè)圖看起來可能不太好懂,我們再畫一個(gè)我們比較熟悉的:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

HBase表的每一行中,列的組成都是靈活的,行與行之間的列不需要相同。如圖下:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

換句話說:一個(gè)列族下可以任意添加列,不受任何限制

數(shù)據(jù)寫到HBase的時(shí)候都會被記錄一個(gè)時(shí)間戳,這個(gè)時(shí)間戳被我們當(dāng)做一個(gè)版本。比如說,我們修改或者刪除某一條的時(shí)候,本質(zhì)上是往里邊新增一條數(shù)據(jù),記錄的版本加一了而已。

比如現(xiàn)在我們有一條記錄:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

現(xiàn)在要把這條記錄的值改為40,實(shí)際上就是多添加一條記錄,在讀的時(shí)候按照時(shí)間戳讀最新的記錄。在外界「看起來」就是把這條記錄改了。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

3.2 HBase 的Key-Value

HBase本質(zhì)上其實(shí)就是Key-Value的數(shù)據(jù)庫,那在HBase里邊,Key是什么?Value是什么?

我們看一下下面的HBaseKey-Value結(jié)構(gòu)圖:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

Key由RowKey(行鍵)+ColumnFamily(列族)+Column Qualifier(列修飾符)+TimeStamp(時(shí)間戳--版本)+KeyType(類型)組成,而Value就是實(shí)際上的值。

對比上面的例子,其實(shí)很好理解,因?yàn)槲覀冃薷囊粭l數(shù)據(jù)其實(shí)上是在原來的基礎(chǔ)上增加一個(gè)版本的,那我們要準(zhǔn)確定位一條數(shù)據(jù),那就得(RowKey+Column+時(shí)間戳)。

KeyType是什么?我們上面只說了「修改」的情況,你們有沒有想過,如果要刪除一條數(shù)據(jù)怎么做?實(shí)際上也是增加一條記錄,只不過我們在KeyType里邊設(shè)置為“Delete”就可以了。

3.3 HBase架構(gòu)

扯了這么一大堆,已經(jīng)說了HBase的數(shù)據(jù)模型和Key-Value了,我們還有一個(gè)問題:「為什么經(jīng)常會有人說HBase是列式存儲呢?」

其實(shí)HBase更多的是「列族存儲」,要談列族存儲,就得先了解了解HBase的架構(gòu)是怎么樣的。

我們先來看看HBase的架構(gòu)圖:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

1、Client客戶端,它提供了訪問HBase的接口,并且維護(hù)了對應(yīng)的cache來加速HBase的訪問。

2、Zookeeper存儲HBase的元數(shù)據(jù)(meta表),無論是讀還是寫數(shù)據(jù),都是去Zookeeper里邊拿到meta元數(shù)據(jù)告訴給客戶端去哪臺機(jī)器讀寫數(shù)據(jù)

3、HRegionServer它是處理客戶端的讀寫請求,負(fù)責(zé)與HDFS底層交互,是真正干活的節(jié)點(diǎn)。

總結(jié)大致的流程就是:client請求到Zookeeper,然后Zookeeper返回HRegionServer地址給client,client得到Zookeeper返回的地址去請求HRegionServer,HRegionServer讀寫數(shù)據(jù)后返回給client。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

3.4 HRegionServer內(nèi)部

我們來看下面的圖:

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

前面也提到了,HBase可以存儲海量的數(shù)據(jù),HBase是分布式的。所以我們可以斷定:HBase一張表的數(shù)據(jù)會分到多臺機(jī)器上的。那HBase是怎么切割一張表的數(shù)據(jù)的呢?用的就是RowKey來切分,其實(shí)就是表的橫向切割。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

說白了就是一個(gè)HRegion上,存儲HBase表的一部分?jǐn)?shù)據(jù)。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

HRegion下面有Store,那Store是什么呢?我們前面也說過,一個(gè)HBase表首先要定義列族,然后列是在列族之下的,列可以隨意添加。

一個(gè)列族的數(shù)據(jù)是存儲在一起的,所以一個(gè)列族的數(shù)據(jù)是存儲在一個(gè)Store里邊的。

看到這里,其實(shí)我們可以認(rèn)為HBase是基于列族存儲的(畢竟物理存儲,一個(gè)列族是存儲到同一個(gè)Store里的)

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

Store里邊有啥?有Mem Store、Store File、HFile,我們再來看看里邊都代表啥含義。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

HBase在寫數(shù)據(jù)的時(shí)候,會先寫到Mem Store,當(dāng)MemStore超過一定閾值,就會將內(nèi)存中的數(shù)據(jù)刷寫到硬盤上,形成StoreFile,而StoreFile底層是以HFile的格式保存,HFile是HBase中KeyValue數(shù)據(jù)的存儲格式。

所以說:Mem Store我們可以理解為內(nèi)存 buffer,HFile是HBase實(shí)際存儲的數(shù)據(jù)格式,而StoreFile只是HBase里的一個(gè)名字。

回到HRegionServer上,我們還漏了一塊,就是HLog。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

這里其實(shí)特別好理解了,我們寫數(shù)據(jù)的時(shí)候是先寫到內(nèi)存的,為了防止機(jī)器宕機(jī),內(nèi)存的數(shù)據(jù)沒刷到磁盤中就掛了。我們在寫Mem store的時(shí)候還會寫一份HLog。

這個(gè)HLog是順序?qū)懙酱疟P的,所以速度還是挺快的(是不是有似曾相似的感覺)...

稍微總結(jié)一把:

HRegionServer是真正干活的機(jī)器(用于與hdfs交互),我們HBase表用RowKey來橫向切分表

HRegion里邊會有多個(gè)Store,每個(gè)Store其實(shí)就是一個(gè)列族的數(shù)據(jù)(所以我們可以說HBase是基于列族存儲的)

Store里邊有Men Store和StoreFile(HFile),其實(shí)就是先走一層內(nèi)存,然后再刷到磁盤的結(jié)構(gòu)

3.5 被遺忘的HMaster

我們在上面的圖會看到有個(gè)Hmaster,它在HBase的架構(gòu)中承擔(dān)一種什么樣的角色呢?讀寫請求都沒經(jīng)過Hmaster呀。

 

過了這么久,我終于看懂了HBase,太不容易了QAQ

 

那HMaster在HBase里承擔(dān)什么樣的角色呢??

  • HMaster is the implementation of the Master Server. The Master server is responsible for monitoring all RegionServer instances in the cluster, and is the interface for all metadata changes.

HMaster會處理 HRegion 的分配或轉(zhuǎn)移。如果我們HRegion的數(shù)據(jù)量太大的話,HMaster會對拆分后的Region重新分配RegionServer。(如果發(fā)現(xiàn)失效的HRegion,也會將失效的HRegion分配到正常的HRegionServer中)

HMaster會處理元數(shù)據(jù)的變更和監(jiān)控RegionServer的狀態(tài)。

四、RowKey的設(shè)計(jì)

到這里,我們已經(jīng)知道RowKey是什么了。不難理解的是,我們肯定是要保證RowKey是唯一的,畢竟它是行鍵,有了它我們才可以唯一標(biāo)識一條數(shù)據(jù)的。

在HBase里邊提供了三種的查詢方式:

  1. 全局掃描
  2. 根據(jù)一個(gè)RowKey進(jìn)行查詢
  3. 根據(jù)RowKey過濾的范圍查詢

4.1 根據(jù)一個(gè)RowKey查詢

首先我們要知道的是RowKey是會按字典序排序的,我們HBase表會用RowKey來橫向切分表。

無論是讀和寫我們都是用RowKey去定位到HRegion,然后找到HRegionServer。這里有一個(gè)很關(guān)鍵的問題:那我怎么知道這個(gè)RowKey是在這個(gè)HRegion上的?

HRegion上有兩個(gè)很重要的屬性:start-key和end-key。

我們在定位HRegionServer的時(shí)候,實(shí)際上就是定位我們這個(gè)RowKey在不在這個(gè)HRegion的start-key和end-key范圍之內(nèi),如果在,說明我們就找到了。

這個(gè)時(shí)候會帶來一個(gè)問題:由于我們的RowKey是以字典序排序的,如果我們對RowKey沒有做任何處理,那就有可能存在熱點(diǎn)數(shù)據(jù)的問題。

舉個(gè)例子,現(xiàn)在我們的RowKey如下:

  1. java3y111 
  2. java3y222 
  3. java3y333 
  4. java3y444 
  5. java3y555 
  6. aaa 
  7. bbb 
  8. java3y777 
  9. java3y666 
  10. java3y... 

Java3yxxx開頭的RowKey很多,而其他的RowKey很少。如果我們有多個(gè)HRegion的話,那么存儲Java3yxxx的HRegion的數(shù)據(jù)量是最大的,而分配給其他的HRegion數(shù)量是很少的。

關(guān)鍵是我們的查詢也幾乎都是以java3yxxx的數(shù)據(jù)去查,這會導(dǎo)致某部分?jǐn)?shù)據(jù)會集中在某臺HRegionServer上存儲以及查詢,而其他的HRegionServer卻很空閑。

如果是這種情況,我們要做的是什么?對RowKey散列就好了,那分配到HRegion的時(shí)候就比較均勻,少了熱點(diǎn)的問題。

HBase優(yōu)化手冊:

建表申請時(shí)的預(yù)分區(qū)設(shè)置,對于經(jīng)常使用HBase的小伙伴來說,HBase管理平臺里申請HBase表流程必然不陌生了。

'給定split的RowKey組例如:aaaaa,bbbbb,ccccc;或給定例如:startKey=00000000,endKey=xxxxxxxx,regionsNum=x'

第一種方式:

是自己指定RowKey的分割點(diǎn)來劃分region個(gè)數(shù).比如有一組數(shù)據(jù)RowKey為[1,2,3,4,5,6,7],此時(shí)給定split RowKey是3,6,那么就會劃分為[1,3),[3,6),[6,7)的三個(gè)初始region了.如果對于RowKey的組成及數(shù)據(jù)分布非常清楚的話,可以使用這種方式精確預(yù)分區(qū).

第二種方式 :

如果只是知道RowKey的組成大致的范圍,可以選用這種方式讓集群來均衡預(yù)分區(qū),設(shè)定始末的RowKey,以及根據(jù)數(shù)據(jù)量給定大致的region數(shù),一般建議region數(shù)最多不要超過集群的rs節(jié)點(diǎn)數(shù),過多region數(shù)不但不能增加表訪問性能,反而會增加master節(jié)點(diǎn)壓力.如果給定始末RowKey范圍與實(shí)際偏差較大的話,還是比較容易產(chǎn)生數(shù)據(jù)熱點(diǎn)問題.

最后:生成RowKey時(shí),盡量進(jìn)行加鹽或者哈希的處理,這樣很大程度上可以緩解數(shù)據(jù)熱點(diǎn)問題.

4.2根據(jù)RowKey范圍查詢

上面的情況是針對通過RowKey單個(gè)查詢的業(yè)務(wù)的,如果我們是根據(jù)RowKey范圍查詢的,那沒必要上面那樣做。

HBase將RowKey設(shè)計(jì)為字典序排序,如果不做限制,那很可能類似的RowKey存儲在同一個(gè)HRegion中。那我正好有這個(gè)場景上的業(yè)務(wù),那我查詢的時(shí)候不是快多了嗎?在同一個(gè)HRegion就可以拿到我想要的數(shù)據(jù)了。

舉個(gè)例子:我們會間隔幾秒就采集直播間熱度,將這份數(shù)據(jù)寫到HBase中,然后業(yè)務(wù)方經(jīng)常要把主播的一段時(shí)間內(nèi)的熱度給查詢出來。

我設(shè)計(jì)好的RowKey,將該主播的一段時(shí)間內(nèi)的熱度都寫到同一個(gè)HRegion上,拉取的時(shí)候只要訪問一個(gè)HRegionServer就可以得到全部我想要的數(shù)據(jù)了,那查詢的速度就快很多。

最后

最后再來帶著大家回顧一下這篇文章寫了什么:

HBase是一個(gè)NoSQL數(shù)據(jù)庫,一般我們用它來存儲海量的數(shù)據(jù)(因?yàn)樗贖DFS分布式文件系統(tǒng)上構(gòu)建的)

HBase的一行記錄由一個(gè)RowKey和一個(gè)或多個(gè)的列以及它的值所組成。先有列族后有列,列可以隨意添加。

HBase的增刪改記錄都有「版本」,默認(rèn)以時(shí)間戳的方式實(shí)現(xiàn)。

RowKey的設(shè)計(jì)如果沒有特殊的業(yè)務(wù)性,最好設(shè)計(jì)為散列的,這樣避免熱點(diǎn)數(shù)據(jù)分布在同一個(gè)HRegionServer中。

HBase的讀寫都經(jīng)過Zookeeper去拉取meta數(shù)據(jù),定位到對應(yīng)的HRegion,然后找到HRegionServer

 

責(zé)任編輯:武曉燕 來源: 今日頭條
相關(guān)推薦

2020-06-09 08:19:25

微服務(wù)網(wǎng)站架構(gòu)

2020-06-18 10:52:17

運(yùn)維架構(gòu)技術(shù)

2019-06-17 13:34:17

Java程序員編程語言

2021-03-22 09:27:44

PythonEXCEL熱點(diǎn)推薦

2021-05-27 21:18:56

谷歌Fuchsia OS操作系統(tǒng)

2012-06-13 14:58:09

BYOD移動辦公

2020-03-30 09:22:03

AI語音技術(shù)機(jī)器視覺

2013-09-22 09:16:25

碼農(nóng)程序員黑客

2018-01-24 07:28:20

2017-04-27 13:30:14

AndroidWebView移動應(yīng)用

2022-02-08 13:39:35

LinuxUNIX系統(tǒng)

2021-05-28 07:12:58

Mybatis面試官Java

2009-09-04 08:19:24

Windows 7優(yōu)缺點(diǎn)

2009-02-12 17:25:21

Windows7試用下載

2021-04-20 19:21:50

臟讀MySQL幻讀

2021-05-28 06:16:28

藍(lán)牙Wi-FiNFC

2021-04-28 11:35:06

Java框架日志

2011-12-16 14:52:55

移動互聯(lián)聯(lián)想

2023-08-31 22:17:15

JavaMySQLB+樹

2018-06-08 10:12:10

Web緩存體系服務(wù)器
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號