AI 助理
备案控制台
开发者社区 数据库 文章 正文

为什么PostgreSQL比MongoDB还快之完结篇(深挖单点索引查询)

2015-04-24 1611
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 MongoDB，独享型 2核8GB
推荐场景：
构建全方位客户视图
云原生数据库 PolarDB PostgreSQL 版，标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版，通用型 2核4GB 50GB
简介： 之前两篇测试中发现：单点索引查询中PostgreSQL的速度是MongoDB(WiredTiger引擎)的4倍。 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4960138 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4981629虽然本人很偏好PG，但也对这个结果表示不能理解。
之前两篇测试中发现：单点索引查询中PostgreSQL的速度是MongoDB(WiredTiger引擎)的4倍。
http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4960138
http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4981629

虽然本人很偏好PG，但也对这个结果表示不能理解。按照常理，纯NoSQL的MongoDB应该比PG快或和PG差不多快才比较合理。
所以，在之前测试的基础上再进行一次深入的挖掘。

之前的0匹配查询，由于执行的时间太短，没有采集到CPU利用率，而且时间值太小，对比的准确性也值得怀疑。
所以，现在构造一个循环的单点索引查询，并在单并发和多并发场景下对比PG和MongoDB的性能。

1. MongoDB（WiredTiger引擎）的测试

单并发测试
循环1万次单点索引查询，平均一次大约返回一条记录。

点击(此处)折叠或打开

  1. -bash-4.1$ cat batchselect_mongo.sh
  2.    for ((i=0;i${1};i++))
  3.    do
  4.        echo "db.json_tables.find({ brand: 'ACME${i}'})"
  5.    done
  6. -bash-4.1$ sh batchselect_mongo.sh 10000|time -p mongo benchmark >/dev/null
  7. real 8.53
  8. user 4.59
  9. sys 2.62
  10. -bash-4.1$ sh batchselect_mongo.sh 10000|time -p mongo benchmark|grep ACME|wc
  11. real 8.33
  12. user 5.33
  13. sys 1.51
  14.    9091 3281851 22061914

看看top的资源使用

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 08:29:13 up 11 days, 11:29, 6 users, load average: 0.09, 0.03, 0.01
  3. Tasks: 159 total, 2 running, 157 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 16.8%us, 1.3%sy, 0.0%ni, 75.6%id, 0.0%wa, 0.0%hi, 6.4%si, 0.0%st
  5. Mem: 1019320k total, 942260k used, 77060k free, 134736k buffers
  6. Swap: 2064376k total, 64712k used, 1999664k free, 265524k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 3951 postgres 20 0 746m 63m 9200 R 85.5 6.4 0:06.97 mongo
  10. 26391 postgres 20 0 617m 339m 12m S 19.3 34.1 10:01.76 mongod

算下来mongod进程占用CPU 1.6s（8.33*19.3%=1.6）

3并发的测试
前面一直是单并发测试，现在看看3并发的场景（测试机是4核）。

点击(此处)折叠或打开

  1. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  2. [1] 5398
  3. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  4. [2] 5401
  5. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  6. [3] 5412
  7. -bash-4.1$ real 8.61
  8. user 6.30
  9. sys 0.64
  10. real 8.61
  11. user 6.37
  12. sys 0.59
  13. real 8.49
  14. user 6.36
  15. sys 0.62
  17. [1] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  18. [2]- Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  19. [3]+ Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null

3并发时的top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 08:42:13 up 11 days, 11:42, 6 users, load average: 1.26, 0.95, 0.39
  3. Tasks: 166 total, 4 running, 162 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 67.4%us, 5.3%sy, 0.0%ni, 25.0%id, 0.0%wa, 0.0%hi, 2.3%si, 0.0%st
  5. Mem: 1019320k total, 570600k used, 448720k free, 1008k buffers
  6. Swap: 2064376k total, 136636k used, 1927740k free, 38632k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 5399 postgres 20 0 746m 63m 9192 R 82.5 6.3 0:05.27 mongo
  10. 5402 postgres 20 0 744m 61m 9192 R 82.5 6.1 0:05.27 mongo
  11. 5413 postgres 20 0 744m 61m 9192 R 82.1 6.2 0:04.96 mongo
  12. 26391 postgres 20 0 625m 266m 3048 S 47.5 26.8 10:27.54 mongod

可以注意到几点
 1）每个客户端的执行时间和单并发时差不多一样。3个mongo进程和1个mongod进程 几乎 各 占了一个CPU核，没有CPU争用。
