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

为什么PostgreSQL比MongoDB还快之续篇(WiredTiger引擎)

2015-04-23 1184
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 MongoDB，独享型 2核8GB
推荐场景：
构建全方位客户视图
云原生数据库 PolarDB MySQL 版，通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版，标准版 2核4GB 50GB
简介： 今年的DTCC大会上，MongoDB中国的唐总带来了《如何在3.0实现7-10倍性能提升》。演讲时顺便倒了点苦水：一些其它数据库喜欢拿MongoDB进行性能PK，但MongoDB之前的开发一直没有怎么关注性能这块，以前也没有发布过官方的性能测试数据，所以结果可想而知。

今年的DTCC大会上，MongoDB中国的唐总带来了《如何在3.0实现7-10倍性能提升》。演讲时顺便倒了点苦水：一些其它数据库喜欢拿MongoDB进行性能PK，但MongoDB之前的开发一直没有怎么关注性能这块，以前也没有发布过官方的性能测试数据，所以结果可想而知。
但是，MongoDB 3.0带来了新的WiredTiger存储引擎,不再像以前(MMAPv1引擎)那样受制于OS内存映射，性能有7-10倍的提升。

这里有一份MongoDB的官方性能测试报告，根据这份测试报告，WiredTiger的性能提升主要表现在数据压缩和并行加载上。
http://www.mongoing.com/archives/862

由于WiredTiger不是默认引擎(根据唐总的说法，以后的版本会考虑作为默认引擎) 。我之前的那篇测试，对比的还是MongoDB的老引擎MMAPv1。
http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4960138

下面用同样的测试方法看看WiredTiger引擎的表现(嫌测试过程写得太长的话，可以直接跳到后面看测试总结)。

1. MongoDB WiredTiger引擎的测试

1）启用MongoDB的WiredTiger引擎

点击(此处)折叠或打开

  1. -bash-4.1$ mongod --dbpath /data/db2 --storageEngine wiredTiger
  2. 2015-04-18T07:51:26.647+0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1G,session_max=20000,eviction=(threads_max=4),statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
  3. 2015-04-18T07:51:27.561+0800 I CONTROL [initandlisten] MongoDB starting : pid=21287 port=27017 dbpath=/data/db2 64-bit host=hanode1
  4. 2015-04-18T07:51:27.563+0800 I CONTROL [initandlisten] db version v3.0.2
  5. 2015-04-18T07:51:27.563+0800 I CONTROL [initandlisten] git version: 6201872043ecbbc0a4cc169b5482dcf385fc464f
  6. 2015-04-18T07:51:27.564+0800 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
  7. 2015-04-18T07:51:27.564+0800 I CONTROL [initandlisten] build info: Linux ip-10-171-120-213 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 BOOST_LIB_VERSION=1_49
  8. 2015-04-18T07:51:27.564+0800 I CONTROL [initandlisten] allocator: tcmalloc
  9. 2015-04-18T07:51:27.564+0800 I CONTROL [initandlisten] options: { storage: { dbPath: "/data/db2", engine: "wiredTiger" } }
  10. 2015-04-18T07:51:27.595+0800 I NETWORK [initandlisten] waiting for connections on port 27017

2）加载数据

点击(此处)折叠或打开

  1. -bash-4.1$ time -p mongoimport --type json --collection json_tables --db benchmark /dev/null 2>/dev/null
  2. real 8.53
  3. user 7.99
  4. sys 4.14

加载期间的系统负载

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
  2. top - 08:19:09 up 7 days, 11:19, 5 users, load average: 0.48, 0.13, 0.04
  3. Tasks: 151 total, 1 running, 150 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 24.9%us, 9.3%sy, 0.0%ni, 56.8%id, 6.2%wa, 0.5%hi, 2.4%si, 0.0%st
  5. Mem: 1019320k total, 949576k used, 69744k free, 82976k buffers
  6. Swap: 2064376k total, 62092k used, 2002284k free, 215228k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 24190 postgres 20 0 549m 219m 3312 S 114.7 22.1 0:08.94 mongoimport
  10. 21287 postgres 20 0 634m 331m 4748 S 34.6 33.3 0:44.48 mongod
