MongoDB01-MongoDB简介

• MongoDB是一个高性能、开源、无模式的文档型数据库，由C++语言编写，旨在为Web应用提供可扩展的高性能数据存储解决方案，是当前NoSql数据库中比较热门的一种。
• MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库中功能最丰富、最像关系数据库的。它支持的数据结构非常松散，是类似于json的bson格式，因此可存储较复杂的数据类型。
• MongoDB最大的特点是支持非常强大的查询语言，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且支持对数据建立索引，在许多场景下可用于替代传统的关系型数据库或键/值存储方式。

• MongoDB(源自单词humongous)是一种较新的数据库，它没有表、模式、SQL或行的概念。也没有事务、ACID兼容性、连接、外键或其他许多容易在凌晨引起问题的特性。简单地说，MongoDB是一个非常特别的数据库，它不同于你之前所使用的数据库，特别是关系数据库管理系统(RelationalDataBaseManagementSystem，RDBMS)。

• MongoDB几乎可运行在任何目标上，可以运行在Linux、Mac OS、Windows和Solaris上。

1、了解MongoDB哲学

1、使用正确的工具处理正确的工作

• MongoDB中最重要的哲学概念是：一鞋难合众人脚。

• 在过去许多年中，传统的关系(SQL)数据库(MongoDB是面向文档的数据库)一直被用于存储所有类型的数据。无论该数据是否符合关系模型(被用在所有的RDBMS数据库中，例如MySQL、PostgreSQL、SQLite、Oracle、MS SQL Server等)都无所谓。因为，一般来说，读取和修改数据库相比操作文件系统更加简单(和安全)。

• MongoDB团队决定不会创建另一个试图为所有人做所有事情的数据库。相反，该团队希望创建一个只用于处理文档的数据库（而不是行），并且它的速度要快，还要具有强大的扩展性和易用性。为实现这个目标，他们不得不忽略一些特性，这意味着MongoDB在某些特定情况下并非最理想的选择。例如，它缺少事务支持，意味着无法使用MongoDB编写财务应用。
• 一般在应用中可以混合使用，例如可以在财务模块中使用传统的RDBMS，而存储文档使用MongoDB。
• 注意：缺少事务和其他传统数据库特性并不意味着MongoDB不稳定，或者不能用于管理重要数据。

• MongoDB的另一个关键概念是：MongoDB数据库应该具有多个副本。如果单个MongoDB服务器出现问题，那么它可以轻松地通过另一个MongoDB服务器恢复到正常状态。

2、MongoDB不支持事务

• MongoDB开发者做出的另一个重要设计决定是：MongoDB数据库不支持事务(用于保证数据一致性和存储的元素)。这是根据MongoDB的目标--简单、快速和可扩展做出的权衡之计。一旦移除这些重量级特性，数据库就可以更轻松地实现水平扩展。
  • 通常在使用传统的RDBMS时，如果需要提高性能，只能垂直扩展，即购买更大、更快的机器。如果使用水平扩展，就不需要使用一台大型机器，相反可以使用许多稍弱一些的小机器。
  • 你可能会认为缺少事务的支持将构成致命缺陷。但在MySQL中最流行的表类型(MYISAM--这也恰好是默认的表类型)之一，也不支持事务，这并未阻止MySQL在之前的10年中变成并保持着主流开源数据库的地位。

• 自MongoDB 1.8版本以来，单个服务器的持久性通过事务日志来保证。这个日志只追加，每100毫秒刷新到磁盘中。
• 注意，MongoDB在同时使用至少两台存储数据的服务器(成为3节点集群)时可以提供持久性，这也是为生产环境部署时推荐使用的基本配置。MongoDB还支持“写顾虑(write concern)”的概念。即给定数量的节点确认写入成功，为数据安全存储提供了一个更强的保证。

3、JSON和MongoDB

• JSON(JavaScript Object Notation，JavaScript对象记号)不止是一种交换数据的方式，也是种存储数据的良好方式。
  • JSON可高效地描述指定文档中的所有内容，所以不需要提前指定文档的结构。
  • JSON是没有模式的(不需要模式)，因为文档可以单独更新，或者独立于其他文档进行修改。
  • JSON还通过将相关数据存储在同一位置的方式，提供了出色的性能。
