每种数据库类型的实例(真实案例)

•企业级支持和sla然后寻找一种能够迎合该市场的产品。Membase就是一个例子。

•记录连续流对于那些可能根本没有一致性保证的数据，那么请考虑Bigtable克隆，因为它们通常工作在可以处理大量写操作的分布式文件系统上。

•使尽可能简单然后寻找托管或PaaS解决方案，因为他们会为你做所有的工作。

•销售给企业客户然后考虑使用关系数据库，因为他们已经习惯了关系技术。

•到动态建立关系在具有动态属性的对象之间然后考虑图形数据库，因为它们通常不需要模式，并且可以通过编程增量地构建模型。

•支持大媒体然后看看S3之类的存储服务。NoSQL系统通常不处理大的blob，尽管MongoDB有一个文件服务。

•到批量上传快速有效地获取大量数据，然后寻找支持该场景的产品。大多数不支持批量操作。

•an更容易升级路径然后使用像文档数据库或键值数据库这样的流动模式系统，因为它支持可选字段、添加字段和删除字段，而不需要构建整个模式迁移框架。

•实现完整性约束然后选择一个支持SQL DDL的数据库，在存储过程中实现，或者在应用程序代码中实现。

•a非常深连接深度然后使用图形数据库，因为它们支持实体之间极快的导航。

•将行为移动到数据附近因此，数据不需要在网络上移动，然后再查看这样或那样的存储过程。这些可以在关系、网格、文档甚至键值数据库中找到。

•到缓存或存储BLOB数据，然后查看键值存储。缓存可以保存网页的比特，或者保存在关系数据库中连接成本很高的复杂对象，以减少延迟，等等。

•a可靠的跟踪记录比如不破坏数据，只是正常工作，那么选择一个成熟的产品，当你遇到扩展(或其他问题)时，使用一种常见的解决方案(缩放、调优、memcached、分片、反规范化等)。

•流体数据类型因为您的数据本质上不是表格式的，或者需要灵活的列数，或者具有复杂的结构，或者因用户而异(或其他)，那么请查看Document、Key-value和Bigtable Clone数据库。它们的数据类型都很灵活。

•其他业务单元运行快速关系查询所以你不必重新实现所有的东西，然后使用一个支持SQL的数据库。

•在云中运行并自动充分利用云功能，那么我们可能还没有到那里。

•支持二级索引因此，您可以通过不同的键来查找数据，然后查看关系数据库和Cassandra的新二级索引支持。

•创建不断增长的数据集(真正的大数据)很少被访问，然后看看Bigtable克隆，它将数据分散到一个分布式文件系统。

•到与其他业务集成然后检查数据库是否提供某种类型的write-behind同步功能，以便您可以捕获数据库更改并将其提供给其他系统以确保一致性。

•容错检查在电源故障、分区和其他故障情况下写操作的持久性。

•把技术的极限推向一个似乎没有人会去的方向，然后自己去做，因为有时这就是伟大的原因。

•在移动平台上工作然后看看CouchDB/Mobile couchbase。

一般用例(NoSQL)

•大． NoSQL被视为支持大数据、大量用户、大量计算机、大供应链、大科学等新数据栈的关键部分。当某件事变得如此庞大，以至于它必须成为大规模分布式时，NoSQL就出现了，尽管不是所有的NoSQL系统都瞄准了大的目标。大可以跨越许多不同的维度，而不仅仅是使用大量的磁盘空间。

•海量写性能。这可能是基于谷歌影响力的规范用法。高容量。Facebook每月需要存储1350亿条消息^(2010年)。例如，Twitter每天存储7 TB/数据的问题^(2010年)，预计这一需求每年会翻几倍。这是数据太大而不能放在一个节点上的问题。以80mb/s的速度存储7TB需要一天的时间，因此写入需要分布在集群上，这意味着键值访问、MapReduce、复制、容错、一致性问题以及所有其他问题。对于更快的写操作，可以使用内存系统。

•快速键值访问。这可能是NoSQL在一般思维模式中被引用次数第二多的优点。当延迟很重要时，很难击败对键进行散列并直接从内存或只需一次磁盘查找即可读取值的方法。不是每个NoSQL产品都是关于快速访问的，例如，有些产品更多的是关于可靠性的。但是人们一直想要的是一个更好的memcached，许多NoSQL系统都提供了这个功能。