2） mongod 进程的CPU实际占用时间是8.6*47.5%=4s，是单并发时的2.5倍（接近理论效果的3倍，里面会有测量误差）
3）性能瓶颈还是在客户端

10 并发的测试
10并发时，忙碌的进程数超过CPU核心数，会 有CPU争用。

点击(此处)折叠或打开

  1. -bash-4.1$
  2. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  3. [1] 5156
  4. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  5. [2] 5159
  6. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  7. [3] 5161
  8. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  9. [4] 5163
  10. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  11. [5] 5166
  12. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  13. [6] 5170
  14. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  15. [7] 5172
  16. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  17. [8] 5174
  18. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  19. [9] 5177
  20. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  21. [10] 5179
  22. -bash-4.1$
  23. -bash-4.1$ real 25.15
  24. user 7.97
  25. sys 1.06
  26. real 25.54
  27. user 7.93
  28. sys 1.02
  29. real 26.32
  30. user 7.94
  31. sys 1.08
  32. real 26.63
  33. user 8.39
  34. sys 0.93
  35. real 27.01
  36. user 8.44
  37. sys 1.04
  38. real 28.06
  39. user 8.52
  40. sys 1.02
  41. real 28.16
  42. user 8.11
  43. sys 1.24
  44. real 28.27
  45. user 8.47
  46. sys 1.03
  47. real 28.64
  48. user 8.23
  49. sys 1.13
  50. real 29.14
  51. user 8.11
  52. sys 1.12
  54. [1] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  55. [2] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  56. [3] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  57. [4] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  58. [5] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  59. [6] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  60. [7] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  61. [8] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  62. [9]- Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  63. [10]+ Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null

10并发时的top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 08:40:22 up 11 days, 11:40, 6 users, load average: 1.60, 0.40, 0.14
  3. Tasks: 187 total, 11 running, 176 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 73.7%us, 24.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.5%si, 0.0%st
  5. Mem: 1019320k total, 969800k used, 49520k free, 77180k buffers
  6. Swap: 2064376k total, 66948k used, 1997428k free, 36160k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 26391 postgres 20 0 625m 332m 5220 S 50.5 33.4 10:10.47 mongod
  10. 5168 postgres 20 0 745m 50m 9200 R 40.5 5.0 0:02.16 mongo
  11. 5175 postgres 20 0 745m 58m 9192 R 40.5 5.9 0:02.19 mongo
  12. 5167 postgres 20 0 745m 48m 9192 R 34.9 4.9 0:01.97 mongo
  13. 5157 postgres 20 0 745m 48m 9192 R 34.6 4.8 0:01.96 mongo
  14. 5184 postgres 20 0 744m 44m 9192 R 34.6 4.5 0:01.68 mongo
  15. 5164 postgres 20 0 744m 44m 9192 R 33.6 4.5 0:01.67 mongo
  16. 5182 postgres 20 0 744m 44m 9192 R 31.2 4.5 0:01.58 mongo
  17. 5180 postgres 20 0 744m 44m 9192 R 30.9 4.5 0:01.58 mongo
  18. 5181 postgres 20 0 744m 44m 9192 R 29.2 4.5 0:01.52 mongo
  19. 5183 postgres 20 0 744m 44m 9192 R 28.6 4.5 0:01.54 mongo

1）mongod 进程 的CPU实际占用时间大约是27*50.5%=13.5s，是 单并发时的8.4倍 （接近理论效果的 10倍，里面会有测量误差 ）
2）CPU被撑满， 客户端消耗的大部分的CPU资源。


2. PostgreSQL的测试

单并发测试
循环1万次单点索引查询，平均一次大约返回一条记录。

