mvcc存儲
Membase
Membase 是 NoSQL 家族的一個新的重量級的成員。Membase是開源項目，源代碼採用了Apache2.0的使用許可。該項目託管在GitHub.Source tarballs上，可以beta版本的Linux二進制包。該產品主要是由North Scale的memcached核心團隊成員開發完成，其中還包括Zynga和NHN這兩個主要貢獻者的工程師，這兩個組織都是很大的在線游戲和社區網路空間的供應商。
Membase容易安裝、操作，可以從單節點方便的擴展到集群，而且為memcached（有線協議的兼容性）實現了即插即用功能，在應用方面為開發者和經營者提供了一個比較低的門檻。做為緩存解決方案，Memcached已經在不同類型的領域（特別是大容量的Web應用）有了廣泛的使用，其中 Memcached的部分基礎代碼被直接應用到了Membase伺服器的前端。
通過兼容多種編程語言和框架，Membase具備了很好的復用性。在安裝和配置方面，Membase提供了有效的圖形化界面和編程介面，包括可配置 的告警信息。
Membase的目標是提供對外的線性擴展能力，包括為了增加集群容量，可以針對統一的節點進行復制。 另外，對存儲的數據進行再分配仍然是必要的。
這方面的一個有趣的特性是NoSQL解決方案所承諾的可預測的性能，類准確性的延遲和吞吐量。通過如下方式可以獲得上面提到的特性：
◆ 自動將在線數據遷移到低延遲的存儲介質的技術（內存，固態硬碟，磁碟）
◆ 可選的寫操作一一非同步，同步（基於復制，持久化）
◆ 反向通道再平衡[未來考慮支持]
◆ 多線程低鎖爭用
◆ 盡可能使用非同步處理
◆ 自動實現重復數據刪除
◆ 動態再平衡現有集群
◆ 通過把數據復制到多個集群單元和支持快速失敗轉移來提供系統的高可用性。
MongoDB
MongoDB是一個介於關系資料庫和非關系資料庫之間的產品，是非關系資料庫當中功能最豐富，最像關系資料庫的。他支持的數據結構非常鬆散，是類似json的bjson格式，因此可以存儲比較復雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關系資料庫單表查詢的絕大部分功能，而且還支持對數據建立索引。它的特點是高性能、易部署、易使用，存儲數據非常方便。
主要功能特性：
◆ 面向集合存儲，易存儲對象類型的數據
「面向集合」（Collenction-Oriented），意思是數據被分組存儲在數據集中，被稱為一個集合（Collenction)。每個 集合在資料庫中都有一個唯一的標識名，並且可以包含無限數目的文檔。集合的概念類似關系型資料庫（RDBMS）里的表（table），不同的是它不需要定 義任何模式（schema)。
◆ 模式自由
模式自由（schema-free)，意味著對於存儲在mongodb資料庫中的文件，我們不需要知道它的任何結構定義。如果需要的話，你完全可以把不同結構的文件存儲在同一個資料庫里。
◆支持動態查詢
◆支持完全索引，包含內部對象
◆支持查詢
◆支持復制和故障恢復
◆使用高效的二進制數據存儲，包括大型對象（如等）
◆自動處理碎片，以支持雲計算層次的擴展性
◆支持RUBY，PYTHON，java，C++，PHP等多種語言
◆文件存儲格式為BSON（一種JSON的擴展）
BSON（Binary Serialized document Format）存儲形式是指：存儲在集合中的文檔，被存儲為鍵-值對的形式。鍵用於唯一標識一個文檔，為字元串類型，而值則可以是各種復雜的文件類型。
◆可通過網路訪問
MongoDB服務端可運行在Linux、Windows或OS X，支持32位和64位應用，默認埠為27017。運行在64位，因為MongoDB在32位模式運行時支持的最大文件尺寸為2GB。
MongoDB把數據存儲在文件中（默認路徑為：/data/db），為提高效率使用內存映射文件進行管理。
Hypertable
Hypertable是一個開源、高性能、可伸縮的資料庫，它採用與Google的Bigtable相似的模型。在過去數年中，Google為在PC集群 上運行的可伸縮計算基礎設施設計建造了三個關鍵部分。第一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的文件系統，提供了一個全局的命名空間。它通過跨機器（和跨機架）的文件數據復制來達到高可用性，並因此免受傳統 文件存儲系統無法避免的許多失敗的影響，比如電源、內存和網路埠等失敗。第二個基礎設施是名為Map-Rece的計算框架，它與GFS緊密協作，幫 助處理收集到的海量數據。第三個基礎設施是Bigtable，它是傳統資料庫的替代。Bigtable讓你可以通過一些主鍵來組織海量數據，並實現高效的 查詢。Hypertable是Bigtable的一個開源實現，並且根據我們的想法進行了一些改進。
Apache Cassandra
Apache Cassandra是一套開源分布式Key-Value存儲系統。它最初由Facebook開發，用於儲存特別大的數據。Facebook在使用此系統。
主要特性：
◆ 分布式
◆ 基於column的結構化
◆ 高伸展性
Cassandra的主要特點就是它不是一個資料庫，而是由一堆資料庫節點共同構成的一個分布式網路服務，對Cassandra 的一個寫操作，會被復制到其他節點上去，對Cassandra的讀操作，也會被路由到某個節點上面去讀取。對於一個Cassandra群集來說，擴展性能 是比較簡單的事情，只管在群集裡面添加節點就可以了。
Cassandra是一個混合型的非關系的資料庫，類似於Google的BigTable。其主要功能比 Dynomite（分布式的Key-Value存 儲系統）更豐富，但支持度卻不如文檔存儲MongoDB（介於關系資料庫和非關系資料庫之間的開源產品，是非關系資料庫當中功能最豐富，最像關系資料庫 的。Cassandra最初由Facebook開發，後轉變成了開源項目。它是一個網路社交雲計算方面理想的資料庫。以Amazon專有的完全分布式的Dynamo為基礎，結合了Google BigTable基於列族（Column Family）的數據模型。P2P去中心化的存儲。很多方面都可以稱之為Dynamo 2.0。
CouchDB
所用語言： Erlang
特點：DB一致性，易於使用
使用許可： Apache
協議： HTTP/REST
雙向數據復制，持續進行或臨時處理，處理時帶沖突檢查，因此，採用的是master-master復制
MVCC – 寫操作不阻塞讀操作
可保存文件之前的版本
Crash-only（可靠的）設計
需要不時地進行數據壓縮
視圖：嵌入式 映射/減少
格式化視圖：列表顯示
支持進行伺服器端文檔驗證
支持認證
根據變化實時更新
支持附件處理
因此， CouchApps（獨立的 js應用程序）
需要 jQuery程序庫
最佳應用場景：適用於數據變化較少，執行預定義查詢，進行數據統計的應用程序。適用於需要提供數據版本支持的應用程序。
例如：CRM、CMS系統。 master-master復制對於多站點部署是非常有用的。
和其他資料庫比較，其突出特點是：
◆ 模式靈活 ：使用Cassandra，像文檔存儲，你不必提前解決記錄中的欄位。你可以在系統運行時隨意的添加或移除欄位。這是一個驚人的效率提升，特別是在大型部 署上。
◆ 真正的可擴展性 ：Cassandra是純粹意義上的水平擴展。為給集群添加更多容量，可以指向另一台電腦。你不必重啟任何進程，改變應用查詢，或手動遷移任何數據。
◆ 多數據中心識別 ：你可以調整你的節點布局來避免某一個數據中心起火，一個備用的數據中心將至少有每條記錄的完全復制。
◆ 范圍查詢 ：如果你不喜歡全部的鍵值查詢，則可以設置鍵的范圍來查詢。
◆ 列表數據結構 ：在混合模式可以將超級列添加到5維。對於每個用戶的索引，這是非常方便的。
◆ 分布式寫操作 ：有可以在任何地方任何時間集中讀或寫任何數據。並且不會有任何單點失敗。
問度娘，啥都有。
② 事務和鎖機制是什麼關系 開啟事務就自動加鎖了嗎 菜鳥，謝謝了。
1、事務與鎖是不同的。事務具有ACID（原子性、一致性、隔離性和持久性），鎖是用於解決隔離性的一種機制。
2、事務的隔離級別通過鎖的機制來實現。另外鎖有不同的粒度，同時事務也是有不同的隔離級別的。
3、開啟事務就自動加鎖。
③ Mysql到底是怎麼實現MVCC的
Mysql到底是怎麼實現MVCC的
Mysql到底是怎麼實現MVCC的？這個問題無數人都在問，但google中並無答案，本文嘗試從Mysql源碼中尋找答案。
在Mysql中MVCC是在Innodb存儲引擎中得到支持的，Innodb為每行記錄都實現了三個隱藏欄位：
6位元組的事務ID（DB_TRX_ID ）
7位元組的回滾指針（DB_ROLL_PTR）
隱藏的ID
6位元組的事物ID用來標識該行所述的事務，7位元組的回滾指針需要了解下Innodb的事務模型。
1. Innodb的事務相關概念
為了支持事務，Innbodb引入了下面幾個概念：
redo log
redo log就是保存執行的SQL語句到一個指定的Log文件，當Mysql執行recovery時重新執行redo log記錄的SQL操作即可。當客戶端執行每條SQL（更新語句）時，redo log會被首先寫入log buffer；當客戶端執行COMMIT命令時，log buffer中的內容會被視情況刷新到磁碟。redo log在磁碟上作為一個獨立的文件存在，即Innodb的log文件。
undo log
與redo log相反，undo log是為回滾而用，具體內容就是事務前的資料庫內容（行）到undo buffer，在適合的時間把undo buffer中的內容刷新到磁碟。undo buffer與redo buffer一樣，也是環形緩沖，但當緩沖滿的時候，undo buffer中的內容會也會被刷新到磁碟；與redo log不同的是，磁碟上不存在單獨的undo log文件，所有的undo log均存放在主ibd數據文件中（表空間），即使客戶端設置了每表一個數據文件也是如此。
rollback segment
回滾段這個概念來自Oracle的事物模型，在Innodb中，undo log被劃分為多個段，具體某行的undo log就保存在某個段中，稱為回滾段。可以認為undo log和回滾段是同一意思。
鎖
Innodb提供了基於行的鎖，如果行的數量非常大，則在高並發下鎖的數量也可能會比較大，據Innodb文檔說，Innodb對鎖進行了空間有效優化，即使並發量高也不會導致內存耗盡。
對行的鎖有分兩種：排他鎖、共享鎖。共享鎖針對對，排他鎖針對寫，完全等同讀寫鎖的概念。如果某個事務在更新某行（排他鎖），則其他事物無論是讀還是寫本行都必須等待；如果某個事物讀某行（共享鎖），則其他讀的事物無需等待，而寫事物則需等待。通過共享鎖，保證了多讀之間的無等待性，但是鎖的應用又依賴Mysql的事務隔離級別。
隔離級別
隔離級別用來限制事務直接的交互程度，目前有幾個工業標准：
- READ_UNCOMMITTED：臟讀
- READ_COMMITTED：讀提交
- REPEATABLE_READ：重復讀
- SERIALIZABLE：串列化
Innodb對四種類型都支持，臟讀和串列化應用場景不多，讀提交、重復讀用的比較廣泛，後面會介紹其實現方式。
2. 行的更新過程
下面演示下事務對某行記錄的更新過程：
1. 初始數據行
F1～F6是某行列的名字，1～6是其對應的數據。後面三個隱含欄位分別對應該行的事務號和回滾指針，假如這條數據是剛INSERT的，可以認為ID為1，其他兩個欄位為空。
2.事務1更改該行的各欄位的值
當事務1更改該行的值時，會進行如下操作：
用排他鎖鎖定該行
④ 如何自己實現一個關系型資料庫
對外數據模型為關系型資料庫，內部的實現主要分成兩大類，一類是disk-based，比如mysql，postgres，一類是memory based，後者包括MemSQL，SAP HAHA，OceanBase。看題目的意思指的是前者。這里說一個disk-based的關系型資料庫涉及多少東西。
上世紀70/80年代內存不大，數據不能都放在內存里，大部分數據都存在磁碟上，讀數據也需要從磁碟讀，然而讀寫磁碟太慢了，所以就在內存里做了一個buffer pool，將已經讀過的數據緩存到buffer pool中，寫的時候也是寫到buffer pool中就返回，buffer pool的功能就是管理數據在磁碟和內存的移動。在buffer pool中數據的管理單位是page。page大小一般幾十KB。一般都可以配置。如果buffer pool中沒有空閑的page，就需要將某一個page提出buffer pool，如果它是dirty page，就需要flush到磁碟，這里又需要一個LRU演算法。一個page包含多條記錄，page的格式需要設計用來支持變長欄位。如果這時宕機了，buffer pool中的數據就丟了。這就需要REDO log，將對數據的修改先寫到redo log中，然後寫buffer pool，然後返回給客戶端，隨後，buffer pool中的dirty page會被刷到數據文件中(NO FORCE)。那麼重啟的時候，數據就能從redo log中恢復。REDO log還沒刷完就刷數據到磁碟可以加快寫入速度，缺點就是恢復的時候需要回放UNDO log，回滾一些還沒有提交的事務的修改。寫log又分為邏輯log和物理log，還有物理邏輯log。簡單說邏輯log就是記錄操作，比如將某個值從1改成2.而物理log記錄具體到record的位置，例如某個page的某個record的某個field，原來的值是多少，新值是多少等。邏輯log的問題是並發情況下不太好恢復成一致。物理log對於某些操作比如create table又過於瑣碎，所以一般資料庫都採用混合的方式。為了跟蹤系統中各種操作的順序，這就需要為log分配id，記做LSN(log sequence number)。系統中記錄各種LSN，比如pageLSN, flushedLSN等等。為了加快宕機恢復速度，需要定期寫checkpoint，checkpoint就是一個LSN。
以上ACID里的C和D有關。下面說A和I，即原子性和隔離性。
這兩個性質通過concurrency control來保證。隔離級別有很多種，最開始有4種，從低到高read uncommitted, read committed, repeatable read, serializable。serializable就是多個事務並發執行的結果和某種順序執行事務的結果相同。除了serializable，其他都有各種問題。比如repeatable read有幻讀問題(phantom)，避免幻讀需要gap lock。read committed有幻讀和不可重復讀問題。後來又多了一些隔離級別，比如snapshot isolation，snapshot isolation也有write skew問題。早期，並發控制協議大多是基於兩階段鎖來做的(2PL)，所以早期只有前面提到的四種隔離級別，後來，又出現一類並發控制協議，統稱為Timestamp Ordering，所以又多了snapshot isolation等隔離級別。關於隔離級別，可以看看這篇論文 http://research.microsoft.com/pubs/69541/tr-95-51.pdf。2PL需要處理deadlock的問題。
Timestamp Ordering大體的思想就是認為事務之間沖突不大，不需要加鎖，只在commit的時候check是否有沖突。屬於一種樂觀鎖。
Timestamp Ordering具體來說包括多種，最常見的MVCC就是這類，還有一類叫做OCC(optimistic concurrency control)。MVCC就是對於事務的每次更新都產生新的版本，使用時間戳做版本號。讀的時候可以讀指定版本或者讀最新的版本。幾乎主流資料庫都支持MVCC，因為MVCC讀寫互相不阻塞，讀性能高。MySQL的回滾段就是用來保存老的版本。MVCC需要有後台線程來做不再需要的版本的回收工作。Postgres的vacuum就是做這事的。OCC和MVCC的區別是，OCC協議中，事務的修改保存在私有空間(比如客戶端)，commit的時候再去檢測沖突，通常的做法是事務開始時看一下自己要修改的數據的最後一次修改的時間戳，提交的時候去check是否這個時間戳變大了，如果是，說明被別人改過了，沖突。沖突後可以回滾或者重試。
上面這些搞定了就實現了資料庫的核心，然後為了性能，需要index，通常有兩種，一種支持順序掃描B+Tree,還有一種是Hash Index。單條讀適合用Hash Index,O(1)時間復雜度，順序掃描只適合用B+Tree，O(logN)復雜度。然後，有些查詢只需要掃描索引就能得到結果，有些查詢直接掃描數據表就能得到結果，有些查詢可以走二級索引，通過二級索引找到數據表然後得到結果。。具體用哪種方式就是優化器的事了。
再外圍一些，關系型資料庫自然需要支持SQL了，由SQL變成最後可以執行的物理執行計劃中間又有很多步，首先SQL通過詞法語法分析生成抽象語法樹，然後planner基於這棵樹生成邏輯執行計劃，邏輯執行計劃的生成通常涉及到等價謂詞重寫，子查詢消除等邏輯層面的優化技術，優化的目的當然是性能。比如等價謂詞重寫，用大於小於謂詞消除like，between .. and..等不能利用索引的謂詞。下一步是邏輯執行計劃生成物理執行計劃，物理執行計劃樹每個節點是一個operator，operator的執行就是實實在在的操作，比如掃表的operator，filter opertor。一個邏輯執行計劃通常可以有多個物理執行對應，選擇哪個就涉及到物理執行計劃優化，這里涉及到經典的cost model，綜合考慮內存,CPU, I/O,網路等。最典型的，三表join，從左到右還是右到左，使用hash join，還是sort merge join等。
⑤ 如何使用mvcc postgresql
而DML語句，會操作當前版本。因此做到了讀寫分離的目的，提高資料庫並發能力。
不同的資料庫，實現MVCC的方法不同。Oracle和MySQL Innodb 存儲引擎類似的使用undo來實現。
對於PostgreSQL資料庫來講，他沒有undo，那麼，PG又是怎麼來實現他自己的MVCC呢？又有那些優缺點呢？
PG用 tuple和tuple的xmin,xmax,cmin,cmax等標記來實現多版本。
xmin：在創建記錄(tuple)時，記錄此時，後面每次update也會更新。
xmax: 在刪除tuple或者lock時，記錄此時；如果記錄沒有被刪除，那麼此時為0。
⑥ 哪個ORM框架可以最好地處理MVCC資料庫設計
1、傳統的建表方式
其實為了方便我們對資料庫表進行管理，Android本身就提供了一個幫助類：SQLiteOpenHelper。這個類集創建和升級資料庫於一身，並且自動管理了資料庫版本，算是一個非常好用的工具。
那我們現在就來試試SQLiteOpenHelper的用法吧。首先你要知道SQLiteOpenHelper是一個抽象類，這意味著如果我們想要使用它的話，就需要創建一個自己的幫助類去繼承它。SQLiteOpenHelper中有兩個抽象方法，分別是onCreate()和onUpgrade()，我們必須在自己的幫助類裡面重寫這兩個方法，然後分別在這兩個方法中去實現創建、升級資料庫的邏輯。本篇文章只需要把注意力放在創建資料庫這里就行了，升級資料庫我們會在下一篇文章中去討論。
新建一個MySQLiteHelper類並讓它繼承SQLiteOpenHelper，這樣一個最基本的資料庫幫助類的代碼如下所示：
[java] view plain
public class MySQLiteHelper extends SQLiteOpenHelper {
public MySQLiteHelper(Context context, String name, CursorFactory factory,
int version) {
super(context, name, factory, version);
}
@Override
public void onCreate(SQLiteDatabase db) {
}
@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
}
}
其中，當資料庫創建的時候會調用onCreate()方法，在這里去執行建表操作就可以了。比如說我們想新建一張news表，其中有title，content，publishdate，commentcount這幾列，分別代表著新聞標題、新聞內容、發布時間和評論數，那麼代碼就可以這樣寫：
[java] view plain
public class MySQLiteHelper extends SQLiteOpenHelper {
public static final String CREATE_NEWS = "create table news ("
+ "id integer primary key autoincrement, "
+ "title text, "
+ "content text, "
+ "publishdate integer,"
+ "commentcount integer)";
public MySQLiteHelper(Context context, String name, CursorFactory factory,
int version) {
super(context, name, factory, version);
}
@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL(CREATE_NEWS);
}
...
}
可以看到，我們把建表語句定義成了一個常量，然後在onCreate()方法中去執行了這條建表語句，news表也就創建成功了。這條建表語句雖然簡單，但是裡面還是包含了一些小的細節，我來解釋一下。首先，根據資料庫的範式要求，任何一張表都應該是有主鍵的，所以這里我們添加了一個自增長的id列，並把它設為主鍵。然後title列和content列都是字元串類型的，commentcount列是整型的，這都很好理解，但是publishdate列該怎麼設計呢？由於SQLite中並不支持存儲日期這種數據類型，因此我們需要將日期先轉換成UTC時間(自1970年1月1號零點)的毫秒數，然後再存儲到資料庫中，因此publishdate列也應該是整型的。
現在，我們只需要獲取到SQLiteDatabase的實例，資料庫表就會自動創建了，如下所示：
[java] view plain
SQLiteOpenHelper dbHelper = new MySQLiteHelper(this, "demo.db", null, 1);
SQLiteDatabase db = dbHelper.getWritableDatabase();
LitePal的基本用法
雖說LitePal宣稱是近乎零配置，但也只是「近乎」而已，它還是需要進行一些簡單配置才可以使用的，那麼我們第一步就先快速學習一下LitePal的配置方法。
快速配置
1. 引入Jar包或源碼
首先我們需要將LitePal的jar包引入到項目當中，可以點擊這里查看LitePal的最新版本，選擇你需要的下載即可。下載好了jar包之後，把它復制到項目的libs目錄中就算是引入成功了，如下圖所示：
如果你不想用jar包的話，也可以把LitePal的源碼下載下來，然後作為一個library庫導入到Eclipse當中，再讓我們的項目去引用這個library庫就可以了。
2. 配置litepal.xml
接著在項目的assets目錄下面新建一個litepal.xml文件，並將以下代碼拷貝進去：
[java] view plain
<?xml version="1.0" encoding="utf-8"?>
<litepal>
<dbname value="demo" ></dbname>
<version value="1" ></version>
<list>
</list>
</litepal>
配置文件相當簡單，<dbname>用於設定資料庫的名字，<version>用於設定資料庫的版本號，<list>用於設定所有的映射模型，我們稍後就會用到。
3. 配置LitePalApplication
由於操作資料庫時需要用到Context，而我們顯然不希望在每個介面中都去傳一遍這個參數，那樣操作資料庫就顯得太繁瑣了。因此，LitePal使用了一個方法來簡化掉Context這個參數，只需要在AndroidManifest.xml中配置一下LitePalApplication，所有的資料庫操作就都不用再傳Context了，如下所示：
[java] view plain
<manifest>
<application
android:name="org.litepal.LitePalApplication"
...
>
...
</application>
</manifest>
當然，有些程序可能會有自己的Application，並在這里配置過了。比如說有一個MyApplication，如下所示：
[java] view plain
<manifest>
<application
android:name="com.example.MyApplication"
...
>
...
</application>
</manifest>
沒有關系，這時只需要修改一下MyApplication的繼承結構，讓它不要直接繼承Application類，而是繼承LitePalApplication類，就可以使用一切都能正常工作了，代碼如下所示：
[java] view plain
public class MyApplication extends LitePalApplication {
...
}
但是，有些程序可能會遇到一些更加極端的情況，比如說MyApplication需要繼承另外一個AnotherApplication，並且這個AnotherApplication還是在jar包當中的，不能修改它的代碼。這種情況應該算是比較少見了，但是如果你遇到了的話也不用急，仍然是有解釋方案的。你可以把LitePal的源碼下載下來，然後把src目錄下的所有代碼直接拷貝到你項目的src目錄下面，接著打開LitePalApplication類，將它的繼承結構改成繼承自AnotherApplication，再讓MyApplication繼承自LitePalApplication，這樣所有的Application就都可以在一起正常工作了。
僅僅三步，我們就將所有的配置工作全部完成了，並且這是一件一本萬利的事情，自此以後，你就可以開心地體驗LitePal提供的各種便利了，就讓我們從建表開始吧。
開始建表
前面在介紹的時候已經說了，LitePal採取的是對象關系映射(ORM)的模式，那麼什麼是對象關系映射呢？簡單點說，我們使用的編程語言是面向對象語言，而我們使用的資料庫則是關系型資料庫，那麼將面向對象的語言和面向關系的資料庫之間建立一種映射關系，這就是對象關系映射了。
但是我們為什麼要使用對象關系映射模式呢？這主要是因為大多數的程序員都很擅長面向對象編程，但其中只有少部分的人才比較精通關系型資料庫。而且資料庫的SQL語言晦澀難懂，就算你很精通它，恐怕也不喜歡經常在代碼中去寫它吧？而對象關系映射模式則很好地解決了這個問題，它允許我們使用面向對象的方式來操作資料庫，從而可以從晦澀難懂的SQL語言中解脫出來。
那麼接下來我們就看一看LitePal中是如何建表的吧。根據對象關系映射模式的理念，每一張表都應該對應一個模型(Model)，也就是說，如果我們想要建一張news表，就應該有一個對應的News模型類。新建一個News類，如下所示：
[java] view plain
package com.example.databasetest.model;
public class News {
}
然後，表中的每一列其實就是對應了模型類中的一個欄位，比如news表中有id、title、content、publishdate、commentcount這幾個列，那麼在News類中就也應該有這幾個欄位，代碼如下所示：
[java] view plain
[java] view plain
public class News {
private int id;
private String title;
private String content;
private Date publishDate;
private int commentCount;
// 自動生成get、set方法
...
}
其中id這個欄位可寫可不寫，因為即使不寫這個欄位，LitePal也會在表中自動生成一個id列，畢竟每張表都一定要有主鍵的嘛。
這里我要特別說明一下，LitePal的映射規則是非常輕量級的，不像一些其它的資料庫框架，需要為每個模型類單獨配置一個映射關系的XML，LitePal的所有映射都是自動完成的。根據LitePal的數據類型支持，可以進行對象關系映射的數據類型一共有8種，int、short、long、float、double、boolean、String和Date。只要是聲明成這8種數據類型的欄位都會被自動映射到資料庫表中，並不需要進行任何額外的配置。
那麼有的朋友可能會問了，既然是自動映射的話，如果News類中有一個字元串欄位我並不想讓它映射到資料庫表中，這該怎麼辦呢？對此，LitePal同樣採用了一種極為輕量的解決方案，只有聲明成private修飾符的欄位才會被映射到資料庫表中，如果你有某一個欄位不想映射的話，只需要將它改成public、protected或default修飾符就可以了。
現在模型類已經建好了，我們還差最後一步，就是將它配置到映射列表當中。編輯assets目錄下的litepal.xml文件，在<list>標簽中加入News模型類的聲明：
[java] view plain
<?xml version="1.0" encoding="utf-8"?>
<litepal>
<dbname value="demo" ></dbname>
<version value="1" ></version>
<list>
<mapping class="com.example.databasetest.model.News"></mapping>
</list>
</litepal>
注意這里一定要填入News類的完整類名。
OK，這樣所有的工作就都已經完成了，現在只要你對資料庫有任何的操作，news表就會被自動創建出來。比如說LitePal提供了一個便捷的方法來獲取到SQLiteDatabase的實例，如下所示：
[java] view plain
SQLiteDatabase db = Connector.getDatabase();
好了，到目前為止你已經算是對LitePal的用法有點入門了，那麼本篇文章的內容就到這里，下篇文章當中我們將學習使用LitePal進行升級表的操作。感興趣的朋友請繼續閱讀 Android資料庫高手秘籍(三)——使用LitePal升級表 。
⑦ 針對PG使用多版本並發控制MVCC機制，所帶來的空間膨脹問題，GBase 8c有什麼解決方案
GBase 8c實現了undo機制，也就是可以在原位置更新數據。這帶來的好處包括
高性能：對插入、更新、刪除等不同負載的業務性能以及資源使用表現相對均衡。相比append update引擎性能提升10%。
運行平穩：性能運行平穩8小時，性能滾降值從13.8%降低至2.5%。
高效存儲：支持最大限度的原位更新， TPCC負載下平均節約空間15%~20%，undo空間統一分配，集中回收，復用效率更高，存儲空間使用更加高效平穩。
⑧ mysql存儲引擎類型有哪些
1、MyISAM
使用這個存儲引擎，每個MyISAM在磁碟上存儲成三個文件。
（1）frm文件：存儲表的定義數據
（2）MYD文件：存放表具體記錄的數據
（3）MYI文件：存儲索引
frm和MYI可以存放在不同的目錄下。MYI文件用來存儲索引，但僅保存記錄所在頁的指針，索引的結構是B+樹結構。下面這張圖就是MYI文件保存的機制：
從這張圖可以發現，這個存儲引擎通過MYI的B+樹結構來查找記錄頁，再根據記錄頁查找記錄。並且支持全文索引、B樹索引和數據壓縮。
支持數據的類型也有三種：
（1）靜態固定長度表
這種方式的優點在於存儲速度非常快，容易發生緩存，而且表發生損壞後也容易修復。缺點是占空間。這也是默認的存儲格式。
（2）動態可變長表
優點是節省空間，但是一旦出錯恢復起來比較麻煩。
（3）壓縮表
上面說到支持數據壓縮，說明肯定也支持這個格式。在數據文件發生錯誤時候，可以使用check table工具來檢查，而且還可以使用repair table工具來恢復。
有一個重要的特點那就是不支持事務，但是這也意味著他的存儲速度更快，如果你的讀寫操作允許有錯誤數據的話，只是追求速度，可以選擇這個存儲引擎。
2、InnoDB
InnoDB是默認的資料庫存儲引擎，他的主要特點有：
（1）可以通過自動增長列，方法是auto_increment。
（2）支持事務。默認的事務隔離級別為可重復度，通過MVCC（並發版本控制）來實現的。
（3）使用的鎖粒度為行級鎖，可以支持更高的並發；
（4）支持外鍵約束；外鍵約束其實降低了表的查詢速度，但是增加了表之間的耦合度。
（5）配合一些熱備工具可以支持在線熱備份；
（6）在InnoDB中存在著緩沖管理，通過緩沖池，將索引和數據全部緩存起來，加快查詢的速度；
（7）對於InnoDB類型的表，其數據的物理組織形式是聚簇表。所有的數據按照主鍵來組織。數據和索引放在一塊，都位於B+數的葉子節點上；
當然InnoDB的存儲表和索引也有下面兩種形式：
（1）使用共享表空間存儲：所有的表和索引存放在同一個表空間中。
（2）使用多表空間存儲：表結構放在frm文件，數據和索引放在IBD文件中。分區表的話，每個分區對應單獨的IBD文件，分區表的定義可以查看我的其他文章。使用分區表的好處在於提升查詢效率。
對於InnoDB來說，最大的特點在於支持事務。但是這是以損失效率來換取的。
3、Memory
將數據存在內存，為了提高數據的訪問速度，每一個表實際上和一個磁碟文件關聯。文件是frm。
（1）支持的數據類型有限制，比如：不支持TEXT和BLOB類型，對於字元串類型的數據，只支持固定長度的行，VARCHAR會被自動存儲為CHAR類型；
（2）支持的鎖粒度為表級鎖。所以，在訪問量比較大時，表級鎖會成為MEMORY存儲引擎的瓶頸；
（3）由於數據是存放在內存中，一旦伺服器出現故障，數據都會丟失；
（4）查詢的時候，如果有用到臨時表，而且臨時表中有BLOB，TEXT類型的欄位，那麼這個臨時表就會轉化為MyISAM類型的表，性能會急劇降低；
（5）默認使用hash索引。
（6）如果一個內部表很大，會轉化為磁碟表。
在這里只是給出3個常見的存儲引擎。使用哪一種引擎需要靈活選擇，一個資料庫中多個表可以使用不同引擎以滿足各種性能和實際需求，使用合適的存儲引擎，將會提高整個資料庫的性能
⑨ mysql mvcc何時創建read view
大部分的MySQL的存儲 引擎，比如InnoDB，Falcon，以及PBXT並不是簡簡單單的使用行鎖機制。它們都使用了行鎖結合一種提高並發的技術，被稱為MVCC（多版本並 發控制）。MVCC並不單單應用在MySQL中，其他的資料庫如Oracle,PostgreSQL,以及其他資料庫也使用這個技術。
MVCC避免了許多需要加鎖的情形以及降低消耗。這取決於它實現的方式，它允許非阻塞讀取，在寫的操作的時候阻塞必要的記錄。