Arthur's Blog

标签 - MongoDB

Windows 平台安装 MongoDB
MongoDB MongoDB教程    2019-04-28 17:30:33    57    0    0

Windows 平台安装 MongoDB


MongoDB 下载

MongoDB 提供了可用于 32 位和 64 位系统的预编译二进制包，你可以从MongoDB官网下载安装，MongoDB 预编译二进制包下载地址：https://www.mongodb.com/download-center#community

注意：在 MongoDB 2.2 版本后已经不再支持 Windows XP 系统。最新版本也已经没有了 32 位系统的安装文件。

  • MongoDB for Windows 64-bit 适合 64 位的 Windows Server 2008 R2, Windows 7 , 及最新版本的 Window 系统。
  • MongoDB for Windows 32-bit 适合 32 位的 Window 系统及最新的 Windows Vista。 32 位系统上 MongoDB 的数据库最大为 2GB。
  • MongoDB for Windows 64-bit Legacy 适合 64 位的 Windows Vista, Windows Server 2003, 及 Windows Server 2008 。

根据你的系统下载 32 位或 64 位的 .msi 文件，下载后双击该文件，按操作提示安装即可。

 

安装过程中，你可以通过点击 "Custom(自定义)" 按钮来设置你的安装目录。

 

下一步安装 "install mongoDB compass" 不勾选，否则可能要很长时间都一直在执行安装，MongoDB Compass 是一个图形界面管理工具，我们可以在后面自己到官网下载安装，下载地址：https://www.mongodb.com/download-center/compass。

创建数据目录

MongoDB将数据目录存储在 db 目录下。但是这个数据目录不会主动创建，我们在安装完成后需要创建它。请注意，数据目录应该放在根目录下（(如： C:\ 或者 D:\ 等 )。

在本教程中，我们已经在 C 盘安装了 mongodb，现在让我们创建一个 data 的目录然后在 data 目录里创建 db 目录。

c:\>cd c:\

c:\>mkdir data

c:\>cd data

c:\data>mkdir db

c:\data>cd db

c:\data\db>

你也可以通过 windo

MongoDB 简介
MongoDB MongoDB教程    2019-04-28 17:29:42    23    0    0

什么是MongoDB ?

MongoDB 是由C++语言编写的，是一个基于分布式文件存储的开源数据库系统。

在高负载的情况下，添加更多的节点，可以保证服务器性能。

MongoDB 旨在为WEB应用提供可扩展的高性能数据存储解决方案。

MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。

主要特点

  • MongoDB 是一个面向文档存储的数据库，操作起来比较简单和容易。
  • 你可以在MongoDB记录中设置任何属性的索引 (如：FirstName="Sameer",Address="8 Gandhi Road")来实现更快的排序。
  • 你可以通过本地或者网络创建数据镜像，这使得MongoDB有更强的扩展性。
  • 如果负载的增加（需要更多的存储空间和更强的处理能力） ，它可以分布在计算机网络中的其他节点上这就是所谓的分片。
  • Mongo支持丰富的查询表达式。查询指令使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。
  • MongoDb 使用update()命令可以实现替换完成的文档（数据）或者一些指定的数据字段 。
  • Mongodb中的Map/reduce主要是用来对数据进行批量处理和聚合操作。
  • Map和Reduce。Map函数调用emit(key,value)遍历集合中所有的记录，将key与value传给Reduce函数进行处理。
  • Map函数和Reduce函数是使用Javascript编写的，并可以通过db.runCommand或mapreduce命令来执行MapReduce操作。
  • GridFS是MongoDB中的一个内置功能，可以用于存放大量小文件。
  • MongoDB允许在服务端执行脚本，可以用Javascript编写某个函数，直接在服务端执行，也可以把函数的定义存储在服务端，下次直接调用即可。
  • MongoDB支持各种编程语言:RUBY，PYTHON，JAVA，C++，PHP，C#等多种语言。
  • MongoDB安装简单。

