包含nosqllist的词条

高性能 NoSQL

关系数据库经过几十年的发展，已经非常成熟，但同时也存在不足：

网站建设哪家好，找成都创新互联！专注于网页设计、网站建设、微信开发、微信平台小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了海州免费建站欢迎大家使用！

表结构是强约束的，业务变更时扩充很麻烦。

如果对大数据量的表进行统计运算，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 可以用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子句进行判断了,例如聚合函数的值是否大于某一个值等等。

linux 怎么安装redis

Redis是当前比较热门的NOSQL系统之一，它是一个key-value存储系统。

和Memcache类似，但很大程度补偿了Memcache的不足，它支持存储的value类型相对更多，包括string、list、set、zset和hash。

这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作。在此基础上，Redis支持各种不同方式的排序。

几种nosql的浅谈

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是什么，用来做什么

Redis是一个nosql数据库，可以存储key-value值。因为其底层实现中，数据读写是基于内存，速度非常快，所以常用于缓存；进而因其为独立部署的中间件，常用于分布式缓存的实现方案。

常用场景有：缓存、秒杀控制、分布式锁。

虽然其是基于内存读写，但底层也有持久化机制；同时具备集群模式；不用担心其可用性。

关于Redis的使用，可以参考《Redis的使用方法、常见应用场景》