閱讀Nosql代碼有感

　　這一年總得來講，讀書的時間很少。一是由於時間啥關係，這一年一直在跟着項目走，或者被項目牽着走，幾乎全部的時間和精力所有被拴在幾個項目上；不過所幸今年創業失敗，又回去上班了，時間相對空餘了一些。

     雙十一是一個好日子，持續關注的幾本書，幾乎五折入手，其中有一本叫作《mysql技術內幕-innodb存儲引擎》。工做閒暇之餘常常拿出來翻翻，所幸本身對於線程和數據結構比較紮實，讀起來雖然吃力，可是仍是能吃透的。正是由於這本書的指引，讓本身對數據庫產生濃厚的興趣，加上以前使用mongodb和redis的經歷，讓我決定好好研究下數據庫。

　  打開linux，eclipse，導入leveldb的工程，邊閱讀代碼邊調試起來；以後又添加了ssdb的代碼，修改了少許代碼，能夠eclipse調試運行；redis也能夠在eclipse裏面跑而且調試，只是你們須要在調試時候指定makefile文件。

　  leveldb是key-value形式的鍵值對數據庫，更多的讚美就不說了，最大的一個特色，leveldb的key是排序的，這個排序的特性在ssdb中有很大的發揮。

　  隨着如今業務的開展，簡單的key-value的鍵值對結構已經不能知足更復雜的系統和業務，因此讓nosql支持更多的數據結構成爲趨勢，因而redis再漸漸代替memcache，因而基於leveldb的支持更多數據結構的nosql愈來愈多，ssdb應該只是其中一個吧。

     起初在個人臆想中，ssdb爲了支持更多的數據結構，那麼應該也只能從value下手，讓leveldb的value多種類型，好比他的value再也不只是簡單的string類型，而是有列表形式，有二叉樹形式等等；看了ssdb的代碼，才知道，原來做者是擴展的key，咱們舉幾個例子。

     簡單的key-value的結構就不說，咱們首先說說hash結構，好比一個玩家，有等級屬性，經驗屬性，名稱屬性，等等，由於leveldb只支持最基本的key-value的鍵值對結構，因此咱們這樣設計key，對於玩家archy，咱們在數據庫中這樣設計,h-role-archy-level表示玩家的等級key，對應的值是2；h-role-archy-exp表示玩家的經驗key，對應的值是200；h-role-archy-name表示的玩家名稱key，對應的值是archy。不少人估計要問了，這樣如何保證獲得玩家archy全部的屬性；就像大概相似於select * from role where id="archy"的操做；或者像redis中hgetall role:archy的操做；前面咱們已經講過leveldb的key是排序的，再加上咱們的key定義規則，咱們能夠輕易的從h-role-archy-""開始查找到 h-role-archy-level,若是查找到h-role-lopze-level,表示到底了，這樣就實現了hgetall的操做。

    再舉個例子，queue的例子，好比咱們要建立一個tasks的隊列,他的值包括archy,lopze,ramon，咱們這樣去定義他的key,q-tasks-0對應值archy;q-tasks-1對應值lopez；q-tasks-2對應值roman；這樣咱們取tasks隊列中全部的值，就能夠取q-tasks-"" 到 q-xxx(xxx不一樣於tasks)截止就好。至於push，只須要設置q-tasks-n和對應的值就ok。這樣咱們就已經能夠支持這個隊列結構了。

    代碼量不大，有興趣的能夠去讀讀源代碼。

    我對於這些茫茫的nosql，感興趣只是在mongo,leveldb,redis這幾個春節以前想熟悉這幾套；對於他的擴展，我想的是是否能夠提供where的操做，好比我想查找level大於10級的玩家，而我卻不想搜索數據庫，想利用索引的方式，將level排序，排序的值正好對應相應的玩家key就好，這樣就簡單實現了select中的where操做，想一想仍是蠻激動的！