nosql项目设计总结,nosql数据库设计

一、NoSQL数据库简介

Web1.0的时代，数据访问量很有限，用一夫当关的高性能的单点服务器可以解决大部分问题。

随着Web2.0的时代的到来，用户访问量大幅度提升，同时产生了大量的用户数据。加上后来的智能移动设备的普及，所有的互联网平台都面临了巨大的性能挑战。

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。

NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。

Memcache Memcache Redis Redis MongoDB MongoDB 列式数据库 列式数据库 Hbase Hbase

HBase是Hadoop项目中的数据库。它用于需要对大量的数据进行随机、实时的读写操作的场景中。

HBase的目标就是处理数据量非常庞大的表，可以用普通的计算机处理超过10亿行数据，还可处理有数百万列元素的数据表。

Cassandra Cassandra

Apache Cassandra是一款免费的开源NoSQL数据库，其设计目的在于管理由大量商用服务器构建起来的庞大集群上的海量数据集(数据量通常达到PB级别)。在众多显著特性当中，Cassandra最为卓越的长处是对写入及读取操作进行规模调整，而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程。

主要应用：社会关系，公共交通网络，地图及网络拓谱(n*(n-1)/2)

相关问答

Q1: nosql数据库是什么 具有代表性以key-value的形式存储的

什么是NoSQL

大家有没有听说过“NoSQL”呢?近年，这个词极受关注。看到“NoSQL”这个词，大家可能会误以为是“No!SQL”的缩写，并深感愤怒：“SQL怎么会没有必要了呢?”但实际上，它是“Not Only SQL”的缩写。它的意义是：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。

为弥补关系型数据库的不足，各种各样的NoSQL数据库应运而生。

为了更好地了解本书所介绍的NoSQL数据库，对关系型数据库的理解是必不可少的。那么，就让我们先来看一看关系型数据库的历史、分类和特征吧。

关系型数据库简史

1969年，埃德加?6?1弗兰克?6?1科德(Edgar Frank Codd)发表了划时代的论文，首次提出了关系数据模型的概念。但可惜的是，刊登论文的《IBM Research Report》只是IBM公司的内部刊物，因此论文反响平平。1970年，他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文，终于引起了大家的关注。

科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升，加之使用简单、性能优越等优点，关系型数据库得到了广泛的应用。

通用性及高性能

虽然本书是讲解NoSQL数据库的，但有一个重要的大前提，请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低，它具有非常好的通用性和非常高的性能”。毫无疑问，对于绝大多数的应用来说它都是最有效的解决方案。

突出的优势

关系型数据库作为应用广泛的通用型数据库，它的突出优势主要有以下几点:

保持数据的一致性(事务处理)

由于以标准化为前提，数据更新的开销很小(相同的字段基本上都只有一处)

可以进行JOIN等复杂查询

存在很多实际成果和专业技术信息(成熟的技术)

这其中，能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下，用关系型数据库是肯定没有错的。但是有些情况不需要JOIN，对上述关系型数据库的优点也没有什么特别需要，这时似乎也就没有必要拘泥于关系型数据库了。

关系型数据库的不足

不擅长的处理

就像之前提到的那样，关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库，并不能完全适应所有的用途。具体来说它并不擅长以下处理：

大量数据的写入处理

为有数据更新的表做索引或表结构(schema)变更

字段不固定时应用

对简单查询需要快速返回结果的处理

。。。。。。

NoSQL数据库

为了弥补关系型数据库的不足(特别是最近几年)，NoSQL数据库出现了。关系型数据库应用广泛，能进行事务处理和JOIN等复杂处理。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。

易于数据的分散

如前所述，关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的，就是说，各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散。相反，NoSQL数据库原本就不支持JOIN处理，各个数据都是独立设计的，很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上，减少了每个服务器上的数据量，即使要进行大量数据的写入操作，处理起来也更加容易。同理，数据的读入操作当然也同样容易。

提升性能和增大规模

下面说一点题外话，如果想要使服务器能够轻松地处理更大量的数据，那么只有两个选择：一是提升性能，二是增大规模。下面我们来整理一下这两者的不同。

