mongodb与mysql全表扫描能力PK

nosql的数据在内存里,而传统rdbms,某个select第一次执行的时候,如果发现内存里没有需要的数据(比如mysql的innodb buffer pool),会去从磁盘读取,然后再开始计算,这样子从原理上就必然比nosql要慢一些,但是,会慢多少呢?可以用一个分组统计的全表扫描来PK下。

测试环境如下:

server:阿里云服务器(Ubuntu14.04+1核cpu和 1G内存)

mysql:5.5.41

mysql服务端参数:innodb_buffer_pool_size = 512M   (其余都默认)

mongodb:2.4.9

这里用一个1000多万行记录的表作为测试对象,这个表只有一个字段:imsi。

在mysql里建测试对象,导表:

create database db_test;

create table ul_inbound(imsi varchar(15));
load data infile ‘/tmp/inbound.sub.log‘ into table ul_inbound(imsi);

测试结果:

mysql> select imsi,count(*) from ul_inbound group by imsi having count(*) >5000;
+-----------------+----------+
| imsi            | count(*) |
+-----------------+----------+
| 250017831851018 |     5166 |
| 283100106389033 |    21291 |
| 302720304966683 |    41598 |
| 302720502859575 |     8787 |
| 302720505260881 |     7932 |
| 310170801568405 |     6018 |
| 310170802085117 |    13452 |
| 310170802299726 |    13824 |
| 310410577936479 |     5772 |
| 310410610359421 |     5790 |
| 310410661857060 |     7038 |
| 310410669731926 |     7788 |
| 310410671702203 |     6705 |
| 310410673812082 |     5403 |
+-----------------+----------+
53 rows in set (1 min 47.73 sec)

花了107秒。

在mongodb里导入数据(导入到my_mongodb的sub里):

#!/usr/bin/python
# Python:2.7.6
# Filename:mongodb.py
import pymongo
import random

conn = pymongo.Connection("127.0.0.1",27017)  #Connection() without parameters will default connect localhost mongodb
db = conn.my_mongodb
for imsi in open(‘inbound.sub.log‘):
    imsi = imsi.strip(‘\n‘)
    db.sub.insert({‘imsi‘:imsi})

> use my_mongodb;
switched to db my_mongodb
> db.sub.aggregate( [ { $group: { _id: "$imsi",  count: { $sum: 1 } } }, { $match: { count: { $gt: 5000 } } } ]);
{
        "result" : [
                {
                        "_id" : "401025006559964",
                        "count" : 17982
                },
                {
                        "_id" : "310410757405261",
                        "count" : 7269
                },

10秒左右搞定。

注:

1)这个只是为了测试全表扫描能力,实际mysql查询能力会受到索引、服务端参数等诸多因素的影响。

2)mongodb的使用,必须内存管够,如果内存不够,要用swap,能力会大受影响。

时间: 2024-10-14 09:32:21

mongodb与mysql全表扫描能力PK的相关文章

造成MySQL全表扫描的原因

全表扫描是数据库搜寻表的每一条记录的过程,直到所有符合给定条件的记录返回为止.通常在数据库中,对无索引的表进行查询一般称为全表扫描:然而有时候我们即便添加了索引,但当我们的SQL语句写的不合理的时候也会造成全表扫描.以下是经常会造成全表扫描的SQL语句及应对措施: 1. 使用null做为判断条件 如:select account from member where nickname = null; 建议在设计字段时尽量将字段的默认值设为0,改为select account where nickn

mysql 全表扫描场景

全表扫描是数据库搜寻表的每一条记录的过程,直到所有符合给定条件的记录返回为止.通常在数据库中,对无索引的表进行查询一般称为全表扫描:然而有时候我们即便添加了索引,但当我们的SQL语句写的不合理的时候也会造成全表扫描. 以下是经常会造成全表扫描的SQL语句及应对措施: 1. 使用null做为判断条件 如:select account from member where nickname = null; 建议在设计字段时尽量将字段的默认值设为0,改为select account where nick