•灵活的模式和灵活的数据类型NoSQL产品支持一系列新的数据类型，这是NoSQL创新的一个主要领域。我们有:面向列的、图形的、高级数据结构、面向文档的和键值的。复杂的对象可以很容易地存储，而不需要大量的映射。开发人员喜欢避免复杂的模式和ORM框架。缺乏结构允许更多的灵活性。我们也有程序友好和程序员友好兼容的数据类型，比如JSON。

•模式迁移。无模式性使处理模式迁移变得更加容易，而不必担心太多问题。模式在某种意义上是动态的，因为它们是由应用程序在运行时强加的，所以应用程序的不同部分可以有不同的模式视图。

•写可用性。你的写作无论如何都需要成功吗?然后我们可以进入分区，CAP，最终一致性和所有的爵士乐。

•更容易维护、管理和操作。这是非常特定于产品的，但许多NoSQL供应商正试图通过使开发人员更容易地采用它们来获得采用。他们在易用性、最小化管理和自动化操作上花费了大量精力。这可以降低操作成本，因为不需要编写特殊代码来扩展从未打算以这种方式使用的系统。

•无单点故障。并不是每个产品都实现了这一点，但我们看到了一个明确的融合，即相对容易配置和管理具有自动负载平衡和集群大小的高可用性。一个完美的云合作伙伴。

•通用并行计算。我们看到MapReduce被融入到产品中，这使得并行计算将成为未来开发的一个正常部分。

•程序员易用性。访问数据应该很容易。虽然关系模型对最终用户(如会计)来说是直观的，但对开发人员来说却不是很直观。程序员学习键、值、JSON、Javascript存储过程、HTTP等等。NoSQL是为程序员准备的。这是一场由开发者主导的政变。对数据库问题的回应不可能总是雇佣一个真正有知识的DBA，让你的模式正确，稍微去规范化，等等，程序员更喜欢一个他们可以为自己工作的系统。让一个产品发挥作用不应该那么难。钱是问题的一部分。如果一个产品的规模化成本很高，那么你会不会选择更便宜的、你能控制的、更容易使用、更容易规模化的产品呢?

•为正确的问题使用正确的数据模型。不同的数据模型用于解决不同的问题。例如，将图操作楔入到关系模型中已经付出了很多努力，但它不起作用。在图形数据库中解决图形问题不是更好吗?我们现在看到的是一种试图在问题和解决方案之间找到最佳匹配的总体策略。

•避免撞墙许多项目在他们的项目中遇到了某种类型的障碍。他们已经用尽了所有的选择，使他们的系统规模或性能正常，并想知道下一步是什么?选择一种产品和一种方法是令人欣慰的，它可以通过使用增量添加的资源进行线性扩展来跳过这堵墙。这曾经是不可能的。所有东西都是定制的，但这已经改变了。我们现在看到了一个项目可以很容易地采用的可用的开箱即用的产品。

•分布式系统支持。并不是每个人都担心非nosql系统所能达到的规模或性能。他们需要的是一个能够跨数据中心处理故障场景的分布式系统。NoSQL系统，因为他们关注规模，倾向于利用分区，倾向于不使用严格的一致性协议，因此很适合在分布式场景中运行。

•可调的CAP权衡。NoSQL系统通常是唯一具有"滑块"的产品，用于选择它们在CAP范围中的位置。关系数据库选择强一致性，这意味着它们不能容忍分区失败。最后，这是一个业务决策，应该根据具体情况来决定。你的应用是否关心一致性?几滴可以吗?你的应用需要强一致性还是弱一致性?可用性更重要还是一致性更重要?失败会比犯错代价更大吗?有产品让你有选择的余地真好。

•更具体的用例

•同步在线和离线数据。这是CouchDB瞄准的一个利基市场。

•所有负载下的快速响应时间。

•当复杂连接的查询负载对于RDBMS来说太大时，避免重连接。

•软实时系统，其中低延迟至关重要。游戏就是一个例子。