首先，提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法，程序方面也不需要进行变更，但需要一些费用。若要购买性能翻倍的服务器，需要花费的资金往往不只是原来的2倍，可能需要多达5到10倍。这种方法虽然简单，但是成本较高。

另一方面，增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更，但由于使用廉价的服务器，可以控制成本。另外，以后只要依葫芦画瓢增加廉价服务器的数量就可以了。

不对大量数据进行处理的话就没有使用的必要吗？

NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话，NoSQL数据库的应用就没有意义吗?

答案是否定的。的确，它在处理大量数据方面很有优势。但实际上NoSQL数据库还有各种各样的特点，如果能够恰当地利用这些特点将会是非常有帮助。具体的例子将会在第2章和第3章进行介绍，这些用途将会让你感受到利用NoSQL的好处。

希望顺畅地对数据进行缓存(Cache)处理

希望对数组类型的数据进行高速处理

希望进行全部保存

多样的NoSQL数据库

NoSQL数据库存在着“key-value存储”、“文档型数据库”、“列存储数据库”等各种各样的种类，每种数据库又包含各自的特点。下一节让我们一起来了解一下NoSQL数据库的种类和特点。

NoSQL数据库是什么

NoSQL说起来简单，但实际上到底有多少种呢?我在提笔的时候，到NoSQL的官方网站上确认了一下，竟然已经有122种了。另外官方网站上也介绍了本书没有涉及到的图形数据库和对象数据库等各个类别。不知不觉间，原来已经出现了这么多的NoSQL数据库啊。

本节将为大家介绍具有代表性的NoSQL数据库。

key-value存储

这是最常见的NoSQL数据库，它的数据是以key-value的形式存储的。虽然它的处理速度非常快，但是基本上只能通过key的完全一致查询获取数据。根据数据的保存方式可以分为临时性、永久性和两者兼具三种。

临时性

memcached属于这种类型。所谓临时性就是 “数据有可能丢失”的意思。memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止的时候，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据(旧数据会丢失)。

在内存中保存数据

可以进行非常快速的保存和读取处理

数据有可能丢失

永久性

Tokyo Tyrant、Flare、ROMA等属于这种类型。和临时性相反，所谓永久性就是“数据不会丢失”的意思。这里的key-value存储不像memcached那样在内存中保存数据，而是把数据保存在硬盘上。与memcached在内存中处理数据比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的。但数据不会丢失是它最大的优势。

在硬盘上保存数据

可以进行非常快速的保存和读取处理(但无法与memcached相比)

数据不会丢失

两者兼具

Redis属于这种类型。Redis有些特殊，临时性和永久性兼具，且集合了临时性key-value存储和永久性key-value存储的优点。Redis首先把数据保存到内存中，在满足特定条件(默认是15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的key发生变更)的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。

同时在内存和硬盘上保存数据

可以进行非常快速的保存和读取处理

保存在硬盘上的数据不会消失(可以恢复)

适合于处理数组类型的数据

面向文档的数据库

MongoDB、CouchDB属于这种类型。它们属于NoSQL数据库，但与key-value存储相异。

不定义表结构

面向文档的数据库具有以下特征：即使不定义表结构，也可以像定义了表结构一样使用。关系型数据库在变更表结构时比较费事，而且为了保持一致性还需修改程序。然而NoSQL数据库则可省去这些麻烦(通常程序都是正确的)，确实是方便快捷。

可以使用复杂的查询条件

跟key-value存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据。虽然不具备事务处理和JOIN这些关系型数据库所具有的处理能力，但除此以外的其他处理基本上都能实现。这是非常容易使用的NoSQL数据库。

不需要定义表结构

可以利用复杂的查询条件

面向列的数据库

Cassandra、Hbase、HyperTable属于这种类型。由于近年来数据量出现爆发性增长，这种类型的NoSQL数据库尤其引人注目。

面向行的数据库和面向列的数据库

普通的关系型数据库都是以行为单位来存储数据的，擅长进行以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被称为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。

高扩展性

面向列的数据库具有高扩展性，即使数据增加也不会降低相应的处理速度(特别是写入速度)，所以它主要应用于需要处理大量数据的情况。另外，利用面向列的数据库的优势，把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同，应用起来十分困难。

高扩展性(特别是写入处理)

应用十分困难

