非关系型数据库（如键值对存储）的好处在于处理大规模数据集时显而易见（例如Google、Facebook和LinkedIn）。您认为中小型应用程序使用非关系型数据库有哪些好处？
非关系型数据库（NoSQL）适用于中小型应用程序
9
- Victor
5
1我承认我没有真正的经验，但我想看到一些链接来支持这个说法，或者至少解释一下其他的选择是什么。我也同意它应该成为社区维基。 - Platinum Azure
请问您能否将“非关系型”定义为不仅仅是“不是关系型”的东西？否则，任何用于存储数据的临时方案都可以符合条件。 - Ira Baxter
你是对的，Ira。我会修改问题。 - Victor
...并转换为社区维基，感谢jldupont和Platinum Azure。 - Victor
请记住，“非关系型”不仅仅意味着新的NoSQL风格数据存储方式。还有其他已经存在很长时间的风格，比如网络，分层和对象数据库。 - JAL
7个回答
6
IBM主机自60年代以来就拥有“非关系型”数据库（如IMS +变体）了。这些数据库仍在使用，因为它们非常快速，处理大规模数据很好。
关系型数据库的目的是提供一种规则化、相对抽象的存储和检索数据的方法，其中调整可以相对独立于数据模型进行（对IMS不适用）。它们是作为对无法轻松重组分层数据库的反应而设计的。优点是良好的组织性；缺点是中等而不是高性能。
谷歌提供可伸缩的存储和MapReduce以处理大规模数据。 它不是关系型的。
上世纪初期曾有一个巨大的推动，将数据以XML的形式存储，本质上是分层的，因为XML是隐式分层的。我认为那是个巨大的错误，因为它重复了分层数据库的不便，但没有性能表现。我不太惊讶这场运动似乎已经几乎消失了。
在我看来，非关系型数据库的大部分实际推动是出于性能和规模考虑。我不明白它如何帮助“小”应用程序。
关系型数据库的目的是提供一种规则化、相对抽象的存储和检索数据的方法，其中调整可以相对独立于数据模型进行（对IMS不适用）。它们是作为对无法轻松重组分层数据库的反应而设计的。优点是良好的组织性；缺点是中等而不是高性能。
谷歌提供可伸缩的存储和MapReduce以处理大规模数据。 它不是关系型的。
上世纪初期曾有一个巨大的推动，将数据以XML的形式存储，本质上是分层的，因为XML是隐式分层的。我认为那是个巨大的错误，因为它重复了分层数据库的不便，但没有性能表现。我不太惊讶这场运动似乎已经几乎消失了。
在我看来，非关系型数据库的大部分实际推动是出于性能和规模考虑。我不明白它如何帮助“小”应用程序。
人们提出了基于知识的方案来进行实际数据管理，但并没有做出很多实践。道格·勒纳特的CYC就是一个例子。数据库帮助应用程序得出非显而易见的结论的能力对于试图变得“聪明”的“小”应用程序来说非常有趣。但这样的应用程序还不是很多。
- Ira Baxter
2
在这个规模下使用NoSQL数据库的优点在于，当数据库模型（键值、文档等）与应用程序的需求相匹配且不需要高级关系功能时，性能最佳。在小规模的情况下，性能不是问题，因为几乎所有东西都很快。如果您不需要复杂的查询引擎，则存储引擎不是问题，缺乏SQL支持也不是问题。您需要考虑它的适配性和易用性。然而，工具成为一个问题。关系型数据库工具已经成熟，NoSQL工具的功能较少，没有经过充分的测试。经常需要自己制定工具。一定要考虑您将放弃哪些工具以及您需要多少工具。
对于较小的项目，在考虑NoSQL服务（如Amazon SimpleDB和Microsoft Azure）与产品时，还有其他一些优点。如果您只需要支付所使用的费用，并且您的使用量不大，那么它可能比运行专用服务器更便宜，甚至可以免费使用SimpleDB免费使用层。
您还可以避免一些服务器和数据库维护成本。如果您没有DBA，或者您的DBA已经超负荷工作，这可能是一个巨大的胜利。当然，您仍然需要进行管理工作，但是这大大减少了工作量，通常更简单。
对于较小的项目，在考虑NoSQL服务（如Amazon SimpleDB和Microsoft Azure）与产品时，还有其他一些优点。如果您只需要支付所使用的费用，并且您的使用量不大，那么它可能比运行专用服务器更便宜，甚至可以免费使用SimpleDB免费使用层。
您还可以避免一些服务器和数据库维护成本。如果您没有DBA，或者您的DBA已经超负荷工作，这可能是一个巨大的胜利。当然，您仍然需要进行管理工作，但是这大大减少了工作量，通常更简单。
- Mocky
1
说到图形数据库（例如我参与的项目Neo4j），它们在扩展到复杂性方面表现出色。这意味着它们提供了"更好的基础来建模业务领域"（请参见NoSQL的状态，同样由Ben Scofield编写）。在我看来，这在小型到中型应用程序中非常重要。
这可能通过示例更好地解释，因此这里有一些示例应用程序/领域建模的链接：
- nawroth
0
问题可能需要更多的上下文...... 假设是Python环境，请参考y_serial项目的教程：http://yserial.sourceforge.net/
NoSQL不仅仅是出于可扩展性的原因而采用。序列化（任何任意Python对象）和持久性在任何规模下都非常方便 - 因此将键值系统视为一种方法。
- code43
0
关系数据库管理系统 (RDBMS) 的问题之一是需要将编程语言的领域模型映射到 RDBMS 的关系模式中，这需要在 ORM 层上进行配置。
NoSQL 数据库不需要强制将对象映射到关系模型中，在大多数情况下，对象会按原样序列化。由于缺乏中介模式，数据迁移和版本控制变得更加容易。
另一个好处是可扩展性和性能。由于大部分时间数据都是通过“键”接收的，所以几乎所有东西都使用索引。通过对密钥在有效 NoSQL 实例数量上执行 %（MOD）运算，可以轻松地进行微不足道的分片，提供自然数据分区，这对于分片至关重要。
如果您有兴趣了解如何使用 NoSQL 开发与 RDBMS 不同的应用程序，我有一个教程，在其中演示如何 使用 Redis 设计简单的博客应用程序。
- mythz
0
如果您将一些常见的PaaS云服务（如键值存储、BLOB存储和消息队列存储）匹配起来，您就会拥有一些方便的工具，可以使小型应用程序开发人员摆脱DBA和基础架构人员的暴政。
今天，小型开发人员经常使用Jet MDBs。为什么？很简单，共享访问只需要将MDB文件存储在对整个应用程序社区可见的文件共享上即可。当他们能够做到这一点时（即得到门卫的必要支持），他们可能会使用SQL Server Express、MySQL等。
可悲的是，在大型组织中，那些门卫可能非常敌对。提到“数据库”，你就会面对DBA团队和相关的延迟、应用程序审查、优先级等问题。提到需要服务器，你就会面对另一个行刑队。
如果您不需要关系型数据库，使用NoSQL解决方案和相关的云服务可以消除大量这些问题。
首先，真正需要的只是一个公共云提供商的帐户。一旦该概念获得批准，这变得相当容易。作为开发人员，一旦获得批准并分配了帐户，您就会更容易，尽管当然还有一些常规的簿记问题。
但是，让我们暂且不谈这个问题。如果您的组织为此类用途实施了私有云呢？很多外部计费问题都会消失，数据不安全的担忧也会消失等等。
这样的东西可以以半匿名的方式实施和配置，几乎就像管理文件共享一样容易。匿名性的原因在于，一旦您被批准在内部云上开发，就没有人需要在使用它之前仔细检查您的活动细节，就像在现有的文件共享上创建文件之前不需要审查请求一样。
显然，需要管理存储和 CPU 配额。没有人能负担得起无限制地扩展。流氓应用程序可能会消耗大量资源。所以您需要一些配额系统来限制使用。这是否由基础设施人员监控是一个实施决策，或者它可能像文件共享使用一样处理：用完了，有人会对程序员大喊大叫，然后程序员会调查并在适当时请求更多（或修复错误）。
但最终您将获得“公用事业计算”，通过“不使用 SQL”，您不会承担与数据库管理员打交道的成本（和问题）。他们仍然可以在他们的大办公室里安静地浏览网页，而您可以完成一些工作。
- Bob77
0
Amazon SimpleDB 可以为那些需要非关系型数据库来存储较小、非结构化数据的人提供帮助。Amazon SimpleDB 的每个域的存储大小受到限制，最多为10GB。Amazon SimpleDB 提供了简单性和灵活性。SimpleDB 自动索引所有数据。Amazon SimpleDB 的定价基于您实际的盒子使用情况。您可以在 Amazon SimpleDB 中存储任何 UTF-8 字符串数据。
- Ashish Pancholi
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接