每种types数据库的实例（实例）
有几种types的数据库用于不同的目的，但是通常情况下MySQL是用于一切的，因为是最知名的数据库。 只是举一个例子，我公司的一个大数据应用程序在初始阶段就有一个MySQL数据库，这是令人难以置信的，会给公司带来严重的后果。 为什么MySQL？ 只是因为没有人知道如何（以及何时）应该使用另一个DBMS。
所以，我的问题不是关于供应商，而是数据库的types。 你能给我一个具体情况（或应用程序）的实际例子，强烈build议使用它的每种types的数据库？
例：
•由于Y，社交networking应使用Xtypes。
•MongoDB或沙发数据库不能支持事务处理，所以文档数据库对银行或拍卖网站的应用程序并不好。
等等…
关系： MySQL ， PostgreSQL ， SQLite ， Firebird ， MariaDB ， Oracle数据库 ， SQL服务器 ， IBM DB2 ， IBM Informix ， Teradata
对象： ZODB ， DB4O ， Eloquera ， Versant ， Objectivity DB ， VelocityDB
graphics数据库： AllegroGraph ， Neo4j ， OrientDB ， InfiniteGraph ， graphbase ， sparkledb ， flockdb ， BrightstarDB
主要价值商店： Amazon DynamoDB ， Redis ， Riak ， Voldemort ， FoundationDB ， leveldb ， BangDB ， KAI ， hamsterdb ， Tarantool ， Maxtable ， HyperDex ， Genomu ， Memcachedb
列家族： Big table ， Hbase ， hyper表 ， Cassandra ， Apache Accumulo
RDF店铺： Apache Jena ， 芝麻
多模型数据库： arangodb ， Datomic ， Orient DB ， FatDB ， AlchemyDB
Document： Mongo DB ， Couch DB ， Rethink DB ， Raven DB ， terrastore ， Jas DB ， Raptor DB ， djon DB ， EJDB ， denso DB ， Couchbase
XML数据库： BaseX ， Sedna ， eXist
分级： InterSystemsCaché ， GT.M 感谢@Laurent Parenteau
我发现了两篇关于这个主题的令人印象深刻
所有学分to highscalability.com 。 这些信息是从这些网站转录的。
http://highscalability.com/blog/2011/6/20/35-use-cases-for-choosing-your-next-nosql-database.html
http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html
如果您的应用程序需要…
• 复杂的事务，因为您不能丢失数据，或者您想要一个简单的事务编程模型，然后查看关系数据库或网格数据库。
• 示例：可能需要完整ACI的库存系统。 当我购买一件产品时，我非常不高兴，他们后来说他们缺货。 我不想要一个有偿的交易。 我想要我的物品！
要扩展， NoSQL或SQL可以工作。 寻找支持横向扩展，分区，现场添加和删除机器，负载平衡，自动分片和重新平衡以及容错的系统。
•为了始终能够写入数据库，因为您需要高可用性，请查看具有最终一致性的Bigtable克隆。
•处理大量的连续读取和写入操作 ，这些操作可能是不稳定的，然后查看提供快速内存访问的文档或键值或数据库。 还要考虑SSD。
•为了实现社交networking操作，您首先可能需要一个Graph数据库，或者第二个需要像Riak这样的支持关系的数据库。 具有简单SQL连接的内存关系数据库可能足够用于小型数据集。 Redis的设置和列表操作也可以工作。
•对各种访问模式和数据types进行操作，然后查看文档数据库，它们通常灵活且性能良好。
• 使用大型数据集的强大的离线报告，然后查看Hadoop的第一个和第二个支持MapReduce的产品。 支持MapReduce并不像擅长的那样。
• 跨越多个数据中心，然后查看Bigtable克隆和其他产品，这些产品提供了分布式选项，可以处理长时间的延迟，并且是分区容错的。
•构buildCRUD应用程序，然后查看文档数据库，可以轻松访问没有连接的复杂数据。
• 内置search，然后看看Riak。
•对列表，集合，队列，发布 – 订阅等数据结构进行操作，然后查看Redis。 有用的分布式locking，封顶的日志，还有更多。
•以JSON，HTTP，REST，Javascript等程序员友好的数据types的forms编程友好，然后首先查看文档数据库，然后查看键值数据库。
• 交易与实时数据馈送的物化视图相结合，然后查看VoltDB。 非常适合数据汇总和时间窗口。
• 企业级支持和SLA然后寻找能够迎合该市场的产品。 Membase就是一个例子。
•logging可能没有一致性保证的连续数据stream ，然后查看Bigtable克隆，因为它们通常在可处理大量写入的分布式文件系统上工作。
• 尽可能简单的操作，然后寻找一个托pipe或PaaS解决scheme，因为他们会为你做所有的工作。
•出售给企业客户，然后考虑一个关系数据库，因为它们习惯于关系型技术。
• dynamicbuild立具有dynamic属性的对象之间的关系 ，然后考虑一个graphics数据库，因为他们往往不需要一个模式，模型可以通过编程逐步构build。
•支持大型媒体，然后查看S3等存储服务。 NoSQL系统往往不处理大BLOBS，尽pipeMongoDB有一个文件服务。
•快速高效地批量上传大量数据，然后查找支持该场景的产品。 大多数不会，因为他们不支持批量操作。
• 更简单的升级path，然后使用文档数据库或键值数据库等stream式架构系统，因为它支持可选字段，添加字段和字段删除，而无需构build整个模式迁移框架。
•实现完整性约束，然后select一个支持SQL DDL的数据库，在存储过程中实现它们，或者在应用程序代码中实现它们。
• 深度连接深度使用graphics数据库，因为它们支持在实体之间快速导航。
•将行为移近数据，以便数据不必通过networking移动，然后查看这种或那种存储过程。 这些可以在关系数据库，网格数据库，文档数据库甚至键值数据库中find。
• caching或存储BLOB数据，然后查看Key-value存储。 caching可以用于多个网页，或者用于保存复杂的对象，这些对象在关系数据库中的join非常昂贵，可以减less延迟等等。
• 经过validation的logging，例如不破坏数据，只是一般地工作，然后select一个已build立的产品，当你遇到扩展（或其他问题）使用常见的变通办法（放大，调整，memcached，分片，非规范化等）。
• stream体数据types是因为您的数据本质上不是表格式，或者需要灵活的列数，或者结构复杂，或者因用户（或其他）而异，请查看Document，Key-value和Bigtable Clone数据库。 每个数据types都有很大的灵活性。
•其他业务部门运行快速关系查询，因此您不必重新实现所有内容，然后使用支持SQL的数据库。
•在云中运行并自动充分利用云特性，那么我们可能还没有到那里。
•支持二级索引，以便您可以通过不同的键查找数据，然后查看关系数据库和Cassandra的新辅助索引支持。
•创build一个不断增长的数据集 （真正的BigData）很less被访问，然后查看Bigtable Clone，它将数据分布在分布式文件系统上。
• 与其他服务集成，然后检查数据库是否提供某种types的后写同步function，以便捕获数据库更改并将其提供给其他系统以确保一致性。
• 容错检查面对电源故障，分区和其他故障情况下的持久写入方式。
•把技术方向推向一个似乎没有人打算的方向，然后自己去build造，因为有时候这很有必要。
•在移动平台上工作，然后查看CouchDB / Mobile couchbase。
一般用例（NoSQL）
• 大 。 NoSQL被看作是支持大数据，大量用户，大量计算机，大供应链，大科学等新数据栈的重要组成部分。 当一些事情变得如此庞大，以至于大规模分发时，NoSQL就在那里，尽pipe并不是所有的NoSQL系统都是针对大型的。 Bigness可以跨越很多不同的维度，而不仅仅是使用大量的磁盘空间。
• 大量的写入性能。 这可能是基于Google影响力的规范使用。 高音量。 Facebook需要每月存储1350亿条消息。 例如，Twitter就存在每天存储7TB /数据的问题，这种需求的前景每年会翻倍。 这是数据太大，不适合一个节点的问题。 在80 MB / s下，需要一天的时间来存储7TB，因此写入需要分布在集群上，这意味着键值访问，MapReduce，复制，容错，一致性问题等等。 为了更快的写入内存系统可以使用。
• 快速键值访问。 这可能是NoSQL在整体思维方面第二大的优点。 当延迟很重要时，很难击败关键字上的哈希，直接从内存中读取值，或者在一次磁盘寻道中读取值。 并不是每一个NoSQL产品都是关于快速访问的，例如一些关于可靠性的更多。 但是人们长期以来想要的是更好的memcached，许多NoSQL系统都提供这个function。
• 灵活的模式和灵活的数据types。 NoSQL产品支持一系列全新的数据types，这是NoSQL的主要创新领域。 我们有：面向列，graphics，高级数据结构，面向文档和键值。 复杂的对象可以很容易地存储，没有大量的映射。 开发人员喜欢避免复杂的架构和ORM框架。 缺乏结构允许更多的灵活性。 我们也有程序和程序员兼容的数据types喜欢JSON。
• 架构迁移。 无模式使处理模式迁移变得更容易，而不必担心。 模式在某种意义上是dynamic的，因为它们是由应用程序在运行时施加的，所以应用程序的不同部分可以具有不同的模式视图。
• 写入可用性。 你的写作需要成功吗？ 然后，我们可以进入分区，CAP，最终一致性和所有爵士乐。
• 易于维护，pipe理和运营。 这是非常特定的产品，但是许多NoSQL厂商正试图通过使开发人员容易采用它们来获得采用。 他们在易用性，最小pipe理和自动化操作上花费了大量的精力。 这可能会导致较低的运营成本，因为不必编写特殊代码来扩展从未打算以这种方式使用的系统。
• 没有单点故障。 并不是每个产品都能够实现这一目标，但是我们看到，通过自动负载平衡和集群规模调整，可以相对容易地configuration和pipe理高可用性。 一个完美的云伙伴。
• 通常可用的并行计算。 我们将MapReduce看成产品，这使得并行计算成为未来发展的一个常态。
• 程序员易于使用。 访问你的数据应该很容易。 虽然关系模型对最终用户（比如会计师）来说很直观，但对于开发人员来说，这并不是很直观。 程序员grok键，值，JSON，Javascript存储过程，HTTP等。 NoSQL适用于程序员。 这是一个开发者领导的政变。 对数据库问题的反应并不总是聘用一个真正知识渊博的DBA，正确地使用你的模式，使其稍微规范化一些，程序员更喜欢一个可以为自己工作的系统。 制作产品应该不那么难。 钱是问题的一部分。 如果产品规模成本很高，那么您是不是会select更便宜的产品，是否可以控制，使用起来更方便，而且更容易扩展？
• 使用正确的数据模型解决正确的问题。 不同的数据模型被用来解决不同的问题。 例如，将graphics操作embedded到关系模型中已经付出了很多努力，但是它不起作用。 在graphics数据库中解决graphics问题不是更好吗？ 现在我们正在看到一个总体策略，就是在问题和解决scheme之间find最合适的方法。
• 避免撞墙。 许多项目在他们的项目中遇到了某种types的墙壁。 他们已经用尽了所有的select，使他们的系统规模或正常运行，并想知道接下来是什么？ select一种产品和一种可以通过使用增量增加的资源进行线性缩放来跳过墙的方法是令人欣慰的。 有一次这是不可能的。 它定制了所有的东西，但是这已经改变了。 现在我们正在看到一个项目可以随时采用的即用型产品。
• 分布式系统支持。 不是每个人都担心超过非NoSQL系统可以达到的规模或性能。 他们需要的是一个分布式系统，可以跨越数据中心，同时处理故障情况，而不会出现呃逆。 NoSQL系统由于专注于规模，倾向于利用分区，往往不使用严格的严格一致性协议，因此能够在分布式场景下运行。
• 可调整的CAP权衡。 NoSQL系统通常是唯一具有“滑块”的产品，用于select他们想要loginCAP频谱的位置。 关系数据库select强一致性，这意味着它们不能容忍分区失败。 最后这是一个商业决定，应该根据具体情况来决定。 你的应用程序是否关心一致性？ 几滴可以吗？ 你的应用程序需要强或弱的一致性？ 可用性更重要还是一致性？ 下来会比错误更昂贵吗？ 有产品给你一个select是很好的。
• 更具体的用例
•pipe理大量非事务性数据：Apache日志，应用程序日志，MySQL日志，点击stream等
•同步在线和离线数据。 这是一个CouchDB有针对性的利基。
•所有负载下的响应时间都很快。
•对于复杂联接的查询加载对于RDBMS来说太大时，避免大量联接。
•低延迟至关重要的软实时系统。 游戏就是一个例子。
•需要支持各种不同的写入，读取，查询和一致性模式的应用程序。 有50％的读取系统为50％写入，95％写入或95％读取进行了优化。 只读应用程序需要极高的速度和弹性，简单的查询，并可以容忍稍陈旧的数据。 应用程序需要适度的性能，读/写访问，简单的查询，完全权威的数据。 只读应用程序哪个复杂的查询要求。
•负载平衡，以适应数据和使用浓度，并帮助微处理器保持繁忙。
•实时插入，更新和查询。
•分层数据，如线程讨论和零件爆炸。
•dynamic创build表格。
•通过快速NoSQL接口提供低延迟数据的两层应用程序，但数据本身可以通过高延迟Hadoop应用程序或其他低优先级应用程序进行计算和更新。
• 顺序数据读取。 需要select正确的基础数据存储模型。 B树可能不是顺序读取的最佳模型。
•将可能需要更高性能/可扩展性的部分服务切片到自己的系统上。 例如，用户login可能需要高性能，并且此function可以使用专用服务来实现这些目标。
• caching。 用于网站和其他应用程序的高性能caching层。 示例是大型强子对撞机所使用的数据聚合系统的caching。 表决。
•实时页面查看计数器。
•用户注册，configuration文件和会话数据。
• 文档，目录pipe理和内容pipe理系统。 这些都是通过存储复杂文档的能力有了一个整体，而不是像关系表那样组织的。 类似的逻辑适用于库存，购物车和其他结构化数据types。
• 存档。 存储大量连续数据，仍然可以在线访问。 面向文档的数据库具有灵活的架构，可以处理架构随着时间的变化。
• 分析。 使用MapReduce，Hive或Pig来执行支持高写入负载的分析查询和扩展系统。
•处理不同types的数据，例如，通用级别的不同媒体types。
• embedded式系统。 他们不希望SQL和服务器的开销，所以他们使用更简单的存储。
•“市场”游戏，你在一个城镇拥有build筑物。 您希望某人的build筑物列表能够快速popup，因此您可以在build筑物表的所有者列上进行分区，以便select是单分区的。 但是当有人购买别人的build筑物时，你会随着价格更新所有者列。
•JPL正在使用SimpleDB来存储漫游者计划属性。 参考文献被保留在S3中的完整计划blob。
•联邦执法机构使用信用卡，会员卡和旅行预订实时跟踪美国人。
•通过实时比较交易与已知模式进行欺诈检测。
•通过整合每位患者的病史帮助诊断肿瘤types。 用于高度更新情况的内存数据库，如显示每个人“最后活跃”时间的网站（可能用于聊天）。 如果用户每30秒执行一次某个活动，那么与同时在线的约5000个用户相比，您将达到极限。 使用实例化视图处理较低频率的多分区查询，同时继续处理高频stream数据。
•优先队列。
•使用友好的程序界面对caching数据进行计算，而不必通过ORM。
•使用简单的键值列独一无二的大数据集。
•要快速查询，可以将值汇总到不同的时间片中。
•计算两个大集合的交集，其中一个联合会太慢。
•时间轴ala Twitter。
由于一般性，这个问题几乎不可能回答。 我想你正在寻找一些简单的答案问题=解决scheme。 问题在于每个“问题”随着业务的变化而变得越来越独特。
你称之为社交networking？ 推特？ Facebook的？ LinkedIn？ 堆栈溢出？ 他们都为不同的部分使用不同的解决scheme，并且可以使用多边形方法存在许多解决scheme。 Twitter有一个像概念图，但只有1度的关系，追随者和追随者。 另一方面，LinkedIn则展示了人们如何超越一级学位。 这是两种不同的处理和数据需求，但都是“社交networking”。
如果你有一个“社交networking”，但不做任何发现机制，那么你可以很容易地使用任何基本的键值存储。 如果您需要高性能，水平缩放，并且将具有二级索引或全文search，则可以使用Couchbase 。
如果您正在收集的日志数据之上进行机器学习，则可以将Hadoop与Hive或Pig或Spark / Shark集成。 或者你可以做一个lambda体系结构，并使用Storm的许多不同的系统。
如果您正在通过graphics进行发现（如超过2度顶点的查询），并对边缘属性进行过滤，则可能会考虑将graphics数据库放在主存储上。 然而，graphics数据库不是会话存储或者通用存储的好select，所以您需要一个多边形的解决scheme来提高效率。
数据速度是多less？ 规模？ 你想如何pipe理它。 您在公司或创业公司有什么专业知识。 有很多原因，这不是一个简单的问题和答案。