怎么对10亿数据量级的mongoDB作高效的全表扫描

转自:http://quentinxxz.iteye.com/blog/2149440 一.正常情况下,不应该有这种需求 首先,大家应该有个概念,标题中的这个问题,在大多情况下是一个伪命题,不应该被提出来.要知道,对于一般较大数据量的数据库,全表查询,这种操作一般情况下是不应该出现的,在做正常查询的时候,如果是范围查询,你至少应该要加上limit. 说一下,我的应用场景:用于全量建立搜索引擎的索引.这就是一种需要用到全表扫描的非一般情况.对于全表扫描的结果,我们没有排序要求. 二.情况说明 既然

MySql查询优化limit 1避免全表扫描(转)

在某些情况下,如果明知道查询结果只有一个,SQL语句中使用LIMIT 1会提高查询效率. 例如下面的用户表(主键id,邮箱,密码): create table t_user(id int primary key auto_increment,email varchar(255),password varchar(255)); 每个用户的email是唯一的,如果用户使用email作为用户名登陆的话,就需要查询出email对应的一条记录. SELECT * FROM t_user WHERE ema

避免全表扫描的sql优化

对查询进行优化,应尽量避免全表扫描,首先应考虑在where 及order by 涉及的列上建立索引:  .尝试下面的技巧以避免优化器错选了表扫描: ·   使用ANALYZE TABLE tbl_name为扫描的表更新关键字分布. ·   对扫描的表使用FORCE INDEX告知MySQL,相对于使用给定的索引表扫描将非常耗时.            SELECT * FROM t1, t2 FORCE INDEX (index_for_column)             WHERE t1.

【大数据课堂0008】会引起全表扫描的几种SQL 以及sql优化

查询语句的时候尽量避免全表扫描,使用全扫描,索引扫描!会引起全表扫描的几种SQL如下 1.模糊查询效率很低: 原因:like本身效率就比较低,应该尽量避免查询条件使用like:对于like ‘%...%’(全模糊)这样的条件,是无法使用索引的,全表扫描自然效率很低:另外,由于匹配算法的关系,模糊查询的字段长度越大,模糊查询效率越低. 解决办法:首先尽量避免模糊查询,如果因为业务需要一定要使用模糊查询,则至少保证不要使用全模糊查询,对于右模糊查询,即like ‘…%’,是会使用索引的:左模糊lik

项目owner看这里,MaxCompute全表扫描新功能,给你“失误”的机会

摘要: MaxCompute发布了"ALIAS 命令",提供了在不修改代码的前提下,在MapReduce或自定义函数(UDF) 代码中,通过某个固定的资源名读取不同资源(数据)的需求. 随着社会数据收集手段的不断丰富及完善,越来越多的行业数据被积累下来.数据规模已经增长到了传统软件行业无法承载的海量数据,达到百GB.TB乃至PB级别. 在分析海量数据场景下,由于单台服务器的处理能力限制,数据分析者通常采用分布式计算模式.但分布式的计算模型对数据分析人员提出了较高的要求,且不易维护.使用

oracle在组合索引上,只使用部分列进行查询(查询时必须包含前导列,否则会走全表扫描)

实验环境:Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production 1.创建表插入数据 SQL> create table txtx(id int,name char(2),tx char(3),id1 int,primary key(id,name,tx)); 表已创建. SQL> insert into txtx values(1,'tx','tx',1); 已创建 1 行. SQL> i

执行计划-数据访问方式(全表扫描与4种索引的方式)

执行计划 Oracle执行计划的相关概念: Rowid:系统给oracle数据的每行附加的一个伪列,包含数据表名称,数据库id,存储数据库id以及一个流水号等信息,rowid在行的生命周期内唯一. Recursive sql:为了执行用户语句,系统附加执行的额外操作语句,譬如对数据字典的维护等. Row source(行源):oracle执行步骤过程中,由上一个操作返回的符合条件的行的集合. Predicate(谓词):where后的限制条件. Driving table(驱动表):又称为连接的