十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
关系数据库经过几十年的发展,已经非常成熟,但同时也存在不足:
网站建设哪家好,找成都创新互联!专注于网页设计、网站建设、微信开发、微信平台小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了海州免费建站欢迎大家使用!
表结构是强约束的,业务变更时扩充很麻烦。
如果对大数据量的表进行统计运算,I/O会很高,因为即使只针对某列进行运算,也需要将整行数据读入内存。
全文搜索只能使用 Like 进行整表扫描,性能非常低。
针对这些不足,产生了不同的 NoSQL 解决方案,在某些场景下比关系数据库更有优势,但同时也牺牲了某些特性,所以不能片面的迷信某种方案,应将其作为 SQL 的有利补充。
NoSQL != No SQL,而是:
NoSQL = Not Only SQL
典型的 NoSQL 方案分为4类:
Redis 是典型,其 value 是具体的数据结构,包括 string, hash, list, set, sorted set, bitmap, hyperloglog,常被称为数据结构服务器。
以 list 为例:
LPOP key 是移除并返回队列左边的第一个元素。
如果用关系数据库就比较麻烦了,需要操作:
Redis 的缺点主要体现在不支持完成的ACID事务,只能保证隔离性和一致性,无法保证原子性和持久性。
最大的特点是 no-schema,无需在使用前定义字段,读取一个不存在的字段也不会导致语法错误。
特点:
以电商为例,不同商品的属性差异很大,如冰箱和电脑,这种差异性在关系数据库中会有很大的麻烦,而使用文档数据库则非常方便。
文档数据库的主要缺点:
关系数据库是按行来存储的,列式数据库是按照列来存储数据。
按行存储的优势:
在某些场景下,这些优势就成为劣势了,例如,计算超重人员的数据,只需要读取体重这一列进行统计即可,但行式存储会将整行数据读取到内存中,很浪费。
而列式存储中,只需要读取体重这列的数据即可,I/O 将大大减少。
除了节省I/O,列式存储还有更高的压缩比,可以节省存储空间。普通行式数据库的压缩比在 3:1 到 5:1 左右,列式数据库在 8:1 到 30:1,因为单个列的数据相似度更高。
列式存储的随机写效率远低于行式存储,因为行式存储时同一行多个列都存储在连续空间中,而列式存储将不同列存储在不连续的空间。
一般将列式存储应用在离线大数据分析统计场景,因为这时主要针对部分列进行操作,而且数据写入后无须更新。
关系数据库通过索引进行快速查询,但在全文搜索的情景下,索引就不够了,因为:
假设有一个交友网站,信息表如下:
需要匹配性别、地点、语言列。
需要匹配性别、地点、爱好列。
实际搜索中,各种排列组合非常多,关系数据库很难支持。
全文搜索引擎是使用 倒排索引 技术,建立单词到文档的索引,例如上面的表信息建立倒排索引:
所以特别适合根据关键词来查询文档内容。
上面介绍了几种典型的NoSQL方案,及各自的适用场景和特点,您可以根据实际需求进行选择。
做过Zabbix的同学都知道,Zabbix通过专用的Agent或者SNMP收集相关的监控数据,然后存储到数据库里面实时在前台展示。Zabbix监控数据主要分为以下两类:
历史数据:history相关表,从history_uint表里面可以查询到设备监控项目的最大,最小和平均值,即存储监控数据的原始数据。
趋势数据:trends相关表,趋势数据是经过Zabbix计算的数据,数据是从history_uint里面汇总的,从trends_uint可以查看到监控数据每小时最大,最小和平均值,即存储监控数据的汇总数据。
Zabbix可以通过两种方式获取历史数据:
1.通过Zabbix前台获取历史数据
通过Zabbix前台查看历史数据非常简单,可以通过Monitoring-Lastest data的方式查看。也可以点击右上角的As plain test按钮保存成文本文件。
2.通过前台获取的数据进行处理和二次查询有很多限制,因此可以通过SQL语句直接从后台DB查询数据。
首先大家应该熟悉SQL语句Select 常用用法:
SELECT [ALL | DISTINCT] Select_List [INTO [New_Table_name]
FROM { Table_name | View_name} [ [,{table2_name | view2_name}
[,…] ]
[ WHERE Serch_conditions ]
[ GROUP BY Group_by_list ]
[ HAVING Serch_conditions ]
[ ORDER BY Order_list [ASC| DEsC] ]
说明:
1)SELECT子句指定要查询的特定表中的列,它可以是*,表达式,列表等。
2)INTO子句指定要生成新的表。
3)FROM子句指定要查询的表或者视图。
4)WHERE子句用来限定查询的范围和条件。
5)GROUP BY子句指定分组查询子句。
6)HAVING子句用于指定分组子句的条件。
7)ORDER BY可以根据一个或者多个列来排序查询结果,在该子句中,既可以使用列名,也可以使用相对列号,ASC表示升序,DESC表示降序。
8)mysql聚合函数:sum(),count(),avg(),max(),avg()等都是聚合函数,当我们在用聚合函数的时候,一般都要用到GROUP BY 先进行分组,然后再进行聚合函数的运算。运算完后就要用到Having子句进行判断了,例如聚合函数的值是否大于某一个值等等。
Redis是当前比较热门的NOSQL系统之一,它是一个key-value存储系统。
和Memcache类似,但很大程度补偿了Memcache的不足,它支持存储的value类型相对更多,包括string、list、set、zset和hash。
这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作。在此基础上,Redis支持各种不同方式的排序。
1、性能
都比较高,性能对我们来说应该都不是瓶颈。
总体来讲,TPS 方面 redis 和 memcache 差不多,要大于 mongodb。
2、操作的便利性
memcache 数据结构单一。(key-value)
redis 丰富一些,数据操作方面,redis 更好一些,较少的网络 IO 次数,同时还提供 list,set,
hash 等数据结构的存储。
mongodb 支持丰富的数据表达,索引,最类似关系型数据库,支持的查询语言非常丰富。
3、内存空间的大小和数据量的大小
redis 在 2.0 版本后增加了自己的 VM 特性,突破物理内存的限制;可以对 key value 设置过
期时间(类似 memcache)
memcache 可以修改最大可用内存,采用 LRU 算法。Memcached 代理软件 magent,比如建立
10 台 4G 的 Memcache 集群,就相当于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 适合大数据量的存储,依赖操作系统 VM 做内存管理,吃内存也比较厉害,服务
不要和别的服务在一起。
4、可用性(单点问题)
对于单点问题,
redis,依赖客户端来实现分布式读写;主从复制时,每次从节点重新连接主节点都要依赖整
个快照,无增量复制,因性能和效率问题,
所以单点问题比较复杂;不支持自动 sharding,需要依赖程序设定一致 hash 机制。
一种替代方案是,不用 redis 本身的复制机制,采用自己做主动复制(多份存储),或者改成
增量复制的方式(需要自己实现),一致性问题和性能的权衡
Memcache 本身没有数据冗余机制,也没必要;对于故障预防,采用依赖成熟的 hash 或者环
状的算法,解决单点故障引起的抖动问题。
mongoDB 支持 master-slave,replicaset(内部采用 paxos 选举算法,自动故障恢复),auto sharding 机制,对客户端屏蔽了故障转移和切分机制。
5、可靠性(持久化)
对于数据持久化和数据恢复,
redis 支持(快照、AOF):依赖快照进行持久化,aof 增强了可靠性的同时,对性能有所影
响
memcache 不支持,通常用在做缓存,提升性能;
MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性
6、数据一致性(事务支持)
Memcache 在并发场景下,用 cas 保证一致性redis 事务支持比较弱,只能保证事务中的每个操作连续执行
mongoDB 不支持事务
7、数据分析
mongoDB 内置了数据分析的功能(mapreduce),其他不支持
8、应用场景
redis:数据量较小的更性能操作和运算上
memcache:用于在动态系统中减少数据库负载,提升性能;做缓存,提高性能(适合读多写
少,对于数据量比较大,可以采用 sharding)
MongoDB:主要解决海量数据的访问效率问题。
表格比较:
memcache redis 类型 内存数据库 内存数据库
数据类型 在定义 value 时就要固定数据类型 不需要
有字符串,链表,集 合和有序集合
虚拟内存 不支持 支持
过期策略 支持 支持
分布式 magent master-slave,一主一从或一主多从
存储数据安全 不支持 使用 save 存储到 dump.rdb 中
灾难恢复 不支持 append only file(aof)用于数据恢复
性能
1、类型——memcache 和 redis 都是将数据存放在内存,所以是内存数据库。当然,memcache 也可用于缓存其他东西,例如图片等等。
2、 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。
3、 虚拟内存——当物理内存用完时,可以将一些很久没用到的 value 交换到磁盘。
4、 过期策略——memcache 在 set 时就指定,例如 set key1 0 0 8,即永不过期。Redis 可以通
过例如 expire 设定,例如 expire name 10。
5、 分布式——设定 memcache 集群,利用 magent 做一主多从;redis 可以做一主多从。都可
以一主一从。
6、 存储数据安全——memcache 断电就断了,数据没了;redis 可以定期 save 到磁盘。
7、 灾难恢复——memcache 同上,redis 丢了后可以通过 aof 恢复。
Memecache 端口 11211
yum -y install memcached
yum -y install php-pecl-memcache
/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid
-d 启动一个守护进程
-p 端口
-m 分配的内存是 M
-c 最大运行并发数-P memcache 的 pid
//0 压缩(是否 MEMCACHE_COMPRESSED) 30 秒失效时间
//delete 5 是 timeout
Redis是一个nosql数据库,可以存储key-value值。因为其底层实现中,数据读写是基于内存,速度非常快,所以常用于缓存;进而因其为独立部署的中间件,常用于分布式缓存的实现方案。
常用场景有:缓存、秒杀控制、分布式锁。
虽然其是基于内存读写,但底层也有持久化机制;同时具备集群模式;不用担心其可用性。
关于Redis的使用,可以参考《Redis的使用方法、常见应用场景》