点击(此处)折叠或打开

  1. -bash-4.1$ cat batchselect_pg.sh
  2. for ((i=0;i
  3. do
  4. echo "SELECT data FROM json_tables WHERE data @> '{\"brand\":\"ACME${i}\"}';"
  5. done
  6. -bash-4.1$ sh batchselect_pg.sh 10000|time -p psql -qAt benchmark >/dev/null
  7. real 1.48
  8. user 0.13
  9. sys 0.14

由于PG太快了，不好收集top信息，改成10万次循环。

点击(此处)折叠或打开

  1. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null
  2. real 10.72
  3. user 0.96
  4. sys 1.01
  5. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark |wc
  6. real 10.91
  7. user 0.61
  8. sys 1.49
  9. 9091 3172759 21561900

看看top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 09:18:00 up 11 days, 12:18, 6 users, load average: 0.35, 0.14, 0.05
  3. Tasks: 166 total, 2 running, 164 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 27.5%us, 4.5%sy, 0.0%ni, 67.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
  5. Mem: 1019320k total, 349168k used, 670152k free, 9200k buffers
  6. Swap: 2064376k total, 68376k used, 1996000k free, 243836k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 9042 postgres 20 0 587m 77m 76m R 81.8 7.8 0:04.35 postgres
  10. 9038 postgres 20 0 103m 1224 1064 S 31.9 0.1 0:01.60 sh
  11. 9041 postgres 20 0 105m 1204 1016 S 18.6 0.1 0:01.08 psql
算下来postgres进程 占用 CPU 8.9s（10.9 *81.1%=8.9 ）。也就是说mongod进程的CPU实际占用时间是postgres进程的1.8倍，而不是之前简单测试得出的4倍。

3并发的测试
点击( 此处 )折叠或打开
  1. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  2. [1] 9740
  3. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  4. [2] 9743
  5. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  6. [3] 9746
  7. -bash-4.1$
  8. -bash-4.1$
  9. -bash-4.1$ real 14.15
  10. user 1.21
  11. sys 1.03
  12. real 14.34
  13. user 1.20
  14. sys 1.01
  15. real 14.41
  16. user 1.23
  17. sys 1.01
  19. [1] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  20. [2]- Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  21. [3]+ Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null

top的结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 09:25:01 up 11 days, 12:25, 6 users, load average: 0.97, 0.24, 0.08
  3. Tasks: 176 total, 4 running, 172 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 68.6%us, 13.3%sy, 0.0%ni, 18.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
  5. Mem: 1019320k total, 354280k used, 665040k free, 9512k buffers
  6. Swap: 2064376k total, 68376k used, 1996000k free, 243848k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 9749 postgres 20 0 587m 77m 76m R 70.2 7.8 0:08.37 postgres
  10. 9750 postgres 20 0 587m 77m 76m R 67.5 7.8 0:08.60 postgres
  11. 9748 postgres 20 0 587m 77m 76m R 65.8 7.8 0:08.44 postgres
  12. 9739 postgres 20 0 103m 1224 1064 S 31.9 0.1 0:03.39 sh
  13. 9745 postgres 20 0 103m 1224 1064 S 28.9 0.1 0:03.35 sh
  14. 9742 postgres 20 0 103m 1228 1064 S 25.3 0.1 0:03.32 sh
  15. 9741 postgres 20 0 105m 1200 1016 S 16.3 0.1 0:01.95 psql
  16. 9744 postgres 20 0 105m 1200 1016 S 15.6 0.1 0:02.01 psql
  17. 9747 postgres 20 0 105m 1200 1016 S 15.6 0.1 0:01.95 psql

算下来postgres进程 占用 CPU 大约28.3s（14*(70%+67%+65%+)=28.3），是单并发时的3.2倍。


10并发的测试
点击( 此处 )折叠或打开
  1. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  2. [1] 10628
  3. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  4. [2] 10631
  5. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  6. [3] 10634
  7. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  8. [4] 10637
  9. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  10. [5] 10639
  11. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  12. [6] 10641
  13. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  14. [7] 10644
  15. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  16. [8] 10646
  17. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  18. [9] 10648
  19. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  20. [10] 10651
  21. -bash-4.1$
  22. -bash-4.1$
  23. -bash-4.1$ real 38.35
  24. user 1.47
  25. sys 0.85
  26. real 38.72
  27. user 1.39
  28. sys 0.90
  29. real 38.87
  30. user 1.45
  31. sys 0.91
  32. real 39.13
  33. user 1.50
  34. sys 0.82
  35. real 39.23
  36. user 1.41
  37. sys 0.94
  38. real 39.63
  39. user 1.42
  40. sys 0.93
  41. real 39.75
  42. user 1.39
  43. sys 0.90
  44. real 39.84
  45. user 1.36
  46. sys 0.98
  47. real 40.24
  48. user 1.42
  49. sys 0.92
  50. real 40.58
  51. user 1.40
  52. sys 0.93
  54. [1] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  55. [2] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  56. [3] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  57. [4] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  58. [5] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  59. [6] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  60. [7] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  61. [8] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  62. [9]- Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  63. [10]+ Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null

10并发时的top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 09:34:12 up 11 days, 12:34, 6 users, load average: 5.21, 1.33, 0.47
  3. Tasks: 201 total, 12 running, 189 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 84.7%us, 14.9%sy, 0.0%ni, 0.3%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
  5. Mem: 1019320k total, 370468k used, 648852k free, 9952k buffers
  6. Swap: 2064376k total, 68376k used, 1996000k free, 243860k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 10664 postgres 20 0 587m 77m 76m R 26.8 7.8 0:08.77 postgres
  10. 10660 postgres 20 0 587m 77m 76m R 26.2 7.8 0:08.83 postgres
  11. 10665 postgres 20 0 587m 77m 76m R 26.2 7.8 0:08.46 postgres
  12. 10642 postgres 20 0 587m 77m 76m R 25.5 7.8 0:08.48 postgres
  13. 10656 postgres 20 0 587m 77m 76m R 25.5 7.8 0:08.15 postgres
  14. 10663 postgres 20 0 587m 77m 76m R 24.8 7.8 0:08.48 postgres
  15. 10662 postgres 20 0 587m 77m 76m R 23.8 7.8 0:08.73 postgres
  16. 10635 postgres 20 0 587m 77m 76m R 23.5 7.8 0:09.20 postgres
  17. 10666 postgres 20 0 587m 77m 76m R 23.5 7.8 0:08.87 postgres
  18. 10654 postgres 20 0 587m 77m 76m R 22.5 7.8 0:07.94 postgres
  19. 10636 postgres 20 0 103m 1224 1064 S 9.9 0.1 0:03.15 sh
  20. 10638 postgres 20 0 103m 1228 1064 S 9.9 0.1 0:03.08 sh
  21. 10650 postgres 20 0 103m 1228 1064 S 9.6 0.1 0:03.18 sh
  22. 10627 postgres 20 0 103m 1228 1064 S 9.3 0.1 0:03.00 sh
  23. 10640 postgres 20 0 103m 1228 1064 R 9.3 0.1 0:02.84 sh
  24. 10645 postgres 20 0 103m 1224 1064 S 9.3 0.1 0:03.14 sh
  25. 10630 postgres 20 0 103m 1228 1064 S 8.6 0.1 0:03.22 sh
  26. 10633 postgres 20 0 103m 1228 1064 S 8.6 0.1 0:02.98 sh
  27. 10647 postgres 20 0 103m 1228 1064 S 8.6 0.1 0:03.17 sh
  28. 10643 postgres 20 0 103m 1228 1064 S 8.3 0.1 0:02.82 sh
  29. 10658 postgres 20 0 105m 1200 1016 S 7.0 0.1 0:02.05 psql
  30. 10655 postgres 20 0 105m 1200 1016 S 6.6 0.1 0:02.09 psql
  31. 10629 postgres 20 0 105m 1200 1016 S 6.3 0.1 0:02.02 psql
  32. 10657 postgres 20 0 105m 1200 1016 S 6.3 0.1 0:01.93 psql
  33. 10652 postgres 20 0 105m 1204 1016 S 6.0 0.1 0:01.88 psql
  34. 10649 postgres 20 0 105m 1204 1016 S 5.6 0.1 0:01.84 psql
  35. 10659 postgres 20 0 105m 1200 1016 S 5.6 0.1 0:01.97 psql
  36. 10632 postgres 20 0 105m 1204 1016 S 5.3 0.1 0:02.09 psql
  37. 10653 postgres 20 0 105m 1204 1016 S 5.3 0.1 0:01.96 psql
  38. 10661 postgres 20 0 105m 1200 1016 S 5.3 0.1 0:02.04 psql

1）大致算下来postgres进程 占用 CPU 大约97.5s（39*25%*10=97.5） ，是单并发时的10.9倍（97.5/8.9）。
2）CPU被撑满， postgres进程 占用了大部分的CPU。

3.总结

测试结果总结如下
从上面的结果可以看出：
1）在多并发场景下， MongoDB和PostgreSQL的服务端进程占用的总 CPU时间和并发数基本成正比。说明负载在CPU多核间分担的比较好。
2）多并发时MongoDB在 单点索引 查询占用的CPU时间大约是PostgreSQL的1.4倍。
3）这个1.4倍的比率基本可以代表了实际场景（高并发，且客户端和服务端不在同一台机器上）下它们的单点索引查询性能差异， 而不是之前简单测试显示的4倍。

经过这样严格的比较，我终于可以相信PostgreSQL在单点索引查询上比 MongoDB(WiredTiger引擎)快了那么一点点。

结合前两次测试结果，最终的总结如下
1）加载
  WiredTiger的性能是PG的3倍（注1，注2）
2）插入
 相差不大，WiredTiger小胜（注1， 注2）
3）全表扫描（0匹配）
 WiredTiger的性能是PG的4倍
4）单点索引扫描
 PG的性能是WiredTiger的1.4倍 （注1）
5）数据大小
 PG的数据大小是WiredTiger的3倍

注1)以服务端进程CPU消耗作为衡量指标的，忽略了MongoDB客户端的高CPU消耗。
注2)仅仅是单并发的测试数据