值得注意的是系统的瓶颈在mongoimport进程(mongoimport的CPU利用率超过了100%)，而不是mongod进程 ， mongod还有很多的余力 。

 3）建索引

点击(此处)折叠或打开

  1. -bash-4.1$ echo "db.json_tables.ensureIndex( { \"name\": 1})" |time -p mongo benchmark >/dev/null
  2. real 1.25
  3. user 0.03
  4. sys 0.03
  5. -bash-4.1$ echo "db.json_tables.ensureIndex( { \"type\": 1})" |time -p mongo benchmark >/dev/null
  6. real 0.45
  7. user 0.02
  8. sys 0.02
  9. -bash-4.1$ echo "db.json_tables.ensureIndex( { \"brand\": 1})" |time -p mongo benchmark >/dev/null
  10. real 0.37
  11. user 0.05
  12. sys 0.03

4）查看存储空间大小

点击(此处)折叠或打开

  1. -bash-4.1$ mongo benchmark
  2. MongoDB shell version: 3.0.2
  3. connecting to: benchmark
  4. > db.json_tables.stats()
  5. {
  6.     "ns" : "benchmark.json_tables",
  7.     "count" : 100001,
  8.     "size" : 266284846,
  9.     "avgObjSize" : 2662,
  10.     "storageSize" : 43167744,
  11.     "capped" : false,
  12.     "wiredTiger" : {
  13.         "metadata" : {
  14.             "formatVersion" : 1
  15.         },
  16.         "creationString" : "allocation_size=4KB,app_metadata=(formatVersion=1),block_allocation=best,block_compressor=snappy,cache_resident=0,checkpoint=(WiredTigerCheckpoint.2=(addr=\"01e208e781e4d41e9d38e208e881e4369503e3e208e981e446480254808080e402928fc0e40291cfc0\",order=2,time=1429314987,size=43118592,write_gen=9063)),checkpoint_lsn=(2,40610048),checksum=uncompressed,collator=,columns=,dictionary=0,format=btree,huffman_key=,huffman_value=,id=5,internal_item_max=0,internal_key_max=0,internal_key_truncate=,internal_page_max=4KB,key_format=q,key_gap=10,leaf_item_max=0,leaf_key_max=0,leaf_page_max=32KB,leaf_value_max=1MB,memory_page_max=10m,os_cache_dirty_max=0,os_cache_max=0,prefix_compression=0,prefix_compression_min=4,split_deepen_min_child=0,split_deepen_per_child=0,split_pct=90,value_format=u,version=(major=1,minor=1)",
  17.         "type" : "file",
  18.         "uri" : "statistics:table:collection-2--333628209475642491",
  19.         "LSM" : {
  20.             "bloom filters in the LSM tree" : 0,
  21.             "bloom filter false positives" : 0,
  22.             "bloom filter hits" : 0,
  23.             "bloom filter misses" : 0,
  24.             "bloom filter pages evicted from cache" : 0,
  25.             "bloom filter pages read into cache" : 0,
  26.             "total size of bloom filters" : 0,
  27.             "sleep for LSM checkpoint throttle" : 0,
  28.             "chunks in the LSM tree" : 0,
  29.             "highest merge generation in the LSM tree" : 0,
  30.             "queries that could have benefited from a Bloom filter that did not exist" : 0,
  31.             "sleep for LSM merge throttle" : 0
  32.         },
  33.         "block-manager" : {
  34.             "file allocation unit size" : 4096,
  35.             "blocks allocated" : 9066,
  36.             "checkpoint size" : 43118592,
  37.             "allocations requiring file extension" : 9046,
  38.             "blocks freed" : 27,
  39.             "file magic number" : 120897,
  40.             "file major version number" : 1,
  41.             "minor version number" : 0,
  42.             "file bytes available for reuse" : 40960,
  43.             "file size in bytes" : 43167744
  44.         },
  45.         "btree" : {
  46.             "btree checkpoint generation" : 8,
  47.             "column-store variable-size deleted values" : 0,
  48.             "column-store fixed-size leaf pages" : 0,
  49.             "column-store internal pages" : 0,
  50.             "column-store variable-size leaf pages" : 0,
  51.             "pages rewritten by compaction" : 0,
  52.             "number of key/value pairs" : 0,
  53.             "fixed-record size" : 0,
  54.             "maximum tree depth" : 3,
  55.             "maximum internal page key size" : 368,
  56.             "maximum internal page size" : 4096,
  57.             "maximum leaf page key size" : 3276,
  58.             "maximum leaf page size" : 32768,
  59.             "maximum leaf page value size" : 1048576,
  60.             "overflow pages" : 0,
  61.             "row-store internal pages" : 0,
  62.             "row-store leaf pages" : 0
  63.         },
  64.         "cache" : {
  65.             "bytes read into cache" : 267348602,
  66.             "bytes written from cache" : 267938187,
  67.             "checkpoint blocked page eviction" : 0,
  68.             "unmodified pages evicted" : 0,
  69.             "page split during eviction deepened the tree" : 0,
  70.             "modified pages evicted" : 26,
  71.             "data source pages selected for eviction unable to be evicted" : 3,
  72.             "hazard pointer blocked page eviction" : 3,
  73.             "internal pages evicted" : 0,
  74.             "pages split during eviction" : 26,
  75.             "in-memory page splits" : 6,
  76.             "overflow values cached in memory" : 0,
  77.             "pages read into cache" : 9005,
  78.             "overflow pages read into cache" : 0,
  79.             "pages written from cache" : 9063
  80.         },
  81.         "compression" : {
  82.             "raw compression call failed, no additional data available" : 0,
  83.             "raw compression call failed, additional data available" : 0,
  84.             "raw compression call succeeded" : 0,
  85.             "compressed pages read" : 9004,
  86.             "compressed pages written" : 9020,
  87.             "page written failed to compress" : 0,
  88.             "page written was too small to compress" : 43
  89.         },
  90.         "cursor" : {
  91.             "create calls" : 14,
  92.             "insert calls" : 100001,
  93.             "bulk-loaded cursor-insert calls" : 0,
  94.             "cursor-insert key and value bytes inserted" : 266602485,
  95.             "next calls" : 300006,
  96.             "prev calls" : 1,
  97.             "remove calls" : 0,
  98.             "cursor-remove key bytes removed" : 0,
  99.             "reset calls" : 100005,
  100.             "search calls" : 0,
  101.             "search near calls" : 0,
  102.             "update calls" : 0,
  103.             "cursor-update value bytes updated" : 0
  104.         },
  105.         "reconciliation" : {
  106.             "dictionary matches" : 0,
  107.             "internal page multi-block writes" : 2,
  108.             "leaf page multi-block writes" : 28,
  109.             "maximum blocks required for a page" : 345,
  110.             "internal-page overflow keys" : 0,
  111.             "leaf-page overflow keys" : 0,
  112.             "overflow values written" : 0,
  113.             "pages deleted" : 0,
  114.             "page checksum matches" : 204,
  115.             "page reconciliation calls" : 32,
  116.             "page reconciliation calls for eviction" : 26,
  117.             "leaf page key bytes discarded using prefix compression" : 0,
  118.             "internal page key bytes discarded using suffix compression" : 9230
  119.         },
  120.         "session" : {
  121.             "object compaction" : 0,
  122.             "open cursor count" : 14
  123.         },
  124.         "transaction" : {
  125.             "update conflicts" : 0
  126.         }
  127.     },
  128.     "nindexes" : 4,
  129.     "totalIndexSize" : 2826240,
  130.     "indexSizes" : {
  131.         "_id_" : 864256,
  132.         "name_1" : 868352,
  133.         "type_1" : 630784,
  134.         "brand_1" : 462848
  135.     },
  136.     "ok" : 1
  137. }
