现今云计算的从业人员对NoSQL一词并不感到陌生，虽然很多技术人员都长期从事关系数据库的工作，但现在他们对NoSQL技术充满期待。对于企业来说，从关系型数据库到NoSQL数据库转变绝对是个需要深思熟虑的大改变。这涉及的不仅是软件的变化，更多的是对于数据存储上观念性的变化。
CouchDB专家兼作者Bradley Holt认为NoSQL并不是反SQL的运动，为对应的工作选择最恰当的工具才是正确的模式。
大多数非关系数据库都具有快速和可伸缩的特性。通过放弃关系存储模型和架构，关系数据库便可脱离由紧密结合的架构所带来对其施加的限制。应用程序也无需再链接数据库内表中的数据。
MongoDB和CouchDB以及RavenDB（RavenDB是基于Mocrosoft .NET framework编写的）等文档数据库除了某些特定的转换外，通常都是通过HTTP为其提供数据，然后将数据存储为JSON（Javascript Object Notation）格式的文档，并提供多种语言的API接口。这三款开源的文档数据库都将简洁、速度和可伸缩性作为其设计的重要指标。RavenDB的创建者Ayende Rahien就表示“RavenDB的设计初衷就旨在快速写入并读取”。
NoSQL——关系数据库的有力补充
现今，NoSQL和文档数据库成为关系数据库的有力补充（而非替代品），同时提供了更多的选择。如果企业准备将数据迁移，那么选择NoSQL的重要标准就是要看CAP（Consistency、Availability和Partition Tolerance），也就是我们所说的一致性、可用性和分区容忍性。但CAP原则要求在分布式系统只能选择一致性、可用性和分区容忍性其中的两项。所以如果企业认为一致性是重要的那么关系数据库理应是优先选择的对象。
例如在银行等应用领域，一致性是非常重要的，这要求必须随时考虑每个数据块。而CAP原则中的可用性也不容忽视，某些领域的数据可用性要比等待所有交易数据收集齐全更为重要。最后在水平缩放时，分区容忍性对于文档数据库显得尤为关键。但MongoDB并不支持复杂的事务，只支持少量的原子操作，所以不适用于“转帐”等对事务和一致性要求很高的场合。这就要求需要一个关系数据库来对交易进行过高级别的控制。
文档数据库的关键特性
RESTful HTTP API
RESTful API设计就是为了消除创建松散耦合服务时的依赖关系，这也正是过去分布式体系结构的缺陷。虽然要映射到一些协议需要依赖于元数据的可用性以及方法等，但REST API的设计目标就是不依赖于任何通信协议。
众多NoSQL数据库都可通过RESTful的方式访问。这样可以通过URI的方式建立数据库连接，而查询和命令则通过HTTP实现。MongoDB和CouchDB都提供了特定语言的API接口，以便编写和执行查询、更新。但MongoDB的默认设置仍然是使用TCP与数据库进行连接。而RavenDB则具备基于.NET的客户端API，可简化与数据库的交互过程。
单个记录中的相关数据
大多数人都错误的认为非关系数据库是一种包含没有相对关系结构的记录的文件。而文档数据库中存储的数据包含形状数据——具有节点的树。数据库中的每个记录都是以文档形式存在的。并具备自我描述的功能，而不依赖于任何其他文档。
示例代码1：文档数据库（MongoDB）中的典型事例
{
"name" : "Jim",
"scores" : [ 75, 99, 87.2 ]
}
示例代码2 CouchDB示例
{
"Subject": "I like Plankton"
"Author": "Rusty"
"PostedDate": "5/23/2006"
"Tags": ["plankton", "baseball", "decisions"]
"Body": "I decided today that I don't like baseball. I like plankton."
}