weixin_33851177
weixin_33851177

为什么PostgreSQL比MongoDB还快？

PostgreSQL9.4带来了全新的NoSQL特性，并且根据EnterpriseDB的测试，其加载，插入和查询的性能都已经几倍于MongoDB了。
虽然我是PG的铁杆粉丝，但是关系数据库背负了ACID的重型装甲，在性能上居然能打败轻装上阵的NoSQL数据库总觉得有点离谱。
所以我在自己的环境里验证了一下EnterpriseDB的测试结果，并且小探一下PG取胜的原因。

1. EnterpriseDB的测试结果

以下是EnterpriseDB的测试结果(数据量为5000万)
http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality
为什么PostgreSQL比MongoDB还快？_第1张图片
（还可以参考这篇译文： http://blog.jobbole.com/78215/）

2. 我的验证结果

测试观点
为了使测试结果更加单纯，我准备单纯比拼CPU消耗(尽量排除IO和网络的干扰)，设定以下测试条件。
1）所有数据都要放进内存
 2）C/S都跑在同一台 单机上
所以，只在单机上进行10万条小数据量的测试。
注）EnterpriseDB的测试环境是32G内存的Amazon Web Services M3.2XLARGE实例，总数据量超过内存了。
测试环境
测试环境为个人PC上的VMware虚拟机
PC
 CPU:Intel Core i5-3470 3.2G(4核)
 MEM:6GB
 SSD:OCZ-VERTEX4 128GB(VMware虚拟机所在磁盘，非系统盘)
 OS:Win7

VMware虚拟机
 CPU:4核
 MEM:1GB
 OS:CentOS 6.5
 PG:PostgreSQL 9.4.0(shared_buffers = 428MB,其他是默认值)
 MG: MongoDB  3.0.2

测试步骤
测试步骤非常简单,可以参考：
https://github.com/EnterpriseDB/pg_nosql_benchmark

但是，在测试前，有些东西要改。
1)把数据量减小到10万
pg_nosql_benchmark-master/pg_nosql_benchmark:
declare -a json_rows=(10000000)
==>
declare -a json_rows=(100000)

2)修改 mongo的 一处脚本(注)
pg_nosql_benchmark-master/lib/mongo_func_lib.sh:
   collectionsize="$(echo ${output}|awk -F"," '{print $5}'|cut -d":" -f2)"
==>
   collectionsize="$(echo ${output}|awk -F"," '{print $ 6}'|cut -d":" -f2)"

注 ) pg_nosql_benchmark原来是基于 MongoDB  2.6设计的，MongoDB 3.0的db.json_tables.stats()输出可能变了，所以这边要修改一下。

测试结果

点击(此处)折叠或打开

  1. -bash-4.1$ sh pg_nosql_benchmark
  2. PID: 2160 [RUNTIME: 04-12-15 08:15:51] pg_nosql_benchmark: MongoDB Version 3.0.2
  3. PID: 2160 [RUNTIME: 04-12-15 08:15:51] pg_nosql_benchmark: PostgreSQL Version 9.4.0
  4. PID: 2160 [RUNTIME: 04-12-15 08:15:51] pg_nosql_benchmark: creating json data.
  5. PID: 2160 [RUNTIME: 04-12-15 08:17:18] pg_nosql_benchmark: preparing postgresql INSERTs.
  6. PID: 2160 [RUNTIME: 04-12-15 08:19:02] pg_nosql_benchmark: preparing mongo insert commands.
  7. PID: 2160 [RUNTIME: 04-12-15 08:20:45] pg_nosql_benchmark: droping database benchmark if exists.
  8. PID: 2160 [RUNTIME: 04-12-15 08:20:45] pg_nosql_benchmark: creating database benchmark.
  9. PID: 2160 [RUNTIME: 04-12-15 08:20:46] pg_nosql_benchmark: dropping mongo collection json_tables
  10. PID: 2160 [RUNTIME: 04-12-15 08:20:46] pg_nosql_benchmark: creating json_tables collection in postgreSQL.
  11. PID: 2160 [RUNTIME: 04-12-15 08:20:46] pg_nosql_benchmark: loading data in postgresql using sample.json.
  12. PID: 2160 [RUNTIME: 04-12-15 08:20:57] pg_nosql_benchmark: creating index on postgreSQL collections.
  13. PID: 2160 [RUNTIME: 04-12-15 08:21:00] pg_nosql_benchmark: testing mongoimport.
  14. PID: 2160 [RUNTIME: 04-12-15 08:21:14] pg_nosql_benchmark: creating index in mongodb.
  15. PID: 2160 [RUNTIME: 04-12-15 08:21:19] pg_nosql_benchmark: testing FIRST SELECT in postgresql.
  16. PID: 2160 [RUNTIME: 04-12-15 08:21:21] pg_nosql_benchmark: testing SECOND SELECT in postgresql.
  17. PID: 2160 [RUNTIME: 04-12-15 08:21:22] pg_nosql_benchmark: testing THIRD SELECT in postgresql.
  18. PID: 2160 [RUNTIME: 04-12-15 08:21:22] pg_nosql_benchmark: testing FOURTH SELECT in postgresql.
  19. PID: 2160 [RUNTIME: 04-12-15 08:21:23] pg_nosql_benchmark: calculating PostgreSQL collection size.
  20. PID: 2160 [RUNTIME: 04-12-15 08:21:23] pg_nosql_benchmark: testing mongo FIRST SELECT.
  21. PID: 2160 [RUNTIME: 04-12-15 08:21:27] pg_nosql_benchmark: testing mongo SECOND SELECT.
  22. PID: 2160 [RUNTIME: 04-12-15 08:21:27] pg_nosql_benchmark: testing mongo THIRD SELECT.
  23. PID: 2160 [RUNTIME: 04-12-15 08:21:30] pg_nosql_benchmark: testing mongo FOURTH SELECT.
  24. PID: 2160 [RUNTIME: 04-12-15 08:21:33] pg_nosql_benchmark: calculating the size of mongo collection.
  25. PID: 2160 [RUNTIME: 04-12-15 08:21:34] pg_nosql_benchmark: dropping mongo collection json_tables
  26. PID: 2160 [RUNTIME: 04-12-15 08:21:34] pg_nosql_benchmark: testing inserts in mongo
  27. PID: 2160 [RUNTIME: 04-12-15 08:23:00] pg_nosql_benchmark: droping json object in postgresql.
  28. PID: 2160 [RUNTIME: 04-12-15 08:23:00] pg_nosql_benchmark: inserting data in postgresql using sample_pg_inserts.json.
  29. number of rows 100000
  30. PG COPY (ns) 10886811763
  31. PG INSERT (ns) 22173081221
  32. PG SELECT (ns) 1018231815
  33. PG SIZE (bytes) 148946944
  34. MONGO IMPORT (ns) 13880183843
  35. MONGO INSERT (ns) 86577229486
  36. MONGO SELECT (ns) 2669842035
  37. MONGO SIZE (bytes) 429092864
除了数据加载的性能差距不明显外，其它数据基本和 EnterpriseDB的测试结果一致（MongoDB的 插入时间是PG的4倍，查询时间是PG的2倍多）。

3.  PostgreSQL真的比MongoDB还快吗

下面模仿 EnterpriseDB的测试方法，单独进行每一项测试。

3.1 测试数据

修改测试脚本后再次执行，将加载和插入的数据文件保留下来。
pg_nosql_benchmark:

点击(此处)折叠或打开

  1. rm -rf ${SAMPLEJSON}*
  2. rm -rf ${PG_INSERTS}
  3. rm -rf ${MONGO_INSERTS}
==>

点击(此处)折叠或打开

  1. #rm -rf ${SAMPLEJSON}*
  2. #rm -rf ${PG_INSERTS}
  3. #rm -rf ${MONGO_INSERTS}