历史

  • 2007年10月，MongoDB由10gen团队所发展。2009年2月首度推出。
  • 2012年05月23日，MongoDB2.1 开发分支发布了! 该版本采用全新架构，包含诸多增强。
  • 2012年06月06日，MongoDB 2.0.6 发布，分布式文档数据库。
  • 2013年04月23日，Mongo
NoSQL 简介
MongoDB MongoDB教程    2019-04-28 17:29:15    24    0    0

NoSQL 简介

NoSQL(NoSQL = Not Only SQL )，意即"不仅仅是SQL"。

在现代的计算系统上每天网络上都会产生庞大的数据量。

这些数据有很大一部分是由关系数据库管理系统（RDBMS）来处理。 1970年 E.F.Codd's提出的关系模型的论文 "A relational model of data for large shared data banks"，这使得数据建模和应用程序编程更加简单。

通过应用实践证明，关系模型是非常适合于客户服务器编程，远远超出预期的利益，今天它是结构化数据存储在网络和商务应用的主导技术。

NoSQL 是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

关系型数据库遵循ACID规则

事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

 

1、A (Atomicity) 原子性

原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。

 

比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

 

2、C (Consistency) 一致性

一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

 

例如现有完整性约束a+b=10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a+b=10，否则事务失败。

3、I (Isolation) 独立性

所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。

比如现在有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的。

4、D (Durability) 持久性

持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。


分布式系统

分布式系统（dist

MongoDB 教程
MongoDB MongoDB教程    2019-04-28 17:27:41    11    0    0

MongoDB 教程

MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。

MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。

使用模式构建：计算模式（The Computed Pattern）
MongoDB 模式构建    2019-03-25 21:01:23    23    0    0

我们已经在使用模式构建系列研究了各种优化存储数据的方法。现在，我们从另一个角度来看看模式设计。通常，仅仅存储数据并使其可用还不够。当我们可以从数据中计算出值时，数据会变得有用的多。最新Amazon Alexa的总销售收入是多少？有多少观众看了这部最新的大片？这类问题可以从数据库中存储的数据那里得到答案，但必须进行计算。

每次在请求时运行这些计算都会是一个极其消耗资源的过程，特别是在大型数据集上。CPU周期、磁盘访问、内存都会被牵涉进来。

假设现在有一个关于电影信息的Web应用程序。每次我们访问应用查找电影时，页面都会提供有关播放这部电影的影院数量、观看电影的总人数以及总收入的信息。如果应用必须不断地为每次页面访问计算这些值，那么当碰上那些很受欢迎的电影时会使用掉大量的处理资源。

然而，大多数时候我们不需要知道确切的数字。我们可以在后台进行计算，然后每隔一段时间更新一次电影信息的主文档。这些计算允许我们在显示有效数据的同时无需给CPU带来额外的负担。

计算模式

当有在应用程序中需要重复计算的数据时，我们可以使用计算模式。当数据访问模式为读取密集型时，也会使用计算模式；例如，如果每小时有1000000次读取而只有1000次写入，则在写入时进行计算会使计算次数减少1000倍。

cpucomputed-fbcpkmvbsy

在我们的电影数据库示例中，我们可以根据特定电影上的所有放映信息进行计算，并将计算结果与电影本身的信息存储在一起。在低写负载的环境中，这个计算可以与源数据的任意更新一起完成。如果有更多的常规写入，则可以按定义好的时间间隔（例如每小时）进行计算。因为不会对上映信息中的源数据做任何修改，所以我们可以继续运行现有的计算，或者在任何时间点运行新的计算，并且确定将得到正确的结果。

一些执行计算的其它策略可能会涉及例如向文档添加时间戳以指示文档上次的更新时间。之后，应用程序可以确定何时需要进行计算。另一种选择是可以生成一个需要完成的计算队列。使用何种更新策略最好留给应用开发人员去选择。

应用场景示例

只要有对数据进行计算的需求，就可以使用计算模式。一个很好的例子是需要求和的数据集（如收入或观影者），但时间序列数据、产品目录、单视图应用程序和事件源也同样很适合这种模式。

