这里需要注意一点的是。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感兴趣，可以转到这篇文章： ）的时钟误差控制在一定可以接受的范围内，我认为还是值得一试的。毕竟动态扩容和rebalance真的是你手指动动秒秒钟的事情，运维成本非常低。