读60行代码完成的NoSQL数据库,看数据库打造面临的挑战

云计算
“不要试图去自建一个数据库”,从某些角度上来说这个观点所言非虚。虽然自建的数据从来都不会被真正投入使用、测试等,然而却是一个非常好的途径去讨论现实数据库打造中所遇到的挑战。下面是说的是一个代码不到60行的键值存储NoSQL数据库 ,具备完善的功能、良好的可扩展性并且允许分片。或许它可以称得上最小的数据库,然而待完善的方面也不可谓不多。

“不要试图去自建一个数据库”,从某些角度上来说这个观点所言非虚。虽然自建的数据从来都不会被真正投入使用、测试等,然而却是一个非常好的途径去讨论现实数据库打造中所遇到的挑战。下面是说的是一个代码不到60行的键值存储NoSQL数据库 ,具备完善的功能、良好的可扩展性并且允许分片。或许它可以称得上最小的数据库,然而待完善的方面也不可谓不多。

首先是服务器端代码:

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
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);
}
}

然后是客户端代码:

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
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。下面是所需修改代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
   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
相关推荐

2021-09-28 09:25:05

NoSQL数据库列式数据库

2024-02-02 10:51:53

2017-05-25 10:11:46

数据库令牌节点

2020-10-31 22:01:40

NoSQL数据库

2021-09-09 09:28:08

面向列数据库面向行

2011-10-09 09:38:03

OracleNoSQL

2011-05-12 09:19:36

海量数据库管理

2009-10-29 17:03:42

2021-04-07 13:43:07

PythonDash数据库

2009-10-12 10:05:33

数据库机DBA

2014-06-30 14:20:05

NoSQL数据库

2019-09-11 15:10:01

NoSQLSQL数据库

2010-03-16 14:05:19

Cassandra

2022-02-14 09:00:00

SQLNoSQL数据库

2019-07-08 10:36:34

数据库WebNoSQL

2010-04-01 09:45:38

NoSQL

2019-03-20 15:59:11

NoSQLRedis数据库

2011-07-19 09:08:50

JavaNoSQL

2012-05-16 16:25:57

国产数据库

2021-10-26 00:33:00

分布式数据库系统
点赞
收藏

51CTO技术栈公众号