數(shù)據(jù)庫到底指的什么？數(shù)據(jù)庫，故名能所，就是能保存數(shù)據(jù)庫倉庫。我下面從幾個角度具體描述下數(shù)據(jù)庫。數(shù)據(jù)庫到底指的是什么？我們先看看百度中對數(shù)據(jù)庫的專業(yè)請解釋：正所謂“數(shù)據(jù)庫”是以一定會存儲在一起、能與多個

數(shù)據(jù)庫到底指的什么？

數(shù)據(jù)庫，故名能所，就是能保存數(shù)據(jù)庫倉庫。我下面從幾個角度具體描述下數(shù)據(jù)庫。

數(shù)據(jù)庫到底指的是什么？我們先看看百度中對數(shù)據(jù)庫的專業(yè)請解釋：

正所謂“數(shù)據(jù)庫”是以一定會存儲在一起、能與多個用戶共享、具高盡可能會小的冗余度、與應(yīng)用程序彼此的的的數(shù)據(jù)子集。這個解釋也很抽象，通俗的講，數(shù)據(jù)庫就是一種計算機(jī)領(lǐng)域普通的配合軟件系統(tǒng)的數(shù)據(jù)存儲，他們比較多利用在硬盤或其它介質(zhì)上存儲和管理數(shù)據(jù)，比如我們偶爾會聽他們說的PostgreSQL、SQLite、MySQL、SQLServer、Oracle、Access等等，都是數(shù)據(jù)庫、又都可以管理數(shù)據(jù)庫的軟件系統(tǒng)。

數(shù)據(jù)庫發(fā)展簡史1970年，IBM的研究員博士在刊物《Communication of the ACM》上發(fā)表了一篇名為“ARelational ModelofDataofLarge Shared Data Banks”的論文，給出了關(guān)系模型的概念，打響了名號了關(guān)系模型的理論基礎(chǔ)。

這篇論文被普遍以為是數(shù)據(jù)庫系統(tǒng)歷史上具高劃時代意義的里程碑。當(dāng)時Codd又大批可以發(fā)表多篇文章，辨析了范式理論和可以衡量關(guān)系系統(tǒng)的12條標(biāo)準(zhǔn)，用數(shù)學(xué)理論夯實的基礎(chǔ)了關(guān)系數(shù)據(jù)庫的基礎(chǔ)。

1974年，IBM的RayBoyce和DonChamberlin將Codd關(guān)系數(shù)據(jù)庫的12條準(zhǔn)則的數(shù)學(xué)定義以簡單的關(guān)鍵字語法表現(xiàn)出，里程碑式地做出了SQL（StructuredQuery Language）語言。

緊接著，Oracle的創(chuàng)始人LarryEllison敏銳的感覺思維到在這個研究基礎(chǔ)上這個可以變更土地性質(zhì)正式商用軟件系統(tǒng)。幾個月后，Ellison他們就變更土地性質(zhì)了Oracle1.0。

1988年，為幫忙解決企業(yè)集成主板問題，IBM公司的研究員BarryDevlin和PaulMurphy創(chuàng)造性的做出了三個新的術(shù)語──數(shù)據(jù)倉庫（DataWarehouse）。

……

當(dāng)下流行的數(shù)據(jù)庫都是那些？數(shù)據(jù)庫發(fā)展起來到當(dāng)下，衍生出出關(guān)系型數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫和NewSQL數(shù)據(jù)庫三條線。關(guān)系型數(shù)據(jù)庫基于組件現(xiàn)代關(guān)系型模型；NoSQL顛復(fù)了關(guān)系型數(shù)據(jù)庫的關(guān)系模型、試圖用另一種角度能表達(dá)越來越大緊張多元化數(shù)據(jù)；NewSQL則更加注重綜合考了兩者的優(yōu)點。

當(dāng)下也很比較流行關(guān)系型數(shù)據(jù)庫，主要分成三類商業(yè)型關(guān)系型數(shù)據(jù)庫和開源關(guān)系型數(shù)據(jù)庫，商業(yè)型關(guān)系型數(shù)據(jù)庫比較多除開DB2、Oracle、SQLServer、Informix等；開源關(guān)系型數(shù)據(jù)庫，主要注意包括PostgresSQL、MySQL、SQLite等。

當(dāng)下比較好很流行NoSQL數(shù)據(jù)庫，據(jù)特性有四大分支，即只讀屬性類、文檔類、列式、圖形類。鍵值類以Redis為代表；文檔類以CouchDB、MongoDB為代表、列式以Cassandra、HBase為代表；圖形類以Neo4為代表。

當(dāng)下也很很流行NewSQL系統(tǒng)，國外的我就不說了，國內(nèi)一幫高手旗下了一套名為TiDB的NewSQL系統(tǒng)，語法兼容性問題MySQL，非常不錯。

phoenix的優(yōu)缺點？

1.幾乎失去抵抗了HBase的多版本特征

