意见:使用NoSQL的理由

Question

我从我的朋友那里得到了关于NoSQL的两个观点。

优先：使用NoSQL来提高性能和保存偶尔更新的数据。仍然使用sql保存所有重要的dan事务数据。

第二:如果您不需要，就不要使用NoSQL。如果您确实保存了大数据，请使用它。

我使用过NoSQL，在选择数据时非常快。

我想知道，第一种意见是否足以实现NoSQL？你们都怎么想这些的？

注意:在我的例子中，仍然运行良好。我想添加NoSQL来提高数据读取速度。所以它将与之并驾齐驱。

这么早使用NoSQL值得吗？

提前感谢

Answer 1

这取决于你在设计什么。

根据我的经验，扩展数据收集，我发现传统的关系存储是一个瓶颈，因为当一个数据库变得非常大时，它无法扩展到多个节点。当然，它的规模扩大了，但这在某种程度上变得成本过高。因此，在这种情况下，它将取决于您的中长期数据存储预测。因此，对我来说，解决方案是将可能经常更新的数据的关系存储和数据的noSQL (文档存储)混合起来，后者的增长速度非常快，通常不是更新后写的。

需要考虑的事项：

查询

SQL关系存储支持越来越多的用于查询的子集语言，以及广泛的筛选器、排序选项以及预测和索引查询。NoSQL也做了所有这一切，但是SQL常常会超越它，允许对您的数据进行强大的聚合，而不仅仅是NoSQL所能做到的。

交易记录

事务很重要，因为它们确保您对数据库进行了原子化的更改。许多NoSQL平台不支持事务，所以当您确定要使用哪一个以及您自己的需求时，请注意这个特性。

一致性

MySQL平台通常使用单个主机来保证数据库中的强一致性。这些方法使用同步复制，以确保不会丢失排队到主服务器的重要更改。相反，NoSQL在没有主服务器的情况下对实体组进行复制，从而使数据在实体组中很强，并最终在所有组中更新。更好的选择取决于数据库的约束和需求。

可扩展性

多年来，数据库管理员依赖于扩展，随着数据库负载的增加而购买更大的服务器。然而，随着交易速率和对数据库的需求继续扩大，重点是扩大规模。扩展是跨多个主机分发数据库，这是NoSQL比标准SQL做得更好的事情。它们是为扩展数据库的最佳使用而设计的。

管理

NoSQL数据库通常被设计成需要更少的整体管理。维修通常是自动的，数据分发和更简单的数据模型有助于减少对总体管理的需求。然而，当出现问题时，您也得到了较少的支持。SQL平台经常有供应商等待向企业提供支持。

模式

常规SQL平台通常严格执行模式更改规则，以避免用户创建的可以在查询中出现错误的排版。NoSQL平台将有自己的机制来应对这一问题。

希望这能有所帮助。

Answer 2

NoSQL在以下领域的得分高于SQL

• 它支持半结构化数据和易失性数据。您可以随时更改结构。
• 它没有模式。
• 读/写通过率很高。
• 水平可伸缩性很容易实现--增加更便宜的硬件，并提供正确的复制因子。
• 将通过使用更便宜的硬件支持海量Terra Bytes和Peta Bytes
• 对Bigdata之上的分析工具的良好支持，特别是Hadoop/Hbase家族
• 在内存中，可以使用缓存选项来提高查询的性能。
• 加快开发人员的开发生命周期

当您不应该使用NoSQL并使用SQL时

• 如果您需要具有ACID属性的业务关键事务，即一致性是关键&最终一致性不是一个选项
• 如果您有跨多个实体的大量聚合查询

总之，您必须为正确的业务用例使用正确的技术。即SQL与NoSQL的结合

关于您的问题：

1. 对业务关键事务使用SQL。如果您的SQL正在为您的业务需求进行扩展，请使用SQL。
2. 对于以Tera/Peta字节为单位的海量数据和各种数据，使用NoSQL，其中SQL无法处理该卷和各种数据。

Answer 3

正如其他人指出的那样，SQL和NoSQL (不仅仅是SQL)都有各自的优势。

经常会有诱惑，使两者并排使用，并从中得到最大限度的利用。被称为多标记持久性的东西

是个好主意吗？有时候，是的。

我应该这么做吗？

虽然它可能有好处，但需要通过维护多个存储进行权衡(注意:它们有不同的数据库管理方式)。

此外，如果您计划对同一事务系统进行数据同步，则数据同步将是一个更大的同步。如果您要存储的数据(在sql和no-sql数据库中)可以逻辑地分开，那么您可能会没事。但如果他们是密切相关的，那么你将有困难的时间来保持他们的一致性。

总的来说，当我评估这个选项时，我得出的结论是，只有当您能够对数据进行逻辑分区时，它才能工作。另一个用例可能是使用Nosql进行分析，并继续使用用于事务系统的sql。

回到用例，您是否尝试过在sql数据库中存储JSON。它可能会给你的性能带来好处，而不会有太多的权衡。