1.Nosql数据库基本知识

1. Nosql在国内的应用

  • 新浪微博
    • Redis+MySQL
    • 200多台物理机
  • 淘宝数据平台
    • Oceanbase
    • Tair：2010年6月30日对外开源

  • 视觉中国

    • MongoDB

  • 优酷

    • 在线评论 MongoDB
    • 运营数据分析 Hadoop/Hbase
  • 飞信空间
    • HandlerSocket
  • 豆瓣社区
    • BeansDB

2. NoSQL数据库的产生背景

2.1. 大数据的兴起于发展

2.1.1. What can you do with the data

  • Reporting
  • Post Hoc—事后比较
  • Real time---实时处理
  • Root Cause Analysis根本原因分析
  • Building Models
  • Prediction
  • Finding Patterns
  • Exploration
  • Control Physical Systems
  • More/More detailed data -> new business models and products…

2.1.2. Analytics Provide the Key To:

  • Personalization—个性化
  • Behavioral Targeting—行为定向
  • Service Optimization—服务优化
  • New and Improved Products
  • New and Improved Business Models

    2.1.3. 大数据能做什么

  • 帮助政府实现市场经济调控、公共卫生安全防范、灾难预警、社会舆论监督
  • 帮助城市预防犯罪，实现智慧交通，提升紧急应急能力
  • 帮助医疗机构建立患者的疾病风险跟踪机制，帮助医药企业提升药品的临床使用效果，帮助艾滋病研究机构为患者提供定制的药物
  • 帮助电商公司向用户推荐商品和服务，帮助旅游网站为旅游者提供心仪的旅游路线，帮助二手市场的买卖双方找到最合适的交易目标，帮助用户找到最合适的商品购买时期、商家和最优惠价格
  • 帮助企业提升营销的针对性，降低物流和库存的成本，减少投资的风险，以及帮助企业提升广告投放精准度
  • 帮助娱乐行业预测歌手，歌曲，电影，电视剧的受欢迎程度，并为投资者分析评估拍一部电影需要投入多少钱才最合适，否则就有可能收不回成本
  • 帮助社交网站提供更准确的好友推荐，为用户提供更精准的企业招聘信息，向用户推荐可能喜欢的游戏以及适合购买的商品

2.1.4. 大数据无处不在

  • 科学研究
    • 基因组
    • LHC 加速器
    • 地球与空间探测
  • 企业应用
    • Email、文档、文件
    • 应用日志
    • 交易记录
  • Web 1.0数据
    • 文本
    • 图像
    • 视频
  • Web 2.0数据 -查询日志/点击流
    • Twitter/ Blog / SNS
    • Wiki

2.1.5. 大数据定义

  • 大数据(big data,mega data)，或称巨量资料，指的是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产

    • 高德纳咨询公司（Gartner Group）

  • 大数据指不用随机分析法（抽样调查）这样的捷径，而采用所有数据进行分析处理

    • 维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》

  • 大数据（Big data）通常用来形容一个公司创造的大量非结构化数据和半结构化数据，这些数据在下载到关系型数据库用于分析时会花费过多时间和金钱

    • 《著云台》的分析师团队

2.1.6. 大数据的四个特征

  • Volume—数量大
  • Velocity—速度快
  • Variety—多样化
  • Value—价值

2.1.7. 从数据库到大数据

池塘捕鱼（数据库）vs.大海捕鱼（大数据） 模式(Schema)和数据的关系处理对象 在“池塘”中捕鱼，“鱼”仅仅是其捕捞对象 在“大海”中，“鱼”除了是捕捞对象之外，还可以通过某些“鱼”的存在来判断其他种类的“鱼”是否存在 传统数据库中数据仅作为处理对象 大数据时代，要将数据作为一种资源来辅助解决其他诸多领域的问题 处理工具 捕捞“池塘”中的“鱼”，一种渔网或少数几种基本就可以应对，也就是所谓的One Size Fits All 在“大海”中，不可能存在一种渔网能够捕获所有的鱼类，也就是说No Size Fits All

2.2. 关系数据库的优势和不足

2.2.1. 优势

  • 通用性和高性能
    • 保持数据的一致性（事务处理）
    • 最小冗余
    • 复杂查询如JOIN
    • 成熟的技术