最近，像Twitter和Facebook这样需要对大量数据进行更新和查询的网络服务不断增加，面向列的数据库的优势对其中一些服务是非常有用的，但是由于这与本书所要介绍的内容关系不大，就不进行详细介绍了。

总结：

NoSQL并不是No-SQL，而是指Not Only SQL。

NoSQL的出现是为了弥补SQL数据库因为事务等机制带来的对海量数据、高并发请求的处理的性能上的欠缺。

NoSQL不是为了替代SQL而出现的，它是一种替补方案，而不是解决方案的首选。

绝大多数的NoSQL产品都是基于大内存和高性能随机读写的（比如具有更高性能的固态硬盘阵列），一般的小型企业在选择NoSQL时一定要慎重！不要为了NoSQL而NoSQL，可能会导致花了冤枉钱又耽搁了项目进程。

NoSQL不是万能的，但在大型项目中，你往往需要它！

Q2: 为什么要使用NoSQL？NOSQL的优势

这次的NoSQL专栏系列将先整体介绍NoSQL，然后介绍如何把NoSQL运用到自己的项目中合适的场景中，还会适当地分析一些成功案例，希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。

NoSQL概念随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。）

NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。

在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。

到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。

Memcached+MySQL

后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。

Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。当时，如果你去面试，你说你有Memcached经验，肯定会加分的。

Mysql主从读写分离

由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

MySQL的扩展性瓶颈

在互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变更，可能又需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。

关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。

NOSQL的优势易扩展NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。

总结NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。

Q3: 什么是nosql

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与关系型数据库设计理念比较

关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。

Q4: NoSQL数据库是否意味着缺乏安全性？