• RFC 7159描述了JSON的初始规范，它由Douglas Crockford制订。JSON允许在简单的、可读文本格式中展现复杂的数据结构，使用它通常比阅读和理解XML要简单得多。如同XML一样，JSON被设计为一种在Web客户端(例如浏览器)和Web应用之间交换数据的方式。由于它描述对象的丰富方式和简单性，大多数开发者都选择它作为交换数据的格式。
• JSON数据格式示例：

{
  "firstname": "Peter",
  "lastname": "Membrey",
  "phone_numbers": [
    "+852 1234 5678",
    "+44 1234 565 555"
  ]
}

• RDBMS是高度结构化的，包含了多个文件(表)用于存储不同的数据。而MongoDB在单个文档中存储所有数据。MongoDB如同JSON一样，该模型为数据存储提供了丰富和高效的方式。
• 实际上，MongoDB并未使用JSON存储数据，而是使用由MongoDB团队开发的一种称为BSON(二进制JSON的英文简称)的开放数据格式。大多数情况下，使用BSON取代JSON并不会改变处理数据的方式。BSON更容易被计算机处理和搜索，使MongoDB处理速度变得更快。BSON还添加了一些标准JSON不支持的特性，包括数字数据(例如int32和int64)的许多扩展类型，以及支持处理二进制数据。

4、MongoDB使用非关系模式

• 扩展关系型数据库性能的方式是：购买更大更快的服务器。而遇到瓶颈时，唯一的选择就是扩展至两台服务器。这听来容易，但它是大多数关系型数据库的绊脚石。例如，PostgreSQL无法在两台服务器上同时运行单个数据库(两台服务器都能够读取或修改数据，通常被称为活跃/活跃集群)；MySQL只有安装了特定的附件包，才能做到这一点；尽管Oracle可以通过强大的实时应用集群(RealApplication Clusters，RAC)架构实现，但如果希望使用该解决方案，就需要使用基于RAC的解决方案需要多台服务器、共享存储和多个软件许可。

• 为什么在两台服务器上部署关系型数据库的活跃/活跃集群这么难?
  • 因为在查询数据库时，数据库需要找到所有相关的数据，并将它们关联在一起。RDBMS解决方案使用了许多巧妙的方式来提高性能，但它们都必须获得所有完整的数据。而这正是问题所在：当有一半数据在另一台服务器上时，这种方式是无法工作的。
  • 当然，你可能只有一个小型数据库，只是因为收到了大量请求，所以希望通过共享负载的方式解决负载问题。遗憾的是，此时会出现另一个问题，需要保证写入第一台服务器的数据在第二台服务器上也是可用的。如果在两台服务器上同时更新数据，将会遇到另一个问题，例如需要决定哪个更新才是正确的。也可能遇到某人可能在第二台服务器上查询刚写入第一台服务器的信息，但是该信息尚未更新到第二台服务器的问题。鉴于以上问题，就很容易明白为什么Oracle的解决方案这么昂贵--这些问题都很难解决。

• MongoDB通过一种非常聪明的方式解决了这些活跃/活跃集群问题，并完全避免这些问题的发生。
  • MongoDB是以BSON文档格式存储数据的，所以数据是自包含的。尽管相似的数据文档被存储在一起，但各个文档之间并没有关系，这意味着，你需要的所有东西都在同一个地方。
  • MongoDB查询将在文档中寻找特定的键和值，该查询可以轻松地扩散到所有可用的服务器上。每台服务器都将执行该查询，并返回结果。这样，可扩展性和性能的提升几乎是线性的。

• MongoDB并不提供主/主复制，两台不同的服务器都可以接受写入请求。不过，MongoDB支持分片，允许将数据分散到多台机器中，每台机器都将负责更新数据集的不同部分。分片集群的好处是可以添加额外的分片，来增加部署中的资源能力，而不必更改任何应用程序代码。
  • 非分片数据库只能垂直缩放：可以添加更多的内存/CPU/磁盘，但是这很快就会变得非常昂贵。
  • 分片的部署也可以垂直缩放，但更重要的是，它们可以基于能力要求进行横向扩展：一个分片集群可以包含更多、能买得起的商用服务器，而不是几个非常昂贵的服务器。水平扩展非常适于通过云实例和容器进行弹性扩展。

5、选择性能，还是特性