查看一下数据
点击( 此处 )折叠或打开
  1. -bash-4.1$ head -1 sample.json
  2. { "name" : "AC33929 Phone", "brand" : "ACME1415", "type" : "phone", "price" : 200, "warranty_years" : 1, "available" : true, "description": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin eget elit ut nulla tempor viverra vel eu nulla. Sed luctus porttitor urna, ac dapibus velit fringilla et. Donec iaculis, dolor a vehicula dictum, augue neque suscipit augue, nec mollis massa neque in libero. Donec sed dapibus magna. Pellentesque at condimentum dolor. In nunc nibh, dignissim in risus a, blandit tincidunt velit. Vestibulum rutrum tempus sem eget tempus. Mauris sollicitudin purus auctor dolor vestibulum, vitae pulvinar neque suscipit. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Phasellus lacus turpis, vulputate at adipiscing viverra, ultricies at lectus. Pellentesque ut porta leo, vel eleifend neque. Nunc sagittis metus at ante pellentesque, ut condimentum libero semper. In hac habitasse platea dictumst. In dapibus posuere posuere. Fusce vulputate augue eget tellus molestie, vitae egestas ante malesuada. Phasellus nunc mi, faucibus at elementum pharetra, aliquet a enim. In purus est, vulputate in nibh quis, faucibus dapibus magna. In accumsan libero velit, eu accumsan sem commodo id. In fringilla tempor augue, et feugiat erat convallis et. Sed aliquet eget ipsum eu vestibulum.Curabitur blandit leo nec condimentum semper. Mauris lectus sapien, rutrum a tincidunt id, euismod ac elit. Mauris suscipit et arcu et auctor. Quisque mollis magna vel mi viverra rutrum. Nulla non pretium magna. Cras sed tortor non tellus rutrum gravida eu at odio. Aliquam cursus fermentum erat, nec ullamcorper sem gravida sit amet. Donec viverra, erat vel ornare pulvinar, est ipsum accumsan massa, eu tristique lorem ante nec tortor. Sed suscipit iaculis faucibus. Maecenas a suscipit ligula, vitae faucibus turpis.Cras sed tellus auctor, tempor leo eu, molestie leo. Suspendisse ipsum tellus, egestas et ultricies eu, tempus a arcu. Cras laoreet, est dapibus consequat varius, nisi nisi placerat leo, et dictum ante tortor vitae est. Duis eu urna ac felis ullamcorper rutrum. Quisque iaculis, enim eget sodales vehicula, magna orci dignissim eros, nec volutpat massa urna in elit. In interdum pellentesque risus, feugiat pulvinar odio eleifend sit amet. Quisque congue libero quis dolor faucibus, a mollis nisl tempus." }

查看 数据的总大小，10万条记录共253MB。
点击( 此处 )折叠或打开
  1. -bash-4.1$ ls -l *.json
  2. -rw-r--r-- 1 postgres postgres 264993924 Apr 12 08:17 sample.json
  3. -rw-r--r-- 1 postgres postgres 267493911 Apr 12 08:20 sample_mongo_inserts.json
  4. -rw-r--r-- 1 postgres postgres 269493962 Apr 12 08:19 sample_pg_inserts.json

3.2 PostgreSQL测试

1）清理旧数据

点击(此处)折叠或打开

  1. benchmark=# drop table json_tables;
  2. DROP TABLE
  3. benchmark=# create table json_tables(data jsonb);
  4. CREATE TABLE

2）加载数据

点击(此处)折叠或打开

  1. -bash-4.1$ cat sample.json |time -p psql benchmark -c "copy json_tables from stdin;"
  2. real 10.00
  3. user 0.00
  4. sys 0.35

执行测试期间的系统负载

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
  2. top - 09:12:31 up 1 day, 12:12,  5 users,  load average: 0.15, 0.03, 0.01
  3. Tasks: 160 total,   2 running, 158 sleeping,   0 stopped,   0 zombie
    Cpu(s): 14.3%us, 13.3%sy,  0.0%ni, 70.0%id,  1.9%wa,  0.1%hi,  0.4%si,  0.0%st
    Mem:   1019320k total,   942632k used,    76688k free,     9768k buffers
    Swap:  2064376k total,    80232k used,  1984144k free,   840444k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                  
    30622 postgres  20   0  588m  34m  32m R 93.4  3.5   0:08.00 postgres                                                                  
    30619 postgres  20   0 98.6m  568  464 S 13.3  0.1   0:00.99 cat                                                                        
    17197 postgres  20   0  587m 212m 211m S 10.3 21.3   0:05.91 postgres                                                                  
    17199 postgres  20   0  586m  14m  13m S  5.0  1.4   0:03.26 postgres                                                                  
    30621 postgres  20   0  167m 2496 1984 S  3.3  0.2   0:00.30 psql                                                                      
      22 root      20   0     0    0    0 S  0.3  0.0   1:13.42 events/3                                                                  
      35 root      20   0     0    0    0 S  0.3  0.0   0:01.84 kblock
注意红色的部分，postgres进程的CPU利用率接近了极限。

3） 建索引
点击( 此处 )折叠或打开
  1. -bash-4.1$ time -p psql benchmark -c "create index json_tables_idx on json_tables using gin(data);"
  2. CREATE INDEX
  3. real 2.71
  4. user 0.00
  5. sys 0.00

4）查看存储空间大小

点击(此处)折叠或打开

  1. benchmark=# select pg_relation_size('json_tables');
  2.  pg_relation_size
  3. ------------------
  4.         148946944
  5. (1 row)

  7. benchmark=# select pg_relation_size('json_tables_idx');
  8.  pg_relation_size
  9. ------------------
  10.          51134464
  11. (1 row)
PostgreSQL的jsonb存储优化还是不错的，表占了142MB，比原始数据（ 253MB）要小。

5）数据查询
点击( 此处 )折叠或打开
  1. -bash-4.1$ time psql -qAt benchmark -c "SELECT data FROM json_tables WHERE (data->>'brand') = 'ACME';" >/dev/null

  3. real    0m0.784s
  4. user    0m0.044s
  5. sys    0m0.032s

看看执行计划

点击(此处)折叠或打开

  1. benchmark=# explain (analyze,buffers) SELECT data FROM json_tables WHERE (data->>'brand') = 'ACME';
  2.                                                     QUERY PLAN
  3. -------------------------------------------------------------------------------------------------------------------
  4.  Seq Scan on json_tables (cost=0.00..19682.01 rows=500 width=1262) (actual time=0.192..486.710 rows=9091 loops=1)
  5.    Filter: ((data ->> 'brand'::text) = 'ACME'::text)
  6.    Rows Removed by Filter: 90910
  7.    Buffers: shared hit=2304 read=15878
  8.  Planning time: 0.645 ms
  9.  Execution time: 487.951 ms
  10. (6 rows)

居然是顺序扫描！GIN索引是吃干饭的吗？
仔细一看，原来 EnterpriseDB的测试SQL里把操作符写错了，无法使用GIN索引（想不到PG大牛出没的 EnterpriseDB也会犯这么低级的错误）。下面改下SQL让GIN上场。

点击(此处)折叠或打开

  1. benchmark=# explain (analyze,buffers) SELECT data FROM json_tables WHERE data @> '{"brand":"ACME"}';
  2.                                                           QUERY PLAN
  3. ------------------------------------------------------------------------------------------------------------------------------
  4.  Bitmap Heap Scan on json_tables (cost=28.78..407.78 rows=100 width=1262) (actual time=3.612..47.001 rows=9091 loops=1)
  5.    Recheck Cond: (data @> '{"brand": "ACME"}'::jsonb)
  6.    Heap Blocks: exact=9091
  7.    Buffers: shared hit=9110
  8.    -> Bitmap Index Scan on json_tables_idx (cost=0.00..28.75 rows=100 width=0) (actual time=2.162..2.162 rows=9091 loops=1)
  9.          Index Cond: (data @> '{"brand": "ACME"}'::jsonb)
  10.          Buffers: shared hit=19
  11.  Planning time: 0.175 ms
  12.  Execution time: 47.690 ms
  13. (9 rows)
效果好了不少啊！

换到外面用psql测。
点击( 此处 )折叠或打开
  1. -bash-4.1$ time psql -qAt benchmark -c "SELECT data FROM json_tables WHERE data @> '{\"brand\":\"ACME\"}'" >/dev/null

  3. real    0m0.326s
  4. user    0m0.047s
  5. sys    0m0.031s

比以前有数据时快了1倍，但是没有explain (analyze,buffers) 快。原因也很简单，输出结果太多了， 9091条数据在客户端和服务端都要消耗不少资源，而explain (analyze,buffers) 只是简单的在服务端把结果丢弃。

为了排除 处理大量结果数据的干扰，换一个0匹配的查询再试试。
点击( 此处 )折叠或打开
  1. -bash-4.1$ time psql -qAt benchmark -c "SELECT data FROM json_tables WHERE data @> '{\"brand\":\"ACME111\"}'" >/dev/null

  3. real    0m0.015s
  4. user    0m0.005s
  5. sys    0m0.002s
15ms，简直神速啊！

再试试 0匹配的全表扫描。

点击(此处)折叠或打开

  1. -bash-4.1$ time psql -qAt benchmark -c "set enable_bitmapscan=false;SELECT data FROM json_tables WHERE data @> '{\"brand\":\"ACME111\"}'"

  3. real    0m0.594s
  4. user    0m0.002s
  5. sys    0m0.006s
全表扫描明显慢多了。

6）数据插入
先清数据

点击(此处)折叠或打开

  1. benchmark=# truncate json_tables;
  2. TRUNCATE TABLE

插入数据

点击(此处)折叠或打开

  1. -bash-4.1$ time -p psql -qAt benchmark --single-transaction -f sample_pg_inserts.json
  2. real 20.77
  3. user 1.23
  4. sys 2.80

插入期间的系统负载

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
    top - 09:58:31 up 1 day, 12:58,  5 users,  load average: 0.23, 0.05, 0.02
    Tasks: 161 total,   3 running, 158 sleeping,   0 stopped,   0 zombie
    Cpu(s): 17.0%us,  8.0%sy,  0.0%ni, 71.7%id,  3.0%wa,  0.0%hi,  0.3%si,  0.0%st
    Mem:   1019320k total,   936824k used,    82496k free,    11420k buffers
    Swap:  2064376k total,    80128k used,  1984248k free,   833644k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                  
    2891 postgres  20   0  587m 110m 109m R 74.5 11.1   0:07.45 postgres                                                                  
    2890 postgres  20   0  167m 2600 2044 R 19.6  0.3   0:01.87 psql                                                                      
    17197 postgres  20   0  587m 212m 211m S  3.3 21.3   0:06.55 postgres                                                                  
    17199 postgres  20   0  586m  14m  13m S  3.0  1.4   0:03.54 postgres                                                                  
    17198 postgres  20   0  586m 2648 2512 S  0.3  0.3   0:01.09 postgres                                                                  
    25933 root      20   0 15036 1088  804 R  0.3  0.1   3:01.30 top                                                                        
       1 root      20   0 19356  816  648 S  0.0  0.1   0:01.18 init      
postgres进程的CPU利用率达到74.5%。
postgres进程的 CPU利用率为什么还要空这么多？原因也很简单，客户端和服务端是串行处理的，在空闲的时间里，它在等psql。
那么把postgres的psql进程的CPU利用率加起来就是94.1%，确实可以判断达到CPU性能瓶颈了。

等一等！其实这个测试中PG作弊了。
既然是和MongoDB PK普通的插入操作，应该是一个SQL一个事务才对。修改后再测。

点击(此处)折叠或打开

  1. -bash-4.1$ time -p psql -qAt benchmark -f sample_pg_inserts.json
  2. real 43.64
  3. user 0.80
  4. sys 2.89

查看系统负载。

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
    top - 11:33:20 up 1 day, 14:33,  5 users,  load average: 0.22, 0.05, 0.02
    Tasks: 157 total,   2 running, 155 sleeping,   0 stopped,   0 zombie
    Cpu(s):  2.1%us, 14.1%sy,  0.0%ni, 71.7%id, 10.2%wa,  0.1%hi,  1.8%si,  0.0%st
    Mem:   1019320k total,   947744k used,    71576k free,     8044k buffers
    Swap:  2064376k total,    67764k used,  1996612k free,   846260k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND      
    12577 postgres  20   0  587m  89m  88m D 52.9  9.0   0:08.94 postgres      
    12576 postgres  20   0  167m 2596 2040 S  8.6  0.3   0:01.35 psql        
    12135 postgres  20   0  586m  48m  47m S  3.0  4.9   0:00.11 postgres      
      34 root      20   0     0    0    0 S  1.0  0.0   0:02.83 kblockd/0    
      36 root      20   0     0    0    0 S  0.3  0.0   0:02.63 kblockd/2    
      59 root      20   0     0    0    0 R  0.3  0.0   0:11.01 kswapd0      
这次 执行时间也长了1倍，postgres+psql进程的CPU也没用满，才61.5%。CPU的空闲那段时间应该是在等WAL被 刷到磁盘。
（由于这是单并发测试，不可避免会出现CPU空闲；但是在多并发的环境里，只要存储的吞吐和IOPS足够高，是完全可以把CPU撑满的。）

3.3 MongoDB

1）清理旧数据
点击( 此处 )折叠或打开
  1. > db.json_tables.drop()
  2. true

2）加载数据

点击(此处)折叠或打开

  1. -bash-4.1$ time -p mongoimport --type json --collection json_tables --db benchmark sample.json >/dev/null 2>/dev/null
  2. real 10.22
  3. user 7.44
  4. sys 5.15

加载期间的系统负载

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
    top - 10:15:50 up 1 day, 13:15,  5 users,  load average: 0.16, 0.03, 0.01
    Tasks: 152 total,   1 running, 151 sleeping,   0 stopped,   0 zombie
    Cpu(s): 17.4%us, 18.7%sy,  0.0%ni, 57.8%id,  5.3%wa,  0.2%hi,  0.5%si,  0.0%st
    Mem:   1019320k total,   895156k used,   124164k free,     1532k buffers
    Swap:  2064376k total,    65560k used,  1998816k free,   428380k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                  
    4673 postgres  20   0  694m 222m 3436 S 89.8 22.4   0:05.53 mongoimport                                                                
    4015 postgres  20   0 2771m 290m 142m S 49.5 29.2   0:04.29 mongod                                                                    
值得注意的是系统的瓶颈在mongoimport 进程，而不是mongod进程 ， mongod还有一半的余力。
（数据加载时，执行的单条语句，大量数据，所以 mongoimport 和mongod进程不是串行而是并行执行的关系）

 3）建索引

点击(此处)折叠或打开

  1. -bash-4.1$ echo "db.json_tables.ensureIndex( { \"name\": 1})" |time -p mongo benchmark >/dev/null
  2. real 1.35
  3. user 0.03
  4. sys 0.02
  5. -bash-4.1$ echo "db.json_tables.ensureIndex( { \"type\": 1})" |time -p mongo benchmark >/dev/null
  6. real 0.58
  7. user 0.07
  8. sys 0.01
  9. -bash-4.1$ echo "db.json_tables.ensureIndex( { \"brand\": 1})" |time -p mongo benchmark >/dev/null
  10. real 0.50
  11. user 0.03
  12. sys 0.01
MongoDB建的是btree索引，json中的每个常用的查询属性都要建1个，万一漏了就只能全集合扫描了（在一个无模式的数据模型里却需要建有模式的索引，不是有点讽刺吗？） 。而PostgreSQL的GIN索引确是对整个json建的索引。这样一比较，PostgreSQL的GIN索引简直太牛了（不光 MongoDB，其它数据库也难有能和PG的扩展索引（GIN，GiST，SP-GiST）匹敌的东西吧？）。

4）查看存储空间大小

点击(此处)折叠或打开

  1. > db.json_tables.stats()
  2. {
  3.     "ns" : "benchmark.json_tables",
  4.     "count" : 100001,
  5.     "size" : 419640560,
  6.     "avgObjSize" : 4196,
  7.     "numExtents" : 16,
  8.     "storageSize" : 429092864,
  9.     "lastExtentSize" : 114012160,
  10.     "paddingFactor" : 1,
  11.     "paddingFactorNote" : "paddingFactor is unused and unmaintained in 3.0. It remains hard coded to 1.0 for compatibility only.",
  12.     "userFlags" : 1,
  13.     "capped" : false,
  14.     "nindexes" : 4,
  15.     "totalIndexSize" : 12452048,
  16.     "indexSizes" : {
  17.         "_id_" : 3262224,
  18.         "name_1" : 3899952,
  19.         "type_1" : 3442096,
  20.         "brand_1" : 1847776
  21.     },
  22.     "ok" : 1
  23. }
MongoDB的json存储 比原始数据（ 253MB ）稍微大一点，409MB。但是这个409MB是包含预先分配了但还没有使用的空间的，不考虑这部分空间则占了400MB（MongoDB每次扩张的空间量会越来越大，所以有时候单看storageSize不是很精确）。

5）数据查询
 点击( 此处 )折叠或打开
  1. -bash-4.1$ echo "DBQuery.shellBatchSize = 10000000000;db.json_tables.find({ brand: 'ACME'})"|time -p mongo benchmark >/dev/null
  2. real 3.62
  3. user 3.53
  4. sys 0.09
查询时间确实长了，比PG慢太多。

但是，不要急，看看资源占用。

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
    top - 10:55:46 up 1 day, 13:55,  5 users,  load average: 0.13, 0.04, 0.01
    Tasks: 152 total,   2 running, 150 sleeping,   0 stopped,   0 zombie
    Cpu(s): 24.7%us,  0.4%sy,  0.0%ni, 74.8%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
    Mem:   1019320k total,   935684k used,    83636k free,     1464k buffers
    Swap:  2064376k total,    66976k used,  1997400k free,   615840k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                  
    8773 postgres  20   0  752m  67m 9052 R 100.4  6.8   0:03.20 mongo                                                                    
    4015 postgres  20   0 2803m 830m 663m S  0.7 83.4   0:26.46 mongod                                                                    
    1424 root      -2   0 85108 1448 1256 S  0.3  0.1   0:19.60 lrmd                                                                      
    1425 hacluste  -2   0 89600 1496 1208 S  0.3  0.1   0:25.34 attrd                                                                      
    25911 root      20   0 98.0m 1104  972 S  0.3  0.1   0:40.12 sshd                                                                      
       1 root      20   0 19356  812  660 S  0.0  0.1   0:01.19 init          
看到没，时间都耗在客户端的mongo进程上。因为客户端在处理大量输出结果时消耗了太多的资源。
其实，执行psql时如果不加“-A”选项也会有类似的问题。

点击(此处)折叠或打开

  1. -bash-4.1$ time psql -qt -p 5433 benchmark -c "SELECT data FROM json_tables WHERE (data->>'brand') = 'ACME';" >/dev/null

  3. real    0m2.124s
  4. user    0m1.401s
  5. sys    0m0.066s

这说明什么？说明之前的查询测试结果根本就是误导嘛！（这就好比两个绝顶高手决斗的时候，比拼的却是谁的小弟递枪的速度快。）
为了排除大量数据处理的误导，下面执行一下0匹配的查询。

点击(此处)折叠或打开

  1. -bash-4.1$ echo "DBQuery.shellBatchSize = 10000000000;db.json_tables.find({ brand: 'ACME111'})"|time -p mongo benchmark >/dev/null
  2. real 0.06
  3. user 0.03
  4. sys 0.01
现在快多了。但是比起PostgreSQL执行相同查询的0.015s还是慢了很多。

再试试0匹配的全表扫描。

点击(此处)折叠或打开

  1. -bash-4.1$ echo "db.json_tables.dropIndexes()"|mongo benchmark
  2. MongoDB shell version: 3.0.2
  3. connecting to: benchmark
  4. {
  5.     "nIndexesWas" : 4,
  6.     "msg" : "non-_id indexes dropped for collection",
  7.     "ok" : 1
  8. }
  9. -bash-4.1$ echo "DBQuery.shellBatchSize = 10000000000;db.json_tables.find({ brand: 'ACME111'})"|time -p mongo benchmark >/dev/null
  10. real 0.24
  11. user 0.03
  12. sys 0.02
MongoDB的全表扫描比PostgreSQL快， PostgreSQL在相同条件下的执行时间是0.594s 。

6）数据插入
先清数据

点击(此处)折叠或打开

  1. -bash-4.1$ echo "db.json_tables.drop()"|mongo benchmark
  2. MongoDB shell version: 3.0.2
  3. connecting to: benchmark
  4. true
  5. bye

插入数据

点击(此处)折叠或打开

  1. -bash-4.1$ time mongo benchmark --quiet sample_mongo_inserts.json >/dev/null

  3. real    1m27.591s
  4. user    0m29.663s
  5. sys    0m48.646s
MongoDB的插入确实挺慢的。
而且如果查看输出的话，还会发现一堆错误，这是由于MongoDB的控制台不允许插入大于4k的文档。

点击(此处)折叠或打开

  1. 2015-04-12T11:19:08.680+0800 E QUERY SyntaxError: Unexpected token ILLEGAL
  2. 2015-04-12T11:19:08.681+0800 E QUERY SyntaxError: Unexpected identifier
  3. WriteResult({ "nInserted" : 1 })
  4. WriteResult({ "nInserted" : 1 })
  5. WriteResult({ "nInserted" : 1 })

下面看看插入时的系统负载

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
    top - 11:20:26 up 1 day, 14:20,  5 users,  load average: 0.00, 0.00, 0.00
    Tasks: 151 total,   2 running, 149 sleeping,   0 stopped,   0 zombie
    Cpu(s):  3.3%us,  1.9%sy,  0.0%ni, 71.1%id,  4.9%wa,  0.0%hi, 18.7%si,  0.0%st
    Mem:   1019320k total,   948452k used,    70868k free,     4076k buffers
    Swap:  2064376k total,    68296k used,  1996080k free,   632796k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    11269 postgres  20   0  753m  66m 9224 R 89.6  6.7   0:15.23 mongo  
    4015 postgres  20   0 2803m 534m 371m S 22.6 53.7   0:38.06 mongod
根据 系统负载，性能瓶颈还是客户端mongo进程。如果要把mongod的负载压满， MongoDB的性能还可以提升4倍。

4. 总结

测试数据总结如下（并根据服务端进程CPU的消耗量进行性能对比）：
PostgreSQL MongoDB PK结果
测试数据 服务端进程
CPU利用率 		服务端进程
CPU占用时间 		测试数据 服务端进程
CPU利用率 		服务端进程
CPU占用时间
Data Load（s) 10 93.40% 9.34 10.22 49.50% 5.06 MongoDB胜出(*1)
Insert(s) 20.77 74.50% 15.47 - - - 不具可比性
每SQL事务Insert(s) 43.64 52.90% 23.09 87.591 22.60% 19.80 MongoDB胜出
全表扫描Select(s) 0.784 - - - - - 不具可比性
Select(s) 0.326 - - 3.62 0.70% 0.03 不具可比性
0匹配Select(s) 0.015 - - 0.06 - - PostgreSQL胜出
0匹配全表扫描Select(s) 0.594 - - 0.24 - - 不具可比性
Size(MB) 142 - - 409 - - PostgreSQL胜出
索引Size(MB) 49 - - 9(*2) - - 不具可比性
*1)考虑到数据加载经常是单线程操作，不能完全无视mongoimport的瓶颈，这一局应该算是平手。
*2)3个索引的总Size(MB)

