NoSQL误用和常见陷阱分析

1 、被误用的NoSQL：非常容易出现的错误使用方法

（1）循环网络调用：循环获取不好主要原因在网络访问环节的开销增大很多；涉及网络请求时要尽量批量获取。

实例1：

实例2：

（2）不压缩大数据

压缩问题一般分为：不压缩、外部Client压缩、NoSQL存储压缩

NoSQL内部压缩，可以减小存储，提升IO性能，不能提升网络IO性能。CPU消耗不可扩展。

外部压缩，可以减小存储，提升IO性能，并能够提升网络IO性能。CPU消耗可扩展。

压缩可以选用常用的gzip。很大的文件用NoSQL也没意义了，不如存文件的。

（3）跨语言交互：序列化、压缩时是否有对应的方法，尽量选择多种语言都支持的，如JSon、Protobuf、Thrift等格式。

2 、NoSQL 陷阱

（1）官方数据很美好，很少有提及缺点的：使用时更应该关注的是缺点。

（2）场景错误

A、Redis做持久存储：不是很好用，下面三方面问题处理的都不是很好。

• 单点、复制问题
• 数据超过内存性能急剧下降
• 扩容问题

B、Redis做Cache存储：比较适合这种场景。

• 性能极高
• 数据结构丰富
• 可以持久化、避免雪崩现象

（3）细节描述不清楚：不少都是小公司开发的，不规范。

如Ttserver宣称的兼容memcached协议，实际上不支持memcached的flag参数（如标记压缩、序列化），早期版本increment与memcached不一致，Status命令也不一致。

（4）缓存重建：代价大，注意雪崩现象

NoSQL都宣称性能很好，但要注意系统重启后，大部分请求到磁盘，整个系统的性能可能出现抖动，出现连锁雪崩反应。

（5）32bit问题：存储数据不能超过限定大小，数据文件会出现无法读写，整个数据就坏掉了，即使换64位也来不及，非常危险。如32bit系统下，Ttserver-2GB，存储的文件不能超过2G大小；Mongodb现在是2.5GB。

（6）版本升级问题：大部分NoSQL升级比较随意，尤其是个人开发为主，以自己兴趣爱好驱动了。版本升级可能带来兼容问题，可能导致使用场景变化。

避免方法：要多了解NoSQL细节；要有一定的testCase；用一个最好精通。

NoSQL的大部分系统的代码都比较简单，可以直接研究它的代码，可以适当改写其中的代码。

3 、NoSQL 与MySQL

（1）不要犹豫改用MySQL还是NoSQL，在你还没有掌握NoSQL前，最好先在小项目中尝试。

（2）选择NoSQL需要考虑：

• 数据的安全性-是否久经考验，如订单存储，一般选择关系型数据库
• 事务性的保障：
• 数据的重要性：是否允许丢失后rebuild
• 是否有DBA运维：
• 未来的业务需求变化

（3）性能之争：差别在哪里？

普通磁盘的IOPS（几百个），和寻道时间、延迟时间有关。

而顺序读和顺序写吞吐上百MB/S。

如果是SSD会怎样呢？

在普通磁盘上NoSQL的优化点：

• 随机写变顺序写：如Apend操作，索引中更新位置；定期清理无用的数据；一般分文件存储，方便做文件合并和清理。
• 内存索引-热数据cache：索引一般在内存中，热点数据一般都会cache
• 读写算法优化（场景化）：关系数据库功能强大，通用，所以算法复杂；而NoSQL可以针对场景做特定优化。
• 网络协议优化：一般都是get、put等

4 、NoSQL 无处不在

很早就已经在接触NoSQL。如Memcached缓存（没有持久化）、SVN使用的BDB。

5 、为什么要构建自己的NoSQL

• 考察清楚场景和需求
• 现有产品满足需求成本高
• 针对特殊场景，也许比想象的简单
• 可掌控

实例1：IP查询，采用Java中的TreeMap

实例2：通过MySQL构建，封装好接口就可以

6 、NoSQL 运维

运维NoSQL并不容易，同样需要DBA，如：

• 文档齐全吗？
• 网上交流多嘛？
• 周边工具齐全吗？如备份、恢复
• 出现意外问题你能搞定吗？很难求助到人

监控：是DBA、系统运维的根本。除了操作系统最近本的监控，还需要监控：

IO、CPU、延迟、QPS、抖动、数据量。

有些NoSQL产品还没有监控接口，这也是NoSQL产品成熟与否的一个特性。

备份很重要：避免单点，定期数据库备份、开发前做好切换准备（能切换到其他产品）。

资料来源：（孙立的讲座ＰＰＴ）

http://www.infoq.com/cn/presentations/sl-nosql-misuse-common-pitfalls