关系型数据库VS NOSQL 使用场景
数据库场景比较
MySQL还是PostgreSQL?
1、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。例如是一个论坛和社区，你应该使用MySQL。
2、你的应用是一个严肃的商业应用，对数据完整性要求很高。而且你希望对一些商业数据逻辑进行很好的封装，例如是一个网上银行，你应该使用PostgreSQL。
3、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。
4、等等
MongoDB适用案例
1. 事件记录
应用程序对事件记录各有需求。在企业级解决方案中，许多不同的应用程序都需要记录事件。文档数据库可以把所有这些不同类型的事件都存起来，并作为事件存储的”中心数据库”使用。如果事件捕获的数据类型一直在变，那么就更应该用文档数据库了。可以按照触发事件的应用程序名”分片”，也可以按照order_processed(表示订单已处理)或customer_logged(表示客户已记录)等事件类型”分片”。
2. 内容管理系统及博客平台
由于文档数据没有”预设模式”，而且通常支持JSON文档，所以它们很适合在用”内容管理系统”及网站发布程序上，也可以用来管理用户评论、用户注册、用户配置和面向Web文档。
3. 网站分析与实时分析
文档数据库可存储实时分析数据。由于可以只更新部分文档内容，所以用它来存储”页面浏览量”(page view)或”独立访问数”会非常方便，而且无需改变模式即可新增度量标准。分析：鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。
4. 电子商务应用程序
电子商务类应用程序通常需要较为灵活的模式，以存储产品和订单。同时，它们也需要在不做高成本数据库重构及数据迁移的前提下进行其数据模型。
5. 日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。
MongoDB不适用场合
目前事务型业务、以及关联操作业务不适合。
在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。
键值（Key-Value）数据库
键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据，鉴于使用主键访问，所以会获得不错的性能及扩展性。
适用的场景
储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择。
不适用场景
1. 取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。
2. 需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
3. 事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。
Cassandra使用场景
1. 事件记录
由于列族数据库可存放任意数据结构，所以它很适合用来保存应用程序状态或运行中遇到的错误等事件信息。在企业级环境下，所有应用程序都可以把事件写入Cassandra数据库。它们可以用appname:timestamp(应用程序名：时间戳)作为行键，并使用自己需要的列。由于Cassandra的写入能力可扩展，所以在事件记录系统中使用它效果会很好。
2. 内容管理系统与博客平台
使用列族，可以把博文的”标签”(tag)、”类别”(category)、”链接”(link)和”trackback”（俗称引用告知，是一种网志工具，它可以让文章作者知道该文读者中有哪些人撰写了哪些与之有关的文章）等属性放在不同的列中。评论信息即可以与上述内容放在同一行，也可以移到另一个”键空间”。同理，博客用户与实际博文亦可存于不同列族中。博客平台：我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个
3. 计数器
在网络应用程序中，通常要统计某页面的访问人数并对其分类，以算出分析数据。此时可使用ConterColumnType来创建列族。
创建好列族后，可以使用任意列记录网络应用程序中每个用户访问每一页面的次数。
也可以使用CQL增加计数器的值。
4. 限期使用
我们可能需要向用户提供试用版，或是在网站上将某个广告条显示一定时间。这些功能可以通过”带过期时限的列”(expiring column)来完成。这种列过了给定时限后，就会又Cassandra自动删除。这个时限叫做TTL(Time To Live，生存时间)，以秒为单位。经过TTL指定的时长后，这种列就被删掉了。程序若检测到此列不存在，则可收回用户访问权限或移除广告条。
5. 日志。因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。
Cassandra不适合场合
有些问题是有列族数据库来解决并不是最佳选择，例如需要以”ACID事务”执行写入及读取操作的系统。如果想让数据库根据查询结果来聚合数据(例如sum求和)或avg(求平均值)，那么得把每一行数据都读到客户端，并在此执行操作。
在开发早期原型或开始试探某个技术方案时，不太适合用Cassandra。开发初期无法确定查询模式的变化情况，而查询模式一旦改变，列族的设计也要随之修改。这将阻碍产品创新团队的工作并降低开发者的生产能力。
在关系型数据库中，数据模式的修改成本很高，而这却降低了查询模式的修改成本；Cassandra则与之相反，改变其查询模式要比改变数据模式代价更高。
1. 如果我们需要ACID事务。Cassandra就不支持事务。
2. 原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。
图数据库(Neo4j)适用案例
1. 互联数据
部署并使用图数据库来处理社交网络非常高效。社交图里并不是只能有”朋友”这种关系，例如也可以用它们表示雇员、雇员的学识，以及这些雇员与其他雇员在不同项目中的工作位置。任何富含链接关系的领域都很适合用图数据库表示。
假如同一个数据库含有不同领域(像社交领域、空间领域、商务领域等)的领域实体，而这些实体之间又有关系，那么图数据库提供的跨领域遍历功能，可以让这些关系变得更有价值。
2. 安排运输路线、分派货物和基于位置的服务
投递过程中的每个地点或地址都是一个节点，可以把送货员投递货物时所经全部节点建模为一张节点图。节点间关系可带有距离属性，以便高效投递货物。距离与位置属性也可用在名胜图(graph of places of interest)中，这样应用程序就可向用户推荐其附件的好餐馆及娱乐场所了。还可将书店、餐馆等售点(point of sales)做成节点，当用户靠近时通知他们，以提供基于位置的服务。
3. 推荐引擎
在系统中创建节点与关系时，可以用它们为客户推荐信息，例如”您的朋友也买了这件产品”或”给这些货品开发票时，通常也要为哪些货品一并开票”。还可以用它们向旅行者提议：来巴塞罗那旅游的人一般都会去看看安东尼.高迪所设计的建筑。
用图数据库推荐信息时，有个副作用值得注意：随着数据量变多，推荐信息所用的节点及关系数也激增。同一份数据可以挖掘出不同信息。例如，既可以从中看出客户总是将其与那些产品一并购买，也可以查出与此产品一并开发票的其余产品。若两者不匹配，则可发出警示。图数据库与其他”推荐引擎”一样，也可以根据关系间的模式侦测交易欺诈。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定
4. 在一些关系性强的数据中
图数据库Neo4j不适用场合
在更新全部或某子集内的实体时就是这样。比如，在某个”数据分析解决方案”中，只要一个属性变了，全部实体就都得更新。此时图数据库的效果就不理想了，因为没有哪个简单的操作能一次性改变所有节点中的某个属性。即便数据模型适合问题领域，某些图数据库可能也无法处理那么大的数据量，尤其在执行”全局图操作”时更是如此。
不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。