这个结果和 EnterpriseDB的测试结果有很大出入。
1)数据加载
 从服务端资源消耗的角度看，是 MongoDB的性能是 PostgreSQL的2倍。但是如果数据加载不能很好的并发展开，让mongoimport成为了瓶颈，那应该算打平。
 另外， EnterpriseDB的 数据加载的测试结果和我的结果差异比较大，可能是因为EnterpriseDB的测试中，数据量超过了系统内存量，IO对测试结果的影响开始显现。

2)数据插入
  从 服务端 资源消耗 的角度看，两者其实相差不大。EnterpriseDB的测试结果被mongo客户端的性能瓶颈绑架了。
3)数据查询
 对无匹配数据(或少量匹配数据)的索引查询， PostgreSQL的性能是MongoDB的4倍(这一点也有点令人不解，同样是走索引的单点查询，为什么差距就这么大呢？)。
 虽然EnterpriseDB的测试结果也表明PostgreSQL的性能是MongoDB 4倍左右，但EnterpriseDB的测试方法是有问题的。

4)数据大小
  MongoDB的数据大小大约是 PostgreSQL的3倍，这和 EnterpriseDB的测试结果是一致的。
PostgreSQL在NoSQL方面的表现确实抢眼。 PostgreSQL不仅是SQL+NoSQL+ACID的完美组合，性能还比 MongoDB技高一筹（分布式集群上MongoDB更有优势）。