WiredTiger引擎的压缩效果确实不错，把253MB的 原始数据压缩到了 41MB。

5）数据查询
匹配9091条记录的查询：
 点击( 此处 )折叠或打开
  1. -bash-4.1$ echo "db.json_tables.find({ brand: 'ACME'}).count()"|mongo benchmark
  2. MongoDB shell version: 3.0.2
  3. connecting to: benchmark
  4. 9091
  5. bye
  6. -bash-4.1$ echo "DBQuery.shellBatchSize = 10000000000;db.json_tables.find({ brand: 'ACME'})"|time -p mongo benchmark >/dev/null
  7. real 3.93
  8. user 3.56
  9. sys 0.11
*）第1次测的时间是12秒，有IO等待的时间，上面是第2次测试的结果，即数据已经被缓存了。

看看top的资源占用。
 点击( 此处 )折叠或打开
  1. Tasks: 158 total, 2 running, 156 sleeping, 0 stopped, 0 zombie
  2. Cpu(s): 22.6%us, 0.4%sy, 0.0%ni, 76.8%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
  3. Mem: 1019320k total, 793584k used, 225736k free, 61424k buffers
  4. Swap: 2064376k total, 64096k used, 2000280k free, 236052k cached
  6. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  7. 27969 postgres 20 0 752m 67m 9304 R 91.4 6.8 0:03.46 mongo
  8. 26391 postgres 20 0 610m 325m 11m S 1.0 32.7 0:10.95 mongod