这是许多客户已经实现的模式。例如，一个客户对车辆数据进行了大量的聚合查询，并将结果存储在服务器上，以在接下来的几个小时显示这些信息。

一家出版公司将所有类型的数据进行编

使用模式构建：异常值模式（The Outlier Pattern）
MongoDB 模式构建    2019-03-25 21:00:53    35    0    0

到目前为止，在《使用模式构建》系列中，我们已经研究了多态模式、属性模式和桶模式。其中，尽管文档的模式略有不同，但从应用程序和查询的角度来看，文档的结构基本上是一致的。然而，如果情况并非如此会怎么样？当有数据不属于“正常”模式时会发生什么？如果有异常值怎么办？

假设你正在搭建一个出售图书的电子商务网站，你可能会想查询“有哪些人购买了某本特定的书”。这对于一个可以向顾客展示他感兴趣书籍的推荐系统来说会很有用。你决定将顾客的user_id存储在每本书的一个数组中。很简单，对吧？

这可能确实适用于99.99%的情况，但是当J.K.罗琳发行了一本新的哈利波特书籍，并且销量以百万计激增时，会发生什么呢？16MB的BSON文档大小限制很容易达到。针对这种异常情况重新设计整个应用程序可能会降低典型书籍的性能，但我们确实需要考虑这一点。

异常值模式

使用异常值模式就是在防止一些少数的查询或文档将我们推向对大多数用例来说都不佳的解决方案。并非每本书都能卖出数百万册。

一个存有user_id的典型book文档可能看起来像这样：

{
    "_id": ObjectID("507f1f77bcf86cd799439011")
    "title": "A Genealogical Record of a Line of Alger",
    "author": "Ken W. Alger",
    …,
    "customers_purchased": ["user00", "user01", "user02"]

}

对于绝大多数不太可能登上“畅销书”排行榜的书来说，这可以工作得很好。尽管将异常值考虑进来后导致了customers_purchased数组超出了我们设置的1000个条目的限制，但我们可以添加一个新字段将这本书“标记”为异常值。

