NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。
创新互联是一家专注于成都网站设计、成都做网站与策划设计,莎车网站建设哪家好?创新互联做网站,专注于网站建设十年,网设计领域的专业建站公司;建站业务涵盖:莎车等地区。莎车做网站价格咨询:028-86922220
键值(Key-Value)存储数据库
这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。[3] 举例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存储数据库。
这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.
文档型数据库
文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。
图形(Graph)数据库
图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。[2] 如：Neo4J, InfoGrid, Infinite Graph.
因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。
创建有效的大数据模型的6个技巧
数据建模是一门复杂的科学，涉及组织企业的数据以适应业务流程的需求。它需要设计逻辑关系，以便数据可以相互关联，并支持业务。然后将逻辑设计转换成物理模型，该物理模型由存储数据的存储设备、数据库和文件组成。
历史上，企业已经使用像SQL这样的关系数据库技术来开发数据模型，因为它非常适合将数据集密钥和数据类型灵活地链接在一起，以支持业务流程的信息需求。
不幸的是，大数据现在包含了很大比例的管理数据，并不能在关系数据库上运行。它运行在像NoSQL这样的非关系数据库上。这导致人们认为可能不需要大数据模型。
问题是，企业确实需要对大数据进行数据建模。
以下是大数据建模的六个提示：
1.不要试图将传统的建模技术强加于大数据
传统的固定记录数据在其增长中稳定且可预测的，这使得建模相对容易。相比之下，大数据的指数增长是不可预测的，其无数形式和来源也是如此。当网站考虑建模大数据时，建模工作应该集中在构建开放和弹性数据接口上，因为人们永远不知道何时会出现新的数据源或数据形式。这在传统的固定记录数据世界中并不是一个优先事项。
2.设计一个系统，而不是一个模式
在传统的数据领域中，关系数据库模式可以涵盖业务对其信息支持所需的数据之间的大多数关系和链接。大数据并非如此，它可能没有数据库，或者可能使用像NoSQL这样的数据库，它不需要数据库模式。
正因为如此，大数据模型应该建立在系统上，而不是数据库上。大数据模型应包含的系统组件包括业务信息需求、企业治理和安全、用于数据的物理存储、所有类型数据的集成、开放接口，以及处理各种不同数据类型的能力。
3.寻找大数据建模工具
有商业数据建模工具可以支持Hadoop以及像Tableau这样的大数据报告软件。在考虑大数据工具和方法时，IT决策者应该包括为大数据构建数据模型的能力，这是要求之一。
4.关注对企业的业务至关重要的数据
企业每天都会输入大量的数据，而这些大数据大部分是无关紧要的。创建包含所有数据的模型是没有意义的。更好的方法是确定对企业来说至关重要的大数据，并对这些数据进行建模。
5.提供高质量的数据
如果组织专注于开发数据的正确定义和完整的元数据来描述数据来自何处、其目的是什么等等，那么可以对大数据模型产生更好的数据模型和关系。可以更好地支持支持业务的数据模型。
6.寻找数据的关键切入点
当今最常用的大数据载体之一就是地理位置，这取决于企业的业务和行业，还
有其他用户需要的大数据常用密钥。企业越能够识别数据中的这些常用入口点，就越能够设计出支持企业关键信息访问路径的数据模型。
执行大数据[注]项目的企业面对的关键决策之一是使用哪个数据库，SQL还是NoSQL?SQL有着骄人的业绩，庞大的安装基础;而NoSQL正在获得可观的收益，且有很多支持者。我们来看看两位专家对这个问题的看法。
专家
·VoltDB公司首席技术官Ryan Betts表示，SQL已经赢得了大型企业的广泛部署，大数据是它可以支持的另一个领域。
·Couchbase公司首席执行官Bob Wiederhold表示，NoSQL是可行的选择，并且从很多方面来看，它是大数据的最佳选择，特别是涉及到可扩展性时。
SQL经历时间的考验，并仍然在蓬勃发展
VoltDB公司首席技术官Ryan Betts
结构化查询语言(SQL)是经过时间考验的胜利者，它已经主宰了几十年，目前大数据公司和组织(例如谷歌、Facebook、Cloudera和Apache)正在积极投资于SQL。
在成为主导技术(例如SQL)后，有时候我们很容易忘记其优越性。SQL的独特优势包括：
1. SQL能够加强与数据的交互，并允许对单个数据库设计提出问题。这是很关键的特征，因为无法交互的数据基本上是没用的，并且，增强的交互性能够带来新的见解、新的问题和更有意义的未来交互。
2. SQL是标准化的，使用户能够跨系统运用他们的知识，并对第三方附件和工具提供支持。
3. SQL能够扩展，并且是多功能和经过时间验证的，这能够解决从快写为主导的传输到扫描密集型深入分析等问题。
4. SQL对数据呈现和存储采用正交形式，一些SQL系统支持JSON和其他结构化对象格式，比NoSQL具有更好的性能和更多功能。
虽然NoSQL的出现带来了一些影响，但SQL仍然主导着市场，并在大数据领域赢得了很多投资和广泛部署。
NoSQL的说法很含糊，对于本次讨论，我借用Rick Cattell对NoSQL的定义，即提供简单操作(例如密钥/数值存储)或简单记录和索引，并专注于这些简单操作的横向可扩展性的系统。
很显然，现在很多新的数据库并不是都一样，认识每种数据库背后的原理以及潜在问题是成功的关键。NoSQL的主要特点使其更适合于特定的问题。例如，图形数据库更适合于数据通过关系组织的情况，而专门的文本搜索系统更适合于需要实时搜索的情况。
在这里，让我们看看SQL系统的主要优势和差异化功能：
* SQL可实现交互性。 SQL是一种声明性查询语言。用户说出他们想要什么(例如，显示过去五年三月份期间顶级客户的地理位置)，数据库内部就会构件算法并提取请求的结果。相比之下，NoSQL编程创新MapReduce是一种程序性查询技术。在用户提出请求时，MapReduce要求用户不仅说出自己想要什么，而且要求他们陈述如何产生答案。
这听起来像一个无趣的技术差异，但这很关键，原因在于：首先，声明性SQL查询更容易通过图形化工具以及点击报告构建器来构建。这让分析师、操作员、管理者和其他不具备软件编程能力的员工进行数据库查询;其次，数据库引擎可以利用内部信息来选择最有效的算法。改变数据库的物理布局或数据库，最佳算法仍然能够计算出来。而在程序性系统中，编程人员需要重新访问和重新编程算法，这是非常昂贵且容易出错的过程。
市场理解这个关键区别。在2010年，谷歌宣布部署SQL来补充MapReduce，主要受内部用户需求所驱动。最近，Facebook发布了Presto(一种SQL部署)来查询其PB级HDFS集群。根据Facebook表示：“随着我们的仓库增长到PB级，以及我们的需求变化，我们清楚地意识到，我们需要一个提供低延时查询的互动系统。”此外，Cloudera也正在构建Impala—另一个基于HDFS的SQL部署。
* SQL是标准化的。 虽然供应商有时候会添加自己的语言到SQL界面，但SQL的核心是标准化的，还有其他规格(例如ODBC和JDBC)提供广泛可用的稳定界面到SQL存储。这带来了一个管理和操作工具生态系统，可以在SQL系统之上设计、监控、检查、探索和构建应用程序。
SQL用户和程序员可用跨多个后端系统重复使用其API和UI知识，减少了应用程序的开发时间。标准化还允许声明性第三方提取、转换、加载(ETL)工具，使企业可以在数据库之间以及跨系统传输数据。
* SQL可扩展。 认为SQL必须牺牲以获得可扩展性的看法，完全是错误的。如前所述，Facebook创建了一个SQL界面来查询PB级数据。SQL能够非常有效地运行极快的ACID传输。SQL对数据存储和索引提供的抽象[注]化允许跨各种问题和数据集大小的一致使用，让SQL可以跨集群复制数据存储有效地运行。使用SQL作为界面独立于构建云、规模或HA系统，SQL中并没有什么在阻止和限制容错、高可用性和复制。事实上，所有现代SQL系统支持云友好型横向可扩展性、复制和容错性。
* SQL支持JSON。 几年前，很多SQL系统增加了XML文档支持。现在，随着JSON成为一种流行的数据交换格式，SQL供应商也纷纷加入了JSON型的支持。基于现在灵活的编程过程和web基础设施的正常运行时间要求，我们很需要结构化数据类型的支持。Oracle 12c、PostgreSQL 9.2、VoltDB和其他支持JSON的数据库，通常具有优于“原生”JSON的性能。
SQL将继续赢得市场份额，并会继续看到新的投资和部署。NoSQL数据库提供专有查询语言或简单的键值语义，而没有更深层次的技术差异化。现代SQL系统提供可扩展性的同时，还支持更丰富的查询语义，并有庞大的用户安装基础，广泛的生态系统整合和深度企业部署。
NoSQL更适合大数据应用程序
Couchbase公司首席执行官Bob Wiederhold
NoSQL越来越多地被认为是关系型数据库的可行替代品，特别是对于大数据应用程序。此外，无模式数据模型通常更适合于现在捕捉和处理的数据种类和类型。
当我们谈论NoSQL领域的大数据时，我们指的是从操作数据库读取和写入。不要将操作数据库与分析数据库混淆，这通常会查看大量数据，并从这些数据获取可视性。
虽然操作数据库的大数据看起来不具有可分析性，但操作数据库通常会存储超大量用户的大型数据集，这些用户经常需要访问数据来实时执行交易。这种数据库的操作规模也解释了NoSQL的关键特性，也就是为什么NoSQL是大数据应用程序的关键的原因。
NoSQL是可扩展性的关键
每次技术行业经历硬件发展的根本性转变时，都会出现一个拐点。在数据库领域，从纵向扩展到横向扩展的转变推动了NoSQL的发展。关系型数据库(包括来自甲骨文和IBM的数据库)是纵向扩展。也就是说，它们是集中式、共享一切的技术，只能通过增加更多昂贵的硬件来扩展。
而NoSQL数据库是分布式横向扩展技术。它们使用了分布式节点集(称为集群)来提供高度弹性扩展功能，让用户可以添加节点来动态处理负载。
分布式横向扩展的做法通常要比纵向做法更加便宜。商业关系型数据库的授权费用也让人望而却步，因为他们的价格是按每台服务器来计算。另一方面，NoSQL数据库通常是开源技术，按照运行的服务器集群收费，而且价格相对便宜。
NoSQL是灵活性的关键
关系型数据库和NoSQL数据模型有很大的不同。关系型模式获取数据，并将数据分配到很多相互关联的表中，这些表通过外键相互应用。
当用户需要对数据集运行查询时，所需信息需要从多个表中收集(通常涉及数百个企业应用程序)，并结合这些信息，再提供给应用程序。同样地，当写入数据时，需要在多个表协调和执行写入。当数据相对较少，并且，数据以较慢速度流入数据库时，关系型数据库通常能够捕捉和存储信息。然而，现在的应用程序通常需要快速写入(和读取)海量数据。
NoSQL数据库采用非常不同的模式。在其核心，NoSQL数据库其实是“NoREL”，或者说非关系型，这意味着它们没有依赖于表以及表之间的联系，以存储和组织信息。例如，以文档为导向的NoSQL数据库获取你想要存储的数据，并采用JSON格式整合到文档中。每个JSON文档可以被你的应用程序视为一个对象。JSON文档可能会提取跨越25个表的数据，将数据集成到一个文档中。
聚合这些信息可能会导致信息重复，但由于存储已不再是一个成本问题，数据模型灵活性、发布所产生文档的简便性以及读取和写入性能提高，让这成为不错的选择。
NoSQL是大数据应用程序的关键
通过第三方(包括社交媒体网站)，数据正变得越来越容易捕捉和访问。这些数据包括：个人用户信息、地理位置数据、用户生产的内容、机器记录数据和传感器产生的数据。企业还可以依赖于大数据来推动其关键任务型应用程序。同时，企业正在转向到NoSQL数据库，因为这种数据库非常适合现在新型的数据类型。
开发人员想要一个灵活的数据库，可以很容易适应新的数据类型，并且，不会受第三方数据供应商的内容结构变化的影响。大多数新数据是非结构化和半结构化，因此，开发人员也需要能够有效存储这些数据的数据库。然而，关系型数据库采用的严格定义的基于模式的做法让其不可能快速整合新数据类型，并且很不适合于非结构化和半结构化数据。
总体来说，随着web和移动应用程序的增加、新的趋势、网上消费者行为的转变以及新的数据类型的出现，行业需要能够提供可扩展的灵活的数据库技术来管理和访问数据。NoSQL技术是有效满足这些需求的唯一可行解决方案。
一般将NoSQL数据库分为四大类：键值(Key-Value)存储数据库、列存储数据库、文档型数据库和图形(Graph)数据库。它们的数据模型、优缺点、典型应用场景。
键值(Key-Value)存储数据库Key指向Value的键值对，通常用hash表来实现查找速度快数据无结构化(通常只被当作字符串或者二进制数据)内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等。
列存储数据库，以列簇式存储，将同一列数据存在一起查找速度快，可扩展性强，更容易进行分布式扩展功能相对局限分布式的文件系统。
文档型数据库，Key-Value对应的键值对，Value为结构化数据，数据结构要求不严格，表结构可变(不需要像关系型数据库一样需预先定义表结构)，查询性能不高，而且缺乏统一的查询语法，Web应用。
图形(Graph)数据库，图结构，利用图结构相关算法(如最短路径寻址，N度关系查找等)，很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案，社交网络，推荐系统等。
nosql是not only sql的意思。是近今年新发展起来的存储系统。当前使用最多的是key-value模型，用于处理超大规模的数据。
以下是摘自百度百科中的一部分
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处：Hadoop、Voldemort、Dynomite，还有其它很多。
NoSQL与关系型数据库设计理念比较
关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。
