nosql

1、概念： SQL（Structured Query Language）数据库，指关系型数据库。主要代表：SQL Server、Oracle、MySQL、PostgreSQL。 NoSQL（Not Only SQL）泛指非关系型数据库。主要代表：MongoDB、Redis、CouchDB。 2、诞生原因： 随着互联网的不断发展，各类型的应用层出不穷，在这个云计算的时代，对技术提出了更多的需求，主要体现在这四个方面： ①低延迟的读写速度：应用快速的反应能极大地提升用户的满意度。 ②海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量。 ③大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理。 ④庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低。 目前世界上主流的存储系统大部分还是采用了关系型数据库，其主要有以下优点： ①事务处理——保持数据的一致性。 ②由于以标准化为前提，数据更新的开销很小 ③可以进行join等复杂查询 虽然关系型数据库已经在业界的数据存储方面占据了不可动摇的地位，但是由于其天生的几个限制，使其很难满足上面这几个要求： ①扩展困难：由于存在类似join这要多表查询机制，使得数据库在扩展方面很艰难 ②读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂

嘉宾专访 |2020 PostgreSQL亚洲大会主论坛：韩锋 2020 P ostgreSQL 亚洲大会组委会特别推出 嘉宾系列专访 ，本期我们邀请到了阿里云数据库高级产品专家韩锋。他将在11月20日主论坛频道16:10-16:50时间段带来《乘云而上，ADB云原生数仓发展之路》分享。 韩 锋 | 阿里云数据库高级产品专家 Q1：您团队在PG领域的核心产品新功能主要解决什么问题，目前效果怎么样？ 韩锋 ：大家好，我是韩锋，一个近20年的IT老兵，早年从事软件开发工作，后因个人兴趣转入数据库领域。对数据库管理、架构、优化等有一定理解。与PG社区接触，是从关注PG产品开始，希望从社区得到更多的知识输入。 Q2：您团队在PG领域的核心产品新功能主要解决什么问题，目前效果怎么样？ 韩锋 ：2013年，开始接触PG，对其强大能力所折服，并在部分场景中尝试取代商业产品。最早是从2014年从Greenplum产品开始。使用GP替换Oracle，很好地解决了公司数仓场景问题。 Q3：您有参与PG版本功能的迭代吗？主要有哪些贡献？ 韩锋 ：目前从事一款分布式分析型数据库产品的规划工作。其产品底层是基于PG构建的，在满足大规模数仓领域，有着产品实践。 Q4：您团队在PG领域的核心产品新功能主要解决什么问题，目前效果怎么样？ 韩锋 ：我们与其他数据生态打通，包括大数据、数据库、文件

微博数据库那些事儿：3个变迁阶段背后的设计思想 编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由肖鹏在高可用架构群分享。转载请注明来自高可用架构公众号「 ArchNotes 」。 肖鹏，微博研发中心技术经理，主要负责微博数据库（MySQL/Reids/HBase/Memcached）相关的业务保障、性能优化、架构设计，以及周边的自动化系统建设。经历了微博数据库各个阶段的架构改造，包括服务保障及 SLA 体系建设、微博多机房部署、微博平台化改造等项目，10 年互联网数据库架构和管理经验，专注于数据库的高性能和高可用技术保障方向。 数据库专家的成长感触 “与 MySQL 结缘主要也是源于兴趣。第一份工作是在一家小公司，由于人手有限，各个领域的工作都要接触，相比之下我发现还是对数据库最感兴趣，所以就一直从事和数据库相关的技术工作了。而随着工作年限的增加，在数据库方面积累的经验也逐渐增多，越来越觉得数据库管理员（DBA）是一个偏实践的工种，很多理论上的东西在现实中会有各种的变化，比如“反范式”设计等。因此，如果想成为数据库方面的专家，建议大家一定要挑选好环境，大平台很多时候会由于量变引发质变产生很多有挑战的问题，而解决这些问题是成为技术专家的必经之路。” —— 肖鹏 微博数据库经历的变迁 首先为大家分享微博数据库经历的几个重要的阶段。 初创阶段 初期微博作为一个内部创新产品

