smf*_*ote 135 couchdb mongodb nosql
使用NoSQL数据库有什么好处？我最近已经阅读了很多关于它们的内容,但是我仍然不确定为什么我要实现它,在什么情况下我想要使用它.
Ram*_*Vel 79
关系数据库强制执行ACID.因此,您将拥有基于模式的面向事务的数据存储.它已被证明适用于99%的实际应用.您几乎可以对关系数据库执行任何操作.
但是,当涉及到大规模高可用性数据存储时,速度和扩展方面存在限制.例如,谷歌和亚马逊在大数据中心存储了数TB的数据.由于RDBM的阻塞/架构/事务性质,在这些场景中查询和插入不具备性能.这就是他们实现自己的数据库(实际上是键值存储)以实现大规模性能增益和可扩展性的原因.
NoSQL数据库已经存在了很长时间 - 只是这个术语是新的.一些示例是图形,对象,列,XML和文档数据库.
对于你的第二个问题:可以在同一个网站上同时使用它们吗？
为什么不？两者都有不同的用途吗？
Asa*_*saf 72
NoSQL解决方案通常用于解决关系数据库不适合使用的问题,使用起来太昂贵(如Oracle)或要求您实现破坏数据库关系性质的东西.
优点通常特定于您的使用,但除非您在RDBMS中对数据建模存在某种问题,否则我认为没有理由选择NoSQL.
我自己使用MongoDB和Riak来解决RDBMS不可行的特定问题,对于我使用MySQL(或SQLite进行测试)的所有其他事情.
如果你需要一个NoSQL数据库,你通常知道它,可能的原因是:
如果您不需要NoSQL解决方案请记住,这些解决方案并不是RDBMS的替代品,而是前者失败的替代方案,更重要的是它们相对较新,因此它们仍然存在很多错误缺少功能.
哦,关于第二个问题,将任何技术与另一个技术结合使用是完全没问题的,所以只要他们不在同一台机器上就可以完成我的经验MongoDB和MySQL一起工作.
Hri*_*esh 15
NoSQL是数据库系统,其中数据被组织到文档(MongoDB),键值对(MemCache,Redis),图形结构形式(Neo4J)中.
也许这里有可能的问题和答案"何时去NoSQL":
需要灵活的架构或处理树状数据？
通常,在敏捷开发中,我们开始设计系统而不需要预先了解所有需求,后来在整个开发过程中,数据库系统可能需要适应频繁的设计更改,展示MVP(最小可行产品).或者您正在处理本质上是动态的数据模式.例如,系统日志,非常精确的示例是AWS cloudwatch日志.
数据集庞大/大？
是NoSQL数据库是数据库需要管理数百万甚至数十亿条记录而不影响性能的应用程序的最佳选择.
在扩展一致性之间权衡
与RDMS不同,NoSQL数据库可能会在这里和那里丢失小数据(注意:概率是.x%),但它在性能方面很容易扩展.示例:这可能适用于存储即时消息应用程序中的联机人员,数据库中的令牌,记录网站流量统计信息.
执行地理定位操作:MongoDB散列支持执行GeoQuerying和Geolocation操作.我真的很喜欢MongoDB的这个功能.
简而言之,MongoDB非常适合可以大规模存储动态结构化数据的应用程序.
处理大量读写操作
\n\n当您需要快速扩展时，请考虑 NoSQL 数据库。通常什么时候需要快速扩展？
\n\n当您的网站上有大量读写操作并且处理大量数据时，NoSQL 数据库最适合这些场景。由于它们能够动态添加节点，因此可以以最小的延迟处理更多并发流量和大量数据。
\n\n数据建模的灵活性
\n\n第二个提示是在开发的初始阶段，当您不确定数据模型、数据库设计时，预计事情会快速变化。NoSQL 数据库为我们提供了更大的灵活性。
\n\n最终一致性优于强一致性
\n\n当我们可以放弃强一致性并且不需要事务时，最好选择NoSQL数据库。
\n\n一个很好的例子就是像 Twitter 这样的社交网站。当名人的一条推文爆红，世界各地的每个人都点赞并转发它时。点赞数在短时间内上升或下降有什么关系吗？
\n\n如果系统显示的点赞数不是实际的500万500，而是短暂的500万250，明星肯定不会在意。
\n\n当大型应用程序部署在遍布全球的数百台服务器上时，地理上分布的节点需要一段时间才能达成全球共识。
\n\n在他们达成共识之前，实体的价值是不一致的。经过一段时间后，实体的值最终会变得一致。这就是最终一致性。
\n\n尽管不一致并不意味着存在任何形式的数据丢失。它只是意味着数据需要很短的时间通过海底的互联网电缆传遍全球，以达成全球共识并变得一致。
\n\n我们一直在经历这种行为。尤其是在 YouTube 上。通常您会看到一个视频有 10 次观看和 15 次点赞。这怎么可能？
\n\n它\xe2\x80\x99 不是。实际的浏览量已经比喜欢的多了。它\xe2\x80\x99s 只是浏览次数不一致，需要一段时间才能更新。
\n\n运行数据分析
\n\nNoSQL 数据库也最适合数据分析用例，在这些用例中我们必须处理大量数据的涌入。
\n小智 8
缺少一些基本信息来回答这个问题：数据库必须能够覆盖哪些用例？是否必须从现有数据 ( OLAP )执行复杂分析，或者应用程序是否必须能够处理许多事务 ( OLTP )？什么是数据结构？这离提问时间的结束还很远。
在我看来，根据大胆的流行语做出技术决策而不确切知道它们背后是什么是错误的。NoSQL 经常因其可扩展性而受到称赞。但是您还必须知道水平扩展（在多个节点上）也有其价格并且不是免费的。然后，您必须处理诸如最终一致性之类的问题，并定义如果无法在数据库级别解决数据冲突，则如何解决这些冲突。但是，这适用于所有分布式数据库系统。
开发人员在 NoSQL 中用“schema less”这个词的喜悦在一开始也很大。这个流行语在经过技术分析后很快就被消解了，因为它在写作时不需要模式是正确的，但在阅读时会起作用。这就是为什么它应该正确地是“读取模式”。能够自行决定写入数据可能很诱人。但是，如果存在现有数据但应用程序的新版本需要不同的架构，我该如何处理？
文档模型（例如在 MongoDB 中）不适用于数据之间存在许多关系的数据模型。连接必须在应用程序级别完成，这是额外的工作，为什么我应该编写数据库应该做的事情。
如果你说谷歌和亚马逊开发了自己的数据库是因为传统的 RDBMS 无法处理海量的数据，你只能说：你不是谷歌和亚马逊。这些公司是先锋，传统数据库不再适用的场景中约有 0.01%，但对于世界其他地方它们却是。
重要的是：SQL已经存在 40 多年，数百万小时的开发已经投入到大型系统中，例如 Oracle 或 Microsoft SQL。这必须通过一些新的数据库来实现。有时，寻找 SQL 管理员也比寻找 MongoDB 的人更容易。这就把我们带到了维护和管理的问题上。一个并不完全性感的主题，但这是技术决策的一部分。