测试结果和MMAPv1引擎差不多，CPU把时间都耗在客户端的mongo进程上。因为客户端在处理大量输出结果时消耗了太多的资源。

 为了排除大量数据处理的误导，下面执行一下0匹配的查询。

点击(此处)折叠或打开

  1. -bash-4.1$ echo "DBQuery.shellBatchSize = 10000000000;db.json_tables.find({ brand: 'ACME111'})"|time -p mongo benchmark >/dev/null
  2. real 0.07
  3. user 0.04
  4. sys 0.01
测试结果 和 MMAPv1引擎也差不多。

再试试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. bye
  10. -bash-4.1$ echo "DBQuery.shellBatchSize = 10000000000;db.json_tables.find({ brand: 'ACME111'})"|time -p mongo benchmark >/dev/null
  11. real 0.14
  12. user 0.02
  13. sys 0.03
测试结果 和 MMAPv1引擎比快了有50%左右。

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    1m31.420s
  4. user    0m30.832s
  5. sys    0m50.319s
测试结果也和MMAPv1引擎差不多。
并且由于MongoDB的控制台不允许插入大于4k的文档，最后插入的数据没有10万条。

点击(此处)折叠或打开

  1. -bash-4.1$ mongo benchmark
  2. MongoDB shell version: 3.0.2
  3. connecting to: benchmark
  4. > db.json_tables.count()
  5. 72728

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

点击(此处)折叠或打开

  1. [root@hanode1 ~]# top
  2. top - 08:02:23 up 7 days, 11:02, 5 users, load average: 0.00, 0.02, 0.00
  3. Tasks: 154 total, 2 running, 152 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 3.3%us, 1.5%sy, 0.0%ni, 76.4%id, 0.0%wa, 0.0%hi, 18.8%si, 0.0%st
  5. Mem: 1019320k total, 888680k used, 130640k free, 83272k buffers
  6. Swap: 2064376k total, 62140k used, 2002236k free, 295144k cached
  8. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  9. 22470 postgres 20 0 753m 66m 9224 R 88.8 6.7 0:03.94 mongo
  10. 21287 postgres 20 0 634m 344m 11m S 22.3 34.6 0:12.53 mongod