• MongoDB通过移除关系数据库中常见的特性来实现惊人的性能。还有一些与MongoDB类似的数据库，它们也非常快，但同样功能也很有限，例如实现了键/值存储的redis数据库。
• MongoDB为了具有竞争力，必须提供组强大的功能，例如搜索特定文档的能力。它还必须能够将文档存储在硬盘中，这样在重启之后数据也不会丢失。

6、MongoDB可以运行在任何地方

• MongoDB以C++编写，因此迁移相对容易，并且可以在任何系统上运行。目前，MongoDB网站提供了针对Linux、Mac OS、Windows和Solaris的二进制包。官方支持Linux软件包包括Amazon Linux、RHEL、Ubuntu Server LTS和SUSE。尽管推荐使用官网提供的二进制包，但仍然可以下载源代码，构建自己的MongoDB。
• MongoDB适度的要求使它可以运行在高性能服务器或虚拟机上，甚至可以运行在基于云的应用中。通过保持事情简单，关注于速度和效率，无论将MongoDB部署在哪里，它都可以提供稳定的性能。

• 警告，32位版本的MongoDB数据库大小被限制为小于等于2GB，因为MongoDB内部使用内存映射文件来实现高性能。在32位系统中任何大于2GB的文件都需要一些特殊的处理，这样会降低处理速度，也会使应用代码变得复杂。官方关于该限制的观点是：64位环境很容易获得；因此，增加代码的复杂性并不是很好的权衡之计，64位版本的MongoDB可以实现所有的意图和目的，并且不含任何限制。

2、MongoDB的基本术语

• 许多特定于MongoDB的术语大致都可以被翻译成对应的RDMBS术语。

1、MongoDB的文档组成

• 文档是MongoDB中的一个存储单元。在RDBMS中，存储单元将被称为行。不过，文档中包含的信息要远比行多，因为它们可以存储复杂的信息，例如列表、词典，甚至是词典的列表。
• MongoDB中的文档由任意数目的键和值组成。在传统数据库中，行是固定的。
• 键是一个标签，它大致相当于RDBMS中的列名。可以使用键引用文档中的数据。

• 在关系数据库中，必须能够通过某种方式唯一定位一条指定的记录；否则，将无法引用特定的行。为此，必须添加一个字段用于存储一个唯的值(称为主键)，或者一组能够唯一定位指定行的字段(称为复合主键)。
• 出于相同的原因，MongoDB要求每个文档必须有唯一标识符；在MongoDB中，该标识符被称为_id，除非为该字段指定某个值，否则MongoDB将自动创建唯一值。即使是在已经成熟的RDBMS数据库世界中，也存在着是应该自己提供唯一键还是由数据库提供的分歧。最近，由数据库提供唯一键的方式已经变得更加流行。
• MongoDB是一个分布式数据库，所以其主要目标之一是消除对共享资源的依赖(例如检查主键是否独一无二)。非分布式的数据库通常使用一个简单的主键，例如自动递增的序列号。MongoDB的默认_id格式是一个Objectld，它是个12字节的唯一标识符，可以独立地在分布式环境中生成。

2、MongoDB的键和值

• 文档由键和值组成。数据格式示例如下：

{
  "firstname": "Peter",
  "lastname": "Membrey",
  "phone_numbers": [
    "+852 1234 5678",
    "+44 1234 565 555"
  ]
}

• 键和值总是成对出现的。与RDBMS不同，RDBMS中的所有字段必须有值，即使值是NULL(有些矛盾的是，NULL意味着未知)，MongoDB不要求每个文档必须含有相同的字段，也不要求同名的字段有相同类型的值。例如，phone_numbers在一些文档中可以是一个字符串，在另外一些文档中可以是一个列表，甚至在其他文档中是空。
• 如果MongoDB中不含某个键/值对，那它就被认为是不存在的。

3、MongoDB的集合

• 集合有点类似于表，但它们不那么死板。集合非常像一个贴有标签的盒子。在家里，你可能会有一个贴着“DVD”的盒子，用于放置DVD，但也没有什么事情可以阻止你将CD或磁带放入该盒子中。

• 在MongoDB中，集合就是一组类似元素的集合，其中的元素不必相似(MongoDB本质上是非常灵活的)；不过，使用索引和高级查询时，就会看到在集合中放置类似元素的优点。

