图数据库适用哪些场景，mongoDB适用什么场合呢

1，mongoDB适用什么场合呢

根据官方网站的描述，Mongo适合用于以下场景：◆网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。◆缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源过载。◆大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。◆高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapReduce引擎的内置支持。◆用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询。自然，MongoDB的使用也会有一些限制，例如它不适合：◆高度事务性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。◆传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。

搜一下：mongoDB适用什么场合呢？

mongoDB适用什么场合呢

2，hbase和hive的差别是什么各自适用在什么场景中

HBase是个基于HDFS的数据库。Hive是用SQL替代写MR的编程框架，做Hadoop上会把用户提交的SQL语句做语法分析，执行计划等一堆乱七八糟的事后变成MR job提交去跑，返回结果给用户。不然每次都写MR很麻烦的，有这个写个SQL就可以拿到等效的结果，很适合运营童鞋用。当然Hive也有HBase的Connector，用这个Connnector后可以写SQL查询HBase的数据而不是HDFS，不过一般不这么搞。像用SQL on HBase的话，可以用下Phoenix，新手第一次用的感觉会觉得很像是MySQL

hbase和hive的差别对比：1、hbase当前nosql数据库的一种，hive是hdfs分布式文件系统的一种，二者对数据的存储方式是不同的。2、使用场景： hbase最常见的应用场景就是采集的网页数据的存储，由于是key-value型数据库，可以再扩展到各种key-value应用场景，如日志信息的存储，对于内容信息不需要完全结构化出来的类cms应用等。注意hbase针对的仍然是oltp应用为主。hive主要针对的是olap应用，其底层是hdfs分布式文件系统，重点是基于一个统一的查询分析层，支撑olap应用中的各种关联，分组，聚合类sql语句。hive一般只用于查询分析统计，而不能是常见的cud操作，要知道hive是需要从已有的数据库或日志进行同步最终入到hdfs文件系统中，当前要做到增量实时同步都相当困难。

hbase和hive的差别是什么各自适用在什么场景中

3，常见NoSQL数据库的应用场景是怎么样的

文档数据库源起：受Lotus Notes启发。数据模型：包含了key-value的文档集合例子：CouchDB, MongoDB 优点：数据模型自然，编程友好，快速开发，web友好，CRUD。图数据库源起：欧拉和图理论。数据模型：节点和关系，也可处理键值对。例子：AllegroGraph, InfoGrid, Neo4j 优点：解决复杂的图问题。关系数据库源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的数据模型：各种关系例子：VoltDB, Clustrix, MySQL 优点：高性能、可扩展的OLTP，支持SQL，物化视图，支持事务，编程友好。对象数据库源起：图数据库研究数据模型：对象例子：Objectivity, Gemstone 优点：复杂对象模型，快速键值访问，键功能访问，以及图数据库的优点。 Key-Value数据库源起：Amazon的论文 Dynamo 和 Distributed HashTables。数据模型：键值对例子：Membase, Riak 优点：处理大量数据，快速处理大量读写请求。编程友好。 BigTable类型数据库源起：Google的论文 BigTable。数据模型：列簇，每一行在理论上都是不同的例子：HBase, Hypertable, Cassandra 优点：处理大量数据，应对极高写负载，高可用，支持跨数据中心， MapReduce。数据结构服务源起： ? 数据模型：字典操作，lists, sets和字符串值例子：Redis 优点：不同于以前的任何数据库网格数据库源起：数据网格和元组空间研究。数据模型：基于空间的架构例子：GigaSpaces, Coherence 优点：适于事务处理的高性能和高扩展性

常见NoSQL数据库的应用场景是怎么样的

4，mongodb mysql 分别适合什么场景

MongoDB已经流行了很长一段时间，相对于MySQL，究竟什么场景更需要用MongoDB？下面是一些总结。更高的写入负载默认情况下，MongoDB更侧重高数据写入性能，而非事务安全，MongoDB很适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB，除非能从架构设计上保证事务安全。高可用性MongoDB的复副集(Master-Slave)配置非常简洁方便，此外，MongoDB可以快速响应的处理单节点故障，自动、安全的完成故障转移。这些特性使得MongoDB能在一个相对不稳定（如云主机）的环境中，保持高可用性。数据量很大或者未来会变得很大依赖数据库(MySQL)自身的特性，完成数据的扩展是较困难的事，在MySQL中，当一个单达表到5-10GB时会出现明显的性能降级，此时需要通过数据的水平和垂直拆分、库的拆分完成扩展，使用MySQL通常需要借助驱动层或代理层完成这类需求。而MongoDB内建了多种数据分片的特性，可以很好的适应大数据量的需求。基于位置的数据查询MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。表结构不明确，且数据在不断变大在一些传统RDBMS中，增加一个字段会锁住整个数据库/表，或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于1G的时候（当大于1TB时更甚）。因MongoDB是文档型数据库，为非结构货的文档增加一个新字段是很快速的操作，并且不会影响到已有数据。另外一个好处当业务数据发生变化时，是将不在需要由DBA修改表结构。没有DBA支持如果没有专职的DBA，并且准备不使用标准的关系型思想（结构化、连接等）来处理数据，那么MongoDB将会是你的首选。MongoDB对于对像数据的存储非常方便，类可以直接序列化成JSON存储到MongoDB中。但是需要先了解一些最佳实践，避免当数据变大后，由于文档设计问题而造成的性能缺陷。BillRun – 基于MongoDB的帐单系统 (来自oc666)BillRun是由Ofer Cohen推出开源账单系统，采用MongoDB做为数据存储。这套账单系统被以色列一家增速最快的电信运营商采用，每月处理5亿条通信记录，Ofer在Slideshare上说明了具体利到了MongoDB的哪些特性：弱数据结构的特点，使得BillRun能很快的支持新的CDR(通讯记录)类型。这个特性使文档型数据库很适用于快速发展、业务需求不确定的系统中。BillRun仅使用了一个Collection，已经管理了数TB的文档数据，并且没有遇到由结构变更、数据爆发式增长的带来的限制和问题。replicaSet副本集特性使建立更多的数据中心DRP变得更轻松。内建的Sharding分片特性避免系统在数据增长的过程中遇到性能瓶颈。每秒钟2000条通信记录的插入，MongoDB在架构设计上很好的支持了高负载的数据写入。并且可以使用findAndModify(相对缓慢)完成基础的事务特性，并且通过应用层面的支持，实现双段式提交。查询方式相比SQL，更加易读、易懂，开发相对轻松。基于位置允许更好的分析用户使用情况，从而更好地制定移动电话基础设施的投入点。

使用json风格语法，易于掌握和理解：mongodb使用json的变种bson作为内部存储的格式和语法。针对mongodb的操作都使用json风格语法，客户端提交或接收的数据都使用json形式来展现。相对于sql来说，更加直观，容易理解和掌握。schema-less，支持嵌入子文档：mongodb是一个schema-free的文档数据库。一个数据库可以有多个collection，每个collection是documents的集合。collection和document和传统数据库的table和row并不对等。无需事先定义collection，随时可以创建。collection中可以包含具有不同schema的文档记录。这意味着，你上一条记录中的文档有3个属性，而下一条记录的文档可以有10个属性，属性的类型既可以是基本的数据类型（如数字、字符串、日期等），也可以是数组或者散列，甚至还可以是一个子文档（embed document）。这样，可以实现逆规范化（denormalizing）的数据模型，提高查询的速度。

文章TAG：图数据库数据数据库适用图数据库适用哪些场景