mongodbredis 和 mongodb 比起来优缺点是什么？

MongoDB是什么

MongoDB不是在实验室设计出来的。

利用自己开发大型，高可用性和健壮性系统的经验，我们开发了MongoDB。

我们并不是从零开始，而是发现 哪些地方有问题，然后尝试解决它。

所以在我眼中，MongoDB让你从使用MySQL的基于关系的数据模型转变为基于文档的模型，从而获得如快速的嵌入式文档，易管理，使用无模式数据库进行敏捷开发，易于横向扩展和伸缩（因为join不再重要）等大量特性。

使用关系型数据时有很多东西工作的很好，比如索引，动态查询和动态更新等，这些在MongoDB中也没怎么变化。

比如，在MongoDB里设计索引应该和你在MySQL或Oracle里一样，你有选择 在一个内嵌的域上建索引的能力。

怎么用mongodb创建数据库

use 命令 MongoDB use DATABASE_NAME 用于创建数据库。

该命令将创建一个新的数据库，如果它不存在，否则将返回现有的数据库。

语法: use DATABASE 语句的基本语法如下： use DATABASE_NAME 示例: 如果想创建一个数据库名称 <mydb>, 那么 use DATABASE 语句如下： >use mydb switched to db mydb 要检查当前选择的数据库使用命令 db >db mydb 如果想检查数据库列表，使用命令show dbs. >show dbs local 0.78125GB test 0.23012GB 创建的数据库mydb 列表中是不存在的。

要显示的数据库，需要把它插入至少一个文件。

>db.movie.insert({"name":"tutorials yiibai"}) >show dbs local 0.78125GB mydb 0.23012GB test 0.23012GB 在 MongoDB 默认数据库测试。

如果没有创建任何数据库，然后集合将被存储在测试数据库。

如何正确的使用mongodb

数据库性能对软件整体性能的影响是不言而喻的，那么，当我们使用MongoDB时改如何提高数据库性能呢？ 1.范式化与反范式化 在项目设计阶段，明确集合的用途是对性能调优非常重要的一步。

从性能优化的角度来看，集合的设计我们需要考虑的是集合中数据的常用操作，例如我们需要设计一个日志（log）集合，日志的查看频率不高，但写入频率却很高，那么我们就可以得到这个集合中常用的操作是更新（增删改）。

如果我们要保存的是城市列表呢？显而易见，这个集合是一个查看频率很高，但写入频率很低的集合，那么常用的操作就是查询。

对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度，在上篇范式化与反范式化的介绍中我们了解到，范式化与反范式化的合理运用对于性能的提高至关重要。

然而这种设计的使用非常灵活，假设现在我们需要存储一篇图书及其作者，在MongoDB中的关联就可以体现为以下几种形式： 1.完全分离（范式化设计） 示例1： View Code { "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ ObjectId("144b5d83041c7dca84416"), ObjectId("144b5d83041c7dca84418"), ObjectId("144b5d83041c7dca84420"), ] } 我们将作者ment) 的id数组作为一个字段添加到了图书中去。

这样的设计方式是在非关系型数据库中常用的，也就是我们所说的范式化设计。

在MongoDB中我们将与主键没有直接关系的图书单独提取到另一个集合，用存储主键的方式进行关联查询。

当我们要查询文章和评论时需要先查询到所需的文章，再从文章中获取评论id，最后用获得的完整的文章及其评论。

在这种情况下查询性能显然是不理想的。

但当某位作者的信息需要修改时，范式化的维护优势就凸显出来了，我们无需考虑此作者关联的图书，直接进行修改此作者的字段即可。

2.完全内嵌（反范式化设计） 示例2： View Code { "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ { "name" : "丁磊" "age" : 40, "nationality" : "china", }, { "name" : "马云" "age" : 49, "nationality" : "china", }, { "name" : "张召忠" "age" : 59, "nationality" : "china", }, ] } 在这个示例中我们将作者的字段完全嵌入到了图书中去，在查询的时候直接查询图书即可获得所对应作者的全部信息，但因一个作者可能有多本著作，当修改某位作者的信息时时，我们需要遍历所有图书以找到该作者，将其修改。

3.部分内嵌（折中方案） 示例3： View Code { "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ { "_id" : ObjectId("144b5d83041c7dca84416"), "name" : "丁磊" }, { "_id" : ObjectId("144b5d83041c7dca84418"), "name" : "马云" }, { "_id" : ObjectId("144b5d83041c7dca84420"), "name" : "张召忠" }, ] } 这次我们将作者字段中的最常用的一部分提取出来。

当我们只需要获得图书和作者名时，无需再次进入作者集合进行查询，仅在图书集合查询即可获得。

这种方式是一种相对折中的方式，既保证了查询效率，也保证的更新效率。

但这样的方式显然要比前两种较难以掌握，难点在于需要与实际业务进行结合来寻找合适的提取字段。

如同示例3所述，名字显然不是一个经常修改的字段，这样的字段如果提取出来是没问题的，但如果提取出来的字段是一个经常修改的字段（比如age）的话，我们依旧在更新这个字段时需要大范围的寻找并依此进行更新。

在上面三个示例中，第一个示例的更新效率是最高的，但查询效率是最低的，而第二个示例的查询效率最高，但更新效率最低。

所以在实际的工作中我们需要根据自己实际的需要来设计表中的字段，以获得最高的效率。

mongodb和mysql的区别

1. MongoDB比MySQL快在它有Memory-Mapping以及它不用处理事物2. MySQL适用于传统的对关联要求高的方面，MongoDB更多用于Logging、SNS等以K-V居多的需求，但是两种数据库其实都能胜任大多数需求。

对MongoDB来说，关联一般是做成内联的，最大程度发挥其优势。

而如果内联起来比较纠结或者冗余太多处理麻烦的时候当然用SQL更恰当了3. 新项目可以考虑用MongoDB 如果经验不足而时间紧迫则可以继续用MySQL4. 总之适当的任务用适当的工具5. MongoDB有比较好的扩展能力，可以很容易做成分布式架构6. 对MongoDB来说，内存越多越好

windows7 怎么启动mongodb

原始方式 只有启动了mongodb的服务，才能使用mongodb的功能，通常情况下会开一个命令窗口，输入下面的命令来启动服务： 配置文件方式 如果不想每次启动的时候都在命令行中输入很多繁琐的参数，可以抄把参数信息保存在配置文件中。

创建一个名为f的配置文件，和那些小工具放在同一个目录中，文件的内容如下： dbpath="d:databasemongodbdata" 然后在命令窗口输入下面命令就可以启动服务 看似和上面的方法差不多，还是需要指定配置文件，但如果参数zhidao不止-dbpath的时候，就可以将参数都写在配置文件中，在命令行调用的时候就会显得方便很多。

daemon方式 上面介绍的两种方式启动服务都需要打开一个命令行窗口，窗口关闭了服务也就停止了。

我们使用--fork参数可以将mongodb的服务放在后台运行，这样相对比较安全。

--fork参数是和--logpath参数一起使用的

redis 和 mongodb 比起来优缺点是什么？

MongoDB和Redis都是NoSQL，采用结构型数据存储。

二者在使用场景中，存在一定的区别，这也主要由于二者在内存映射的处理过程，持久化的处理方法不同。

MongoDB建议集群部署，更多的考虑到集群方案，Redis更偏重于进程顺序写入，虽然支持集群，也仅限于主-从模式。