讀60行代碼完成的NoSQL數據庫，看數據庫打造面臨的挑戰

作者：Ayende Rahien 2013-07-17 09:42:34

“不要試圖去自建一個數據庫”，從某些角度上來說這個觀點所言非虛。雖然自建的數據從來都不會被真正投入使用、測試等，然而卻是一個非常好的途徑去討論現實數據庫打造中所遇到的挑戰。下面是說的是一個代碼不到60行的鍵值存儲NoSQL數據庫，具備完善的功能、良好的可擴展性并且允許分片。或許它可以稱得上最小的數據庫，然而待完善的方面也不可謂不多。

首先是服務器端代碼：

public class NoSqlDbController : ApiController
{
static readonly ConcurrentDictionary<string, byte[]=""> data =
new ConcurrentDictionary<string, byte[]="">(StringComparer.InvariantCultureIgnoreCase);
public HttpResponseMessage Get(string key)
{
byte[] value;
if(data.TryGetValue(key, out value) == false)
return new HttpResponseMessage(HttpStatusCode.NotFound);
return new HttpResponseMessage
{
Content = new ByteArrayContent(value)
};
}
 
public void Put(string key, [FromBody]byte[] value)
{
data.AddOrUpdate(key, value, (_, __) => value);
}
public void Delete(string key)
{
byte[] value;
data.TryRemove(key, out value);
}
}

然后是客戶端代碼：

public class NoSqlDbClient
{
private readonly HttpClient[] clients;
      
public NoSqlDbClient(string[] urls)
{
clients = new HttpClient[urls.Length];
for (var i = 0; i < urls.Length; i++)
{
clients[i] = new HttpClient { BaseAddress = new Uri(urls[i]) };
}
}
     
public Task PutAsync(string key, byte[] data)
{
var client = clients[key.GetHashCode()%clients.Length];
return client.PutAsync("?key=" + key, new ByteArrayContent(data));
}
     
public Task DeleteAsync(string key, byte[] data)
{
var client = clients[key.GetHashCode() % clients.Length];
return client.DeleteAsync("?key=" + key);
}
     
public async Task<byte[]> GetAsync(string key)
{
var client = clients[key.GetHashCode() % clients.Length];
var r = await client.GetAsync("?key=" + key);
return await r.Content.ReadAsByteArrayAsync();
     
}
}

如代碼所見，這個世界上最小的NoSQL數據庫有著非常好的并發模型，并且基于Last Write Wins策略。可以安全的應對并發問題，然而這樣就萬無一失了?

實際情況并非如此。在實際生產過程中，數據庫不是只需要處理并發問題，比如其它需要注意的地方：

插入時必須檢驗該值是否已存在

修改時必須校驗該值是否同于修改前

實現這些其實非常簡單，你必須為每次修改增加一個元數據字段version。下面是所需修改代碼：

   public class Data
   {
       public byte[] Value;
       public int Version;
   }
     
   static readonly ConcurrentDictionary<string, Data> data =
      new ConcurrentDictionary<string, Data>(StringComparer.InvariantCultureIgnoreCase);
     
   public HttpResponseMessage Get(string key)
   {
       Data value;
       if(data.TryGetValue(key, out value) == false)
           return new HttpResponseMessage(HttpStatusCode.NotFound);
    
       return new HttpResponseMessage
           {
               Headers = { "Version", value.Version },
              Content = new ByteArrayContent(value.Value)
           };
   }
    
  public void Put(string key, [FromBody]byte[] value, int version)
  {
      data.AddOrUpdate(key, () =>
      {// create
         if(version != 0)
             throw new ConcurrencyException();
         return new Data{ Value = value, Version = 1 };
      }, (_, prev) =>
      {// update
          if(prev.Version != version)
            throw new ConcurrencyException();
          return new Data{ Value = value, Version = prev.Version +1 };
      });
}

如上所見，僅僅將代碼量改為雙倍，但是卻解決了很多問題。RavenDB使用了類似的并發寫入控制，雖然RavenDB的ETag機制還可以做更多的事情。然而以上版本實際上是不夠，它只可以做寫入的并發控制，而缺乏讀取的相關操作。

我們還需要對不可重復讀和幻讀做出處理：

不可重復讀指在一個需要對數據進行重復讀取的事務中，第一次讀取到了數據，而在第二次卻讀取不到數據，因為這里存在被他人刪除的情況。

幻讀則是反過來的，第一次未讀取到數據，而在第二次被其他人建立后，又讀取到了數據。

因為你只注重單操作/事務/會話，所以在特定的場景下，可能會產生非常有意思的bug，實際上也沒有辦法去處理這個問題。

另一個需要處理的方面是鎖。有些時候用戶有著非常合理的理由去給某條記錄加上一定時間的鎖，而在多用戶對某條記錄并發修改時加鎖也是唯一的解決方案。鎖又分為Write和ReadWrite兩種。Write鎖只允許其它用戶對被鎖的數據進行讀取，同時禁止其對數據進行修改。在實際情況中，讓用戶立刻失敗也比讓其等待要好的多。

之所以會立即返回失敗是因為你操作的數據被加上了Write鎖，這就意味著該數據已經被修改或者將要被修改。你寫入將會作用在一個過期的數據，所以返回立即失敗會更恰當一點。對于ReadWrite鎖，情況會有所不同。在這種情況下，我們同時禁止了其它用戶的讀操作。這么做一般是為了保障系統的一致性，基本上任何作用在該條記錄上的操作都要等待鎖的失效。

在實踐中，一旦加ReadWrite鎖，你必須要去處理鎖的有效期、手動解鎖、鎖失效檢測、鎖維護等一系列的問題。ReadWrite鎖主要用于在不支持事務的系統中的進行一些事務操作，其它情況下謂之雞肋亦不為過。

責任編輯：王程程來源： Dzone

云計算數據庫 NoSQL