有多种类型的数据库用于不同的目的，但通常 MySQL 可以用于所有用途，因为它是最知名的数据库。举个例子，在我的公司，大数据的应用初期就有MySQL数据库，这是令人难以置信的，会给公司带来严重的后果。为什么选择 MySQL？只是因为没有人知道应该如何（以及何时）使用另一个 DBMS。
所以，我的问题不是关于供应商，而是关于数据库类型。您能给我一个强烈建议使用每种类型数据库的特定情况（或应用程序）的实际示例吗？
Example:
• 由于Y，社交网络应使用X 类型。
• MongoDB 或couchDB 无法支持事务，因此Documentdb 不适合用于银行或拍卖网站的应用程序。
等等...
关系： MySQL http://www.mysql.com/, PostgreSQL http://www.postgresql.org/, SQLite http://www.sqlite.org/, Firebird http://www.firebirdsql.org/, MariaDB http://mariadb.org, 甲骨文数据库 http://www.oracle.com/technetwork/indexes/downloads/index.html#database, SQL服务器 http://www.microsoft.com/sqlserver/pt/br/default.aspx, IBM DB2 http://www-01.ibm.com/software/data/db2/, IBM Informix http://www-01.ibm.com/software/data/informix/,
Object: ZODB http://zodb.org/, DB4O http://www.db4o.com/, Eloquera http://eloquera.com, Versant http://actian.com/products/versant , 客观性数据库 http://www.objectivity.com/, 速度数据库 http://www.velocitydb.com/
图数据库： 快板 http://www.franz.com/agraph/allegrograph/, Neo4j http://www.neo4j.org/, OrientDB http://www.orientdb.org, 无限图 http://www.objectivity.com/infinitegraph, 图库 http://graphbase.net/, 火花数据库 http://www.sparkledb.net/, flockdb https://github.com/twitter/flockdb, 亮星数据库 http://www.brightstardb.com/
关键价值存储： 亚马逊动态数据库 http://aws.amazon.com/dynamodb/, Redis http://redis.io/, Riak http://basho.com/riak/, 伏地魔 http://www.project-voldemort.com/, 基金会数据库 http://foundationdb.com/, leveldb http://code.google.com/p/leveldb/, BangDB http://www.iqlect.com/, KAI http://sourceforge.net/projects/kai/, 仓鼠数据库 http://hamsterdb.com/, 塔兰图尔 http://www.tarantool.org/, Maxtable http://code.google.com/p/maxtable/, HyperDex http://hyperdex.org/, Genomu http://hyperdex.org/, 内存缓存数据库 http://code.google.com/p/memcachedb/downloads/list
列族： 大桌子 http://research.google.com/archive/bigtable.html, Hbase http://hbase.apache.org/, 超级表 http://hypertable.org/, 卡桑德拉 http://cassandra.apache.org, 阿帕奇累积 http://accumulo.apache.org/
RDF 商店： 阿帕奇耶拿 http://jena.apache.org/, Sesame http://www.openrdf.org/
多模型数据库： arangodb http://www.arangodb.org/, Datomic http://www.datomic.com/, 东方数据库 http://www.orientechnologies.com/, FatDB http://fatcloud.com/net_nosql_database.html, 炼金数据库 http://code.google.com/p/alchemydatabase/
文档： Mongo DB http://www.mongodb.org/, Couch DB http://couchdb.apache.org, 重新思考数据库 http://www.rethinkdb.com/, Raven DB https://github.com/ravendb/ravendb, 特拉存储 http://code.google.com/p/terrastore/, Jas DB http://www.oberasoftware.com/, 猛禽数据库 http://www.codeproject.com/Articles/375413/RaptorDB-the-Document-Store, djon DB http://djondb.com/, EJDB http://ejdb.org/, denso DB http://www.densodb.net/, 沙发底座 http://www.couchbase.com/
XML 数据库： BaseX http://basex.org/, Sedna http://www.sedna.org/, eXist http://exist-db.org/exist/apps/homepage/index.html
层次结构： 系统间缓存 http://www.intersystems.com/cache/, GT.M http://sourceforge.net/projects/fis-gtm/ 感谢@Laurent Parenteau
我发现了两篇关于这个主题的令人印象深刻的文章。所有学分至highscalability.com http://highscalability.com/。本回答中的信息摘自以下文章：
选择下一个 NoSQL 数据库的 35 个以上用例 http://highscalability.com/blog/2011/6/20/35-use-cases-for-choosing-your-next-nosql-database.html
你到底在用 NoSQL 做什么？ http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html
如果您的应用程序需要...
• 复杂的交易因为您不能丢失数据，或者如果您想要一个简单的事务编程模型，那么请考虑关系数据库或网格数据库。
• Example:一个可能需要完整的库存系统ACID https://en.wikipedia.org/wiki/ACID_(computer_science)。当我购买产品时我非常不高兴，后来他们说缺货了。我不想要补偿交易。我想要我的物品！
• to scale那么 NoSQL 或 SQL 都可以工作。寻找支持横向扩展、分区、实时添加和删除机器、负载平衡、自动分片和重新平衡以及容错的系统。
• to always能够write到数据库，因为您需要高可用性，然后查看Bigtable https://cloud.google.com/bigtable/具有最终一致性的克隆。
• 处理大量小型连续读取和写入，这可能是易失性的，然后查看文档或键值或提供快速内存访问的数据库。另外，考虑SSD https://en.wikipedia.org/wiki/Solid-state_drive.
• 实施社交网络运营那么你首先可能需要一个图形数据库，或者第二个数据库，例如Riak http://basho.com/products/支持关系。具有简单 SQL 连接的内存关系数据库可能足以满足小型数据集的需要。Redis https://redis.io/' 设置和列表操作也可以工作。
• 操作超过各种各样的访问模式和数据类型然后看文档数据库，它们一般都很灵活并且性能良好。
• 强大的大型数据集的离线报告然后看看Hadoop https://hadoop.apache.org/第一和第二，支持的产品映射减少 https://www.ibm.com/analytics/hadoop/mapreduce。支持 MapReduce 并不等于擅长它。
• to 跨多个数据中心然后看看Bigtable https://cloud.google.com/bigtable/克隆和其他提供分布式选项的产品可以处理长延迟，并且分区容忍 https://stackoverflow.com/q/12346326/1429387.
• 建造CRUD然后应用程序查看文档数据库，它们使无需连接即可轻松访问复杂数据。
• 内置搜索然后看看Riak http://basho.com/products/.
• 操作于数据结构像列表、集合、队列、发布-订阅然后看看Redis https://redis.io/。对于分布式锁定、上限日志等很有用。
• 程序员友好度以程序员友好的数据类型（如 JSON、HTTP、REST、Javascript）的形式，首先查看文档数据库，然后查看键值数据库。
• 交易结合物化视图 for 即时的数据馈送然后查看VoltDB https://www.voltdb.com/。非常适合数据汇总和时间窗口 https://forum.voltdb.com/forum/voltdb-discussions/building-voltdb-applications/791-aggregation-over-time-window.
• 企业级支持和 SLA然后寻找一种能够迎合该市场的产品。Membase https://en.wikipedia.org/wiki/Couchbase_Server就是一个例子。
• 记录连续流可能根本没有必要的一致性保证的数据，然后查看Bigtable https://cloud.google.com/bigtable/克隆，因为它们通常在可以处理大量写入的分布式文件系统上工作。
• to be 尽可能简单进行操作，然后寻找托管或PaaS https://en.wikipedia.org/wiki/Platform_as_a_service解决方案，因为他们会为您完成所有工作。
• 出售给企业客户然后考虑关系数据库，因为他们习惯了关系技术。
• to 动态建立关系具有的对象之间动态特性然后考虑图形数据库，因为它们通常不需要模式，并且可以通过编程增量构建模型。
• 支持大媒体然后看看存储服务S3 https://aws.amazon.com/s3/. NoSQL https://en.wikipedia.org/wiki/NoSQL系统往往不处理大型BLOBS https://en.wikipedia.org/wiki/Binary_large_object， 尽管MongoDB https://www.mongodb.com/有文件服务。
• to 批量上传快速有效地获取大量数据，然后寻找支持该场景的产品。大多数不会，因为它们不支持批量操作。
• an 更简单的升级路径然后使用文档数据库或键值数据库等流体模式系统，因为它支持可选字段、添加字段和字段删除，而无需构建整个模式迁移框架。
• 实施完整性约束然后选择一个支持SQL的数据库DDL https://en.wikipedia.org/wiki/Data_definition_language，在存储过程中实现它们，或者在应用程序代码中实现它们。
• a 非常深的连接深度然后使用图形数据库，因为它们支持实体之间的快速导航。
• 移动行为接近数据因此，数据不必通过网络移动，然后查看一种或另一种存储过程。这些可以在关系、网格、文档甚至键值数据库中找到。
• to 缓存或存储 BLOB数据然后查看键值存储。缓存可以用于网页的位，或者保存在关系数据库中加入成本高昂的复杂对象，以减少延迟等等。
• a 良好的记录就像不损坏数据并且正常工作一样，然后选择一个成熟的产品，当您遇到扩展（或其他问题）时，使用常见的解决方法之一（扩展、调整、memcached、sharding https://docs.mongodb.com/manual/sharding, 非规范化 https://en.wikipedia.org/wiki/Denormalization, etc).
• 流体数据类型因为您的数据本质上不是表格形式，或者需要灵活的列数，或者具有复杂的结构，或者因用户（或其他原因）而异，然后查看文档、键值和Bigtable https://cloud.google.com/bigtable/克隆数据库。每个数据类型都具有很大的灵活性。
• 其他业务部门运行快速关系查询因此您不必重新实现所有内容，然后使用支持 SQL 的数据库。
• 要在云中运行并自动充分利用云功能，那么我们可能还无法做到这一点。
• 支持二级指标所以你可以通过不同的键查找数据，然后查看关系数据库，卡桑德拉 https://cassandra.apache.org/'s new 二级索引 https://docs.datastax.com/en/cql/3.3/cql/cql_using/useSecondaryIndex.html支持。
• 创建一个不断增长的数据集（真的BigData https://en.wikipedia.org/wiki/Big_data）很少被访问然后看看Bigtable https://cloud.google.com/bigtable/克隆将数据分布在分布式文件系统上。
• to 与其他服务集成然后检查数据库是否提供某种后写同步功能，以便您可以捕获数据库更改并将其输入其他系统以确保一致性。
• 容错检查面对电源故障、分区和其他故障情况时写入的持久性如何。
• 将技术极限推向似乎没有人会去的方向，然后自己构建它，因为有时这就是伟大所需要的。
• 致力于移动平台然后看看 CouchDB/移动沙发底座 https://www.couchbase.com/products/mobile.
一般用例 (NoSQL)
• Bigness。 NoSQL 被视为新数据堆栈的关键部分，支持：大数据、大量用户、大量计算机、大供应链、大科学等。当某些东西变得如此庞大以至于必须大规模分布时，NoSQL 就会出现，尽管并非所有 NoSQL 系统都以大型为目标。大可以跨越许多不同的维度，而不仅仅是使用大量的磁盘空间。
• Massive write performance. This is probably the canonical usage based on Google's influence. High volume. Facebook needs to store 135 billion messages a month http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html (in 2010). Twitter, for example, has the problem of storing 7 TB/data per day https://www.slideshare.net/kevinweil/nosql-at-twitter-nosql-eu-2010 (in 2010) with the prospect of this requirement doubling multiple times per year. This is the data is too big to fit on one node problem. At 80 MB/s it takes a day to store 7TB so writes need to be distributed over a cluster, which implies key-value access, MapReduce, replication, fault tolerance, consistency issues, and all the rest. For faster writes in-memory systems can be used.
• 快速键值访问。这可能是人们普遍认为 NoSQL 的第二大优点。当延迟很重要时，很难击败对键进行散列并直接从内存或在一次磁盘寻道中读取值。并非每个 NoSQL 产品都注重快速访问，有些产品更注重可靠性等。但人们长期以来一直想要的是更好的 memcached，许多 NoSQL 系统都提供了这一点。
• 灵活的模式和灵活的数据类型。NoSQL 产品支持一系列新的数据类型，这是 NoSQL 的一个主要创新领域。我们有：面向列、图、高级数据结构、面向文档、键值。无需大量映射即可轻松存储复杂对象。开发人员喜欢避免复杂的模式ORM https://en.wikipedia.org/wiki/Object-relational_mapping构架。缺乏结构可以提供更大的灵活性。我们还有程序和程序员友好的兼容数据类型，例如 JSON。
• 架构迁移。无模式性使得处理模式迁移变得更加容易，而无需担心太多。模式在某种意义上是动态的，因为它们是由应用程序在运行时强加的，因此应用程序的不同部分可以有不同的模式视图。
• 写可用性。无论如何，您的写入都需要成功吗？然后我们就可以进入分区了，CAP https://en.wikipedia.org/wiki/CAP_theorem, 最终一致性 https://en.wikipedia.org/wiki/Eventual_consistency以及所有爵士乐。
• 更容易维护、管理和操作。这是非常特定于产品的，但许多 NoSQL 供应商正试图通过让开发人员更容易采用它们来获得采用。他们在易用性、最少的管理和自动化操作方面投入了大量精力。这可以降低运营成本，因为不必编写特殊代码来扩展从未打算以这种方式使用的系统。
• 无单点故障。并非每个产品都能实现这一点，但我们看到相对容易配置和管理高可用性与自动负载平衡和集群规模的明确融合。完美的云合作伙伴。
• 一般可用的并行计算。我们看到 MapReduce 融入到产品中，这使得并行计算成为未来开发的正常组成部分。
• 程序员易用性。访问您的数据应该很容易。虽然关系模型对于会计师等最终用户来说很直观，但对于开发人员来说却不是很直观。程序员熟悉键、值、JSON、Javascript 存储过程、HTTP 等。 NoSQL 适合程序员。这是开发商主导的政变。解决数据库问题并不总是需要聘请真正知识渊博的人DBA https://en.wikipedia.org/wiki/Database_administrator、让你的模式正确、稍微反规范化等等，程序员会更喜欢一个他们可以为自己工作的系统。让产品发挥作用应该不难。金钱是问题的一部分。如果扩展一个产品的成本很高，那么您是否会选择您控制的更便宜、更容易使用、更容易扩展的产品？
• 针对正确的问题使用正确的数据模型。不同的数据模型用于解决不同的问题。例如，人们已经投入了很多努力，例如将图操作楔入关系模型中，但它不起作用。在图数据库中解决图问题不是更好吗？我们现在看到的是试图找到问题和解决方案之间最佳匹配的总体策略。
• 避免撞到墙上。许多项目在他们的项目中遇到了某种类型的障碍。他们已经用尽了使系统扩展或正常运行的所有选项，并且想知道下一步该怎么做？选择一种可以通过使用增量添加的资源进行线性扩展来跨越障碍的产品和方法是令人欣慰的。一度这是不可能的。它需要定制一切，但现在已经改变了。我们现在看到项目可以轻松采用的可用的开箱即用产品。
• 分布式系统支持。并非所有人都担心非 NoSQL 系统所能实现的规模或性能。他们需要的是一个可以跨数据中心同时处理故障场景而不会出现问题的分布式系统。 NoSQL 系统由于注重规模，倾向于利用分区，倾向于不使用严格的一致性协议，因此非常适合在分布式场景中运行。
• 可调 CAP 权衡 https://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html.NoSQL 系统通常是唯一具有“滑块”的产品，用于选择它们想要在 CAP 范围内的位置。关系数据库选择强一致性，这意味着它们不能容忍分区故障。最后，这是一项商业决策，应根据具体情况做出决定。您的应用程序是否关心一致性？几滴就可以了吗？您的应用程序需要强一致性还是弱一致性？可用性更重要还是一致性更重要？失败会比犯错付出更大的代价吗？很高兴拥有能为您提供选择的产品。
• 更具体的用例
• 管理大量非事务性数据：Apache 日志、应用程序日志、MySQL https://www.mysql.com/日志、点击流等
• 同步在线和离线数据。这是一个利基市场CouchDB https://couchdb.apache.org/已瞄准。
• 所有负载下的快速响应时间。
• 当复杂连接的查询负载变得太大而无法满足要求时，避免使用繁重的连接。RDBMS https://en.wikipedia.org/wiki/Relational_database_management_system.
• 低延迟至关重要的软实时系统。游戏就是一个例子。
• 需要支持各种不同的写入、读取、查询和一致性模式的应用程序。有些系统针对 50% 读取、50% 写入、95% 写入或 95% 读取进行了优化。只读应用程序需要极高的速度和弹性、简单的查询，并且可以容忍稍微陈旧的数据。需要中等性能、读/写访问、简单查询、完全权威数据的应用程序。查询要求复杂的只读应用程序。
• 负载平衡以适应数据和使用集中度并帮助保持微处理器繁忙。
• 实时插入、更新和查询。
• 分层数据，如线索讨论和零件爆炸。
• 动态表创建。
• 两层应用程序，其中通过快速NoSQL 接口提供低延迟数据，但数据本身可以由高延迟Hadoop 应用程序或其他低优先级应用程序计算和更新。
• 顺序数据读取。需要选择正确的底层数据存储模型。 B 树可能不是顺序读取的最佳模型。
• 将可能需要更好性能/可扩展性的部分服务划分到自己的系统上。例如，用户登录可能需要高性能，并且此功能可以使用专用服务来满足这些目标。
• Caching.适用于网站和其他应用程序的高性能缓存层。示例是大型强子对撞机使用的数据聚合系统的缓存。 表决。
• 实时页面浏览计数器。
• 用户注册、个人资料和会话数据。
• 文档、目录管理和内容管理系统。这些是通过将复杂文档存储为一个整体而不是组织为关系表的能力来实现的。类似的逻辑适用于库存、购物车和其他结构化数据类型。
• 归档。存储仍可在线访问的大量连续数据流。具有灵活架构的面向文档的数据库，可以处理架构随时间的变化。
• 分析。使用 MapReduce、Hive 或 Pig 执行分析查询和支持高写入负载的横向扩展系统。
• 与异构数据类型 https://brehaut.net/blog/2010/couch_impedance#例如，通用级别的不同媒体类型。
• 嵌入式系统。他们不想要 SQL 和服务器的开销，因此他们使用更简单的存储方式。
• “市场”游戏，您在城镇中拥有建筑物。您希望快速弹出某人的建筑物列表，因此您对建筑物表的所有者列进行分区，以便选择是单分区的。但是，当有人购买其他人的建筑物时，您会更新所有者栏以及价格。
• JPL https://www.jpl.nasa.gov/ is using SimpleDB https://aws.amazon.com/simpledb/ to store rover https://opensourcerover.jpl.nasa.gov/ plan attributes. References are kept to a full plan blob in S3 https://aws.amazon.com/s3/. (source) https://qconsf.com/sf2010/sf2010/presentation/Out+of+This+World+Cloud+Computing.html
• 联邦执法机构实时追踪美国人 https://www.wired.com/2010/12/realtime/使用信用卡、会员卡和旅行预订。
• 欺诈识别 https://www.slideshare.net/SparsityTechnologies/dex-introduction通过实时比较交易与已知模式。
• 帮助诊断 https://www.slideshare.net/SparsityTechnologies/dex-introduction通过整合每位患者的病史来了解肿瘤的类型。
• 用于高更新情况的内存数据库，例如website https://news.ycombinator.com/item?id=16430显示每个人的“最后活跃”时间（可能用于聊天）。如果用户每 30 秒执行一次某项活动，那么大约 5000 个并发用户将几乎达到极限。
• 使用物化视图处理低频多分区查询，同时继续处理高频流数据。
• 优先级队列。
• 使用程序友好的界面对缓存的数据运行计算，无需通过ORM https://en.wikipedia.org/wiki/Object-relational_mapping.
• Uniq 大数据集 https://wiki.apache.org/cassandra/UseCases#Uniq_a_large_dataset_using_simple_key-value_columns使用简单的键值列。
• 为了保持快速查询，可以将值汇总到不同的时间片中。
• 计算两个大集合的交集，其中连接速度太慢。
• A 时间线 ala Twitter http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster.
Redis 用例、VoltDB 用例等在这里找到 http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html.