2.2.2. 不足

  • 不适合在分布式环境中的向外扩展

  • 为什么？

    • 假设你要建设这样的系统，有数千用户的要求要处理，合理的方法是使用LAMP(Linux, apache, MySQL, PHP)来实现商业原型。
    • 关系数据库自身有很多特性
    • 事务可以保证更新多张表的数据是原子的， 保证你数据是强一致性的；
    • 参照完整性保证不同表模式间的关系；
    • sql让你可以执行复杂的查询(on everything)；
    • 你不必关心数据是如何保存的，只需要关心表模式。
    • 这种工作模式是很好的，而且能在相当长的一段时间内提供很好的服务

    • 如果幸运，你可以成为Internet上下一个

      • 热门话题，越来越多的人关注你的网站

    • 随着用户数的不断增加，需要增加更多的应用服务器，但是相对来说比较简单，真正的压力在于所有的应用服务器都共享一个中心的数据库服务器。随着数据库服务器的CPU/IO负载的不断增加，你就要考虑以当前这种用户增速，它还能支持多久

    • 第一步，你可能会为主服务器增加多个从服务器，主服务器响应写操作，从服务器只能响应读操作，对于你的网站来说，用户的读操作要远远的多于写操作 (eg. EC2 RDS MySQL read replicas)
    • 为减轻主服务器写压力，增加1台主服务器。增加主服务器确实这样似乎可以把每台主数据库的负载减少一半，但是更新处理会发生冲突(同样的数据在两台服务器同时更新成其他值)，可能会造成数据的不一致。为了避免这样的问题,就需要把对每个表的请求分别分配给合适的主数据库来处理
    • 当第一种方案仍然难以满足访问量时，你可能会考虑增加一个cache，比如说Memcached，把数据放到读取更快速的内存中，缓解读负载压力。但这是要考虑cache和数据库中数据一致性的问题，保证数据库的更新在很短的时间内反映到cache中
    • 尽管读负载压力能缓解，但所有的写操作还是集中在主服务器上，一旦主服务器难以承担写负载压力，就要考虑采用向上扩展的模式，增加主服务器的计算资源；同时，从服务器也要相应的升级。当然，这会花更多的钱(eg. EC2 RDS支持DB instance配置的升级)
    • 随后网站更热门，以前运行的很好的join sql 现在突然慢下来。情况变得更糟的话，你不得不停止存储过程， 因为这些存储过程变的很慢无法结束
    • 负载持续的增加，更多用户访问网站，你可能删除二级索引，因为管理这个索引负担很大，让数据库变的很慢。然后开始只使用主索引 ，其他不在使用
    • 如果几个月后你的负载成数量级的增长，甚至更多呢？下一步干什么呢？

    • 还能做的是将数据进行切分(垂直切分和水平切分)，分布到多个节点，但代价是很高的(经验丰富并且很贵的DBAs等)，同时可能带来一些问题

      • 引入分布式事务：由于关系数据库支持事务，切分可能引入分布式事务，但分布式事务对系统资源消耗大，性能也并不高

      • 跨节点的join和排序操作：尽管能在数据库端解决(Oracle DBlink, MySQL Federated)，但可能耗费大量的网络资源。通常推荐在应用层进行数据的整合，这需要应用层做很多额外的工作，也加重了应用服务器的负担

        • 很多公司将RDBMS作为技术储备，例如facebook, google都有很大的MySQL集群，而且能很好的承担它们的工作
        • RDBMS在一定程度上还是很难扩展的

      • 难以支持高并发读写

        • 为保障可用性，数据通常保存副本。
        • 关系数据库本质上支持事务，那么就要保证ACID特性中的原子性和一致性，因此数据的更新必须在所有副本间同步，会带来一定的延迟。
        • 只有极个别云中的关系数据库也支持读副本(Amazon RDS MySQL)，允许副本间数据不一致，但这种副本无法在主副本故障时，替代主副本，仍然需要存在同步备份的副本。

总结：

  • 大量数据的写入处理
  • 表结构变更及建立索引
  • 字段不固定的应用
  • 对简单查询需要快速返回结果的处理

2.3. Nosql的优势

  • 易于数据的分散
  • 提升性能和增大规模
  • 模式自由
  • 扩展性好
  • 。。。

3. NoSQL数据库的种类

存储类型 解决方案 特点 --
列存储 Hbase，Cassandra， 按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。 如果翻转数据，列式存储与关系存储将会非常相似。与关系模型存储记录不同，列式存储以流的方式在列中存储所有的数据。对于任何记录，索引都可以快速地获取列上的数据。Map-reduce的实现Hadoop的流数据处理效率非常高，列式存储的优点体现的淋漓极致。因此，HBase和Hypertable通常作为非关系型数据仓库，为Map-reduce进行数据分析提供支持。关系类型的列标对数据分析效果不好，因此，用户经常将更复杂的数据存储在列式数据库中。这直接体现在Cassandra中，它引入的“column family”可以被认为是一个“super-column”。列式存储支持行检索，但这需要从每个列获取匹配的列值，并重新组成行
文档存储 MongoDB，CouchDB 文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。 文档存储支持对结构化数据的访问，不同于关系模型的是，文档存储没有强制的架构。事实上，文档存储以封包键值对的方式进行存储。在这种情况下，应用对要检索的封包采取一些约定，或者利用存储引擎的能力将不同的文档划分成不同的集合，以管理数据。与关系模型不同的是，文档存储模型支持嵌套结构。例如，文档存储模型支持XML和JSON文档，字段的“值”又可以嵌套存储其它文档。文档存储模型也支持数组和列值键。与键值存储不同的是，文档存储关心文档的内部结构。这使得存储引擎可以直接支持二级索引，从而允许对任意字段进行高效查询。支持文档嵌套存储的能力，使得查询语言具有搜索嵌套对象的能力，XQuery就是一个例子。MongoDB通过支持在查询中指定JSON字段路径实现类似的功能。
key-value存储 Tokyo Cabinet / Tyrant，Berkeley DB，MemcacheDB，Redis 可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能） 键值存储提供了基于键对值的访问方式。键值对可以被创建或删除，与键相关联的值可以被更新。键值存储一般不提供事务处理机制。对不同的编程语言而言，键值存储类似于哈希表。对此，不同的编程语言有不同的名字（如，Java称之为“HashMap”，Perl称之为“hash”，Python称之为“dict”，PHP称之为“associative array” ，C++则称之为“boost::unordered_map<...>” ）。键值存储支持键上自有的隐式索引。键值存储看起来好像不太有用，但却可以在“值”上存储大量信息。“值”可以是一个XML文档，一个JSON对象，或者其它任何序列化形式。重要的是，键值存储引擎并不在意“值”的内部结构，它依赖客户端对“值”进行解释和管理

results matching ""

    No results matching ""