这个测试结果也和MMAPv1引擎惊人的相识。那么WiredTiger引擎的插入性能提升在什么地方呢？
其实WiredTiger引擎在插入上主要提升的是并发性能，MMAPv1引擎在并发时是简单粗暴的锁库模式，严重制约并发性能，CPU核心再多性能也上不去。而我的测试是单并发测试，所以看不出MMAPv1引擎的这个致命缺点。

2. 总结

以单并发时的服务端进程CPU消耗作为衡量指标，PG和WiredTiger的对比总结如下：
1）加载
  WiredTiger的性能是PG的3倍（注）
2）插入
 相差不大，WiredTiger小胜（注）
3）全表扫描（0匹配）
 WiredTiger的性能是PG的4倍
4）单点索引扫描（0匹配）
 PG的性能是WiredTiger的4倍
5）数据大小
 PG的数据大小是WiredTiger的3倍


注意，以上加载和插入的这两个数据以单并发时的服务端进程CPU消耗作为衡量指标的，忽略了MongoDB客户端的高CPU消耗，实际场景中也有可能PG更快。之所以这样对比，是因为：

我们假设好的引擎可以在高并发时可以把负载均衡地分散到所有CPU核心上，对这样的引擎，在CPU成为瓶颈的场景中，单并发时的CPU实际占用时间可以作为一个重要的参考指标。

但是，服务端能不能在高并发时实现多CPU核心上的线性或近似线性的性能Scale UP还需看服务端（PG/MongoDB）的素质和具体使用场景。

最后，即使PG在加载和插入的PK上输了也很正常，因为PG是保障了ACID的，WiredTiger却有丢失数据的风险。
Journal 默认不会即时刷盘，系统宕机会丢失最多100MB Journal数据








