NOSQL的选择

开发中经常遇到是否使用NOSQL的选择。抉择机制如下：

规划需求

• 首先统计你目前的应用规模，包括单位时间存取次数，记录条数，记录占用硬盘空间大小。并基于你的业务在半年以内的增长速度，找到系统的瓶颈是在高并发读写上还是在海量数据的高效存储和访问上。例如每秒上万次读写请求，上亿条记录的表，上T的多媒体数据。

• 分析你的业务是否对事务一致性，读写实时性，复杂查询有需求。如果某些数据有这方面需求能否将其拆分成有需求和没需求的两块。

• 在应用NOSQL之前，想想系统架构设计上能否进行优化，例如读写分离，逻辑切分，数据库分片。利用纯内存key-value数据库来进行告诉缓存。从头应用Nosql对于研发和运维的技术要求很高，你的业务能否承担长时间不推出新功能以及各种运维事故的代价。

选择方案

Key-Value 存储： MemCached,TokyoTyrant,HandleSocket,MemBase,Redis

• 其中MemCached 是没有持久存储的，可以用来做高速缓存。基本上是使用最广的NOSQL方案。
• TokyoTyrant 是有持久存储的，Qzone社交游戏和日本最大的SNS网站Mixi.jp都使用.
• HandleSocket 可以同MySQL无缝集成，是现有方案升级的一个好方案
• Membase 被Zynga 使用来做社交游戏的存储。
• Redis实际上存储的是结构化数据，功能相对较多，可以针对特定类型数据进行操作，使用者较多，有新浪微博，飞信。

Key-文档存储： CouchDB,MongoDB,Riak

• 存储结构化的文档，可以用来做比较灵活的应用。
• 淘宝，CraigList,Foursquare,大众点评在使用MongoDB.
• GitHub,MochiMedia 使用Riak

BigTable类： HBase,Cassandra,Voldemort

• 主要用在海量数据处理和存储
• Facebook的消息数据库使用HBase
• 优酷的数据分析使用HBase
• Linkedin使用Voldemort
• Twitter,Digg.com 使用Cassandra.

国内开源的主要有豆瓣的BeansDB和淘宝的OceanBase,应用案例不多。

实际操作

然后根据自己的业务类型分析，以及性能指标，迁移难易程度来选择适合自己的NoSQL
方案。在应用过程中不要盲目相信网上的评测，还是要自己进行测试，并且灌入自己的
真实数据进行实际操作，才能得到可靠的结果。

然后在架构设计中考虑好如何动态扩展，灾难恢复和数据备份如何实现，现有系统如何
迁移。

转自http://www.dewen.org/q/220/NoSQL%E6%95%B0%E6%8D%AE%E5%BA%93%E5%BA%94%E8%AF%A5%E6%80%8E%E4%B9%88%E9%80%89%E5%8F%96%EF%BC%9F