这几年，NoSQL数据库可以说是风头强劲，甚至有专家和牛人撰文，说关系型数据库已经走到头了，对此，我本人持怀疑态度。并且，花了几个星期时间，研究了一点这方面的东西，把自己的心得记录在下面。
NoSQL数据库的特征:
- 开源、自由使用，有问题到社区寻求帮助；
- 无Scheme限制，使用灵活；
- 分布式支持，易于横向扩展，总体成本低；
- 事务支持不好，数据读写一致性差；
- 对复杂数据结构和复杂SQL的支持不好
第一、开源软件的特征。
开源软件的特征就是由社区这样的非盈利组织维护。对传统行业来讲，最大的问题是开源软件不能给予一个商业承诺，而自己的业务连续性需要得到最大限度的保证。对于一些行业来讲，甚至停电、火灾、地震（甚至战争），都要有业务连续性保证的预案，如果因为使用的基础软件总出问题，而导致数据库停止服务，业务中断，是绝对接受不了的。
对运维来讲，最关心的问题就是出了问题谁负责，谁来快速解决问题保证业务连续性。采用了开源软件，是否意味着只要出问题了，都要运维自己负责（不知是否负得起，如果能负得起，当然很好），都要运维解决？
我之前看到过很多大客户那里，都有数据库厂商（Oracle、DB2）的人常驻在哪里，以备不时的咨询和问题处理。Oracle和IBM在DBA培训上也做得非常好，可以培养出很多专业的数据库维护的工程师和专家，来解决客户的问题，进行例行检查、维护工作。
第二、事务性和读写一致性的需求
当然，现代互联网应用，的确很多场景不需要那么强的事务性和读写一致性，但是并不是所有的应用都如此，比如银行应用，比如和钱有关的财务、OA等等，都有很强的事务性要求，否则，造成的损失由谁来负责呢？
例如，银行转账一定要在事务里从支付方扣钱，增加到向收款方账户，如果事务得不到保障，意味着什么？
反而，复杂SQL还好说一些。可以从设计层面尽量避免。
当初，也就是有这方面的需求，才会有关系型数据库的产生；显著，仍然有这方面的需求，所以，关系型数据库依然是一些关键性应用的基础；在同时，因为有了很多互联网应用对事务性和读写议执行要求不那么强烈，只是要求水平扩展、低成本这一需求，所以，才出现了NoSQL数据库。
基于上面的因素，我认为，NoSQL数据库现在最适合的场景是还是互联网应用和非关键应用，其优势是低成本、大数据量、在廉价硬件上更加容易水平扩展。在这个场景下，出现问题不会造成多大的影响；或者，一些网站之类的，可以基于NoSQL数据库来运营，有了问题从网上找资料解决；再有，就是有足够的资源和技术力量的情况下，培养自己NoSQL方面的工程师，来维护（当然这样最好）自己的数据库。
而非互联网行业（例如金融、财务等等），还是使用商用的关系型数据库稳妥。NoSQL非常适合在传统行业中记录各种日志和数据挖掘这两个场景。原因是：
（1）记录日志一般不是业务流程的关键因素，即便这部分因为各种原因出现问题，不会阻断正常的业务，造成大的问题和社会影响；
（2）一般来讲，日志是一种不需要和其他数据进行较多关联的数据，而且多是松散结构的数据，因此，使用关系型数据库处理，也不能更好的利用关系型数据库的特性。
（3）日志数据量非常大，使用关系型数据库的总体成本很高。
（4）数据挖掘是离线数据，使用分布式的数据库分析有天生的优势（例如使用Hadoop的MapReduce）。
最后，我觉得NoSQL技术的发展，基本都是开源软件在推动，但是如果想有更多的应用使用，还是需要有大厂商的支持，形成开源产品和商业产品并行这种局面。
从我个人的兴趣来讲，非常希望能有更好的NoSQL数据库产品可用。在我自己接触过的这类产品来看，HBase/Hadoop非常不错，问题是版本之间兼容性不好，网上关于HBase/Hadoop的资料满天飞，说哪个版本的都有，基本上都不能通用，害的我折腾好长时间。希望Apache能够对这个东西有足够长远的计划，在设计时能再多考虑一些版本之间的兼容性，那就很不错了。