{
    "_id": ObjectID("507f191e810c19729de860ea"),
    "title": "Harry Potter, the Next Chapter",
    "author": "J.K. Rowling",
    …,
   "customers_purchased": ["user00", "user01", "user02", …, "user999"],
   "has_extras": "true
使用模式构建：桶模式（The Bucket Pattern）
MongoDB 模式构建    2019-03-25 20:59:48    18    0    0

在本期《使用模式构建》中，我们将介绍桶模式。这种模式在处理物联网（IOT）、实时分析或通用时间序列数据时特别有效。通过将数据放在一起，我们可以更容易地将数据组织成特定的组，提高发现历史趋势或提供未来预测的能力，同时还能对存储进行优化。

桶模式

随着数据在一段时间内持续流入（时间序列数据），我们可能倾向于将每个测量值存储在自己的文档中。然而，这种倾向是一种非常偏向于关系型数据处理的方式。如果我们有一个传感器每分钟测量温度并将其保存到数据库中，我们的数据流可能看起来像这样：

{
   sensor_id: 12345,
   timestamp: ISODate("2019-01-31T10:00:00.000Z"),
   temperature: 40
}

{
   sensor_id: 12345,
   timestamp: ISODate("2019-01-31T10:01:00.000Z"),
   temperature: 40
}

{
   sensor_id: 12345,
   timestamp: ISODate("2019-01-31T10:02:00.000Z"),
   temperature: 41
}

随着我们的应用程序在数据和索引大小上的扩展，这可能会带来一些问题。例如，我们可能最终不得不对每次测量的sensor_id和timestamp进行索引，实现以内存为代价的快速访问。但利用文档数据模型，我们可以按时间将这些数据“以桶的方式”储存到特定时间片测量值的文档中。我们还可以通过编程方式向每一个“桶”中添加附加信息。

通过将桶模式应用于数据模型，我们可以在节省索引大小、简化潜在的查询以及在文档中使用预聚合数据的能力等方面获得一些收益。获取上面的数据流并对其应用桶模式，我们可以得到：

{
    sensor_id: 12345,
    start_date: ISODate("2019-01-31T10:00:00.000Z"),
    end_date: ISODate("2019-01-31T10:59:59.000Z"),
    measurements: [
       {
       timestamp: ISODate("2019-01-31T10:00:00.000Z"),
       temperature: 40
 
使用模式构建：属性模式（The Attribute Pattern）
MongoDB 模式构建    2019-03-25 20:59:20    15    0    0

欢迎回到MongoDB模式设计系列。上一次我们研究了多态模式，它涵盖了集合中所有文档具有相似但不相同结构的情况。在本文中，我们将了解一下属性模式。属性模式特别适用于以下情况：

  • 我们有一些大文档，它们有很多相似的字段，而这些字段的一个子集具有共同的特征，我们希望对该子集字段进行排序或查询；
  • 我们需要排序的字段只能在一小部分文档中找到；
  • 上述两个条件均满足。

出于性能原因考虑，为了优化搜索我们可能需要许多索引以照顾到所有子集。创建所有这些索引可能会降低性能。属性模式为这种情况提供了一个很好的解决方案。

属性模式

假设现在有一个关于电影的集合。其中所有文档中可能都有类似的字段：标题、导演、制片人、演员等等。假如我们希望在上映日期这个字段进行搜索，这时面临的挑战是“哪个上映日期”？在不同的国家，电影通常在不同的日期上映。

{
    title: "Star Wars",
    director: "George Lucas",
    ...
    release_US: ISODate("1977-05-20T01:00:00+01:00"),
    release_France: ISODate("1977-10-19T01:00:00+01:00"),
    release_Italy: ISODate("1977-10-20T01:00:00+01:00"),
    release_UK: ISODate("1977-12-27T01:00:00+01:00"),
    ...
}

搜索上映日期需要同时查看多个字段。为了快速进行搜索，我们需要在电影集合中使用多个索引：

{release_US: 1}
{release_France: 1}
{release_Italy: 1}
...

使用属性模式，我们可以将此信息移至数组中并减少对索引需求。我们将这些信息转换成一个包含键值对的数组：

{
    title: "Star Wars",
    director: "George Lucas",
    …
    releases: [
        {
        location: "USA",
        date: ISODate("1977-05-20T01:00:00+01:00")
        },
        {
        locat
使用模式构建：多态模式（The Polymorphic Pattern）
MongoDB 模式构建    2019-03-25 20:58:47    14    0    0

当涉及MongoDB时，一个经常被问到的问题是“我如何在MongoDB中为我的应用程序构造模式（schema）？”老实说，这要看情况而定。你的应用程序读操作比写操作多吗？从数据库中读取时需要将哪些数据放在一起？有哪些性能因素需要考虑？文档有多大？它们今后会变成多大？你预计数据会如何增长和扩展？

所有这些以及更多的问题，都涉及到如何在MongoDB中设计数据库模式（schema）。有人说MongoDB是无模式的，而实际上模式设计在MongoDB中非常重要。有一个严峻的现实，我们发现的大多数性能问题都可以追溯到糟糕的模式设计。

在本系列文章“使用模式构建”中，我们将了解在MongoDB中行之有效的十二种常见的模式设计方式（Schema Design Patterns）。我们希望本系列文章能够建立一种在设计模式时可以使用的通用方法和词汇表。利用这些模式（patterns）可以在模式（schema）规划中使用“构建基块（building blocks）”，从而使这个过程更多地成为一种方法论而不是艺术。

MongoDB使用文档数据模型。此模型具有内在的灵活性，允许数据模型支持你的应用程序需求。灵活性也可能导致模式比它们应有样子的更复杂。在考虑模式设计时，我们应该考虑性能、可伸缩性和简单性。

让我们开始探索模式设计时先看一下被认为是所有模式基础的模式——多态模式。当我们的文档具有比差异更多的相似性时，就会使用这种模式。它也同样适合于当我们希望将文档保存在单一集合中的场景。

多态模式

当集合中的所有文档都具有相似但不相同的结构时，我们将其称为多态模式。如前所述，当我们希望从单个集合中访问（查询）信息时，多态模式非常有用。根据我们要运行的查询将文档分组在一起（而不是将其分散在多个表或集合中）有助于提高性能。

假设我们有一个应用程序用来跟踪所有不同运动项目的专业运动员。

我们仍然希望能够在应用程序中访问所有的运动员，但每个运动员的属性都不尽相同，这就是多态模式可以发挥作用的地方。在下面的示例中，我们将来自两个不同项目运动员的数据存储在同一个集合中。即使文档在同一集合中，存储的关于每个运动员的数据也不必须是相同的。

Polymorphic1-nanehssyv3
Polymorphic Design Pattern with Common Fields

对于职业运动员的记录既有相似之处也有不同之处。使用多态模式，我们可以很容易地适应这些差异。如果不使用

使用模式构建：子集模式（The Subset Pattern）
MongoDB 模式构建    2019-03-25 20:58:00    18    0    0

在多年前，第一代PC拥有高达256KB的RAM和两个5.25英寸的软盘驱动器。没有硬盘，因为在当时它们极为昂贵。这些限制导致在处理大量（对那时来说）数据时由于内存不足，必须在物理上交换软盘。如果当时有办法只把我经常使用的数据（如同整体数据的一个子集）放入内存就好了。

现代应用程序也无法幸免于资源消耗的影响。MongoDB将频繁访问的数据（称为工作集）保存在RAM中。当数据和索引的工作集超过分配的物理RAM时，随着磁盘访问的发生以及数据从RAM中转出，性能会开始下降。

我们如何解决这个问题？首先，我们可以向服务器添加更多的RAM，不过也就只能扩展这么多。我们也可以考虑对集合进行分片，但这会带来额外的成本和复杂性，而我们的应用程序可能还没有准备好来应对这些。另一种选择是减小工作集的大小，这就是我们可以利用子集模式的地方。

子集模式

此模式用来解决工作集超出RAM，从而导致信息从内存中被删除的问题。这通常是由拥有大量数据的大型文档引起的，这些数据实际上并没有被应用程序使用。我这么说到底是什么意思呢？

假设一个电子商务网站有一个产品评论列表。当访问该产品的数据时，我们很可能只需要最近10个左右的评论。将整个产品数据与所有评论一起读入，很容易导致工作集的膨胀。

fulldocsubset-0jesu52gzs

相比于将所有的评论与产品存储在一起，我们可以将其分为两个集合。一个集合具有最常用的数据，例如当前的评论；另一个集合具有不太常用的数据，例如旧的评论、产品历史记录等。我们可以复制在一对多或多对多关系中最常用的那部分数据。

docsubset2-ncq6t9lt01

在Product集合中，我们只保留最近十次的评论。这允许通过只引入整体数据的一部分或子集来减少工作集。附加信息（本例中的reviews）存储在单独的Reviews集合中，如果用户希望查看更多的评论，则可以访问该集合。在考虑将数据拆分到何处时，文档中使用最多的部分应放入“主”集合，而使用频率较低的数据应放入另一个集合。对于我们例子中的评论，这个分割点可能是产品页面上可见的评论数。

应用场景示例

当我们的文档拥有大量数据而其并不常用时，子集模式就非常有用。产品评论、文章评论、电影中的演员信息都是这个模式的应用场景案例。每当文档大小对工作集的大小产生压力并导致工作集超过计算机的RAM容量时，子集模式便成为一个可以考虑的选项。

结论

通过使用包含有频繁访问数据的较小文档，我们减少了工作集的总体大小。这使得应用程序所需要的最常用信息的

5/6
Powered by iStudy 服务器由edgenat提供