NoSQL薄弱的安全性会给企业带来负面影响 。Imperva公司创始人兼CTO Amichai Shulman如是说。在新的一年中，无疑会有更多企业开始或筹划部署NoSQL。方案落实后就会逐渐发现种种安全问题，因此早做准备才是正确的选择。 作为传统关系型数据库的替代方案，NoSQL在查询中并不使用SQL语言，而且允许用户随时变更数据属性。此类数据库以扩展性良好著称，并能够在需要大量应用程序与数据库本身进行实时交互的交易处理任务中发挥性能优势，Couchbase创始人兼产品部门高级副总裁James Phillips解释称：NoSQL以交易业务为核心。它更注重实时处理能力并且擅长直接对数据进行操作，大幅度促进了交互型软件系统的发展。Phillips指出。其中最大的优势之一是能够随时改变(在属性方面)，由于结构性的弱化，修改过程非常便捷。 NoSQL最大优势影响其安全性 NoSQL的关键性特色之一是其动态的数据模型，Shulman解释道。我可以在其运作过程中加入新的属性记录。因此与这种结构相匹配的安全模型必须具备一定的前瞻性规划。也就是说，它必须能够了解数据库引入的新属性将引发哪些改变，以及新加入的属性拥有哪些权限。然而这个层面上的安全概念目前尚不存在，根本没有这样的解决方案。 根据Phillips的说法，某些NoSQL开发商已经开始着手研发安全机制，至少在尝试保护数据的完整性。在关系型数据库领域，如果我们的数据组成不正确，那么它将无法与结构并行运作，换言之数据插入操作整体将宣告失败。目前各种验证规则与完整性检查已经比较完善，而事实证明这些验证机制都能在NoSQL中发挥作用。我们与其他人所推出的解决方案类似，都会在插入一条新记录或是文档型规则时触发，并在执行过程中确保插入数据的正确性。 Shulman预计新用户很快将在配置方面捅出大娄子，这并非因为IT工作人员的玩忽职守，实际上主要原因是NoSQL作为一项新技术导致大多数人对其缺乏足够的知识基础。Application Security研发部门TeamSHATTER的经理Alex Rothacker对上述观点表示赞同。他指出，培训的一大问题在于，大多数NoSQL的从业者往往属于新生代IT人士，他们对于技术了解较多，但往往缺乏足够的安全管理经验。 如果他们从传统关系型数据库入手，那么由于强制性安全机制的完备，他们可以在使用中学习。但NoSQL，只有行家才能通过观察得出正确结论，并在大量研究工作后找到一套完备的安全解决方案。因此可能有90%的从业者由于知识储备、安全经验或是工作时间的局限而无法做到这一点。 NoSQL需在安全性方面进行优化 尽管Phillips认同新技术与旧经验之间存在差异，但企业在推广NoSQL时加大对安全性的关注会起到很大程度的积极作用。他认为此类数据存储机制与传统关系类数据库相比，其中包含着的敏感类信息更少，而且与企业网络内部其它应用程序的接触机会也小得多。 他们并不把这项新技术完全当成数据库使用，正如我们在收集整理大量来自其它应用程序的业务类数据时，往往也会考虑将其作为企业数据存储机制一样，他补充道。当然，如果我打算研发一套具备某种特定功能的社交网络、社交游戏或是某种特殊web应用程序，也很可能会将其部署于防火墙之下。这样一来它不仅与应用程序紧密结合，也不会被企业中的其它部门所触及。 但Rothacker同时表示，这种过度依赖周边安全机制的数据库系统也存在着极其危险的漏洞。一旦系统完全依附于周边安全模型，那么验证机制就必须相对薄弱，而且缺乏多用户管理及数据访问方面的安全保护。只要拥有高权限账户，我们几乎能访问存储机制中的一切数据。举例来说，Brian Sullivan就在去年的黑帽大会上演示了如何在完全不清楚数据具体内容的情况下，将其信息罗列出来甚至导出。 而根据nCircle公司CTO Tim ‘TK’ Keanini的观点，即使是与有限的应用程序相关联，NoSQL也很有可能被暴露在互联网上。在缺少严密网络划分的情况下，它可能成为攻击者窥探存储数据的薄弱环节。因为NoSQL在设计上主要用于互联网规模的部署，所以它很可能被直接连接到互联网中，进而面临大量攻击行为。 其中发生机率最高的攻击行为就是注入式攻击，这也是一直以来肆虐于关系类数据库领域的头号公敌。尽管NoSQL没有将SQL作为查询语言，也并不代表它能够免受注入式攻击的威胁。虽然不少人宣称SQL注入在NoSQL这边不起作用，但其中的原理是完全一致的。攻击者需要做的只是改变自己注入内容的语法形式，Rothacker解释称。也就是说虽然SQL注入不会出现，但JavaScript注入或者JSON注入同样能威胁安全。 此外，攻击者在筹划对这类数据库展开侵袭时，也很可能进一步优化自己的工具。不成熟的安全技术往往带来这样的窘境：需要花费大量时间学习如何保障其安全，但几乎每个IT人士都能迅速掌握攻击活动的组织方法。因此我认为攻击者将会始终走在安全部署的前面，Shulman说道。遗憾的是搞破坏总比防范工作更容易，而我们已经看到不少NoSQL技术方面的公开漏洞，尤其是目前引起热议的、以JSON注入为载体的攻击方式。 NoSQL安全性并非其阻碍 然而，这一切都不应该成为企业使用NoSQL的阻碍，他总结道。我认为归根结底，这应该算是企业的一种商业决策。只要这种选择能够带来吸引力巨大的商业机遇，就要承担一定风险，Shulman解释道。但应该采取一定措施以尽量弱化这种风险。 举例来说，鉴于数据库对外部安全机制的依赖性，Rothacker建议企业积极考虑引入加密方案。他警告称，企业必须对与NoSQL相对接的应用程序代码仔细检查。换言之，企业必须严格挑选负责此类项目部署的人选，确保将最好的人才用于这方面事务，Shulman表示。当大家以NoSQL为基础编写应用程序时，必须启用有经验的编程人员，因为客户端软件是抵挡安全问题的第一道屏障。切实为额外缓冲区的部署留出时间与预算，这能够让员工有闲暇反思自己的工作内容并尽量多顾及安全考量多想一点就是进步。综上所述，这可能与部署传统的关系类数据库也没什么不同。 具有讽刺意味的是，近年来数据库应用程序在安全性方面的提升基本都跟数据库本身没什么关系，nCircle公司安全研究及开发部门总监Oliver Lavery如是说。

Q5: 如何设计出一款NoSql数据库系统？

思路如下：

1 数据库要以某种格式保存到磁盘上

2 有利于对数据的保存，查询以及修改的语法

3 要支持高级编程语言，结合应用程序的api接口