C#和NewSQL更配 —— CockroachDB入门（可能是C#下的全网首发）

一、CockroachDB是什么

　　CockroachDB（https://www.cockroachlabs.com）是Google备受瞩目的Spanner的开源模仿，承诺提供一种高存活性、强一致性，可横向扩展的SQL数据库。主要的设计目标是全球一致性和可靠性，从蟑螂（cockroach）的命名上是就能看出这点 [ 打不死的小强：) ]。Cockroach节点是均衡的，其设计目标是同质部署（只有一个二进制包）且最小配置。CockroachDB的扩展非常容易，只要一行命令，秒级进行。

二、环境部署

　　官方文档写的非常详细，按照做就好了。部署的文档（https://www.cockroachlabs.com/docs/stable/install-cockroachdb.html），笔者在CentOS上直接使用Binary的方式进行的部署。

　　安装完之后开始启动CockroachDB了，启动命令参考文档（https://www.cockroachlabs.com/docs/stable/start-a-node.html）。

cockroach start –insecure –store=hello-1 –host=192.168.118.21

　　解释下这行命令：启动一个CockroachDB的节点，存储位置为安装所在目录下的hello-1，并且使用192.168.118.21进行host，如果需要还可以指定管理站点的端口和数据库对外端口，对应的参数为 –port = 26257（默认值）、–http-port = 8080（默认值）。

　　OK，启动完之后可以在浏览器输入host中指定的IP:端口进入到管理站点，界面如下图1：

 

　　　　　　　　　　　　　　　　　　        【图1】

三、实战

　　在真正的使用C#代码调用之前首先先创建一个账户，使用cockroach user 命令。需要注意的是，如果之前在启动节点时指定了ip和端口，那么同样需要进行指定。同样的，再创建一个数据库并且给创建的账户设置权限。代码如下：

cockroach user set testaccount –insecure –host=192.168.118.21

 

cockroach sql –insecure -e ‘CREATE DATABASE test’ –host=192.168.118.21

 

cockroach sql –insecure -e ‘GRANT ALL ON DATABASE test TO testaccount’  –host=192.168.118.21

　　其实在安装完CockroachDB之后会自带SQL Client，在这个上面可以运行所有的SQL语句。当然我们这里暂时不讨论这个，有兴趣的小伙伴可以转到（https://www.cockroachlabs.com/docs/stable/use-the-built-in-sql-client.html）。

　　由于CockroachDB支持PostgreSQL的协议，所以我们可以使用C#下比较热门的PostgreSQL驱动，下载地址：https://github.com/npgsql/npgsql 。我们需要使用的其实就是其中的npgsql项目编译出来的dll。好了，开始创建一个表并初始化2条数据：

 

using (var conn = new NpgsqlConnection("Server=192.168.118.21;PORT=26257;User ID=testaccount;Password=testaccount;Database=test;Timeout=0;Command Timeout=0")) {         conn.Open();          conn.ExecuteNonQuery("CREATE TABLE IF NOT EXISTS accounts (id INT PRIMARY KEY, balance INT)");                

       using (var cmd = new NpgsqlCommand(“INSERT INTO accounts (id, balance) VALUES (1, 1000), (2, 250)”,conn))        {               cmd.ExecuteNonQuery();        } }

　　可以看到建表的语句所支持的语法和SQL SERVER还是有一些差别的，可以直接在CREATE TABLE 后面跟判断表是否存在。好了，执行完可以点击管理站点左上角的“DATABASES”选项卡，就可以看到下面的数据库（test）和表（accounts）了，图2：

　　　　　　　　　　　　　　　　　　　　　　　【图2】

 　　好，我们来尝试着读取的一下数据：

using (var conn = new NpgsqlConnection("Server=192.168.118.21;PORT=26257;User ID=testaccount;Password=testaccount;Database=test;Timeout=0;Command Timeout=0")) {     conn.Open();          
    using (var cmd = new NpgsqlCommand("SELECT id, balance FROM accounts", conn))    {                    
     using (var reader = cmd.ExecuteReader(Behavior))      {                        
        while (reader.Read())         {              Console.WriteLine(@" reader[id] is {0}", reader["id"]);              Console.WriteLine(@" reader[balance] is {0}", reader["balance"]);          }       }     }  }

 

　　这里需要注意一点的是。npgsql如果使用连接字符串的方式来初始化连接，那么其默认的连接模式为连接池模式。在此模式下，一但创建的NpgsqlConnection被Dispose()一次之后，后续哪怕再继续实例化一个新的NpgsqlConnection也会报错。如果要使用这种短链接的方式，需要使用NpgsqlConnectionStringBuilder来进行连接的实例化，并且指定 Pooling = true ，如下。

var connString = new NpgsqlConnectionStringBuilder("Server=192.168.118.21;PORT=26257;User ID=testaccount;Password=testaccount;Database=test;Timeout=0;Command Timeout=0") {     Pooling = true
}.ToString();            
using (var conn = new NpgsqlConnection(connString))

 

四、性能测试

　　测试客户端机器是 4核 i5-4300U，数据库所在的机器是 8核 Xeon(R) E5630。为了做一个相应的对比，我在CockroachDB所在的机器装了SQL Server 2017 on Lunix、另外也用了装在同等配置下的windows服务器上的SQL SERVER2008进行对比。见图3（点击图片可查看大图）：

　　　　　　　　　　　　　　　　　　　　　　【图3】

　　大家可以着重看数据库响应时间那列，这里的时间是纯的数据库响应+2次网络I/O的时间，减少数据库访问SDK对结果的影响。但是很明显从”线程时间列“中看出nqgsql中对连接的开销比.net framework中的sqlconnection还是大了2个数量级，所以我们在运用的时候需要考虑封装一层连接池来实现。

　　测试结果得出的结论是：CockroachDB在长连接模式下的性能是SQL SERVER的3倍以上，其它场景完全没法用，所以如果要运用CockroachDB还是要围绕这个模式去做。另外SQL SERVER在自家Windows和Lunix上还是有些小差异的，都使用默认设置，性能上高出几个百分点，当然SQL SERVER的版本不同可能也会带来一些影响，这里没有继续深入测试，结果仅供参考。

五、结语

　　再做上面的一系列工作中，也对CockroachDB的一些信息做了更深入的了解。其目前主要还是围绕着开头说的”可伸缩、跨地域（全球）复制且兼容事务的 ACID 特性的分布式数据库“来做，并不适用于复杂Join或者OLAP型需求的场景。不过其还很年轻，目前只有3岁，从github上的热度来看，其未来的发展还是前途一篇光明的，并且谷歌在Go语言上的投入对CockroachDB的受益是直接的，所以保持持续的关注。

　　另外如果各位的确有跨机房多数据中心的需求，并且几个机房的位置离的不远，能够对NTP（如果对CockroachDB的基于NTP的实现HLC感兴趣，可以转到这篇文章：http://www.jianshu.com/p/8500882ab38c）的时钟误差控制在一定可以接受的范围内，我认为还是值得一试的。毕竟动态扩容和rebalance真的是你手指动动秒秒钟的事情，运维成本非常低。