关系数据库和nosql设计schema时的差别的例子 - jackyrong - ITeye技术网站
博客分类：
在关系数据库中和nosql的设计时,对于schema的设计是不同的.比如MYSQL中,设计如下一个例子:
mysql& select *
+----+------------+
| id | name
+----+------------+
1 | Stephane
3 | Michael
4 | Cinderella |
+----+------------+
mysql& select *
+----+-----------+---------+-------------+
| id | people_id | country | valid_until |
+----+-----------+---------+-------------+
+----+-----------+---------+-------------+
& 这个如果要转换为mongodb要如何设计呢,首先一个方法是全部放在一个collection中,如
& db.people_all.find().pretty()
"_id" : ObjectId("51f7be1cdd3bf"),
"name" : "Stephane",
"country" : "FR",
"valid_until" : ISODate("T23:00:00Z")
"_id" : ObjectId("51f7be3fdd3c0"),
"name" : "John",
"country" : "US",
"valid_until" : ISODate("T23:00:00Z")
"_id" : ObjectId("51f7be4ddd3c1"),
"name" : "Michael",
"country" : "RU",
"valid_until" : ISODate("T23:00:00Z")
{ "_id" : ObjectId("51f7be5cdd3c2"), "name" : "Cinderella" }
& 这样的话,如果要查询people的所有信息,放在同一个collection中是很快的,当然也可以分开两个collection进行嵌套,如:
& db.people_embed.find().pretty()
"_id" : ObjectId("51f7c0048ded44d5ebb83774"),
"name" : "Stephane",
"passport" : {
"country" : "FR",
"valid_until" : ISODate("T23:00:00Z")
"_id" : ObjectId("51f7c70e8ded44d5ebb83775"),
"name" : "John",
"passport" : {
"country" : "US",
"valid_until" : ISODate("T23:00:00Z")
"_id" : ObjectId("51f7c71b8ded44d5ebb83776"),
"name" : "Michael",
"passport" : {
"country" : "RU",
"valid_until" : ISODate("T23:00:00Z")
{ "_id" : ObjectId("51f7c7258ded44d5ebb83777"), "name" : "Cinderella" }
& 甚至可以这样:
& db.passports_embed.find().pretty()
"_id" : ObjectId("51f7c7e58ded44d5ebb8377b"),
"country" : "FR",
"valid_until" : ISODate("T23:00:00Z"),
"person" : {
"name" : "Stephane"
"_id" : ObjectId("51f7c7ec8ded44d5ebb8377c"),
"country" : "US",
"valid_until" : ISODate("T23:00:00Z"),
"person" : {
"name" : "John"
"_id" : ObjectId("51f7c7fa8ded44d5ebb8377d"),
"country" : "RU",
"valid_until" : ISODate("T23:00:00Z"),
"person" : {
"name" : "Michael"
"_id" : ObjectId("51f7c8058ded44d5ebb8377e"),
"person" : {
"name" : "Cinderella"
& 如果是大部分只查询people的本身信息的话,那么建议分开两个collection存放,避免每次把不需要加载的信息加载进去了.
&
浏览: 3474114 次
来自: 广州
感谢分享！
正则这一项解了燃眉之急，谢谢~
我的是Spring MVC 4.2.4，但是有问题：
写的不错，学习了
C# 如何调用jax-ws 接口时，怎么将验证数据放在 Web ...NoSql数据库使用半年后在设计上面的一些心得
查看: 15352|
评论: |原作者: AllenDang|来自:
摘要: NoSql数据库这个概念听闻许久了，也陆续看到很多公司和产品都在使用，优缺点似乎都被分析的清清楚楚。但我心里一直存有一个疑惑，它的出现究竟是为了解决什么问题？ ... ...
NoSql数据库这个概念听闻许久了，也陆续看到很多公司和产品都在使用，优缺点似乎都被分析的清清楚楚。但我心里一直存有一个疑惑，它的出现究竟是为了解决什么问题？这个疑惑非常大，为此我看了很多分析文章，但却总感觉是隔靴搔痒。为了一探究竟，半年前我决定用Mongodb这个著名的NoSql数据库做个产品试试。只有在真实的使用环境中才能得到最贴切的感受。一晃眼，半年过去了，现在我能用亲身的体会来谈谈NoSql数据库存在的理由和试图解决的问题了。就像所有的哲学思考都来源于对日常活动的观察一样，我们也从最基本的东西说起吧。来看这样一个业务要求，用户可以为一本书打分，并且写评论。熟悉数据库结构设计的人看到这一句话脑子里应该瞬间就会出现下面这样的表结构（我这里就不太讲究了，大家意会即可）：用户信息表，书籍信息表，用户为书籍打分信息表，评论表。现在假想要做一个显示评论内容的页面，上面会有用户信息和相关书籍的信息，想必大家脑子里已经出现各种select和join了吧。如果用NoSql还是同样的设计的话，那你会惊喜的发现NoSql数据库的性能简直差到爆。性子火爆的估计当场就要掀桌。什么破烂数据库，不是号称性能一流的吗！好吧，性能问题也就不说了，竟然连事务都不支持！？那我同时插入四张表的数据该怎么保持一致？开玩笑的吧！&NoSql数据库此时默默的泪流满面，冤枉啊……你别说，还真是冤枉它了。先从最基本的设计元素说起，几乎所有的NoSql数据库都没有表（table）的概念，取而代之的是文档（document）。文档是个什么东西？Mongodb的解释，文档是一个使用JSON格式以key-value方式存储数据的结构，比如：{ "item": "pencil", "qty": 500, "type": "no.2" }看起来和表没什么不同嘛？咳咳，JSON是支持嵌套结构的，比如可以把书籍信息和用户打分的信息存到一起：{&& "id": "123zxcrweq2",&& "title": "雪中悍刀行",&& "author": "烽火戏诸侯",&& "scores": [&&&& {&&&&&& "userid": "454zxcfwer1",&&&&&& "nickname": "Allen",&&&&&& "score": 3,&&&& },&&&& {&&&&&& "userid": "678zxkiou1",&&&&&& "nickname": "Judy",&&&&&& "score": 4,&&&& }&& ],&}一堆document存储到一起就叫做collection，而同一个collection里面的document可以不一样。注意，这里也是重点概念。如果切换到关系型数据库的话，相当于一张表里每一行数据的列都可以不一样。这不是乱套了吗？用不好确实会乱套的。概念说完了，来看看面对下面这种产品要求的时候应该怎么办。产品经理说了，要在书籍信息页面看到所有评论，评论人的信息和打的分也要出现。如果是关系数据库，获取数据的思路是这样的：1. 根据书籍Id取到书籍信息。2. 根据书籍Id取到所有评论信息。3. 根据评论信息中的用户Id取到相关用户的信息。4. 根据书籍Id和用户Id取到打分信息。那在NoSql数据库中如果我们用如下结构存储数据的话……{&& "id": "123zxcrweq2",&& "title": "雪中悍刀行",&& "author": "烽火戏诸侯",&& "comments": [&&&& {&&&&&& "author": {&&&&&&&& "id": "454zxcfwer1",&&&&&&&& "nickname": "Allen",&&&&&&&& "avatarurl": "头像1.png",&&&&&& },&&&&&& "score": 3,&&&&&& "title": "书评1",&&&&&& "content": "书评内容1",&&&& },&&&& {&&&&&& "author": {&&&&&&&& "id": "454zxcfwer1",&&&&&&&& "nickname": "Judy",&&&&&&&& "avatarurl": "头像2.png",&&&&&& },&&&&&& "score": 4,&&&&&& "title": "书评2",&&&&&& "content": "书评内容2"&&&& }&& ],&}似乎只要根据书籍Id查询一次就能得到结果了吧……明白为什么说NoSql数据库效率高了吗？一边是从四个集合中查找数据，一边是从一个集合中查找数据，这运行效率肉眼就能看出来差别了吧。所以到这里我得到了一条设计心得，尽可能把一次展示所需的必要数据都存储到一起。这是典型的空间换时间。所幸现在的科技条件下空间的价格非常低廉，所以很划算。根据这个设计结构，似乎也不需要事务的支持了，用户为一本书籍打分只需要在一个document里面添加数据就够了。好，document特性的用处明白了，现在就来研究下NoSql数据库另外一条原则的用途了，还记得是什么吗？同一个collection里面的document可以不一样。还是从实际应用中来看，某日，产品经理说，书籍详细信息页面上还要显示书评的创建时间。如果使用关系数据库该怎么办？1. 创建一个为Review表增加”creationtime“列的sql脚本。2. 到数据库中运行。3. 修改相关代码和存储过程。NoSql呢？1. 在Comment结构实体中增加CreationTime，增加赋值代码。没了，不需要去修改历史数据，因为？同一个collection里面的document可以不一样。那如果取到历史数据怎么办？Comment的CreationTime会被置为空。挺合理的，也不会产生什么危害。大家都知道，互联网产品的更新速度是非常快的，经常根据用户反馈和市场情况调整产品形态，而数据结构也会经常发生变化。为了适应这种环境，如何处理历史数据就成了老大难。还记得当年看到一个DBA在设计表的时候会留出几个字段叫做”Reserved1，Reserved2……“，感觉好无厘头，浪费空间，后来随着产品功能的增加才明白这其实是经验丰富的表现。如果用NoSql就不用这么纠结了。总结一下，就我浅薄的使用经验来看，NoSql的优点是：1. 在精心的设计下查询性能巨好。2. 数据结构弹性十足，特别适合快速发展中的产品。另外需要提醒一下，Mongodb不支持事务，所以务必在设计的时候考虑到这一点。核心业务数据尽可能通过结构设计做到数据插入的一致性。如果实在无法达成，请立即转回去用关系数据库，否则或早或晚你一定会后悔的。本文链接：
刚表态过的朋友 ()
上一篇：下一篇：
快毕业了，没工作经验，
找份工作好难啊？
赶紧去人才芯片公司磨练吧!!NoSQL系列：选择合适的数据库
为什么使用NoSQL数据库？
阻抗失衡 关系模型和内存中的数据结构不匹配
采用更为方便的数据交互方式提升开发效率
待处理的数据量很大
数据量超过关系型数据库的承载能力
大集群的出现
在成本方面，集群中应用关系数据库，许可费用是一笔很大的支出；
横向扩展和纵向扩展：关系数据库一般只能是纵向扩展，通过对单机服务器的性能换代增强而实现；而对于扩展到多个服务器，
DBMS先天不足；（DBMS不是设计给集群使用的）
对数据的访问效率要求高
NoSQL数据库的分类
键值数据库
BerkerleyDB
Project Voldemort
存放会话信息
用户配置信息
购物车数据
不适合的场景
数据间有大量关系
含有多项操作的事务
根据键值的部分来查询数据
操作关键字集合
文档数据库
Terrastore
内容管理系统及博客平台
网站分析及实时分析
电子商务应用程序
（需要较灵活的模式，低成本建立数据模型）
不适合场景
包含多项操作的复杂查询
查询持续变化的聚合结构
列族数据库
Amazon SimpleDB
Hypertable
BigTable（google）
（保存应用程序状态，运行中遇到的错误）
CMS及博客平台
不适用场景
需要ACID事务
查询模式变化频繁的场合
HyperGraphDB
Infinite Graph
基于位置的服务
不适用场景
更新全部或某个子集的实体
附思维导图
Posted by: 大CC | 07JUL,2014
阅读(...) 评论()10个出色的NoSQL数据库
发表于 14:32|
来源InfoWorld|
作者Peter Wayner
摘要：随着大数据的不断发展，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。现今的计算机体系结构在数据存储方面要有庞大的水平扩展性，而NoSQL也正是致力于改变这一现状。目前Google的 BigTable和Amazon 的Dynamo使用的就是NoSQL型数据库，本文介绍了10种出色的NoSQL数据库。
虽然NoSQL流行语火起来才短短一年的时间，但是不可否认，现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验，然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实：技术越来越成熟&&以至于原来很好的NoSQL数据存储不得不进行重写，也有少数人认为这就是所谓的2.0版本。这里列出一些比较知名的工具，可以为大数据建立快速、可扩展的存储库。
1. Casssandra
最初由Facebook开发，后来成了Apache开源项目，它是一个网络社交云计算方面理想的数据库。它集成了其他的流行工具如Solr，现在已经成为一个完全成熟的大型数据存储工具。Cassandra是一个混合型的非关系的数据库，类似于Google的BigTable。其主要功能比Dynomite（分布式的Key-Value存储系统）更丰富，但支持度却不如文档存储MongoDB。Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，而对Cassandra的读操作，也会被路由到某个节点上面去读取。在最近的一次测试中，。
2. Lucene/Solr
是Apache软件基金会4 jakarta项目组的一个子项目，这是一个开放源代码的全文检索引擎工具包，就是说它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构。不过大多数人并不认同Lucene是一个数据库，因为大多数人只是用它来检索大量的文本块，不过它的确采用了与其他NoSQL数据存储相似的模型。如果说查询并不是仅仅局限于精确的匹配，而是寻找出那些出现在块中的字或者字段的话，毫无疑问，Lucene/Solr是最好的查询方式。
是由技术公司basho开发的一个类似Dynamo的分布式Key-Value系统。其以分布式，水平扩展性，高容错性等特点著称。从事Riak工作最有趣的部分是可以使用JavaScript或者Erlang来做Map/Reduce查询，它们会查询每个节点，收集结果，而且可以重复，如果需要使用的结果进行重新进行搜寻的话。该系统还为类似于Solr的搜索提供全文索引，同时还提供一个控制面板，可以查看集群的信息。
4. CouchDB
是用Erlang开发的面向文档的数据库系统，不过它不是一个传统的关系数据库，而是面向文档的数据库，其数据存储方式有点类似lucene的index文件格式，CouchDB最大的意义在于它是一个面向web应用的新一代存储系统。作为一个分布式的数据库，CouchDB可以把存储系统分布到n台物理的节点上面，并且很好的协调和同步节点之间的数据读写一致性。CouchDB支持REST API，可以让用户使用JavaScript来操作CouchDB数据库，也可以用JavaScript编写查询语句，可以想像一下，用AJAX技术结合CouchDB开发出来的CMS系统会是多么的简单和方便。
CouchDB还有一个更加商业化的&表亲&&&Couchbase，不过它提供缓存功能，更好的分片，增量查询，更好的索引和一些其他的功能。其实Couchbase与CouchDB也是紧密相关的，Couchbase产品包含了CouchDB的一个副本。
大多数的NoSQL数据库只是存储键和值的一个灵活的捆绑。不过的存储的是对象之间的关系，或者说这种结构就是数学中的&图&。Neo4J是一个面向网络（&图&）的数据库，也就是说，它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎，但是它将结构化数据存储在网络上而不是表中，当然也可以把Neo4J看作是一个高性能的图引擎，该引擎具有成熟和健壮的数据库的所有特性。该工具包括很多有关搜索和分析的关系的算法，它能够帮助寻找谁是我的朋友，或者寻找朋友的朋友。这些&图的遍历&算法，可以节省很多指针查询的麻烦。
6. Oracle的NoSQL
也许是NoSQL运动太红火的原因，Oracle决定开发一款产品，将键/值对拆分在整个节点集上，这样的优势在于提供了一个灵活的事务保护措施，进而可以确保从数据在节点上等待存储开始到通过网络被成功备份结束，都尽在掌握之中。
Oracle的，是在10月4号的甲骨文全球大全上发布的Big Data Appliance的其中一个组件，Big Data Appliance是一个集成了Hadoop、NoSQL Database、Oracle数据库Hadoop适配器、Oracle数据库Hadoop装载器及R语言的系统。
7. MongoDB
是一个基于分布式文件存储的数据库，介于关系数据库和非关系数据库之间，是非关系数据库当中功能最丰富，最像关系数据库的。MongoDB最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。MongoDB支持RUBY，PYTHON，JAVA，C++，PHP,C#等多种语言。
MongoDB是高性能开源文档数据库，也是目前最受关注的NoSQL技术之一，以敏捷、可扩展和对企业应用友好（支持事务，一致性和数据完整性保证，有大企业应用案例）而著称。有人甚至认为LAMP中的M应该用MongoDB取代MySQL，其火热程度可见一斑。使用MongoDB的公司包括Foursquare, Craiglist, 迪士尼，SAP，Intuit，EA等，国内淘宝、大众点评、视觉中国等公司有应用。(最新版)
8. Hadoop的HBase
(Hadoop Database)，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据。
虽然大多数人都认为Hadoop及其所有的工具都是作为管理大规模集群的一种机制，其实不然，Hadoop也包括数据库，在HBase中也是通过节点来传播数据。Hadoop的Map /Reduce的架构是非常适合于复杂的计算任务或查询工作。领土在不断的扩张，新的数据库像Accumulo就是Hadoop平台的一个延伸。(Apache Accumulo是一个可靠的、可伸缩的、高性能的排序分布式的Key-Value存储解决方案，基于单元访问控制以及可定制的服务器端处理。使用Google BigTable设计思路，基于Apache Hadoop、Zookeeper和Thrift构建)
9. BigTable/ Accumulo/ Hypertable
BigTable是非关系的数据库,是一个稀疏的、分布式的、持久化存储的多维度排序Map。Bigtable的设计目的是可靠的处理PB级别的数据，并且能够部署到上千台机器上。Bigtable已经实现了下面的几个目标：适用性广泛、可扩展、高性能和高可用性。Bigtable已经在超过60个Google的产品和项目上得到了应用，包括Google Analytics、GoogleFinance、Orkut、Personalized Search、Writely和GoogleEarth。
谷歌的BigTable开启了NoSQL的热潮，现在很多公司都模仿谷歌的架构搭建了自己的平台。，而Hadoop的用户可以把它们放在Accumulo上，其他的可以使用Hypertable。所有的这些基本上都属于键/值存储，只不过添加了一些额外的功能，增加了搜索的速度而已。
10. DynamoDB
是亚马逊的key-value模式的存储平台，可用性和扩展性都很好，性能也不错：读写访问中99.9%的响应时间都在300ms内。DynamoDB的NoSQL解决方案，也是使用键/值对存储的模式，平且通过服务器把所有的数据存储在SSD上的三个不同的区域。如果有更高的传输需求，DynamoDB也可以在后台添加更多的服务器。（编译/，审校/包研）
原文链接：
本文为CSDN编译整理，未经允许不得转载。如需转载请联系
推荐阅读相关主题：
网友评论有（0）
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章}