译者：陈峻
众所周知，被软件开发界经常使用到的数据库主要分为两种类型：SQL和NoSQL。两者到底孰优孰劣，我们又该在何种应用场景下使用呢?本文将和您对此进行深入探讨。
类型定义
SQL，即结构化查询语言，是传统的关系型数据库的查询语言。SQL数据库能够通过简化CRUD操作，处理数据库中的结构化数据。此处的CRUD代表了创建(create)、检索(或读取，retrieve、read)、更新(update)和删除(delete)，四种控制数据的主要操作。
SQL数据库通常被称为关系型数据库管理系统(RDBMS)。由于此类系统主要利用基于行的数据库结构，连接各个数据表之间的相关数据对象，因此传统的RDBMS使用的是SQL语法。我们熟悉的MicrosoftAccess、MySQL、MicrosoftSQLServer、SQLite、OracleDatabase、IBMDB2、以及Backendless等都是RDBMS类型的SQL数据库。
而NoSQL数据库并没有任何固定用于保存数据的结构化数据表。从技术上讲，所有非关系型数据库都可以被称为NoSQL数据库。不同于关系型数据库，NoSQL数据库不但可以被快速地设置，并且只需最少量的预先规划(pre-planning)。常见的NoSQL数据库示例包括：MongoDB、DynamoDB、SimpleDB、CouchDB、CouchBase、OrientDB、InfiniteGraph、Neo4j、FlockDB、Cassandra、以及HBase等。
截至年5月，在DB-Engines上排名前六的数据库系统中，有五个是关系型数据库。其中前四名分别是Oracle、MySQL、MicrosoftSQLServer和PostgreSQL。
下面，让我们来深入探讨SQL和NoSQL数据库的各种优缺点：
SQL的优势
从广义上说，SQL数据库需要对关系模型进行更高级的准备和规划。不过，其好处是您的数据将能够保持一致与整洁。通常，关系模型表示了数据在数据库中的存储方式，例如：每个数据表的结构、以及与其他表的关联方式。
(1)标准化模式
尽管具有标准化模式的SQL数据库、以及关系型数据库，通常被认为“死板”且难以被修改，但是它们有着更多的规范优势。例如，添加到数据库的每个数据对象，都必须符合各种链接表(包括行和列)的公认架构。显然，这对于数据的合规性、完整性、一致性、以及安全性，都是至关重要的。
(2)大量的用户群
由于SQL是一种成熟且应用广泛的编程语言，因此拥有着各种庞大的用户社区，其中不乏许多拥有丰富经验的专家。由他们提供的强大的SQL知识，可以为应用程序的开发人员提供大量的咨询、协作、以及提高技能的机会。
(3)ACID的合规性
由于关系型数据库的数据表结构比较精确，因此SQL数据库具有ACID(请见下面的详述)的特点，能够有助于确保数据表的同步、以及事务的有效性。也就是说，因为SQL数据库可以提供较高数据完整性级别，所以它往往是运行应用程序的优先选择。
原子性(Atomicity)：所有数据和事务的更改都是被完全作为单个操作执行的。如果失败，数据库则不会执行任何更改。
一致性(Consistency)：数据在事务开始和完成时须保持一致且有效。
隔离性(Isolation)：事务能够同步运行，且不产生任何竞争或冲突。它们能够表现得好像是连续发生的那样。
持久性(Durability)：一旦事务完成，其数据结果应当是永久的，且不能被更改的。
比如说，对于一个库存管理系统，最重要的是一旦物品被购买掉，就应当从库存中被移除，以防止产生库存与实际产品数量不符的问题。也就是说，在客户下订单时，系统应及时更新库存、创建新的发货数据对象、更新付款信息、以及更新客户信息等。所有与此相关的数据表，都会得到同步和更新，以完成规定的事务。
(4)几乎不需要代码
SQL是一种对开发人员非常友好的语言。他们使用简单的英语，就可以轻松地学会管理和查询各种关系型数据库。而且他们需要使用的只是简单的关键字，而无需编写代码。
例如，Backendless数据库的查询就可以用SQL来编写。此外，SQL的相关术语还可以用于制作精确的API调用，以实现数据的访问和修改。即使是没有任何SQL查询编写背景的用户，也可以使用DatabaseViews，直观地创建各种查询。
SQL的缺点
硬件
SQL数据库只适合垂直方向的扩展。这意味着，您只能通过在现有的服务器上，增加诸如CPU、SSD和RAM之类的部件，或购买更快、更昂贵的服务器，以实现扩容。随着业务数据的不断增长，您会被持续要求增加硬盘空间，以及具有更优性能的主机，来承载更新、更先进的技术。正因为如此，由它产生的硬件淘汰率也会更高。
现代化SQL数据库往往会用到分片(sharding)的过程。分片技术可以在具有相同模式的多个数据表中，通过分离或分区数据，来实现水平扩展。例如，开发人员无需在同一个数据表中存储,个对象，而只要创建两个具有相同模式的数据表，并保证每个表都存储50,个对象即可。而且两张表之间没有重复性。
当然，使用诸如Backendless之类的无服务器托管服务，也可以缓解扩展性的问题。该数据系统可以为您管理自动化的扩展，既省去了物理服务器的管理，又实现了大规模的数据库效能。
过于死板
SQL数据库的传统关系模型或模式，必须在使用之前被事先定义好。而且一旦完成了定义，也就丧失了部分灵活性。即：任何调整都可能会成为资源密集型的负担。因此，开发者在将数据库投入生产环境之前，必须在规划设计上投入大量的时间。
当然，Backendless可以让开发人员即便是在应用程序启动之后，也可以随时修改架构，添加新的数据表和列，以及建立关系等，相较传统SQL数据库，具有更大的灵活性。因此，Backendless系统非常适合早期的产品开发，毕竟开发过程的初期不会被锁定在某一固定的模式中。
数据规范化
开发关系型数据库的一项目标便是消除数据的重复。每张数据表都具有不同的信息。这些信息可以通过一些常用的值(如序列号)进行查询和连接。不过，当SQL数据库的变化过于频繁时，在多张数据表之间进行连接和查询，一旦碰到单个查询所需的数据表过多的情况，系统的速度要么会被拖慢，要么需要大量调用相应的处理能力。
传统的资源密集型升级和扩展
如前所述，SQL数据库的纵向扩展能力需要通过扩大硬件投资来实现。显然，此举不但费钱而且费时，因此一些组织会试图让开发人员通过编程的方式，实现分区和水平扩展。例如，Backendless会以基础架构即服务(IaaS)的形式，为您自动管理扩展的过程，处理服务器的维护，以及资源的分配等艰巨任务，以便用户专注于构建出色的产品，而非数据库的增长。
NoSQL的优势
查询速度
由于NoSQL查询是非规范化的，而特定查询所需的所有信息通常会被存储在一起，因此开发者能够对正在处理的大量数据进行轻松地查询，无需担心出现重复的数据。同时，NoSQL对于简单查询的响应也非常快。
持续可用性
对于NoSQL数据库而言，由于数据分布在不同的区域和多个服务器上，因此，NoSQL数据库不但消除了单点故障，减少了停机时间，而且更具有扩展性、稳定性、以及持续可用性。
敏捷
NoSQL数据库通过为开发人员提供了足够的灵活性，以协助提高他们的生产力和创造力。它们不但不会受到行和列的约束，并且其模式也不需要预先定义。此外，由于NoSQL数据库是动态的，因此它可以处理包括：多态化、半结构化、结构化、以及非结构化等各种类型的数据。
应用程序开发人员可以直接构建并开始使用NoSQL数据库，而无需花费精力和时间去进行前期规划。当需求发生变化、或需要添加新的数据类型时，它能够按需修改，以满足不同数据类型和不断变化的功能需求。
低成本扩展
NoSQL数据库的水平扩展能力具有一定的成本效益。与昂贵的硬件升级不同，此类数据库可以通过简单地添加云实例、或虚拟服务器，来实现低成本的扩展。此外，许多开源的NoSQL数据库也为软件开发公司提供了廉价的数据库选择。
NoSQL的缺点
没有标准化的语言
由于没有统一的用于执行NoSQL查询的固定语言，因此我们在查询不同的NoSQL数据库类型的数据时，所使用的语法会有所不同。这就导致了与只需学习一种SQL语言相比，NoSQL的学习曲线会更加陡峭。此外，由于出现得较晚，开发团队内可能缺乏研发与实施NoSQL系统的、有经验的人员，因此团队需要增加在培训或引进人才方面的成本。
执行复杂查询的效率低下
如果NoSQL数据库中存在着丰富的数据结构，那么会因为缺乏可执行复杂查询的标准接口，而导致查询效率的低下。而且，由于数据结构的原因，就算执行简单的NoSQL查询，也可能需要一定的编程技巧。显然，这对于倡导无代码化的开发人员而言，会是一种挑战。
专家数量有待增加
不可否认，已有越来越多开发人员愿意使用NoSQL数据库，并且在不断地壮大着其相应的社区。但是，相对于成熟的SQL社区，该领域的专家和顾问可能需要更多的时间，去解决那些未曾被记录的NoSQL问题。
数据检索不一致
由于NoSQL数据库是分布式的，数据在被快速获得的同时，其查询结果可能不会返回的是最新、最准确的数据信息。毕竟分布式方法会使得数据库，根据查询服务器的不同，而持续返回不同的数据值。
相对于前面提到的ACID级别，许多NoSQL数据库更符合BASE标准(译者注：是基本可用--BasicallyAvailable、软状态--Softstate和最终一致性--Eventuallyconsistent，三个短语的简写)。显然，NoSQL更重视的是可用性与速度。可以说，数据检索的不一致性，是NoSQL数据库的主要缺点之一。
小结
综上所述，SQL和NoSQL数据库都有着各自的适用场景，并能满足特定的数据需求与应用目标。您可以根据自己手头项目的实际特点，权衡两者的利弊，做出合适的选择。当然，您的选择也不一定是排他的。您完全可以将两者结合起来使用，让每种数据库类型都能够发挥各自的优势。事实上，许多公司在其云端架构中、甚至是在同一个应用程序中，正在同时使用这两种类型的数据库。