我发现了两篇关于这个主题的令人印象深刻的文章。highscalability.com的所有学分。此答案中的信息转录自以下文章：
选择下一个 NoSQL 数据库的 35 多个用例
你到底在用 NoSQL 做什么？
如果您的应用程序需要...
•复杂的事务，因为您不能承受丢失数据，或者如果您想要一个简单的事务编程模型，那么请查看关系或网格数据库。
•示例：可能需要完整ACID的库存系统。当我买一个产品时我很不高兴，他们后来说他们缺货了。我不想要有偿交易。我想要我的物品！
•扩展然后NoSQL 或SQL 可以工作。寻找支持横向扩展、分区、实时添加和删除机器、负载平衡、自动分片和重新平衡以及容错的系统。
•因为您需要高可用性，所以始终能够写入数据库，然后查看具有最终一致性的Bigtable Clone。
• 处理大量可能不稳定的小型连续读取和写入，然后查看提供快速内存访问的文档或键值或数据库。另外，考虑SSD。
• 要实现社交网络操作，您首先可能需要一个图形数据库，或者第二个，像Riak这样支持关系的数据库。具有简单 SQL 连接的内存中关系数据库可能足以处理小型数据集。Redis的 set 和 list 操作也可以工作。
• 要对各种访问模式和数据类型进行操作，然后查看文档数据库，它们通常很灵活并且性能良好。
• 具有大型数据集的强大离线报告然后看看Hadoop，其次是支持MapReduce的产品。支持 MapReduce 不等于擅长它。
• 要跨越多个数据中心，请查看Bigtable Clone 和其他提供分布式选项的产品，这些选项可以处理长延迟并具有分区容错性。
• 构建CRUD应用程序然后查看文档数据库，它们可以轻松访问复杂数据而无需连接。
•内置搜索然后查看Riak。
• 对列表、集合、队列、发布-订阅等数据结构进行操作，然后查看Redis。对分布式锁定、封顶日志等很有用。
•以对程序员友好的数据类型（如 JSON、HTTP、REST、Javascript）的形式对程序员友好，然后首先查看文档数据库，然后查看键值数据库。
•事务与实时数据馈送的物化视图相结合，然后查看VoltDB。非常适合数据汇总和时间窗口。
•企业级支持和 SLA然后寻找能够满足该市场需求的产品。Membase就是一个例子。
• 记录可能根本不需要一致性保证的连续数据流，然后查看Bigtable克隆，因为它们通常在可以处理大量写入的分布式文件系统上工作。
•尽可能简单地操作然后寻找托管或PaaS解决方案，因为他们会为您完成所有工作。
• 要出售给企业客户，然后考虑使用关系数据库，因为他们习惯于关系技术。
• 要在具有动态属性的对象之间动态建立关系，请考虑使用图形数据库，因为它们通常不需要模式，并且可以通过编程逐步建立模型。
• 支持大型媒体再看S3之类的存储服务。NoSQL系统倾向于不处理大型BLOBS，尽管MongoDB有文件服务。
• 快速高效地批量上传大量数据，然后寻找支持该方案的产品。大多数不会，因为它们不支持批量操作。
•升级路径更简单，然后使用文档数据库或键值数据库等流动模式系统，因为它支持可选字段、添加字段和删除字段，无需构建完整的模式迁移框架。
• 要实现完整性约束，然后选择支持 SQL DDL的数据库，在存储过程中实现它们，或者在应用程序代码中实现它们。
•非常深的连接深度然后使用图形数据库，因为它们支持实体之间的极快导航。
• 将行为靠近数据移动，这样数据就不必通过网络移动，然后查看一种或另一种存储过程。这些可以在关系、网格、文档甚至键值数据库中找到。
•缓存或存储 BLOB数据，然后查看键值存储。缓存可以用于网页的位，或者保存复杂的对象，这些对象在加入关系数据库时很昂贵，可以减少延迟等等。
• 一个经过验证的跟踪记录，例如不破坏数据并且正常工作，然后选择一个已建立的产品，当您遇到扩展（或其他问题）时，使用一种常见的解决方法（扩展、调整、memcached、分片、非规范化等）。
•流动数据类型，因为您的数据本质上不是表格，或者需要灵活数量的列，或者具有复杂的结构，或者因用户（或其他）而异，然后查看文档、键值和Bigtable克隆数据库. 每个人的数据类型都有很大的灵活性。
• 其他业务部门运行快速关系查询，因此您不必重新实现所有内容，然后使用支持 SQL 的数据库。
• 在云中运行并自动充分利用云功能，那么我们可能还没有。
• 支持二级索引，因此您可以通过不同的键查找数据，然后查看关系数据库和Cassandra的新二级索引支持。
• 创建一组很少被访问的不断增长的数据（实际上是BigData），然后查看Bigtable Clone，它将数据分布在分布式文件系统上。
•与其他服务集成，然后检查数据库是否提供某种后写同步功能，以便您可以捕获数据库更改并将它们提供给其他系统以确保一致性。
•容错检查在面对电源故障、分区和其他故障情况时写入的持久性。
• 将技术信封推向一个似乎没人会去的方向，然后自己构建它，因为有时这就是伟大的需要。
• 要在移动平台上工作，请查看 CouchDB/ Mobile couchbase。
一般用例 (NoSQL)
•大。NoSQL 被视为支持新数据堆栈的关键部分：大数据、大量用户、大量计算机、大供应链、大科学等等。当某些东西变得如此庞大以至于必须大规模分布时，NoSQL 就在那里，尽管并非所有 NoSQL 系统都以大为目标。Bigness 可以跨越许多不同的维度，而不仅仅是使用大量的磁盘空间。
•强大的写入性能。这可能是基于谷歌影响的规范用法。高音量。Facebook 每月需要存储1350 亿条消息 （2010 年）。例如，Twitter 存在每天 （2010 年）存储 7 TB/数据的问题，而这一需求预计每年会翻倍。这是数据太大而无法容纳一个节点的问题。以 80 MB/s 的速度存储 7TB 需要一天的时间，因此写入需要分布在集群上，这意味着键值访问、MapReduce、复制、容错、一致性问题等等。对于更快的写入，可以使用内存系统。
•快速键值访问。这可能是 NoSQL 在一般思维集中被引用次数第二多的优点。当延迟很重要时，很难在键上散列并直接从内存中读取值，或者只需一次磁盘查找。并非每个 NoSQL 产品都与快速访问有关，例如，有些产品更注重可靠性。但是人们长期以来一直想要的是更好的 memcached，许多 NoSQL 系统都提供了这种功能。
•灵活的模式和灵活的数据类型。 NoSQL 产品支持一系列新的数据类型，这是 NoSQL 的一个主要创新领域。我们有：面向列、图形、高级数据结构、面向文档和键值。无需大量映射即可轻松存储复杂对象。开发人员喜欢避免使用复杂的模式和ORM框架。缺乏结构允许更大的灵活性。我们还有对程序和程序员友好的兼容数据类型，例如 JSON。
•架构迁移。无模式使处理模式迁移变得更容易，而无需过多担心。模式在某种意义上是动态的，因为它们是由应用程序在运行时强加的，因此应用程序的不同部分可以有不同的模式视图。
•写入可用性。无论如何，您的写作都需要成功吗？然后我们可以进入分区、CAP、最终一致性和所有这些爵士乐。
•更易于维护、管理和操作。这是非常特定于产品的，但许多 NoSQL 供应商正试图通过让开发人员轻松采用它们来获得采用。他们在易用性、最少的管理和自动化操作上花费了大量精力。这可以降低运营成本，因为不必编写特殊代码来扩展从未打算以这种方式使用的系统。
•没有单点故障。并非每个产品都提供这一点，但我们看到了相对容易配置和管理高可用性的明确融合，以及自动负载平衡和集群大小调整。完美的云合作伙伴。
•普遍可用的并行计算。我们看到 MapReduce 融入产品，这使得并行计算成为未来发展的常态。
•程序员的易用性。访问您的数据应该很容易。虽然关系模型对于最终用户（如会计师）来说是直观的，但对于开发人员来说却不是很直观。程序员了解键、值、JSON、Javascript 存储过程、HTTP 等等。NoSQL 适用于程序员。这是一场由开发商主导的政变。对数据库问题的反应并不总是聘请真正知识渊博的DBA，正确设置架构，进行一些非规范化等等，程序员更喜欢他们可以为自己工作的系统。让产品发挥作用应该不难。钱是问题的一部分。如果扩展一个产品的成本很高，那么你会不会选择更便宜、你控制、更容易使用、更容易扩展的产品？
•为正确的问题使用正确的数据模型。不同的数据模型用于解决不同的问题。例如，已经付出了很多努力，将图操作嵌入到关系模型中，但它不起作用。在图数据库中解决图问题不是更好吗？我们现在看到了一种试图在问题和解决方案之间找到最佳匹配的一般策略。
•避免撞墙。许多项目在他们的项目中遇到了某种类型的墙。他们已经用尽了所有选项来使他们的系统扩展或正常运行，并且想知道下一步是什么？选择一种产品和一种方法，可以通过使用增量添加的资源进行线性扩展来跳过墙壁，这是令人欣慰的。有一次这是不可能的。一切都需要定制，但这已经改变了。我们现在看到了一个项目可以轻松采用的可用的开箱即用产品。
•分布式系统支持。并不是每个人都担心非 NoSQL 系统所能达到的规模或性能。他们需要的是一个分布式系统，它可以跨越数据中心，同时处理故障场景而不会出现问题。NoSQL 系统，因为它们专注于规模，倾向于利用分区，倾向于不使用严格的严格一致性协议，因此非常适合在分布式场景中运行。
•可调的 CAP 权衡。NoSQL 系统通常是唯一带有“滑块”的产品，用于选择他们想要在 CAP 范围内的哪个位置。关系数据库选择强一致性，这意味着它们不能容忍分区故障。最后，这是一个商业决定，应该根据具体情况来决定。你的应用甚至关心一致性吗？几滴可以吗？您的应用需要强一致性还是弱一致性？可用性更重要还是一致性更重要？失败会比犯错更昂贵吗？很高兴拥有可以让您选择的产品。
•更具体的用例
• 管理大量非事务性数据：Apache 日志、应用程序日志、MySQL日志、点击流等。
• 同步在线和离线数据。这是CouchDB所针对的利基市场。
• 所有负载下的快速响应时间。
• 当复杂连接的查询负载对于RDBMS来说太大时，避免重连接。
• 低延迟至关重要的软实时系统。游戏就是一个例子。
• 需要支持各种不同的写入、读取、查询和一致性模式的应用程序。有些系统针对 50% 读取、50% 写入、95% 写入或 95% 读取进行了优化。只读应用程序需要极快的速度和弹性、简单的查询，并且可以容忍稍微陈旧的数据。需要中等性能、读/写访问、简单查询、完全权威数据的应用程序。具有复杂查询要求的只读应用程序。
• 负载平衡以适应数据和使用集中并帮助保持微处理器忙碌。
• 实时插入、更新和查询。
• 分层数据，如线程讨论和部件爆炸。
• 动态表创建。
• 两层应用程序，其中低延迟数据通过快速 NoSQL 接口提供，但数据本身可以由高延迟 Hadoop 应用程序或其他低优先级应用程序计算和更新。
•顺序数据读取。需要选择正确的底层数据存储模型。B 树可能不是顺序读取的最佳模型。
• 将可能需要更好性能/可扩展性的部分服务切割到自己的系统上。例如，用户登录可能需要高性能，并且此功能可以使用专用服务来实现这些目标。
•缓存。用于网站和其他应用程序的高性能缓存层。示例是大型强子对撞机使用的数据聚合系统的缓存。表决。
• 实时页面查看计数器。
• 用户注册、配置文件和会话数据。
•文档、目录管理和内容管理系统。这些都是通过存储复杂文档的能力来促进的，它具有一个整体而不是组织为关系表。类似的逻辑适用于库存、购物车和其他结构化数据类型。
•归档。存储仍然可以在线访问的大量连续数据流。具有灵活模式的面向文档的数据库，可以处理模式随时间的变化。
•分析。使用 MapReduce、Hive 或 Pig 执行支持高写入负载的分析查询和横向扩展系统。
• 处理异构类型的数据，例如，通用级别的不同媒体类型。
• 嵌入式系统。他们不想要 SQL 和服务器的开销，因此他们使用更简单的存储方式。
• 一个“市场”游戏，您在其中拥有城镇中的建筑物。你想让某人的建筑列表快速弹出，所以你在建筑表的所有者列上进行分区，这样选择是单分区的。但是，当有人购买其他人的建筑物时，您会更新所有者列以及价格。
• JPL正在使用SimpleDB来存储流动站计划属性。对S3中的完整计划 blob 的引用保持不变。（来源）
• 联邦执法机构使用信用卡、会员卡和旅行预订实时跟踪美国人。
•通过实时将交易与已知模式进行比较来检测欺诈。
•通过整合每位患者的病史，帮助诊断肿瘤类型。
• 用于高更新情况的内存数据库，例如显示每个人“最后一次活动”时间的网站（可能用于聊天）。如果用户每 30 秒执行一次某些活动，那么您将几乎达到您的极限，同时有大约 5000 个用户。
• 使用物化视图处理低频多分区查询，同时继续处理高频流数据。
• 优先队列。
• 使用程序友好的界面对缓存数据运行计算，而无需通过ORM。
•使用简单的键值列对大型数据集进行唯一化。
• 为了保持快速查询，可以将值汇总到不同的时间片中。
• 计算两个大集合的交集，其中连接会太慢。
•时间线ala Twitter。
Redis 用例、VoltDB 用例等可在此处找到。