•需要支持各种不同的写、读、查询和一致性模式的应用程序。有些系统优化为50%读50%写、95%写或95%读。只读应用程序需要极高的速度和弹性、简单的查询，并且可以容忍稍微过时的数据。应用程序要求适度的性能，读/写访问，简单的查询，完全权威的数据。一个具有复杂查询需求的只读应用程序。

•负载平衡以适应数据和使用集中，并帮助保持微处理器繁忙。

•实时插入、更新和查询。

•分层数据，如线程讨论和部件爆炸。

•动态创建表。

•两层应用程序，通过快速NoSQL接口提供低延迟数据，但数据本身可以由高延迟Hadoop应用程序或其他低优先级应用程序计算和更新。

•顺序读取数据。需要选择正确的底层数据存储模型。b树可能不是顺序读取的最佳模型。

•将可能需要更好性能/可伸缩性的部分服务切割到自己的系统上。例如，用户登录可能需要高性能，此功能可以使用专用服务来满足这些目标。

•缓存。用于网站和其他应用程序的高性能缓存层。示例是大型强子对撞机使用的数据聚合系统的缓存。投票。

•实时页面浏览量计数器。

•用户注册、配置文件和会话数据。

•文档、目录管理和内容管理系统。这得益于将复杂文档存储成一个整体而不是组织成关系表的能力。类似的逻辑也适用于库存、购物车和其他结构化数据类型。

•存档。存储仍可在线访问的大量连续数据流。面向文档的数据库，具有灵活的模式，可以处理模式随时间的变化。

•分析。使用MapReduce、Hive或Pig来执行分析查询和扩展支持高写负载的系统。

•处理异构类型的数据，例如，在通用级别上处理不同的媒体类型。

•嵌入式系统。他们不想要SQL和服务器的开销，所以他们使用更简单的东西来存储。

•一个"市场"游戏，你在一个城镇拥有建筑。您希望快速弹出某人的建筑物列表，因此您对建筑物表的所有者列进行分区，以便选择是单分区的。但是当有人买了别人的房子，你就会更新业主栏和价格。

•JPL使用SimpleDB来存储漫游者计划属性。在S3中，引用保持在一个完整的计划blob中。<一口>(源)

•联邦执法机构实时跟踪使用信用卡、会员卡和旅行预订的美国人。

•通过实时比较交易和已知模式来检测欺诈。

•通过整合每位患者的病史，帮助诊断肿瘤的类型。

•内存数据库用于高更新情况，如网站显示每个人的"最后活动"时间(聊天可能)。如果用户每30秒执行一次活动，那么您将几乎达到5000个同时用户的极限。

•使用物化视图处理低频多分区查询，同时继续处理高频流数据。

•优先队列。

•在缓存数据上运行计算，使用程序友好的界面，而无需经过ORM。

•使用简单的键值列来统一一个大型数据集。

•为了保持查询的速度，可以将值滚动到不同的时间片中。

•计算两个大集合的交集，在那里连接太慢了。

•Twitter上的时间轴。

Redis用例，voldb用例和更多的发现在这里。

如果你有一个"社交网络"，但没有任何发现机制，那么你可以很容易地使用任何基本的键值存储。如果您需要高性能、横向扩展，并且需要二级索引或全文搜索，那么您可以使用Couchbase。

如果你在收集日志数据的基础上进行机器学习，你可以将Hadoop与Hive或Pig，或Spark/Shark集成。或者你可以做一个lambda架构，在Storm中使用许多不同的系统。

如果你正在通过图形进行发现，比如超越二度顶点的查询，并且还过滤边缘属性，你可能会考虑将图形数据库放在你的主存储之上。然而，图数据库不是会话存储的好选择，或者作为通用存储，所以你需要一个多语言的解决方案来提高效率。

数据速度是多少?规模?你想怎么管理它?你在公司或创业公司有哪些专业技能。这不是一个简单的问题和答案，原因有很多。

键值vs面向文档

如果您定义了清晰的数据结构，使得所有数据都只有一个键，那么选择键-值存储。这就像你有一个大的哈希表，人们主要将它用于缓存存储或明显基于键的数据。然而，当您需要基于多个键查询相同的数据时，事情就开始变得有点棘手了!

一些键值存储:memcached, Redis, Aerospike。