• 可以在一个集合中混合各种不同的元素，但几乎没有必要这么做。创建一个称为媒体的集合，那么家里所有的DVD、CD和磁带都应该放在其中。毕竟，这些元素有着共同的特性，例如艺术家名称、发布日期和内容。换句话说，是否应该将特定的文档存储在相同的集合中取决于应用的需求。至于性能方面，创建多个集合并不比只使用一个集合慢。

• 集合可以按需求即时创建。尤其是，在第一次尝试保存文档时，MongoDB将创建引用它的集合。这意味着可以按照需求即时创建集合(但并不是应该这么做)。因为MongoDB也允许动态地创建索引，执行其他数据库级别的命令，所以可以利用该特性构建出一些非常动态的应用。

4、MongoDB数据库

• 可以将MongoDB数据库看成一个集合的集合。如同集合一样，数据库可以按需创建。

3、MongoDB的特性

• 本节讲到的特性涉及到一些MongoDB幕后的内容，事实上在使用MongoDB时并不需要了解所有特性。换句话说，你可以自由挑选希望阅读的特性!
• 这里介绍的是MongoDB 3.x的特性。

1、WiredTiger

• WiredTiger是一个性能卓越的数据库引擎。WiredTiger在MongoDB 3.0中引入，是一个可选的存储引擎，是MongoDB 3.2的默认存储引擎。经典的MMAP(内存映射)存储引擎仍然可用，但是对于大多数用例而言，WiredTiger更高效，性能更好。

• WiredTiger就使MongoDB达到一个全新水平，取代了内部数据存储和管理的旧MMAP模型。
  • WiredTiger允许MongoDB更好地优化驻留在内存中的数据和驻留在磁盘上的数据，而没有以前的杂乱溢出。
  • 对所有用户而言，WiredTiger往往是一个真正的性能增益。WiredTiger也更好地优化了数据存储在磁盘上的方式，提供了一个内置的压缩API，大大节省了磁盘空间。

2、使用面向文档存储(BSON)

• JSON更容易以文档真正的形式存储和获取文档，有效地避免了任何映射或特有转换代码的需求。
• BSON是一个开放标准，在网址http://bsonspec.org/上可以找到它的规范。当人们听到BSON是JSON的二进制形式时，他们期望BSON占用的空间要比JSON少得多。不过，事实上并不是这样的，在许多情况下BSON比相同的JSON要占用更多的空间。