这个结果虽然和开头那个 EnterpriseDB的流传 较广的测试结果有很大出入，但PG的NoSQL特性在单机环境下仍然有巨大的优势（即：NoSQL+SQL+ACID）。

文章标签：
云数据库 MongoDB 版
云原生数据库 PolarDB
关系型数据库
Shell
测试技术
NoSQL
索引
关键词：
云数据库 MongoDB 版查询
云数据库 MongoDB 版索引
PostgreSQL索引
PostgreSQL查询
云数据库 MongoDB 版索引查询
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识，包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用（唯一索引、地理索引、过期索引、全文索引等）、MapReduce操作实现、用户管理、Java对MongoDB的操作支持（基于2.x驱动与3.x驱动的完全讲解）。 通过学习此课程，读者将具备MongoDB数据库的开发能力，并且能够使用MongoDB进行项目开发。   相关的阿里云产品：云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构，具备安全审计，时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版（ApsaraDB for MongoDB）完全兼容MongoDB协议，基于飞天分布式系统和高可靠存储引擎，提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
小桥河西
目录
相关文章
sunrr
|
1月前
|
监控 关系型数据库 数据库
PostgreSQL的索引优化策略？
【8月更文挑战第26天】PostgreSQL的索引优化策略？
sunrr
54 1
Star时光
|
1月前
|
监控 NoSQL MongoDB
MongoDB数据库的索引管理技巧
【8月更文挑战第20天】MongoDB数据库的索引管理技巧
Star时光
45 1
数据知道
|
3天前
|
存储 NoSQL 关系型数据库
MongoDB中的索引操作总结
这篇文章总结了MongoDB中索引的概念、创建方法、常见操作指令、限制以及索引对查询效率的影响。
数据知道
15 2
数据知道
|
2天前
|
SQL NoSQL JavaScript
04 MongoDB各种查询操作 以及聚合操作总结
文章全面总结了MongoDB中的查询操作及聚合操作，包括基本查询、条件筛选、排序以及聚合管道的使用方法和实例。
数据知道
14 0
土木林森
|
1月前
|
JSON NoSQL MongoDB
MongoDB Schema设计实战指南：优化数据结构，提升查询性能与数据一致性
【8月更文挑战第24天】MongoDB是一款领先的NoSQL数据库，其灵活的文档模型突破了传统关系型数据库的限制。它允许自定义数据结构，适应多样化的数据需求。设计MongoDB的Schema时需考虑数据访问模式、一致性需求及性能因素。设计原则强调简洁性、查询优化与合理使用索引。例如，在构建博客系统时，可以通过精心设计文章和用户的集合结构来提高查询效率并确保数据一致性。正确设计能够充分发挥MongoDB的优势，实现高效的数据管理。
土木林森
40 3
土木林森
|
1月前
|
存储 NoSQL MongoDB
【掌握MongoDB】轻松精通MongoDB查询，从基础到高级一网打尽！
【8月更文挑战第24天】在数据驱动的时代，数据库的性能与灵活性对企业至关重要。MongoDB作为一种高性能、无模式的文档数据库，为开发者提供了灵活的数据存储方案。尤其在处理半结构化或多变数据时展现出强大优势。本文重点介绍MongoDB中的查询操作，包括基本查询、条件查询、复杂查询以及字段选择、排序和限制等功能。通过掌握这些基本查询技巧，开发者能够有效从MongoDB中检索数据，支持复杂的业务逻辑。
土木林森
49 1
蓝易云
|
1月前
|
监控 NoSQL MongoDB
mongodb查询100万数据如何查询快速
综上，提高MongoDB百万级数据的查询性能需要综合多项技术，并在实际应用中不断调优和实践。理解数据的特征，合理设计索引，优化查询语句，在数据访问、管理上遵循最佳的实践，这样才能有效地管理和查询大规模的数据集合。
蓝易云
115 1
sunrr
|
1月前
|
缓存 关系型数据库 数据库
PostgreSQL 查询性能
【8月更文挑战第5天】PostgreSQL 查询性能
sunrr
42 8
游客jfno57fqk5sv4
|
1月前
|
存储 NoSQL 关系型数据库
4-MongoDB索引知识
MongoDB通过索引提升查询效率，避免全集合扫描。索引采用B树结构存储部分数据集，按字段值排序，支持快速匹配与排序查询。主要类型包括：单字段索引，支持升序/降序；复合索引，字段顺序影响排序逻辑；地理空间索引，适用于坐标数据查询；文本索引，用于搜索字符串内容；哈希索引，用于散列分片，仅支持等值查询。更多详情参见官方文档：[MongoDB索引指南](https://docs.mongodb.com/manual/indexes/)。
游客jfno57fqk5sv4
40 8
土木林森
|
27天前
|
C# 微服务 Windows
模块化革命：揭秘WPF与微服务架构的完美融合——从单一职责原则到事件聚合器模式，构建高度解耦与可扩展的应用程序
【8月更文挑战第31天】本文探讨了如何在Windows Presentation Foundation（WPF）应用中借鉴微服务架构思想，实现模块化设计。通过将WPF应用分解为独立的功能模块，并利用事件聚合器实现模块间解耦通信，可以有效提升开发效率和系统可维护性。文中还提供了具体示例代码，展示了如何使用事件聚合器进行模块间通信，以及如何利用依赖注入进一步提高模块解耦程度。此方法不仅有助于简化复杂度，还能使应用更加灵活易扩展。
土木林森
57 0

热门文章

最新文章

  • 1
    2011年功力的德哥教你两天撸通PostgreSQL - 入门、开发、原理、管理、调优
  • 2
    PostgreSQL 字符串 collate 与排序 源码分析
  • 3
    SQLServer CDC数据通过Kafka connect实时同步至分析型数据库 AnalyticDB For PostgreSQL及OSS
  • 4
    【独家直播】洞见数据库前沿 集结阿里云数据库最强阵容 DTCC 2019 八大亮点抢先看
  • 5
    如何在PostgreSQL中调试plpgsql存储过程(pldebugger, pldbgapi)
  • 6
    PostgreSQL 最佳实践 - 逻辑增量复制(MySQL <-> PgSQL <-> PgSQL)
  • 7
    PostgreSQL索引页
  • 8
    《PolarDB for PostgreSQL三节点功能介绍》电子版地址
  • 9
    PostgreSQL 10.1 手册_部分 I. 教程_第 3 章 高级特性_3.7. 小结
  • 10
    postgresql 优化之--不会使用索引
  • 1
    【MongoDB系列笔记】索引
    43
  • 2
    【MongoDB系列相关笔记】常用命令
    189
  • 3
    【MongoDB系列相关笔记】单机部署
    159
  • 4
    【MongoDB系列笔记】MongoDB相关概念
    149
  • 5
    docker安装mongodb(单点)图文详解
    257
  • 6
    MongoDB聚合框架与复杂查询优化：技术深度解析
    241
  • 7
    MongoDB实时数据分析与流处理的技术探讨
    169
  • 8
    MongoDB性能调优：监控与诊断工具的技术探讨
    340
  • 9
    MongoDB安全机制：认证、授权与加密
    375
  • 10
    MongoDB复制集原理：高可用性与数据一致性的保障
    152

    • 相关课程

    更多
  • MongoDB精讲课程（下）
  • MongoDB精讲课程（上）
  • MongoDB完全自学手册
  • 云数据库MongoDB版使用教程
  • 快速掌握 MongoDB 数据库
  • MongoDB快速入门

    • 相关电子书

    更多
  • 开源数据库 MongoDB 专场 MongoDB疑难杂症分析及优化
  • MongoDB多数据中心的方案选型之路
  • 饿了么高级架构师陈东明：MongoDB是如何逐步提高可靠性的

    • 相关实验场景

    更多
  • 体验PolarDB-X透明分布式
  • MySQL引擎及架构优化
  • 云数据库MongoDB快速入门
  • 云原生HTAP数据库，让你的交易和分析一库搞定
  • PolarDB for PostgreSQL 闪回特性体验
  • 函数计算X RDS PostgreSQL，基于LLM大语言模型构建AI知识库

    • 推荐镜像

    更多
  • mongodb
  • postgresql
  • clickhouse
    • 下一篇
    使用OSS上传下载文件