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在设计表的时候会留出几个字段叫做”Reserved1Reserved2……“感觉好无厘头浪费空间后来随着产品功能的增加才明白这其实是经验丰富的表现。如果用NoSql就不用这么纠结了。总结一下就我浅薄的使用经验来看NoSql的优点是1. 在精心的设计下查询性能巨好。2. 数据结构弹性十足特别适合快速发展中的产品。另外需要提醒一下Mongodb不支持事务所以务必在设计的时候考虑到这一点。核心业务数据尽可能通过结构设计做到数据插入的一致性。如果实在无法达成请立即转回去用关系数据库否则或早或晚你一定会后悔的。免责声明本内容来自平台创作者博客园系信息发布平台仅提供信息存储空间服务。
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在设计表的时候会留出几个字段叫做”Reserved1Reserved2……“感觉好无厘头浪费空间后来随着产品功能的增加才明白这其实是经验丰富的表现。如果用NoSql就不用这么纠结了。总结一下就我浅薄的使用经验来看NoSql的优点是1. 在精心的设计下查询性能巨好。2. 数据结构弹性十足特别适合快速发展中的产品。另外需要提醒一下Mongodb不支持事务所以务必在设计的时候考虑到这一点。核心业务数据尽可能通过结构设计做到数据插入的一致性。如果实在无法达成请立即转回去用关系数据库否则或早或晚你一定会后悔的。免责声明本内容来自平台创作者博客园系信息发布平台仅提供信息存储空间服务。
