hadoop架构：大数据对设计人员要求变高，设计nosql需谨慎

现在hadoop很火，大数据很火。确实大数据已经是未来方向，而且这个肯定是以后的趋势。因为有太多的企业需要客户行为分析，数据统计等。

hadoop与之相应的nosql，hbase，hive等其他数据库变得非常火。

现在很多公司已经被使用，而且还有更多的公司想要利用这一项新技术。

首先来看一下，我们为什么想使用nosql。

nosql优点

• 分布式
  

       这可能是我们选择nosql的根本原因，面临海量的数据，我们能够通过增加节点来存储数据

• 查询快速
  

       nosql数据库的设计，采用key-value的方式。输入key能够快速查询结果


nosql缺点

• 非结构化数据
  

由于不使用SQL，NoSQL数据库系统不具备高度结构化查询等特性。没有传统SQL强大的查询处理能力，缺乏对结构化数据处理的有力支撑，使得NOSQL在大部分场景下必须依赖RDBMS出现。以致于现在出现了NewSQL这么个概念。

• 数据准确性待提高
  

很多NOSQL产品不能提供ACID（原子性、一致性、隔离性和耐久性）的操作，比如HBASE。不能提供事务能力，对于数据错误、异常恢复等产生影响，不适合要求数据质量的场景。

• 没有统一的规范
  

不同的NoSQL数据库都有自己的查询语言， 这使得很难规范应用程序接口，增加了持久层应用的复杂度。同时。不同的操作语言对于人员能力提出了新的要求，上NOSQL意味着更高的人力成本。

• 缺乏商业支持
  

大部分NOSQL产品开源，导致缺乏商业化的技术团队支持，增加了客户的顾虑，也提高了部署团队的能力要求。这一点在我上个项目实施Hadoop时，就在客户方遇到了较大的阻力，客户担心最终的平台运维缺乏保障。当然，这里面也存在一些机遇。

上面我们从宏观角度来了解nosql，这让我们来选择是否使用nosql。

那么如果使用nosql，我们会遇到什么问题


1. 在系统层次，数据模型为键值。没 有能设计单一的、定义良好的数据模型的熟练专家，无论采用何种技术，都有其缺点。数据模型可能遭受数据对象重复的折磨（非规范化模型）。由于不同的开发者 采用不同的对象模型且映射到持久模型时可能产生此类现象 。在系统层面上，人们还必须了解所选择的数据服务的局限性，与其大小、每秒的操作次数，以及并发模型等无关。

2. 在结构层次，两个主要问题是接口和互操作性。NoSQL的数据服务的接口有待规范。即使是DHT，这是一个简单的接口，仍然没有标准的语义，其中包括事务、非阻塞API等。每个DHT的服务使用其自己的一套接口。另一个大问题是不同的数据结构，如DHT和二叉树，只是作为一个例子，共享数据对象。所有这些服务中，指针没有内在的语义。 事实上，这些服务中，处理互操作性是开发者的职责，这一点很很重要，尤其是当需要数据被多个服务访问时 。一个简单的例子：后台工作由Java实现，Web服务类工作由PHP实现，数据可以被轻易地从两个域访问数据吗？显然，人们可以使用Web服务作为前端 数据访问层，但是，事情变得更复杂，并降低了业务敏捷性，灵活性和性能，同时增加了开发工作量。

3. 转向操作领域。最大的困难在于，在云或一组固定的服务器环境下，操作环境需要一套工具，不仅可扩展性好，而且还要可管理并且稳定。 当出现错误时，它不应该需要通过整个环境链和上溯到开发者层次来诊断问题。事实上，这正是运营经理的噩梦 。你有没有试过让开发人员诊断为什么支付系统不能正常工作，而他在一间酒吧喝啤酒？我确信该开发者岁月中将被他对工作的奉献精神留下深刻的印象，但这是一 种来打动别人的相当昂贵的方式 ? 操作需要系统化和自包含。目前市场上可用的的NoSQL服务，这是不容易实现的，即使在诸如亚马逊的管理环境



4.从设计角度，由于nosql对于sql操作支持有限。我们必须确定我们需要什么结果。也就是说查询必须是固定。
在这里就需要跟传统数据库设计做对比：传统数据库开发，在国内说白了点，就是我们现有一个基本的架构。确定架构之后，有些甚至程序自己就来设计数据库，设计程序。
那么如果出现问题该怎么办？
没有问题，增加一个字段就好了。这样修改需要成本。但是还是能修改的。
但是面临nosq数据库的设计。如果场景还没有明确，笼统的来设计nosql数据库，造成的损失将是非常大的。
这里之举一个简单的例子。
我们在设计nosql的时候，不可能简单的就是两个key-value值。
我们为了提高查询效率，其中把两个字段和起来，作为key，这是非常常见的一种设计方式。如果场景不确定，那么我们很有可能需要对key，进行在此拆分，然后再次整合。
面对数据库底层的改变，关系型数据库也在尽量避免，而对于nosql数据的修改，则更应该避免。


总结：对于架构师，项目经理来讲，可能对与nosql接触的时间不是太长，所以在设计nosql数据库应该谨慎。