6. 参考

http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/edb-makes-open-call-postgres-nosql-performance-benchmarks
http://blog.163.com/digoal@126/blog/static/16387704020151443228780/
http://blog.163.com/digoal@126/blog/static/16387704020151435825593/
http://blog.163.com/digoal@126/blog/static/1638770402015142858224/
http://www.cnblogs.com/lovecindywang/archive/2011/03/02/1969324.html











你可能感兴趣的:(为什么PostgreSQL比MongoDB还快？)

  • 随笔 | 仙一般的灵气 海思沧海
    仙岛今天，我看了你全部，似乎已经进入你的世界我不知道，这是否是梦幻，还是你仙一般的灵气吸引了我也许每一个人都要有一份属于自己的追求，这样才能够符合人生的梦想，生活才能够充满着阳光与快乐我不知道，我为什么会这样的感叹，是在感叹自己的人生，还是感叹自己一直没有孜孜不倦的追求只感觉虚度了光阴，每天活在自己的梦中，活在一个不真实的世界是在逃避自己，还是在逃避周围的一切有时候我嘲笑自己，嘲笑自己如此的虚无，
  • C语言宏函数 南林yan C语言c语言
    一、什么是宏函数？通过宏定义的函数是宏函数。如下，编译器在预处理阶段会将Add(x,y)替换为((x)*(y))#defineAdd(x,y)((x)*(y))#defineAdd(x,y)((x)*(y))intmain(){inta=10;intb=20;intd=10;intc=Add(a+d,b)*2;cout<
  • 地推话术，如何应对地推过程中家长的拒绝 校师学
    相信校长们在做地推的时候经常遇到这种情况：市场专员反馈家长不接单，咨询师反馈难以邀约这些家长上门，校区地推疲软，招生难。为什么？仅从地推层面分析，一方面因为家长受到的信息轰炸越来越多，对信息越来越“免疫”；而另一方面地推人员的专业能力和营销话术没有提高，无法应对家长的拒绝，对有意向的家长也不知如何跟进，眼睁睁看着家长走远；对于家长的疑问，更不知道如何有技巧地回答，机会白白流失。由于回答没技巧和专业
  • 小丽成长记（四十三） 玲玲54321
    小丽发现，即使她好不容易调整好自己的心态下一秒总会有不确定的伤脑筋的事出现，一个接一个的问题，人生就没有停下的时候，小问题不断出现。不过她今天看的书，她接受了人生就是不确定的，厉害的人就是不断创造确定性，在Ta的领域比别人多的确定性就能让自己脱颖而出，显示价值从而获得的比别人多的利益。正是这样的原因，因为从前修炼自己太少，使得她现在在人生道路上打怪起来困难重重，她似乎永远摆脱不了那种无力感，有种习
  • 30天风格练习-DAY2 黄希夷
    Day2（重义）在一个周日/一周的最后一天，我来到位于市中心/市区繁华地带的一家购物中心/商场，中心内人很多/熙熙攘攘。我注意到/看见一个独行/孤身一人的年轻女孩/，留着一头引人注目/长过腰际的头发，上身穿一件暗红色/比正红色更深的衣服/穿在身体上的东西。走下扶梯的时候，她摔倒了/跌向地面，在她正要站起来/让身体离开地面的时候，过长/超过一般人长度的头发被支撑身体/躯干的手掌压/按在下面，她赶紧用
  • 18-115 一切思考不能有效转化为行动，都TM是扯淡！ 成长时间线
    7月25号写了一篇关于为什么会断更如此严重的反思，然而，之后日更仅仅维持了一周，又出现了这次更严重的现象。从8月2号到昨天8月6号，5天！又是5天没有更文！虽然这次断更时间和上次一样，那为什么说这次更严重？因为上次之后就分析了问题的原因，以及应该如何解决，按理说应该会好转，然而，没过几天严重断更的现象再次出现，想想，经过反思，问题依然没有解决与改变，这让我有些担忧。到底是哪里出了问题，难道我就真的
  • 398顺境，逆境 戴骁勇
    2018.11.27周二雾霾最近儿子进入了一段顺境期，今天表现尤其不错。今天的数学测试成绩喜人，没有出现以往的计算错误，整个卷面书写工整，附加题也在规定时间内完成且做对。为迎接体育测试的锻炼有了质的飞跃。坐位体前屈成绩突飞猛进，估测成绩能达到12cm，这和上次测试的零分来比，简直是逆袭。儿子还在不断锻炼和提升，唯恐到时候掉链子。跑步姿势在我的调教下，逐渐正规起来，速度随之也有了提升。今晚测试的50
  • 有舍才有得 _清净_
    为什么经常讲放下？放下就是让你要舍得、舍去。喜舍心就是把自己喜欢的，用慈悲心喜舍出去。这就锻炼了你们在人间，学会放下原本不舍得的东西或一些事物，学会舍出去，学会帮助别人，学会多付出。你今天付出了慈悲心、喜舍心，以后会得到更多的缘助力。缘助力是什么？——贵人缘啊。今天没有付出，不懂得付出，什么都只会想到自己，那你也得不到缘助力。慈悲喜舍就是用慈悲心去帮助别人，用喜舍心去付出，最后也会得到别人回报。别
  • MongoDB Oplog 窗口 喝醉酒的小白 MongoDB运维
    在MongoDB中，oplog（操作日志）是一个特殊的日志系统，用于记录对数据库的所有写操作。oplog允许副本集成员（通常是从节点）应用主节点上已经执行的操作，从而保持数据的一致性。它是MongoDB副本集实现数据复制的基础。MongoDBOplog窗口oplog窗口是指在MongoDB副本集中，从节点可以用来同步数据的时间范围。这个窗口通常由以下因素决定：Oplog大小：oplog的大小是有限
  • node.js学习 小猿L node.jsnode.js学习vim
    node.js学习实操及笔记温故node.js，node.js学习实操过程及笔记~node.js学习视频node.js官网node.js中文网实操笔记githubcsdn笔记为什么学node.js可以让别人访问我们编写的网页为后续的框架学习打下基础，三大框架vuereactangular离不开node.jsnode.js是什么官网：node.js是一个开源的、跨平台的运行JavaScript的运行
  • 如何成为段子手 欣雅阅读
    我是一个尬聊大师，与朋友聊天经常把话题聊死，留我一个人在群里，望着自己打下的最后一句话无语凝噎。看到风趣幽默的朋友与人聊天，很是艳羡，觉得自己何时才能成为这样的段子手呢？一、段子是什么？“段子”一词在百度百科上的解释：本是相声中的一个艺术术语，指的是相声作品中一节或一段艺术内容。我的理解：段子就是一些搞笑的故事或者笑话。二、为什么要会说段子？不知道大家有没有这样的朋友，本来很无趣的聚会，只要有他参
  • Low Power概念介绍-Voltage Area 飞奔的大虎
    随着智能手机，以及物联网的普及，芯片功耗的问题最近几年得到了越来越多的重视。为了实现集成电路的低功耗设计目标，我们需要在系统设计阶段就采用低功耗设计的方案。而且，随着设计流程的逐步推进，到了芯片后端设计阶段，降低芯片功耗的方法已经很少了，节省的功耗百分比也不断下降。芯片的功耗主要由静态功耗（staticleakagepower）和动态功耗(dynamicpower)构成。静态功耗主要是指电路处于等
  • 2019-05-13 王健_100a
    【撒下18:2】大卫打发军兵出战，分为三队：一队在约押手下，一队在洗鲁雅的儿子约押兄弟亚比筛手下，一队在迦特人以太手下。大卫对军兵说：“我必与你们一同出战。”解释：大卫检阅部队，将它分成三队，每队由一位元帅统领；约押与兄弟亚比筛，并迦特人以太共同指挥。大卫想与他们一同出战！应用：作为领袖与军兵一起出战是很重要。领袖在事奉中与信徒一起，领袖在任何的环境里与信徒一起走过。我们要同心协力为主而战。祷告：
  • 想家，想念家乡的四季 三妹杨敏
    不知道，为什么，这次我回自己出生地—老家，反倒有了一种出差走亲戚的感觉。人啊，出来得久了，就生分了。就不再那么心贴着心脸对着脸了。需要时间，需要机缘，需要我们再重新把自己的思维重置一遍，你才能够转得回这个弯儿的。最好的转弯儿，不是说教，也不是余旧，都有些治标不治本。真正管用的东西，只有一样。也简单。一个字：吃。吃一顿家乡的饭，喝一口家乡的水，听一听那浓重得有些陌生的乡音，心就回来了。心回来，人才算
  • 一个历史事件和查理一世走上断头台有很大关系，这个事件是什么？ 王老师聊围棋
    今天我要讲的历史事件，查理一世被处死的始末。其实查理一世给被处死的时候，与一个事件有很大的联系。这个事件是“普莱德清洗”。提到这个事件，我们不得不提到一个人，这个人就是克伦威尔。可以说，查理一世能够走上断头台，克伦威尔有很大的功劳。为什么这么说呢。那我们就成英国内战的终结说起吧。我们都知道英国的内战是有保王党挑起来。在保王党军队一路凯歌进攻的同时。就在1645年6月14日，在纳西比荒原上进行最后的
  • 福袋生活邀请码在哪里填写，福袋生活app邀请码使用教程 小小编007
    很多人下载福袋生活后，注册使用时需要填写邀请码。因为福袋生活是注册邀请制，所以首次使用填写邀请码才可以正常登录使用。福袋生活是广州市福袋生活信息科技有限公司旗下一家多元化社交电商导购平台，以APP为载体，社群为媒介，汇集衣食住行、吃喝玩乐生活服务板块，使用福袋生活可以领到淘宝，拼多多等电商平台的商品优惠券和返利，还可以兼职去分享赚钱。我为什么从福袋生活转到果冻宝盒呢？当然是因为福袋生活返利更高，注
  • 《大兴安岭猎人传说》今年最好看的东北鬼怪故事，很优秀 一部电影
    《大兴安岭猎人传说》是最新上映于愚人节的网剧，别看是网剧却远超出我的个人预料。该片由民俗故事改编，这点就很吸引人，因为民俗故事口口相传，比那些编造而成的鬼故事更具有了真实性，网大做的电影还不错哦，如果可以我打四星好评。大兴安岭的故事我们经常听老人提起，那里有原始大森林，物产丰富，更流传着精灵怪物的传说。什么红黄白柳灰，出马仙、人参娃娃的故事层出不穷，以大兴安岭为背景的故事真不少。可很多鬼片看到最后
  • 数字里的世界17期：2021年全球10大顶级数据中心，中国移动榜首 张三叨
    你知道吗？2016年，全球的数据中心共计用电4160亿千瓦时，比整个英国的发电量还多40％！前言每天，我们都会创造超过250万TB的数据。并且随着物联网（IOT）的不断普及，这一数据将持续增长。如此庞大的数据被存储在被称为“数据中心”的专用设施中。虽然最早的数据中心建于20世纪40年代，但直到1997-2000年的互联网泡沫期间才逐渐成为主流。当前人类的技术，比如人工智能和机器学习，已经将我们推向
  • nosql数据库技术与应用知识点 皆过客，揽星河 NoSQLnosql数据库大数据数据分析数据结构非关系型数据库
    Nosql知识回顾大数据处理流程数据采集(flume、爬虫、传感器)数据存储(本门课程NoSQL所处的阶段)Hdfs、MongoDB、HBase等数据清洗(入仓)Hive等数据处理、分析(Spark、Flink等)数据可视化数据挖掘、机器学习应用(Python、SparkMLlib等)大数据时代存储的挑战(三高)高并发(同一时间很多人访问)高扩展(要求随时根据需求扩展存储)高效率(要求读写速度快)
  • 《Python数据分析实战终极指南》 xjt921122 python数据分析开发语言
    对于分析师来说，大家在学习Python数据分析的路上，多多少少都遇到过很多大坑**，有关于技能和思维的**：Excel已经没办法处理现有的数据量了，应该学Python吗？找了一大堆Python和Pandas的资料来学习，为什么自己动手就懵了？跟着比赛类公开数据分析案例练了很久，为什么当自己面对数据需求还是只会数据处理而没有分析思路？学了对比、细分、聚类分析，也会用PEST、波特五力这类分析法，为啥
  • 一比一复刻手表哪里可以买到？推荐三个可靠渠道 腕表世界
    在我国，提及一比一复刻手表，人们总是充满好奇与争议。这种高度仿真的复刻手表，凭借其精湛的工艺、时尚的设计，以及与正品相差无几的质感，深受一部分消费者的喜爱。但与此同时，其背后的侵权争议也一直不断。那么，究竟哪里可以买到这些令人心动的一比一复刻手表呢？腕表咨询微信：10428850一、何为一比一复刻手表？一比一复刻手表，指的是严格按照正版手表的设计、尺寸和工艺制作的仿制品。这些手表在材质、外观、功能
  • Java 重写(Override)与重载(Overload) 叨唧唧的
    Java重写(Override)与重载(Overload)重写(Override)重写是子类对父类的允许访问的方法的实现过程进行重新编写,返回值和形参都不能改变。即外壳不变，核心重写！重写的好处在于子类可以根据需要，定义特定于自己的行为。也就是说子类能够根据需要实现父类的方法。重写方法不能抛出新的检查异常或者比被重写方法申明更加宽泛的异常。例如：父类的一个方法申明了一个检查异常IOExceptio
  • STM32中的计时与延时 lupinjia STM32stm32单片机
    前言在裸机开发中，延时作为一种规定循环周期的方式经常被使用，其中尤以HAL库官方提供的HAL_Delay为甚。刚入门的小白可能会觉得既然有官方提供的延时函数，而且精度也还挺好，为什么不用呢？实际上HAL_Delay中有不少坑，而这些也只是HAL库中无数坑的其中一些。想从坑里跳出来还是得加强外设原理的学习和理解，切不可只依赖HAL库。除了延时之外，我们在开发中有时也会想要确定某段程序的耗时，这就需要
  • 安徽省这个湖,比西湖大8倍,称是安徽的北戴河, 合肥的后花园 旅游小号角
    旅游爱好者都知道，安徽省是一个旅游资源十分丰富的省份，且不说黄山、九华山、天柱山这三大名山，单说湖泊就不比其它省份少，今天我们一起走遍世界将为大家说说一个号称安徽北戴河，合肥后花园的湖泊，看看到底是哪个湖泊？话说，这个湖泊位于安徽省六安市舒城县境内，东距合肥50千米，大约一个小时左右的车程，它号称是合肥的后花园，安徽的北戴河。相传，湖畔石壁之上有一奇石神似观音临湖，湖中漂动众多小岛栩栩如佛子，宛若
  • 摘选《靠谱》 海伦美少女
    作家池莉说：“靠谱，说起来简单，落下去复杂；听起来像感觉，做起来是原则。”靠谱的人，为人正直有原则，做事稳重重诺言。在他们眼里，人品比钱财重要，良心比利益可贵。和他们深交，不用防备，无需猜疑，相处最是舒心。魏晋名士嵇康和山涛，同为竹林七贤，两人私交甚笃。后来，山涛出仕为司马氏效力，嵇康则隐居山林。山涛几次举荐嵇康入朝为官，都被嵇康拒绝，最后甚至写下了绝交书。世人都认为两人恩断义绝，可两年后，嵇康遭
  • 童年那些故事教给我们的 山川大地日月星辰
    同事的女儿二次考研失败，但是仍不气馁还想接着再学再考，得为孩子点个赞，可是同事很矛盾，以她的意见，当初女儿大学毕业就该直接考编，回到家过安稳日子，我问她还记不记得《小马过河》的故事？她说跟小马有啥关系？幼儿园就给孩子讲《小马过河》，当然孩子们除了喜欢故事里的“人物”小松鼠、老牛、小马跟老马，对小马爱劳动喜欢帮助妈妈干活也是有基本认知的，孩子们对为什么老牛说水浅、而松鼠说水深也有一定的常识，到了成人
  • 读书为什么这么难，听拆书帮赵周怎么说。 董小萌读书
    赵周的《这样读书就够了》提炼了成年人读书难的三个问题。问题一：没时间、没精力这是压力与学习的矛盾问题二：看不懂、记不住这是搞错了学习主体其实，我们大多数人在学习主体是谁的问题一直都很模糊。问题三：看不下去这是学习目的不明确，说白了就是不知道为啥而看。也许你会觉得这话有点一竿子打死一片的劲头。不急着反驳，可以回忆一下，哪本书，哪类书，是你曾经读完了，并在脑海中至今还留下痕迹的？是的。成年人的读书，是
  • 为什么瘦子很难增胖？ 我的狗毛毛
    我是个标准的瘦子，168，100斤。用一句通俗的话来讲，我连马甲线都瘦出来了（体脂含量比较低）。但是我反而很羡慕那些比较丰满的女人，我的理想是再增重十五斤，练成前凸后翘的魔鬼身材。为此我开始纠正自己不规律的作息，吃高热量的食物，减少运动量，能坐着绝不站着，能躺着绝不坐着。但是结果却没有丝毫变化。我一直很苦恼，直到最近在网上看到一个视频，英国的某个研究机构做了一个实验，想要知道瘦子能否在高热量的食物
  • 为什么你总是对下属不满意? ZhaoWu1050
    【ZhaoWu的听课笔记】大多数公司，都存在两种问题。我创业四年，更是体会深切。这两种问题就是：老板经常不满意下属的表现；下属总是不知道老板想要什么；虽然这两种问题普遍存在，其实解决方法并不复杂。这节课，我们再聊聊第一个问题：为什么老板经常不满意下属表现?其实，这背后也是一条管理常识。管理学家德鲁克先生早就说过：管理者的任务，不是去改变人。*来自《卓有成效的管理者》只是大多数老板和我一样，都是一边
  • 过了放弃的半生，很想偿偿坚持后的结果 乐安河
    这一阵子又迷茫了，找不到生活的目标，失去了坚持的意义，放弃太简单了，不想了，不看了，不写了，不做了，就行了。放弃的剎那，仿佛全身获得了解救，不再跟自己较劲，真轻松，真爽。短暂的惬意过后，是被抛弃的痛苦，是本该可以的不甘，是悔不当初的懊恼。我的前半生就是一次次的放弃过后的自我放逐。不愿努力，只好说平凡可贵，我们都是普通人，为什么非要整出仙人。不愿意轰轰烈烈，只想要现世安稳。只是，到最后发现，安稳变得
  • jdk tomcat 环境变量配置 Array_06 javajdktomcat
    Win7 下如何配置java环境变量 1。准备jdk包，win7系统，tomcat安装包（均上网下载即可） 2。进行对jdk的安装，尽量为默认路径（但要记住啊！！以防以后配置用。。。） 3。分别配置高级环境变量。   电脑-->右击属性-->高级环境变量-->环境变量。 分别配置 : path    &nbs
  • Spring调SDK包报java.lang.NoSuchFieldError错误 bijian1013 javaspring
            在工作中调另一个系统的SDK包，出现如下java.lang.NoSuchFieldError错误。 org.springframework.web.util.NestedServletException: Handler processing failed; nested exception is java.l
  • LeetCode[位运算] - #136 数组中的单一数 Cwind java题解位运算LeetCodeAlgorithm
    原题链接：#136 Single Number 要求： 给定一个整型数组，其中除了一个元素之外，每个元素都出现两次。找出这个元素 注意：算法的时间复杂度应为O(n)，最好不使用额外的内存空间 难度：中等 分析： 题目限定了线性的时间复杂度，同时不使用额外的空间，即要求只遍历数组一遍得出结果。由于异或运算 n XOR n = 0, n XOR 0 = n，故将数组中的每个元素进
  • qq登陆界面开发 15700786134 qq
    今天我们来开发一个qq登陆界面，首先写一个界面程序，一个界面首先是一个Frame对象，即是一个窗体。然后在这个窗体上放置其他组件。代码如下： public class First {         public void initul(){        jf=ne
  • Linux的程序包管理器RPM 被触发 linux
    在早期我们使用源代码的方式来安装软件时，都需要先把源程序代码编译成可执行的二进制安装程序，然后进行安装。这就意味着每次安装软件都需要经过预处理-->编译-->汇编-->链接-->生成安装文件--> 安装，这个复杂而艰辛的过程。为简化安装步骤，便于广大用户的安装部署程序，程序提供商就在特定的系统上面编译好相关程序的安装文件并进行打包，提供给大家下载，我们只需要根据自己的
  • socket通信遇到EOFException 肆无忌惮_ EOFException
    java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:
  • 基于spring的web项目定时操作 知了ing javaWeb
    废话不多说，直接上代码，很简单 配置一下项目启动就行 1，web.xml <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="h
  • 树形结构的数据库表Schema设计 矮蛋蛋 schema
    原文地址： http://blog.csdn.net/MONKEY_D_MENG/article/details/6647488     程序设计过程中，我们常常用树形结构来表征某些数据的关联关系，如企业上下级部门、栏目结构、商品分类等等，通常而言，这些树状结构需要借助于数据库完成持久化。然而目前的各种基于关系的数据库，都是以二维表的形式记录存储数据信息，
  • maven将jar包和源码一起打包到本地仓库 alleni123 maven
    http://stackoverflow.com/questions/4031987/how-to-upload-sources-to-local-maven-repository <project> ... <build> <plugins> <plugin> <groupI
  • java IO操作 与 File 获取文件或文件夹的大小，可读，等属性！！！ 百合不是茶
    类 File File是指文件和目录路径名的抽象表示形式。 1，何为文件： 标准文件（txt doc mp3...） 目录文件（文件夹） 虚拟内存文件   2，File类中有可以创建文件的 createNewFile（）方法,在创建新文件的时候需要try{} catch(）{}因为可能会抛出异常；也有可以判断文件是否是一个标准文件的方法isFile();这些防抖都
  • Spring注入有继承关系的类（2） bijian1013 javaspring
    被注入类的父类有相应的属性，Spring可以直接注入相应的属性，如下所例：1.AClass类 package com.bijian.spring.test4; public class AClass { private String a; private String b; public String getA() { retu
  • 30岁转型期你能否成为成功人士 bijian1013 成长励志
            很多人由于年轻时走了弯路，到了30岁一事无成，这样的例子大有人在。但同样也有一些人，整个职业生涯都发展得很优秀，到了30岁已经成为职场的精英阶层。由于做猎头的原因，我们接触很多30岁左右的经理人，发现他们在职业发展道路上往往有很多致命的问题。在30岁之前，他们的职业生涯表现很优秀，但从30岁到40岁这一段，很多人
  • 【Velocity四】Velocity与Java互操作 bit1129 velocity
    Velocity出现的目的用于简化基于MVC的web应用开发，用于替代JSP标签技术，那么Velocity如何访问Java代码.本篇继续以Velocity三http://bit1129.iteye.com/blog/2106142中的例子为基础，      POJO    package com.tom.servlets; public
  • 【Hive十一】Hive数据倾斜优化 bit1129 hive
    什么是Hive数据倾斜问题   操作：join,group by,count distinct 现象：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成；查看未完成的子任务，可以看到本地读写数据量积累非常大，通常超过10GB可以认定为发生数据倾斜。 原因：key分布不均匀 倾斜度衡量：平均记录数超过50w且
  • 在nginx中集成lua脚本：添加自定义Http头，封IP等 ronin47 nginx lua csrf
    Lua是一个可以嵌入到Nginx配置文件中的动态脚本语言，从而可以在Nginx请求处理的任何阶段执行各种Lua代码。刚开始我们只是用Lua 把请求路由到后端服务器，但是它对我们架构的作用超出了我们的预期。下面就讲讲我们所做的工作。 强制搜索引擎只索引mixlr.com Google把子域名当作完全独立的网站，我们不希望爬虫抓取子域名的页面，降低我们的Page rank。 location /{
  • java-3.求子数组的最大和 bylijinnan java
    package beautyOfCoding; public class MaxSubArraySum { /** * 3.求子数组的最大和 题目描述： 输入一个整形数组，数组里有正数也有负数。 数组中连续的一个或多个整数组成一个子数组，每个子数组都有一个和。 求所有子数组的和的最大值。要求时间复杂度为O(n)。 例如输入的数组为1, -2, 3, 10, -4,
  • Netty源码学习-FileRegion bylijinnan javanetty
    今天看org.jboss.netty.example.http.file.HttpStaticFileServerHandler.java 可以直接往channel里面写入一个FileRegion对象，而不需要相应的encoder： //pipeline（没有诸如“FileRegionEncoder”的handler）： public ChannelPipeline ge
  • 使用ZeroClipboard解决跨浏览器复制到剪贴板的问题 cngolon 跨浏览器复制到粘贴板Zero Clipboard
    Zero Clipboard的实现原理 Zero Clipboard 利用透明的Flash让其漂浮在复制按钮之上，这样其实点击的不是按钮而是 Flash ，这样将需要的内容传入Flash，再通过Flash的复制功能把传入的内容复制到剪贴板。 Zero Clipboard的安装方法 首先需要下载 Zero Clipboard的压缩包，解压后把文件夹中两个文件：ZeroClipboard.js
  • 单例模式 cuishikuan 单例模式
    第一种（懒汉，线程不安全）： public class Singleton {   2     private static Singleton instance;   3     pri
  • spring+websocket的使用 dalan_123
    一、spring配置文件 <?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans"    xmlns:xsi="http://www.w3.or
  • 细节问题：ZEROFILL的用法范围。 dcj3sjt126com mysql
    1、zerofill把月份中的一位数字比如1，2，3等加前导0 mysql> CREATE TABLE t1 (year YEAR(4), month INT(2) UNSIGNED ZEROFILL,    -> day
  • Android开发10——Activity的跳转与传值 dcj3sjt126com Android开发
    Activity跳转与传值，主要是通过Intent类，Intent的作用是激活组件和附带数据。   一、Activity跳转 方法一Intent intent = new Intent(A.this, B.class); startActivity(intent)   方法二Intent intent = new Intent();intent.setCla
  • jdbc 得到表结构、主键 eksliang jdbc 得到表结构、主键
    转自博客：http://blog.csdn.net/ocean1010/article/details/7266042 假设有个con DatabaseMetaData dbmd = con.getMetaData(); rs = dbmd.getColumns(con.getCatalog(), schema, tableName, null); rs.getSt
  • Android 应用程序开关GPS gqdy365 android
    要在应用程序中操作GPS开关需要权限： <uses-permission android:name="android.permission.WRITE_SECURE_SETTINGS" /> 但在配置文件中添加此权限之后会报错，无法再eclipse里面正常编译，怎么办？ 1、方法一：将项目放到Android源码中编译； 2、方法二：网上有人说cl
  • Windows上调试MapReduce zhiquanliu mapreduce
    1.下载hadoop2x-eclipse-plugin https://github.com/winghc/hadoop2x-eclipse-plugin.git 把 hadoop2.6.0-eclipse-plugin.jar 放到eclipse plugin 目录中。 2.下载 hadoop2.6_x64_.zip http://dl.iteye.com/topics/download/d2b
  • 如何看待一些知名博客推广软文的行为？ justjavac 博客
    本文来自我在知乎上的一个回答：http://www.zhihu.com/question/23431810/answer/24588621 互联网上的两种典型心态： 当初求种像条狗，如今撸完嫌人丑 当初搜贴像条犬，如今读完嫌人软 你为啥感觉不舒服呢？ 难道非得要作者把自己的劳动成果免费给你用，你才舒服？ 就如同 Google 关闭了 Gooled Reader，那是
  • sql优化总结 macroli sql
    为了是自己对sql优化有更好的原则性，在这里做一下总结，个人原则如有不对请多多指教。谢谢！   要知道一个简单的sql语句执行效率，就要有查看方式，一遍更好的进行优化。   一、简单的统计语句执行时间 declare @d datetime ---定义一个datetime的变量set @d=getdate() ---获取查询语句开始前的时间select user_id
  • Linux Oracle中常遇到的一些问题及命令总结 超声波 oraclelinux
    1.linux更改主机名   (1)#hostname oracledb　　　　临时修改主机名 (2) vi /etc/sysconfig/network 　　修改hostname (3) vi /etc/hosts　　　　　　　　修改IP对应的主机名   2.linux重启oracle实例及监听的各种方法 （注意操作的顺序应该是先监听，后数据库实例） &nbs
  • hive函数大全及使用示例 superlxw1234 hadoophive函数
      具体说明及示例参 见附件文档。     文档目录：   目录 一、关系运算： 4 1. 等值比较: = 4 2. 不等值比较: <> 4 3. 小于比较: < 4 4. 小于等于比较: <= 4 5. 大于比较: > 5 6. 大于等于比较: >= 5 7. 空值判断: IS NULL 5
  • Spring 4.2新特性-使用@Order调整配置类加载顺序 wiselyman spring 4
    4.1 @Order Spring 4.2 利用@Order控制配置类的加载顺序 4.2 演示 两个演示bean package com.wisely.spring4_2.order; public class Demo1Service { } package com.wisely.spring4_2.order; public class
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他