文章标签：
云数据库 MongoDB 版
云原生数据库 PolarDB
关系型数据库
NoSQL
测试技术
Shell
PostgreSQL
关键词：
postgresql云数据库 MongoDB 版
PostgreSQL mongodb
云数据库 MongoDB 版wiredtiger
云数据库 MongoDB 版引擎
PostgreSQL引擎
相关实践学习
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
小桥河西
目录
相关文章
阿兵云原生
|
12月前
|
存储 NoSQL MongoDB
mongodb 存引擎及配置
mongodb 存引擎及配置
阿兵云原生
106 0
qhhf_地道酬勤
|
1月前
|
存储 关系型数据库 MySQL
一个项目用5款数据库？MySQL、PostgreSQL、ClickHouse、MongoDB区别，适用场景
一个项目用5款数据库？MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景比较
qhhf_地道酬勤
262 0
qhhf_地道酬勤
|
1月前
|
存储 关系型数据库 MySQL
四种数据库对比MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
四种数据库对比 MySQL、PostgreSQL、ClickHouse、MongoDB——特点、性能、扩展性、安全性、适用场景
qhhf_地道酬勤
197 0
土木林森
|
6月前
|
JavaScript 前端开发 NoSQL
【MongoDB 专栏】MongoDB 的 JavaScript 引擎与脚本执行
【5月更文挑战第11天】MongoDB 的 JavaScript 引擎允许在服务器端直接执行脚本，提升效率并实现定制化操作。脚本环境提供独立但与数据库关联的运行空间，引擎负责脚本的解析、编译和执行。执行过程包括脚本提交、解析、编译和执行四个步骤。掌握脚本逻辑设计和 JavaScript 语言特性对于高效利用这一功能至关重要。例如，通过脚本可以计算商品总销售额，增强数据库操作的灵活性。
土木林森
102 1
【MongoDB 专栏】MongoDB 的 JavaScript 引擎与脚本执行
公众号:码到三十五
|
5月前
|
存储 NoSQL 算法
MongoDB存储引擎发展及WiredTiger深入解析（二）
MongoDB存储引擎发展及WiredTiger深入解析（二）
公众号:码到三十五
134 0
IT陈寒
|
NoSQL Cloud Native 关系型数据库
云原生数据库比较：MySQL、PostgreSQL、MongoDB和Cassandra的优势与劣势
选择适合自己应用的云原生数据库需要考虑多个因素，包括数据模型、性能需求、扩展性、学习曲线等。如果应用需要严格的 ACID 事务，关系型数据库如 MySQL 或 PostgreSQL 是不错的选择。如果应用需要灵活的数据模型和快速迭代开发，MongoDB 可能更适合。而对于大规模数据存储和高可用性需求，Cassandra 可能是一个值得考虑的选项。
IT陈寒
1288 3
云原生数据库比较：MySQL、PostgreSQL、MongoDB和Cassandra的优势与劣势
游戏服务器开发社区
|
12月前
|
存储 NoSQL Shell
如何将阿里云WiredTiger引擎的MongoDB物理备份文件恢复至自建数据库
数据库操作一直是一个比较敏感的话题，动不动“删库跑路”，可见数据库操作对于一个项目而言是非常重要的，我们有时候会因为一个游戏的严重bug或者运营故障要回档数据库，而你们刚好使用的是阿里云的Mongodb，那么这篇文章将给你提供一个思路（或许你按照阿里云官网的文档一顿操作下来，并不是那么顺利，有一些报错，无法登录...）
游戏服务器开发社区
193 0
阿里云专家技术服务助手
|
存储 弹性计算 运维
互娱NoSQL架构优化 —— 暨MongoDB“在线换引擎”技术服务指南”
XX工作室是某大客户核心游戏工作室，其核心业务是国内二次元RPG手游，采用实时开放世界对战模式，整体采用阿里云方案，本次专项攻坚主要对于玩家在游戏期间各类游戏属性交互（包含过图、物品、面板、剧情等）的核心业务模块进行优化，其中涉及NoSQL部分由于在专项优化期间存在诸多细节，特此提炼出来给各位有类似互娱业务场景进行参考。
阿里云专家技术服务助手
1623 18
阿兵云原生
|
存储 NoSQL MongoDB
【mongo 系列】mongodb 学习十三，内存引擎及配置
上次我们分享到了 wiredTiger 引擎以及他对于以前默认的 MMAPV1 引擎的优势 关于 wiredTiger 引擎 配置这里补充一下
阿兵云原生
325 0
架构师研究会
|
SQL 存储 NoSQL
「技术选型」比较MongoDB和PostgreSQL:谁才是王者？
「技术选型」比较MongoDB和PostgreSQL:谁才是王者？
架构师研究会
1050 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 ident和peer基于操作系统用户的认证
  • 7
    PostgreSQL 最佳实践 - 逻辑增量复制(MySQL <-> PgSQL <-> PgSQL)
  • 8
    RDS for MySQL权限问题（错误代码：1227，1725）
  • 9
    postgresql 9.6 建立多列索引测试
  • 10
    postgresql 时区与时间函数
  • 1
    【docker 】docker-compose 部署mongoDB
    187
  • 2
    docker部署mongoDB
    211
  • 3
    MongoDB非关系型数据库实战
    190
  • 4
    mongoDB查看数据的插入日志
    375
  • 5
    【MongoDB系列笔记】索引
    52
  • 6
    【MongoDB系列相关笔记】常用命令
    202
  • 7
    【MongoDB系列相关笔记】单机部署
    170
  • 8
    【MongoDB系列笔记】MongoDB相关概念
    163
  • 9
    docker安装mongodb(单点)图文详解
    355
  • 10
    MongoDB聚合框架与复杂查询优化：技术深度解析
    294

    • 相关课程

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

    • 相关电子书

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

    • 相关实验场景

    更多
  • 通过Lindorm-cli连接并使用宽表引擎
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 云数据库MongoDB快速入门
  • PolarDB for PostgreSQL 闪回特性体验
  • 函数计算X RDS PostgreSQL，基于LLM大语言模型构建AI知识库

    • 推荐镜像

    更多
  • mongodb
  • postgresql
  • clickhouse
    • 下一篇
    DataWorks智能数据建模全面公测开始啦！