NoSQL 的用例 [关闭]
Posted
技术标签:
【中文标题】NoSQL 的用例 [关闭]【英文标题】:Use cases for NoSQL [closed] 【发布时间】:2011-02-21 22:58:31 【问题描述】:NoSQL 最近在我们的行业中得到了很多关注。我真的很感兴趣人们对使用关系数据库存储的最佳用例的想法。什么应该触发开发人员认为特定数据集更适合 NoSQL 解决方案。我对 MongoDB 和 CouchDB 特别感兴趣,因为它们似乎在 php 开发方面获得了最多的报道,这是我的重点。
【问题讨论】:
Cassandra 和 MongoDB 是完全不同的产品——完全不同的类别。如果该问题询问的是特定类型的数据库(OODB、DODB、DKVS 等)的用例,这个问题会更容易回答。“NoSQL”只是“任何't SQL" - 它也可以是 BerkleyDB 或网络共享上的一堆平面文件。 @Aaronaught 我很欣赏这些差异,我想我可能对使用 nosql 的总括术语感到内疚 【参考方案1】:我使用 NoSQL DB 已经有一段时间了,这是我对该主题的贡献:
NoSQL 数据库的伟大用例是用于统计和/或报告生成的应用程序, 尤其是从第三方来源提供数据时。
在这种情况下,NoSQL 数据库可能是不错的选择
我们以 MongoDB 为例:
一旦你有 JSON 格式的数据,(它可能来自第三方 API,或从 sql 应用程序导出)MongoDB 非常可以直接导入
并更新数据库中的JSON 数据;例如使用命令行mongoimport
实用程序
此时非常使用过滤和分组构建动态查询非常简单,非常适合这种应用程序。
例如,使用Aggregation Framework:
$pipeline = [];
//filter by date
$pipeline[] = [ '$match' => [ 'created_at' => [ '$gte' => $starDate, '$lte' => $endDate ] ] ];
//if we want to filter by a specific field, we add the filter to the pipeline array
if( $filters->isFilterByField() )
$pipeline[] = [ '$match' => [ 'field' => $fieldValue ] ];
//group the results by date and get the count
$pipeline[] = [ '$group' => [ '_id' => '$created_at', 'num_elements' => [ '$sum' => 1 ] ] ];
return $collection->aggretate( $pipeline );
我想指出 简单,我们可以使用 php 数据结构动态添加/删除过滤器,避免繁琐 字符串连接来构建我们的查询。使用这种方法,动态添加/删除过滤器就像添加/删除一样简单 数组中的元素
另一个巨大的好处是这样的解决方案可能比使用关系数据库更快, 我们必须与不同的表进行连接以获取我们需要的所有数据
此外,此用例是最佳的,因为 避免了 NoSQL 数据库的所有主要限制:
缺少事务:应用程序不执行写入,只执行读取,因此我们根本不需要事务
表之间缺少连接:我们不需要连接,因为我们可以使用冗余来存储我们的非规范化数据在收藏中。 由于我们只读取数据,因此我们无需担心在更新之间同步非规范化数据。
通过这种方式,我们可以专注于以冗余方式存储数据,以非常适合我们查询的方式,这将专注于单个集合。
我之所以写这个,是因为如果我以前读过类似的东西,它本来可以节省我一些时间进行研究
希望对某人有用
【讨论】:
【参考方案2】:首先,您必须了解 CAP(一致性、可用性和分区,您必须选择其中的三个)理论和我们的业务用例。 MongoDB 满足一致性和分区,Couch DB 满足可用性和分区。
youtube 上有关 NoSQL 的 Edureka 视频是一些最好的视频教程。
https://www.youtube.com/watch?v=gJFG04Sy6NY
https://www.youtube.com/watch?v=KSq6tMMXZ8s
https://www.youtube.com/watch?v=3z1KFA2qcSo
slideshare.net 中提供了很好的演示文稿
http://www.slideshare.net/quipo/nosql-databases-why-what-and-when?qid=3bb9f7f6-a53d-41b1-8403-cd6f181d0ca7&v=qf1&b=&from_search=1
http://www.slideshare.net/EdurekaIN/no-sql-databases-35591065?qid=f1b9c095-6d70-4d0a-91da-1df664c4f389&v=qf1&b=&from_search=3(此演示支持youtube视频教程)
【讨论】:
【参考方案3】:我强烈推荐 Martin Fowler 的这次演讲:
https://www.youtube.com/watch?v=qI_g07C_Q5I
摘要: Martin 快速介绍了 NoSQL 数据库:它们来自哪里,它们使用的数据模型的性质,以及您必须考虑一致性的不同方式。从这里他概述了你应该考虑在哪些情况下使用它们,为什么它们不会使关系数据库过时,以及多语言持久性的重要后果。
它很好地描绘了 NoSQL 是什么、不同的类别以及每个人在来自关系数据库世界时必须了解的内容。 问候。
【讨论】:
了解,以后会记住的。【参考方案4】:因为现在市场上的 NoSQL 数据库比以往任何时候都多,如果您正在寻找一种基于支持、可扩展性、可扩展性也非常适合企业应用程序的数据库,我建议您查看 Gartner 魔力象限。管理,成本。
http://www.gartner.com/technology/reprints.do?id=1-23A415Q&ct=141020&st=sb
我想向尚未尝试过但不是基于报告中显示的版本 (2.5.1) 的任何人推荐 Couchbase,因为它比 CB Server 今天的版本落后了近 2 个修订版,即将发布2H15 4.0。
http://www.couchbase.com/coming-in-couchbase-server-4-0
关于 Couchbase 作为供应商/产品的另一部分是它是一种多用途类型的数据库。它可以充当纯 K/V 存储、具有多维扩展的面向文档的数据库、Memcached、具有持久性的缓存,并支持具有自动连接功能的符合 ANSI 92 的 SQL,只需按一下按钮即可复制到 DR 集群,以及甚至在生态系统中内置了一个移动组件。
如果没有别的,值得查看最新的基准:
http://info.couchbase.com/Benchmark_MongoDB_VS_CouchbaseServer_HPW_BM.html http://info.couchbase.com/NoSQL-Technical-Comparison-Report.html
【讨论】:
【参考方案5】:MongoDB 网站上提到了一些很棒的用例 - 无论如何都是针对 MongoDB 的。给出的示例是实时分析、日志记录和全文搜索。这些文章都值得一读http://www.mongodb.com/use-cases
还有一篇关于 NoSQL 数据库最适合哪种类型的项目的精彩文章:http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
【讨论】:
【参考方案6】:对于您需要的某些用例,特别是对于分析查询,您可以使用 Postgres 的 this wrapper 在 MongoDB 上运行 SQL 查询。
【讨论】:
【参考方案7】:只要向自己保证,您永远不会尝试将关系数据模型映射到像 MongoDB 或 CouchDB 这样的 NoSQL 数据库...这是开发人员在评估新兴技术时最常犯的错误。
这种方法类似于开车并试图用它像马一样把你的车拉到路上。
由于每个人的经验,这当然是一种自然反应,但使用文档数据库的真正价值在于能够简化您的数据模型并最大程度地减少您作为开发人员的痛苦。你的代码库会缩小,你的 bug 会更少,更容易找到,性能会很棒,扩展会更简单。
作为 Joomla 的创始人,我有偏见 :-) 但来自 CMS 领域,像 MongoDB 这样的东西是灵丹妙药,因为内容非常自然地映射到文档系统。
MongoDB 的另一个很好的案例是实时分析,因为 MongoDB 具有非常强大的性能和规模,尤其是在并发方面。 MongoDB.org 网站上的案例研究证明了这些属性。
我同意每个数据库都有自己的目标和用例的观点;对每个数据库的用途进行相应的评估。
【讨论】:
spacemonkey 说得真好,我和 seegee 处于同一个位置,显然我们要以一种新的方式思考,应该问自己如何将我的应用程序数据构造成一个文档结构,将自己从我们进行此分析时的 RDBMS 思维方式【参考方案8】:我建议 Rick Cattell 撰写这篇关于杂项数据存储(又名 NoSQL)、它们的区别和一些用例的文章:http://www.cattell.net/datastores/index.html
【讨论】:
【参考方案9】:我喜欢 NoSQL 的地方与性能无关,而是与可用性有关。当您的原子数据单元类似于文档时,文档存储更容易使用,因为序列化对象和从对象序列化是微不足道的。它只是更有趣,这对于个人或业余项目来说是一个重要因素。
【讨论】:
我不会说它是琐碎的,但这对于面向文档的数据库来说是一个很好的观点。对于其他一些 NoSQL 产品,情况恰恰相反——DKVS 往往比 SQL/关系数据库更难映射。以上是关于NoSQL 的用例 [关闭]的主要内容,如果未能解决你的问题,请参考以下文章
在 TypeORM 中使用 QueryBuilder 与 Repository 都有哪些不同的用例? [关闭]