• 为什么要使用BSON？毕竟，CouchDB(另一个强大的面向文档数据库)使用的就是纯JSON。
  • (1)要记住MongoDB的设计目标是快速，而不是节省空间。
    • BSON更易于遍历(即浏览)，遍历索引页非常快。尽管比起JSON，BSON需要稍微多一些的硬盘空间，但这并不是问题，因为硬盘很便宜。MongoDB多占用一点硬盘空间，换来更好的查询和索引性能。
    • WiredTiger存储引擎支持多个压缩库，默认启用索引和数据压缩。压缩级别默认可以在每个服务器上设置，也可以在每个集合(在创建时)设置。在存储数据时，较高的压缩级别会使用更多CPU，但可节省大量磁盘空间。
  • (2)可以很容易将BSON数据快速转换为编程语言的原生数据格式。
    • 以纯JSON方式存储数据，就需要添加一个较高级别的转换。
    • MongoDB对于大量的编程语言(例如Python、Ruby、PHP、C、C++和C#)都有对应的BSON驱动，它们的工作方式也稍有不同，但可以在各种语言中快速构建原生数据结构，而不需要首先对JSON进行处理。这将使代码更简捷，而它们都是MongoDB的目标。

• BSON提供了对JSON的一些扩展。例如，通过BSON可以存储二进制数据，以及处理特定的数据类型。因此，BSON可以存储任何JSON文档，但有效的BSON文档可能不是有效的JSON。且每种语言都有自己的驱动，可完成数据和BSON之间的转换，而不需要使用JSON作为中间语言。

3、MongoDB支持动态查询

• MongoDB支持动态查询，类似于在RDBMS中运行SQL查询。
• 为什么这也会作为特性列出来？这应该是所有数据库都支持的特性。实际上不是，例如CouchDB(通常被认为是MongoDB的最大“竞争对手”)并不支持动态查询，因为CouchDB提出了一种全新的思考数据的方式(诚然这令人兴奋)。

• 作为一个面向文档的数据库，CouchDB是无模式的，所以数据也是动态的。但查询是静态的，即在使用查询之前，需要提前定义它们。CouchDB还允许为查询编写map和reduce函数。

• 在MongoDB中，只需要提供希望匹配的部分文档即可，MongoDB将完成其他的部分。不过MongoDB可以做更多，例如使用map或reduce函数。

4、为文档创建索引

• MongoDB可以对文档创建索引。
  • 创建索引时，可以决定是否强制"键"具有唯一性。默认情况下，如果在一个具有重复值的键上创建唯一索引，将会返回一个错误。
  • 许多情况下，都希望创建一个允许"键"重复的索引。例如，如果应用是按姓氏搜索的，那么可以在lastname键上创建索引。
  • 可以在内嵌文档上创建索引。例如，如果在地址键中存储了大量地址，那么可以在ZIP或邮政编码上创建索引。这意味着，可以轻松地将基于任意邮政编码的文档提取出来，并且非常快速。
  • MongoDB还支持复合索引。在复合索引中，可以使用两个或多个键构建索引。例如，可能需要创建一个包含了lastname和firstname标签的索引。这时搜索全名将是非常快速的，因为MongoDB可以快速地定位到姓氏，然后同样快速地定位到名字。

• MongoDB中的所有文档都将会在_id键上自动创建索引。
  • _id键被认为是一个特殊例子，因为不能删除它。
  • _id索引用于保证每个值都是唯一的。使用该键的优点之是：可以确定每个文档都是唯一可识别的，RDBMS并不会保证这一点。

5、使用地理空间索引

• 索引中特别值得一提的一种就是地理空间索引。MongoDB 1.4中引入了这个全新的特殊索引技术。通过使用该特性可以索引基于位置的数据，从而处理从给定坐标开始的特定距离内有多少个元素这样的查询。
• 随着使用基于位置数据的Web应用的增加，该特性在日常开发中的作用越来越重要。

6、分析查询

• 通过一个内置的分析工具可以显示出MongoDB如何找到返回的文档。
• 在许多情况下，通过添加一个索引就可以提高查询的性能。如果现在有一个复杂的查询，并且不确定到底为什么运行速度这么慢，那么查询分析器(MongoDB的查询规划器explain())可以提供极具价值的信息。

7、就地更新信息(仅用于内存映射的数据库)

• 当数据库更新一行数据时(对于MongoDB来说更新的是文档)，它有多种更新方式可供选择。

• 许多数据库选择多版本并发控制(Multi-Version Concurrency Control，MVCC)方式，这种方式允许多用户看到不同版本的数据。因为在给定的事务过程中，这种方式可以保证数据不会被另一个程序改变，所以它非常有用。不利的一面在于数据库需要追踪数据的多个副本。例如，CouchDB提供了非常强大的版本控制，但这是以记录所有数据为代价的。这种方式虽然能够保证数据以一种健壮的方式存储，但也增加了复杂性，降低了性能。

• MongoDB将就地更新信息。
  • 与CouchDB相比，MongoDB可以在数据所在的位置更新它们。这通常意味着不需要更新额外的空间，索引可以保持不变。
  • 另一个优点是，MongoDB将执行懒写入。写入内存或从内存读取是非常快速的，但写入磁盘就会慢上几千倍。这意味着要尽可能限制从磁盘读写数据。
• MongoDB只在必需的时候才向磁盘写入，频率大概是每100毫秒一次左右。这意味着如果一秒内某个值被更新了许多次，那么该值只会被写入一次。
  • 这种方式使MongoDB更快速。
• CouchDB可能慢一些，因为CouchDB需要保证每次写操作都被快速地写入磁盘中，因此它保证了数据将被安全地存储在硬盘中。

8、存储二进制数据

• BSON支持在一个文档中存储最多16MB的二进制数据，即小于16MB的二进制数据可以存储在BSON文档中。

• GridFS是MongoDB在数据库中存储二进制数据的解决方案，即大于16MB的二进制数据要使用GridFS。

• GridFS通过在files集合中存储文件的信息(称为元数据)来实现。数据本身被分成多块(称为信息块)存储在chunks集合中。这种方式使数据存储既简单又有扩展性；还使范围操作(例如获取文件的特定部分)变得更简单。
• 通常来说，我们将通过编程语言对应的MongoDB驱动来使用GridFS，所以并不需要清楚GridFS的细节。与其他所有MongoDB中的特性一样，GridFS的目标也是快速和可扩展性。

9、复制数据

• RDBMS数据库为数据存储的安全提供某种保证，而这是MongoDB所不具备的。由于一些原因，MongoDB并未实现这些保证：
  • 第一，这些特性会降低数据库的速度。
  • 第二，它们将大大地增加程序的复杂性。
  • 第三，最常见的故障应该是硬件故障，这种情况下即使数据被安全地保存到硬盘中，数据也无法使用，
• 当然，这些原因都不意味着数据安全不重要。如果无法在需要的时候访问到数据，那就不会有人愿意使用MongoDB。
  • 刚开始，MongoDB提供了主/从复制，这种情况下只有一个数据库可以处于活跃状态。
  • 现在使用复制集代替主/从复制，基本的主/从复制已经被弃用，也不应该再使用。
• 复制集包含：一台主服务器和多台辅助服务器(类似于主/从复制)
  • 复制集中只能有一台主服务器，它将处理所有来自客户端的请求，保证所有写入都会被正确处理。当写入操作发生时，该操作也会被写入主服务器的oplog集合中。
  • oplog集合将被复制到辅助服务器(可能有许多)，并帮助它们将数据更新到与主服务器一致的状态。一旦主服务器出现故障，辅助服务器中的某一台将会成为主服务器，并负责处理所有来自客户端的写入请求。
• MongoDB驱动将自动检测副本集配置或副本集状态的任何更改，根据更新的副本集状态重新连接。为让副本集维护主服务器，大多数健康的副本节点必须能够相互连接，例如一套3个节点的副本集需要两个健康的节点来维护一个主服务器。

10、MongoDB分片

• 对于涉及大规模部署的应用，自动分片可能是MongoDB最重要和最常用的特性。

• 在自动分片场景中，MongoDB将处理所有数据的分割和重组。它将保证数据进入正确的服务器，并以最高效的方式运行查询和重组结果。事实上，从开发者的角度看，使用含有数百个分片的MongoDB数据库和使用单个MongoDB数据库并没有区别。

• MongoDB可以很容易从单实例扩展成多个实例的MongoDB集群。

11、使用map和reduce函数

• CouchDB只支持map和reduce函数，这也是为什么它有着陡峭的学习曲线。

• MongoDB并不要求使用map和reduce函数。但MongoDB也提供了对这些函数的支持。map和reduce函数以JavaScript编写并运行在服务器中。map函数的工作是查找所有符合条件的文档，然后将这些结果传递给reduce函数，reduce函数将处理这些数据。不过reduce函数并不会返回一个文档的集合，而是返回一个新文档，其中包含衍生出的信息。使用规则是，如果你会在SQL中使用GROUPBY，那么在MongoDB中就应该会使用map和reduce函数

• 事实上，MongoDB只依赖于简单的查询语法，这种语法与MySQL中使用的类似。

12、聚集框架

• MapReduce是一个非常强大的工具，但它有一个主要的缺点：性能不高。其原因是MapReduce在幕后是如何实现的。简而言之，要完成很多工作，都需要移动数据，本地存储格式(BSON)和JSON之间转换，应用过滤器等。

• 聚集框架提供了大量的操作符，它们是用C++编写的，性能很高。可用的操作符一直在增加，每个版本都会引入新特性。
• 聚集框架基于管道，并允许依次处理查询的各个部分，然后将它们按顺序串联起来，获得要查询的结果。这在保持了MongoDB面向文档设计的优点之外，还提供了高性能。

• 如果需要使用强大的MapReduce，那么仍然可以使用它。如果只是希望完成一些简单的统计和数字运算，你一定会喜欢新的聚集框架。

4、获取帮助

• https://www.mongodb.com/
  • MongoDB官网
• www.stackoverflow.com
  • 如果有一个特别的问题,正在寻找专业的答案,访问Stack Overflow就最合适。
• https://jira.mongodb.org/
  • MongoDB使用JIRA问题跟踪系统。
• https://freenode.net/
  • 开发者通常会使用Freenode网站(www.freenode.net)上的Intermet Relay Chat(IRC),频道为#MongoDB。

#                                                                                                                          #