精华内容
下载资源
问答
  • nosql应用场景

    千次阅读 2015-08-17 18:03:24
    NoSql,主要指非关系的、分布式的数据库设计模式。也有许多专家将NoSql解读为Not Only SQL,表示NoSQL只是关系数据库的补充,而不是替代方案。一般而言,NoSQL数据库产品都放弃了关系型数据库的两大重要基础:以关系...

          关系数据库根据范式将表到最小冗余,再通SQL查询出数据。NoSQL数据库产品都放弃了关系型数据库的两大重要基础:以关系代数为基础的结构化查询语句(SQL)和事务一致性保证(ACID)。而强化了其他一些大型网站更关注的特性:高可用性和可伸缩性。

            NoSql准确点翻译成Not Only SQL    ,并非表之间没有关系。比如可以通过Id和索引来读取多个表中的数据,然后手动将他们关联在一起。相对对于SQL来讲,关联性相对更自由,限制也较少。但是它为非关系而生,不适用于需要大量关联的数据。

    1、High performance - 对数据库高并发读写的需求

    web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求。


    2、对海量数据的高效率存储和访问

    对于大型的SNS网站,每天用户产生海量的用户动态,以国外的Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。


    3、高可用性和可伸缩性
    在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?


    在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地,例如:

    1、数据库事务一致性需求
    很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
    2、数据库的写实时性和读实时性需求
    对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性。
    3、对复杂的SQL查询,特别是多表关联查询的需求
    任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。
    因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生。
    NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构,通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
    当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系,如Facebook 的Cassandra, Apache 的HBase,也得到了广泛认同。


    MongoDB

    MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是 类似json的bjson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语 言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。






     

    展开全文
  • nosql应用场景——用redis打造山寨twitter 使用关系型数据库时,需要产生一些表、索引等等,但是使用k/v键值数据库我们没有表,我们怎么设计? 我们需要确定一些key来表达对象、以及需要思考用什么类型数据 ...

    nosql应用场景——用redis打造山寨twitter


    使用关系型数据库时,需要产生一些表、索引等等,但是使用k/v键值数据库我们没有表,我们怎么设计?
    我们需要确定一些key来表达对象、以及需要思考用什么类型数据
    我们先从设计"User"开始,山寨twitter的User有username,userid,password,followers(关注我的),following(我关注的) 等等属性
    第一个问题:在系统中用什么来标识一个用户?username可以,但是它太大了,我们需要保持low memory。
    因此我们可以像关系型数据库一样给每个用户关联一个唯一的id
    其它数据的引用通过userId来关联。首先生成一个userId,很简单,因为我们有原子性的INCR操作!



    使用 "global:nextUserI" 来生成userID
    然后使用userID关联所有该用户的数据
    这个做法是key-value存储设计模式!
    做了这些以后,还需要填充一些信息,比如:根据username来查找userID:


    这个做法看起来极傻,但是记住:我们只能通过key来访问数据!"username:derby:uid"是一个KEY
    这是新范式:只能使用key来访问数据,将强制我们组织所有数据。

    下面要设计following、followers用户列表、以及文章



    另外非常重要的是显示你的主页更新,我们需要按日期倒序排序,使用List比较完美
    基本上每个新的文章使用LPush,插在list最前方就可以啦!非常感谢LRange功能可以分页!



    ==========================
    身份验证:
    =========================
    像山寨twitter这种东西,别的功能搞多点少点没关系,但是登陆及权限验证,我们不能马虎
    我们不想使用http session或其它类似这样的东西来搞验证
    要让系统在分布式中的不同的服务器上运行,所以必须把握所有状态,
    所以我们需要一个随机字符串作为cookie来设置用户权限
    我们需要两个key来保证系统健壮运行:



    验证要的几点简单操作:

    • 1.从用户请求获取username,password
    • 2.验证username是否存在
    • 3.验证password是否正确
    • 4.以上验证都通过,就设置一个auth到cookie

    每次登陆都做以上的操作


    另外要检查用户是否已验证,要做以下操作:

    • 1.从cookie取出的cookie,如果没有cookie,则没登陆
    • 2.取出cookie中的"auth",去redis中取
    •    userId = redis.get("auth:AuthCookie")   PS:AuthCookie代表cookie中的值
    • 3.去redis验证uid:1000:auth 是否匹配
    •    if(AuthCookie == redis.get("uid:1000:auth")) {  通过!;  }
    • 4.验证通过,取用户信息

    登出操作:只要把cookie中的值删掉就可以啦,如果你嫌这种方式不安全,可以采用另外一种方法:logout的时候去服务器请求,请求服务器换一个随机auth string,也就是每次登陆的cookie都换一次


    ================================
    Updates(或叫Posts):
    ============================
    当创建一个update的时候,做如下操作:

    NCR global:nextPostId => 10343
    SET post:10343 userid+"|"+time+"|"+"I'm having fun with Retwis"

    生成一个postId以后,LPush这个文章到作者以及每一个关注(following)用户,大致代码如下:



    ===================
    显示页面:
    ====================

     

    ============================
    我关注的用户(following users):
    ==============================


    又一次使用这种看起来很傻的模式
    需要在following和followers都加入记录,这点跟关系型数据库不同
    这种模式的使用需要付出这么一点代价,但是另一方面,我们可以极其极其快速的访问数据!
    而且我们可以使用SInter,SUnion等做些有意思的事

    =========================
    横向扩展
    =========================
    慈祥的读者,如果你都读到这了,说明你是个真英雄,谢谢!
    在谈到横向扩展之前,单一服务器的价值。
    retwis是出奇的快,不使用任何缓存。在一个慢的像驴的服务器上,ab(apache benchmark)测试100个客户端100000个请求平均耗时5耗秒。意思就是这台驴可以每天支持1000000个用户!想像一下普通硬件可以达到什么水平。

    ----------------------
    hashing the key
    ----------------------
    第一件事就是散列key和请求在不同的服务器上,有很多算法可以做这件事,比如:consistent hashing的ruby实现,但是一般情况都是把key转成一个数值,然后用这个数除以服务器的总数量:

    server_id = crc32(key) % number_of_servers


    这么做有很多问题,当你添加一个服务器以后,你需要移动非常多的key.
    所有的用户数据会分步在不同的服务器上。这么做就不能做inter-key操作了(比如:SInter)

    -----------------
    special keys
    -----------------
    假如每次我们要发个新贴子,我们需要一个增长的key "global:nextPostId",怎么来解决这个问题?id不太需要一个增长的数值,但是必须要唯一,所以搞个随机字符串足矣了。
    还有另外一个问题:例子中的global:timeline,不同的服务器可能需要merge一下,或者找台专门的服务器来做这件事。
    一个普通的硬件,redis可以处理10万个写操作每秒,我想,足够一个山寨twitter了

    原文:
    redis-2.2.4/doc/TwitterAlikeExample.html
    把原文的php代码翻译成java,看起来舒服些。

    展开全文
  • redis学习-当下NoSQL应用场景简介

    千次阅读 2020-12-06 19:29:22
    SQL和NoSQL双剑合璧 Alibaba中文站商品信息如何存放 看看阿里巴巴中文网站首页以女装/女包包为例 架构发展历程: 1.演变过程 2.第5代 3.第5代架构使命 和我们相关的,多数据源类型的存储问题 看看阿里巴巴中文...

    SQL和NoSQL双剑合璧

    Alibaba中文站商品信息如何存放

    看看阿里巴巴中文网站首页以女装/女包包为例

    架构发展历程:

    1.演变过程

    在这里插入图片描述

    2.第5代

    在这里插入图片描述

    3.第5代架构使命

    在这里插入图片描述
    和我们相关的,多数据源类型的存储问题
    在这里插入图片描述
    看看阿里巴巴中文网站首页,以女装/女宝宝为例
    1.商品基本信息(编号和名字等等,不变的,稳定的数据)
    名称,价格,出厂日期,生产厂商这些稳定不变的数据
    关系型数据库,Mysql/oracle目前淘宝在去O化(也即拿掉Oracle),注意,淘宝内部用 的Mysql是里面的大牛自己改造过的。
    为什么去IOE
    大部分都是用Mysql。

    2.商品描述、详情、评价信息(多文字类)
    多文字信息描述类,IO读写性能变差,文档数据库MongoDB
    3.商品的图片
    商品图片展现类
    分布式的文件系统中:淘宝自己的TFS,Google的GFS,Hadoop的HDFS
    4.商品的关键字
    淘宝自家
    ISearch
    5.商品的波段性的热点高频信息(如,情人节的巧克力)
    提前准备好
    内存数据库
    Tair、Redis、Memcache
    6.商品的交易、价格计算、积分累计
    外部系统,外部第3方支付接口
    支付宝

    多数据源和多数据类型的存储问题。

    总结大型互联网应用(大数据、高并发、多样数据类型)的难点和解决方案

    难点
    数据类型多样性
    数据源多样性和变化重构
    数据源改造而数据服务平台不需要大面积重构
    解决方法
    EAI
    UDSL 统一数据平台服务层
    是什么

    展开全文
  • Redis—B站学习—redis当下nosql使用场景简介 一、当下是mysql和nosql一起使用 二、阿里巴巴中文站商品信息如何存放的 看看阿里巴巴中文网站首页 架构发展历程 第五代架构的演变 第五代架构使命 和我们相关...

    Redis—B站学习—redis当下nosql使用场景简介

    一、当下是mysql和nosql一起使用

    二、阿里巴巴中文站商品信息如何存放的

    1. 看看阿里巴巴中文网站首页
      1. 架构发展历程
        在这里插入图片描述
      2. 第五代架构的演变
        在这里插入图片描述
      3. 第五代架构使命
        在这里插入图片描述

    和我们相关的,多数据源多数据类型的存储问题

    数据架构的日益复杂型

    在这里插入图片描述
    在这里插入图片描述

    1. 商品基本信息

      1. 名称、价格,出厂日期,生产厂商等
      2. 关系型数据库:mysql/oracle目前淘宝在去O化(也即拿掉Oracle)。
        注意:淘宝内部用的Mysql是里面的大牛自己改造过的
        为什么去IOE:“去IOE”(在IT建设过程中,去除IBM小型机、Oracle数据库及EMC存储设备)的想法
    2. 商品描述、详情、评价信息(多文字类)

      1. 多文字信息描述类,IO读写性能变差
      2. 文档数据库MongDB中
    3. 商品的图片(存在分布式的文件系统中)

      1. 商品图片展现类
      2. 分布式的文件系统中
        1. 淘宝自己的TFS
        2. Google的GFS
        3. Hadoop的HDFS
    4. 商品的关键字

      1. 搜索引擎,淘宝内用
      2. ISearch
    5. 商品的波段性的热点高频信息

      1. 内存数据库
      2. tair、Redis、Memcache
    6. 商品的交易、价格计算、积分累计

      1. 外部系统,外部第3方支付接口
      2. 支付宝
    7. 总结大型互联网应用(大数据、高并发、多样数据类型)的难点和解决方案

      1. 难点

        1. 数据类型多样性
        2. 数据源多样性和变化重构
        3. 数据源改造而数据服务平台不需要大面积重构
      2. 解决办法

        1. 给学生画图介绍EAI和统一数据平台服务层
        2. 阿里、淘宝干了什么?UDSL:统一数据服务平台
          1. UDSL是什么
            在这里插入图片描述
            在这里插入图片描述
          2. UDSL什么结构样
            在这里插入图片描述
            在这里插入图片描述
      3. UDSL完成什么
        1. 模型数据映射DSL在这里插入图片描述在这里插入图片描述
        2. 提供统一的API在这里插入图片描述
        在这里插入图片描述
        3. 热点缓存在这里插入图片描述
        在这里插入图片描述
        4. …

    展开全文
  • 今天我主要讲两个方面的内容,一是NoSQL应用场景,另一个是Cassandra架构实现分析。作为一个NoSQL非常接触的应用,我们分析它的架构,看看它怎么做的。看看它的可操作一致性等等的优点。  为了让大家很清楚的...
  • 今天小编就为大家分享一篇关于sql与各个nosql数据库使用场景的讲解,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
  • NoSQL使用场景

    2020-01-31 13:05:33
    NoSQL=Not Only SQL 常见的NoSQL解决方案: 1)K-V存储:解决关系数据库无法存储数据结构的问题,以Redis为代表;... 使用场景:在常见的电商网站设计中,可以使用关系型数据库存储商品库存信息、订单基...
  • 对比传统关系型数据库,NoSQL有着更为复杂的分类——键值、面向文档、列存储以及图数据库。这里就带你一览NoSQL各种类型的适用场景及一些知名公司的方案选择。 在过...
  • Nosql的实际应用场景

    万次阅读 2015-03-30 17:20:45
    Nosql 实际应用场景
  • NoSQL数据库应用场景

    2017-01-10 11:41:00
    ...http://www.csdn.net/article/2013-07-24/2816330-how-to-choose-nosql-db http://www.jb51.net/article/51599.htm 转载于:https://my.oschina.net/cccyb/blog/821943
  • 点击上方蓝色“方志朋”,选择“设为星标”回复“666”获取独家整理的学习资料!来源:r6d.cn/r4P7 对比传统关系型数据库,NoSQL有着更为复杂的分类——键值、面向文档、...
  • 关系型数据库与NoSQL数据库场景说明

    千次阅读 2016-05-19 15:24:02
    为什么使用MySQL呢,因为它是开源的,同时具备轻量、简单、稳定和高性能等特点,尤其是其学习成本相对其他数据库,比如Oracle和Sybase更简单,入门更低。MySQL的应用范围从中小型Web网站到大型的企业级应用随处都...
  • 什么是NoSQL NoSQL,指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写,是对不同于传统的关系型数据库的数据库管理系统的统称,它具有非关系型、分布式、不提供ACID的数据库设计模式等特征。 NoSQL用于...
  • NoSQL以及其应用场景

    千次阅读 2014-04-17 19:27:35
    今天主要想了想在项目(音乐网站)中如何使用我们的有没有必要使用Nosql,突然发现原来只是粗浅的认为:就要用NoSQL,因为NoSQL听起来是高新技术,然后我就要用。而不考虑适合不适合。今天上午看了本 noSql数据库...
  • 该脑图是介绍NoSQL数据库的使用模型及使用场景,请贡献给大家下载!
  • 键值数据库 适用案例 现在讲几个适合使用键值数据库的情况 1 存触会话信息 通常来说每一次网络会话都是唯一的所以分配给它们的 session id 值也各 不相同如果应用程序原来要把 session id 存在磁盘上或关系型数据库...
  • 常见NoSQL系统使用场景分析

    千次阅读 2011-11-29 11:15:35
    •Cassandra •特性:分布式与复制的权衡\根据列和键范围进行查询\BigTable类似的功能:... •应用场景:银行,金融行业。数据分析。 ------------------------------------------------------------------------------
  • NoSQL 数据库的使用场景

    千次阅读 2016-03-20 21:27:01
    这里就带你一览NoSQL各种类型的适用场景及一些知名公司的方案选择。 在过去几年,关系型数据库一直是数据持久化的唯一选择,数据工作者考虑的也只是在这些传统数据库中做筛选,比如SQL Server、Oracle、MySQL。...
  • 一、NoSQL入门及应用场景 NoSQL:即 Not-Only SQL( 泛指非关系型的数据库),作为关系型数据库的补充。 作用:应对基于海量用户和海量数据前提下的数据处理问题。 常见 Nosql 数据库: Redis memcache HBase ...
  • 这些模型的分类方法来自于Emil Eifrem 和 NoSQL databases。 文档数据库 源起:受Lotus Notes启发。数据模型:包含了key-value的文档集合例子:CouchDB, MongoDB优点:数据模型自然,编程友好,快速开发,web...
  • sql与各个nosql使用场景

    千次阅读 2018-06-26 00:27:59
    SQL为主干 为什么我这样理解:当从技术角度来说,1关系型网格 - 充分的体现了现实事务2....什么时候引入的NoSQL 先看看sql - > sql + nosql的过程。了解是否应该用nosql 该用哪些NoSQ...
  • NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,是一项全新的数据库革命性运动,早期就有人提出,发展至2009...NoSQL的特点:处理差大量的数据运行在廉价的PC服务器集群解决性能瓶颈NOSQL应用场景:对数据高并...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 60,150
精华内容 24,060
关键字:

nosql应用场景