（转自网络） 如今随着互联网的发展，数据的量级也是撑指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。 虽然关系型数据库在海量数据中逊色于NoSQL数据库，但是如果你操作正确，它的性能还是会满足你的需求的。针对数据的不同操作，其优化方向也是不尽相同。对于数据移植，查询和插入等操作，可以从不同的方向去考虑。而在优化的时候还需要考虑其他相关操作是否会产生影响。就比如你可以通过创建索引提高查询性能，但是这会导致插入数据的时候因为要建立更新索引导致插入性能降低，你是否可以接受这一降低那。所以，对数据库的优化是要考虑多个方向，寻找一个折衷的最佳方案。 一：查询优化 1：创建索引。 最简单也是最常用的优化就是查询。因为对于CRUD操作，read操作是占据了绝大部分的比例，所以read的性能基本上决定了应用的性能。对于查询性能最常用的就是创建索引。经过测试，2000万条记录，每条记录200字节两列varchar类型的

Redis Redis 是高性能的基于内存的 NoSQL 数据库。因为内存是比较宝贵的资源，无法无限制使用，所以 Redis 提供了： 键过期策略 来防止内存饱和。 内存淘汰策略 来使得内存饱和之后继续对外提供服务。 内存过期策略 expire命令 Redis 提供了 expire 命令来给一个键(key)设置过期时间： redis> SET foo "bar" "OK" redis> EXPIRE foo 10 (integer) 1 redis> TTL foo (integer) 10 类似 setex 命令，也可以对目标键设置过期时间，但它其实相当于 set 和 expire 两个命令的原子操作。 expire 只能作用于 Redis 中的键，所以无法对 list 或者 set 中的元素设置过期时间。对某个键调用删除(delete)或者重写(override)的命令如 del , set , getset 之后，会清除键上的过期时间；调用 persist 命令也会清除键上的过期时间；而修改键内容的操作如 incr , hset ，则不会对键的过期时间产生影响。 键的过期原理 Redis 键有两种过期方式：被动方式(passive way)和主动方式(active way)。 被动删除 当某个设置了过期时间的键被访问时，如果发现它已经过期， Redis

昨天，我写的博客 备份软件老矣？存储新风口——超融合第二存储来了 阅读量还挺多，在业界引起了不少反响，很多人回帖说他们家的产品就是超融合第二存储，但也许可能就是一个备份一体机，虽然感觉像，但可能并不是，我把它叫形像和神不似。 今天，我就以Cohesity为例，来讲讲超融合第二存储有哪些典型特征，大家可以对号入座，看看你的产品是否具备这样的特性。 1、无限节点。真正的分布式节点，可以无限scale-out扩展，没有节点规模限制。Cohesity号称所有的数据和元数据都是分布式的，类似google file system，没有节点限制。哈哈，投标你写不死它。Nutanix也是这么宣传的，没有节点限制。但是很多SDS是有节点限制的，比如EMC SCALEIO，宣传好像是1000多个，华为的FusionStorage，宣传是2000多个。不过，有高人分析说Cohesity的集群节点数目其实最大只有256个，但是它通过集中管理方式，把这些集群统一进行管理，实现真正的无限扩展。虽然Cohesity怎么能吹，但目前部署的最大集群只有20多个节点。 2、无限高性能快照。Cohesity号称采用SnapTree专利技术，整体系统的快照数是无限的，和IBM的XIV宣传的口径类似。而很多的存储系统，整个系统的快照数是有一个上限的。并且，支持快照的快照（无限递归），并且中间任何一个快照删除

前言 如今随着互联网的发展，数据的量级也是成指数式的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求,这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。 但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。如何使用关系型数据库解决海量存储的问题呢？ 此时就需要做数据库集群，为了提高查询性能将一个数据库的数据分散到不同的数据库中存储，为应对此问题就出现了——MyCat 。 在前不久，我偶然翻到了一个MyCat笔记，那是我向一个阿里大神求得的。 笔记比较详细的介绍了他对于MyCat的理解，结合了实战进行分析讲解。 对MyCat感兴趣的朋友可以拿去看看。 下面将这份文档的内容以图片的形式展现出来，但篇幅有限只能展示部分，如果你需要**“高清完整的pdf版” ，可以直接 点击「 MyCat 」备注：CSDN** 即可免费领取。 这份笔记从：MyCat简介→MyCat入门→MyCat配置文件详解→MyCat分片→MyCat高级→MyCat高可用集群搭建→MyCat架构剖析→MyCat综合案例 进行了详细的分析讲解。 MyCat 简介