【IT168 专稿】本文的作者是一位拥有25年以上RDBMS(Relational Database Management System 关系型数据库管理系统)相关经验的数据库架构师，目前在Recorded Future公司工作。他认为尽管RDBMS应用广泛(多为MySQL)，但同时NoSQL解决方案也在越来越多地应用，其中MongoDB是目前最流行的一种。

　　也许有人会抱怨，NoSQL并不是一个好的选择。但拥有长时间NoSQL使用经验的DBA会找到它的优势。

　　Recorded Future公司的NoSQL系统环境如下：有几个Tb的数据保存在Mongo中，使用Replication以及Sharding / Clustering。另外，MongoDB运行在Amazon EC2上。

　　因此，为什么我们转向MongoDB?包括两方面原因：

　　1、更好的性能。MongoDB本身并没有更好的性能，但通过使用sharding以及大的in-memory存储(in-memory stores)，可以使其性能更好。

　　2、更好更容易的可扩展性设置。该特性也不是其本身自带的，并且也不是没有瑕疵的。但是MongoDB中内置的sharding效果很不错，很大程序上对应用程序来说是透明的。

　　听起来很棒吧?每个人都希望使自己的应用有更好的性能和可扩展性。为什么不能让MySQL拥有像MongoDB的高扩展性呢?当然，任何方式都会有一定的弊端。

　　需要着重注意的一点是：扩展性是透明的且易于使用和实现，因为NoSQL基本的思想(本例中为一个key-value存储器)非常简单：一个unique key指向一个值，就是这样。即：它很容易shard。而一个包含多个表的关系型schema在这方面要差得多，应该在MySQL中对schema进行简化来使其更容易shard，但如果这么做的话，RDBMS的特点似乎就不存在了。MongoDB可扩展性是MongoDB数据库性能最重要的部分(除了它的in-memory特性)。

　　Amazon EC2的扩展性非常重要，其中包括对内存与CPU能力的限制。限制设置比较宽(如70G RAM)，但总归是一种限制。也许读者会说对于500Gb、1Tb或更多数据来说，70G的限制并不算宽，因此不得不进行shard、cluster或其他工作。而这恰恰就是MongoDB所擅长的，它很容易使数据shard，NoSQL中的简单数据结构意味着它的高透明度。

　　还有其他的选择吗?有!如MySQL Cluster，NimbusDB(即NuoDB)，oracle，Cassandra，等。但我们选择使用MongoDB。

　　因此从一个DBA的角度来看，什么是mongo?基本上没有SQL接口，没有“查询语言”，对用户来说，MongoDB看起来更像一个为变量及排序提供存储空间的JavaScript环境。MongoDB是一个数据库，这种数据库中包含collection，与RDBMS中的表有些类似。一个collection即为一个key-value存储，可以为collection定义一个key，或者MongoDB为用户自动生成。MongoDB没有schema，意味着一个collection中不包含任何预定义的column或其他内容。相反，如果用户存储的某一个对象包含一个名为foo的属性，那么可以将该对象中的一个值与它相关联并插入到对象中。即，如果用户需要，就可以拥有一个属性foo的索引，并且在这种情况下该索引为传统的B-树索引，没有比这更令人兴奋的了!

　　上文中提到的Mongo对象是一种JSON结构，在Mongos内部表示为BSON。要访问之前提到的应用Javascript的collections，像如前所述的那样使用属性foo将一个对象插入到collection bar中，可使用如下语句：

　　相同功能的语句在SQL中表示为：

　　用这种方式，Mongo会将对象关联到一个唯一的id，命名为_id，与SQL RDBMS中的主键类似。要检索刚刚插入的一行，使用如下命令：

　　相同功能的SQL语句为：

　　并且可能得到类似如下内容的返回结果：

　　MongoDB中包含大量内置的Javascript函数，前文中提到的只是非常小的一部分。要使用Mongo，或多或少地需要了解一些Javascript与JSON，如果用户不了解这些就使用MongoDB，也应该在以后使用中慢慢了解学习。

　　我从未用过上述创建的collection(bar)，原因是不必非得使用它们，只需要在访问的时候再去创建即可。数据库也一样。这就是为什么有些用户的Mongo中经常包含写错名称的数据库和collection了，当然在发现拼写错后是可以撤销的。