HBases起碼也是二維結(jié)構(gòu)（row、cf:cq、timestamp）的數(shù)據(jù)模型，Phoenix將其映射為二維的關(guān)系模型后，便面對著損失信息精度的為難場面。這種尷尬主要表現(xiàn)在Phoenix在用的兩個方面：

a.肯定不能為一個cell指定不可以的timestamp

另外HBase的第3維特征，timestamp的重要性再清楚不過。由于絕大部分?jǐn)?shù)據(jù)應(yīng)用場景都離不開時間維度，因此我們經(jīng)常會會將數(shù)據(jù)中的某個時間字段映射到timestamp，也就不需要在CF中存儲該字段了。這樣的好處是：既節(jié)省用水了存儲空間，也也可以不使用timestamp相關(guān)的API（的或get#setTimeRange）并且查詢。

遺憾的是，Phoenix并肯定不能讓我們像HBase差不多指定輸入的timestamp。可是Phoenix在F.A.Q.中煞有其事的給出了好像沒有吧這個問題的解決方案。只不過深究之后你就會發(fā)現(xiàn)這是一個都很坑爹啊的方案。理由萬分感謝：

首先，該方案好像沒有吧也可以指定不可以的timestamp，不過需要在應(yīng)用程序中正常的創(chuàng)建和關(guān)閉Connection，可是他們還專業(yè)點強(qiáng)調(diào)這不是一個“貴得要命”的操作（is notanexpensiveoperation），但是這樣的代碼風(fēng)格估計也會讓很多人納悶。

主要，該方案的輸入timestamp反正是有條件的，即需要大于表的創(chuàng)建時間，否則，會會出現(xiàn)“Tableundefined”的異樣。

需要只能證明的是，Phoenix這個可以Upsert重復(fù)的記錄，三條記錄的timestamp是不一樣的。這樣來看，可是timestamp并非我希冀的，不過多版本是不是早實現(xiàn)方法了呢？看見了下面的一點你應(yīng)經(jīng)就明白了。。。。。。

b.沒法獲取一個cell的多個版本

Phoenix總是會聲望兌換cell的哪個網(wǎng)站版本，有不可能去獲取其它版本呢？

我曾經(jīng)受F.A.Q.中CurrentSCN屬性的啟發(fā)，自以為是一想到一個方法：不管三七二十一，先去拿三次，拿到的肯定是2012版版本了。取其timestamp賦給_SCN_ATTRIB后再去拿，那樣就取得次新版本了。以此類推，每次來拿一個版本，等到能拿只不過。只不過這種方法有點笨，但我想著老是是可以能解決問題的。只不過聽說后來忽然間才發(fā)現(xiàn)一個攻擊的缺陷：怎么取結(jié)果中的timestamp呢？嘛，看來這個方法不光是是“有點笨”了......

我相信這個問題也困擾中了許多人，并直接導(dǎo)致了許多人的思考。PHOENIX-590便行專門對于這個問題，遺憾的是，雖說給出了一些解決思路，只不過到現(xiàn)在為止依舊沒有推動性的進(jìn)展。

變通方案

PHOENIX-590做出了一種解決方案，其實也和我們想的一樣的。。。。。。那是將timestamp作為Phoenix表的不能一列，因此和其它字段以及兩種主鍵。這樣的本質(zhì)是row和timestamp二維怎么合一維，反映在HBase里面，總之是將timestamp的值附加在row后面了。這樣的話也可以幫忙解決不使用timestamp查詢的問題，缺點是浪費(fèi)了了一些存儲空間。

2.二級索引設(shè)計比較粗糙

[sql]viewplain剪切粘貼print

CREATEINDEXidx_nameinTAB_NAME(IDX_FIELD);

SELECTOtherFieldaroundTAB_NAMEWHERRIDX_FIELD;

我以為我這樣的就可以不利用索引了，只不過那就錯了，前提是要

[sql]viewplain全部復(fù)制print

CREATEINDEXidx_nameoffTAB_NAME(IDX_FIELD) INCLUDE(OtherField);

是因為二級索引修改了個新的索引表，沒有INICLUDE時，索引表中的value為空，上述查詢將不可能憑借索引表，而是clearScan主表。INCLUDE時，會將OtherField字段寫入文件索引表的value中，本案所涉查詢城就會憑借索引表進(jìn)行RangeSacn。

這種做法讓人不得不狂吐槽，雖說說存儲不太值錢，可是也沒法這么多浪費(fèi)吧。

但轉(zhuǎn)念間看看，這又是Phoenix的無奈之舉：是因為它肯定不能絕對的保證主表和索引表對應(yīng)Region的本地化，所以我也就無法根據(jù)索引表的結(jié)果再去查主表了。

變通方案

a.客戶端自己可以解決：先查索引表資源PrimaryKey，然后再依據(jù)什么PrimaryKey二次查詢主表；

b.建議使用其他索引方案......

針對目前Phoenix的二級索引方案，我個人我建議你必須得很謹(jǐn)慎建議使用。據(jù)我所知其無人能及的膨脹性，我個人建議只考慮到在用在比較比較小的表上，因此對該表是寫少讀多。