1、Mongodb分享,钟秋,2015-11-27,1. 背景2. MongoDB入门3. 索引4. 复制5. 分片6. 管理与监控7. 使用优化案例,主要内容,1.背景,1.1 从集中式到分布式1.2 从sql到nosql1.3 分布式一致性问题1.4 CAP和BASE理论,1.1 从集中式到分布式,集中式的问题：计算、存储能力瓶颈单点问题分布式的问题：通信异常网络分区三态节点故障一致性,1.2 从SQL到NoSQL,SQL建立在严格的关系模型基础之上，通常支持复杂的事务操作，提供严格的数据一致性、完整性约束，并且支持关联查询等。复杂事务，关联查询等特性影响读写性能，同时限制了关系型数据库的分布
2、式扩展能力。NoSQLnon-relationalnot only sql是对SQL的补充：高并发读写海量数据高可扩展和高可用性还无法替代SQL:复杂事务，严格的一致性读写实时性join与SQL不同，NoSQL没有统一的标准，种类繁多（key-value，列式，文档，图），根据业务选择适合的,1.3 分布式一致性问题,强一致性弱一致性最终一致性鱼和熊掌：分布式系统中数据一致性和系统性能之间的关系,1.4 CAP和BASE理论,CAPC：ConsistencyA：AvailabilityP：Partitiontolerance分布式系统中，P是基础，所以 一般只能在C、A之间进行取舍。Mongo
3、DB处于哪一部分？BASEBasicallyAvailable，Softstate，Eventuallyconsistent,2.MongoDB入门,2.1 什么是MongoDB2.2 存储引擎与版本选择2.3 mongo shell2.4 mongodb数据模型2.5 数据类型2.6 bson2.7 GridFS2.8 模式设计2.9 CRUD,2.1 什么是MongoDB,MongoDB是面向文档的，无模式(schema-less)的，支持二级索引，支持冗余、自动故障转移，支持数据分片、负载均衡，易扩展，能为海量数据提供支撑的非关系型数据库。MongoDB不支持跨多个文档的复杂事务，但保证
4、单文档操作原子性。MongoDB不支持联接（join）。MongoDB不支持MVCC（3.x wiredTiger引擎支持）。,2.2 存储引擎,版本2.8(3.0)开始支持插件式存储引擎MMAPv1WiredTiger（since 3.0）,2.2 存储引擎-MMAPv1(1),读写锁不支持MVCCVersion 2.2 : 只支持进程级锁，一个Mongod实例一个锁。2.2 Version 2.8 : 支持库级锁，一个db一把锁。3.0.0 Version支持 collection 级别的锁。内存内存映射文件交由操作系统管理，不能 手动配置管理无强制内存量要求缓存索引、热数据等,2.2 存
5、储引擎-MMAPv1(2),Journal日志Journal日志，是MongoDB的预写日志WAL(类似Mysql的Redo log)。因为Journal日志文件是磁盘上连续分配的空间，MongoDB在运行时通过顺序追加的方式记录，通过顺序IO来改善写性能。同时，后台会定时刷写Journal日志文件以将写操作持久化到数据文件。通过这种两次写的方式，当Mongodb因为一次非正常退出（比如崩溃），重启mongod进程后会根据journal下的文件来恢复数据以达到数据一致，防止数据丢失。同时，一次正常的退出时MongoDB会刷写并删除journal目录下所有文件。journal除了故障恢复的作用之
6、外，还可以提高写入的性能，通过批量提交（batch-commit）的方式减少IO次数，一般默认100ms刷新一次到journal，可通过下面参数修改：mitIntervalMs值越低，刷新输出频率越高，journal的持久性也就越高(故障意外情况下丢失的数据越少)，但同时意味着更多的磁盘IO。2.0以上版本默认开启的，可以通过nojournal = true 或-nojournal关闭，但建议开启。Journal文件是以“j._”开头命名的，且是append only的，如果1个journal文件满了1G大小，mongodb就会新创建一个journal文件来使用，一旦某个journal文件所记
7、载的写操作都被使用过了，mongodb就会把这个journal文件删除。通常在journal文件所在的文件夹下，只会存在23个journal文件，除非你使用mongodb每秒都写入大量的数据。使用 smallfiles 这个运行时选项可以将journal文件大小减至128M大小。,2.2 存储引擎-MMAPv1(3),数据文件每个db有1个.ns（namespace）和若干个数据文件(.n)构成数据文件随着数据的增多而增多，默认从64M开始，数据文件每新增一次，大小为上一个数据文件的2倍，上限为2GB。这样的设计有利于防止数据量较小的数据库浪费过多的空间，同时又能保证数据量较大的数据库有相应的
8、空间使用。MongoDB会使用预分配方式来保证写入性能的稳定（可通过noprealloc关闭，但不建议）。预分配在后台进行。预分配使得MongoDB始终保持额外的空间和空余的数据文件，从而避免了数据增长过快而带来的分配磁盘空间引起的阻塞。,版本3.0起引入，只支持64位系统，还不是默认的存储引擎，需要手动指定。在即将到来的3.2版本将成为默认引擎。storageEngine = wiredTiger读写锁通过MVCC实现文档级别锁（更细粒度 的锁，大大提高并发读写性能）以前的微分片，分库分表及其他为提高 MMAPv1并发率而实现的变通方案将 不再需要,2.2 存储引擎-WiredTiger(1
9、),MVCC(snapshot, copyOnWrite),2.2 存储引擎-WiredTiger(2),内存可配置缓存大小(默认为1GB或物理内存的一半)wiredTigerCacheSizeGB = 10压缩wiredTigerCollectionBlockCompressor=snappy/zlibwiredTigerIndexPrefixCompression=truewiredTigerJournalCompressor=snappy/zlib高效的压缩算法，相比先前版本数据占用更少空间,2.2 存储引擎-WiredTiger(3),Snapshots 和 CheckpointsSn
10、apshot代表缓存中数据的一个一致性状态下的视图快照。WiredTiger会以一种一致性的方式将snapshot写到磁盘的所有数据文件上，这些持久化的数据被称为一个checkpoint。当一个checkpoint在写入过程中，上个checkpoint会保留，如果在这个过程中，系统崩溃，则可以恢复到上一个checkpoint的状态。Checkpoint在此扮演的角色类似一个恢复点（recover point).一旦一个新的checkpoint写入完成并可访问，则会释放上次的checkpoint。Mongodb每60秒或者每2GB journal的时候创建一个checkpoint（即将snaps
11、hot写到磁盘）Journal100MB避免故障重启后丢失上次checkpoint之后的数据,2.2 存储引擎-WiredTiger(4),数据文件db.collection.stats().wiredTiger.uri,2.2 版本选择,Mongodb版本：x.y.zX是主要版本. 功能上要么不变要么就做很大的改动。Y是发行版本号. 这种版本经常更新功能，包括一些新的特性并且常常不向后兼容。偶数是稳定版本，奇数是开发版本。Z版本号是用来修改BUG和安全性。历史版本：2.6.4当前使用版本：3.0.1和3.0.3（WiredTiger存储引擎）建议升级到3.0.7即将发布的新版本：3.2.0D
12、ocument Validationpartial indexesreadConcern: level: left outer join（企业版）,2.3 mongo shell,DBQuery.shellBatchSize = 100注意数值字面量默认是双精度类型help,2.4 mongodb数据模型,和关系型数据库的一个类比：,2.4 mongodb数据模型,一个MongoDB实例可以承载多个数据库，它们之间可视为完全独立的，每个数据库都有独立的权限控制，各自的数据文件。集合就是一组文档，集合可以看作没有模式(shema-less)的表。特殊集合：Capped Collection, T
13、TL Collection文档是MongoDB中数据的基本单元，类似于关系数据库中的行。多个键及其关联的值有序地放置在一起便是文档，类似映射，散列或字典。文档的键是字符串（不能含有0, ., $），文档中的值不仅可以是字符串，也可是其他类型。文档中的键/值对是有序的，不同序则是不同文档。键是区分大小写的，否则为不同文档。文档不能有重复的键，否则非法。,2.5 数据类型基本类型和$type,db.collection.find( field: $type: 8 ); 尽量不要在同一字段上混合类型。注意js(mongo shell) 等一些弱类型语言数值 默认都视为浮点数，在使用时记得做类型转换。
14、,2.5 数据类型比较排序,当比较不同BSON类型的值时，MongoDB使用如下的比较排序，从低到高为：注意：在3.0.0中，Date对象排在Timestamp对象之前。先前版本中，Date和Timestamp对象是同等的。,2.5 数据类型-null,_id:1,cancelDate:null_id:2-db.test.find(cancelDate:null)_id:1,cancelDate:null_id:2-db.test.find(cancelDate:$type:10)_id:1,cancelDate:null-db.test.find(cancelDate:$exists:fal
15、se)_id:2,2.5 数据类型-内嵌文档和数组,通过内嵌冗余文档、数组的方式解决一些事务和join查询的需求。数组元素和内嵌文档字段也可以建索引。在文档中使用数组的时候，同时在文档中维护数组的长度。数组元素经常动态增减且元素过多的，不要使用内嵌数组的方式。数组不是HashSet，尽量不要使用数组来排重。,2.5 数据类型-ObjectId,_id的默认类型时间戳(4byte,秒级)+机器标识(3byte)+PID(2byte)+计数器(3byte)尽量客户端生成，减轻服务端压力,2.5 数据类型-自定义_id,findAndModifyCASReturn new,2.5 数据类型-自定义_
16、id,1）简单的方式（SimpleMongoIdGenerator）: 一次获取一个,2.5 数据类型-自定义_id,2）池化的方式（PooledMongoIdGenerator）：一次获取多个,2.6 BSON,Binary Json，传输和存储所使用的格式16MB更快的遍历速度，操作更简单，扩充的数据类型，无类似sql注入风险优化无需遍历定位，基于记录的长度进行seek数据存储有类型长度可能变化的字段尽量靠后固定不变的数字使用字符串,2.7 GridFS,大于16M小于16M的二进制数据，使用BinData,2.8 模式设计-相关因素,设计需要思考和平衡的因素：程序本身的需求查询，更新等维
17、护不变数据，易变数据数据天然的逻辑层次数据规模mongodb的性能特点单文档原子操作文档增长capped collection数据获取模式随机访问范围查询是否排序,2.8 模式设计-范式与反范式,范式与反范式文档引用手动引用DBRefs内嵌文档，数组优缺点内嵌文档数据更直观，更接近对象的定义。连续存储，一次获取，读取性能好。一个文档，单文档能保证原子事务。内嵌减少文档数量，减少文档本身的杂项开支。数据存在大量冗余，更新维护数据代价大。文档引用减少冗余，数据一致性完整性易维护不支持join，需要多次查询获取采用何种设计，综合前面提到的3个因素做权衡,2.9 CRUD,基本操作增删改查db.col
18、lection.find(query, projection)Return a cursorProjection(如果可以，索引覆盖查询)db.collection.findOne(query, projection)CAS(findAndModify)db.collection.insert( , writeConcern: , ordered: )批量写入varbulk=db.inventory.initializeUnorderedBulkOp(); bulk.insert(); bulk.execute();db.collection.remove( , )db.collection.
19、update( , , upsert: , multi: , writeConcern: )默认multi:falseupdate未使用操作符针对特定字段修改的话，默认行为是覆盖整个文档聚合：基本的聚合函数，pipeline, map-reduce结果超过bson大小限制（16MB)或过程中使用内存超过限制（100MB)，使用map-reduce，并且结果输出到临时表。执行计划之前：db.coll.find().explain()现在：db.coll.explain(verbose).update(query,update)queryPlanner(default，预估)executionSt
20、ats（执行不应用，winning plan）allPlansExecution（执行不应用，all plan）操作符(Operators)尽量不要用$where(javascript，不能使用索引),2.9 CRUD,游标(cursor)Batch 第一批 : 101documents or 1MB, 之后: 4MbatchSize(), limitDBQuery.Option.noTimeout(默认 10min or exhaust)tailable cursorcapped collectionDBQuery.Option.tailableDBQuery.Option.awaitDat
21、a写关注(WriteConcern)w、jUnacknowledgedw=0read uncommitedAcknowledgedw=1默认，read uncommitedJournaledw=1, j=truerollback，read uncommitedReplica Acknowledgedw=2w=majority （推荐）wtimeout,3. 索引,3.1 索引概述3.2 索引的类型3.3 索引的属性3.3 索引的创建、管理3.4 索引交集3.5 覆盖查询3.6 如何发现问题,3.1 索引概述,查询、排序都需要Sort: 32M程序中大部分的读取超时可能都和缺乏/不当索引有关。服
22、务器端CPU，内存，磁盘IO使用率暴增也可能和没有索引相关。避免在业务高峰创建索引，在线创建使用background参数避免阻塞其他操作。注意版本2.6，secondary是在前台创建索引。不要在选择性低的字段创建索引，不要创建无意义或重复的索引。不走索引的情况$nin,$ne前导正则匹配形式的正则表达式Javascript（$where）hint(),3.2 索引的类型,单键索引复合索引复合索引注意创建顺序：选择性，范围查询，排序前缀的查询索引顺序决定索引是否支持直接排序操作(而不需要额外附加一个排序阶段)多键索引数组上的索引，当查询中的值和该数组中的任一值相匹配时，索引匹配成功文本索引全文
23、检索db.reviews.ensureIndex(comments:text)$text哈希索引使用被索引键的值的哈希值来维护索引db.active.ensureIndex(a:hashed)支持相等查询，不支持范围查询地理空间索引,3.3 索引的属性,TTL索引db.collection.ensureIndex(date_field:1,expireAfterSeconds:3600)Since 2.2Background check interval: 1min唯一索引db.members.ensureIndex(user_id:1,unique:true)duplicatekey exc
24、eption，w=1稀疏索引不会索引那些不包含被索引键的文档db.collection.ensureIndex(a:1,sparse:true)部分索引3.2db.restaurants.createIndex( cuisine: 1, name: 1 , partialFilterExpression: rating: $gt: 5 ),3.4 索引的创建、管理,创建db.collection.createIndex( orderDate: 1, zipcode: -1 , background: true)查询db.collection.getIndexes()删除db.pets.drop
25、Index( cat : -1 )db.collection.dropIndexes()将删除_id以外的所有索引修改删除后重建重建所有索引db.collection.reIndex() 不要在线上使用结束索引创建过程db.currentOp()，db.killOp()2.4只能kill background的索引,3.5 索引交集,Since 2.6使用多个索引的交集来匹配查询，在2.6之前只能使用一个索引执行计划：ComplexPlan注意查询和排序不能分别使用不同的索引,3.5 索引覆盖查询,覆盖查询不需要单独一次文档检索，直接查询索引就可返回结果。索引键一般都小于被索引的文档，而且索引
26、一般都在内存中直接可用或者在磁盘上顺序存储。在查询中的所有键都是索引的一部分，并且所有结果集中返回的键也都在同一个索引中。Explain: indexOnly, fetch,3.6 如何发现问题,执行计划explainStage: COLLSCAN, IXSCAN, FETCH(nscannedObjectsnscanned), SORT(scanAndOrder=true)db.currentOp慢查询日志db.setProfilingLevel(level, slowms)Level: 0-none, 1-slow, 2-allshow profile or db.system.profi
27、le.find()mongostatidx miss(2.x)db.serverStatus().indexCounters2.x,4. 复制(Replication),4.1 复制备份4.2 复制基本介绍4.3 oplog4.4 复制节点4.4 选举 4.5 read-preference与write-concern4.6 复制集数据的一致性4.7 rollback与脏读,4.1 复制备份,复制可以离线多长时间？复制集高可用：24*7冗余，故障自动failover，多数据中心部署对用户透明的系统维护升级备份可以丢失多少数据？数据文件灾难恢复程序bug数据损坏人为误操作复制具备一定备份的功能，
28、但不能替代备份,4.2 复制集基本介绍,复制复制是在多台服务器之间同步数据的过程复制的目的failover（故障转移，故障切换，故障恢复）andredundancy（数据冗余）避免单点，用于灾难时恢复，报表处理，提升数据可用性读写分离，分担读压力MongoDB中的复制复制集是由一组mongod实例组成的，这些mongod主要分为两个角色：Primary主节点只能有一个，所有的写请求都是在它上面完成的。主节点会将所有变动（数据，索引等）记录到oplog（类似mysql的binlog）中以支持复制的实现。Secondary从节点接收从主节点上传来的操作(oplog的记录)并重放，以此来保证其与主节
29、点的数据集一致。,4.2 oplog,类似mysql的binlog定容集合(capped collection)local.oplog.rs 没有索引，顺序写，循环滚动primary记录所有引发数据变动的操作，secondary异步复制并在自己机器上重放这些操作以与primary保持数据一致。tailable cursor为了提高复制的效率，复制集中所有节点之间会互相进行心跳检测（通过ping）。每个节点都可以从任何其他节点上获取oplog。oplogSizeMB默认5% avaliable幂等可能产生大量记录rs.printReplicationInfo(),4.3 复制节点,Primary
30、Secondarypriority:0不能成为primary，复制数据，可以提供读，可以参与投票可以用作备用节点hidden:truepriority:0对于客户端程序, mongos不可见，复制数据，不能成为primary，可以投票可用作报表节点或备份节点slaveDelay:3600(s)hidden:true, priority:0延时复制主节点数据，对于客户端程序, mongos不可见，不能成为primary，可以投票Delay时间必须大于或者等于你的维护窗口。必须小于oplog的存储能力可以帮助我们在人为误操作或是其他意外情况下恢复数据Arbiter仲裁节点/投票节点，不复制数据，加
31、入打破投票僵局（偶数成员时，无法形成多数票）Max: 12members(3.x up to 50), 7votes,4.4 选举,副本集使用选举来决定哪个副本集成员将成为primary。选举发生在副本集启动后，任何时候primary变为不可用。primary是副本集中唯一可以接受写操作的成员。如果一个primary变为不可用，选举允许副本集恢复正常操作而不需要人工干预。选举是故障转移过程的一部分,4.4 选举,Heartbeat复制集成员每两秒向复制集中其他成员进行心跳检测影响选举的因素心跳检测：如果某个节点在10秒内没有返回，那么它将被标记为不可用。优先级：优先级设置影响选举。成员将更宁愿
32、投票给优先级值更高的成员。优先级为0的节点将不能成为主节点，也不会发起选举。副本集不会举行选举只要当前primary拥有最高的优先级值或者没有secondary拥有更高优先级并且其操作日志记录的最新操作时间与primary的oplog记录的最新记录相差小于10秒的时候。如果一个更高优先级成员并且其操作日志所记录最新操作时间和当前primay节点记录的时间相差小于10秒的时候，副本集就会举行一次选举以提供一次机会给更高优先级节点成为primary.Optimeoptime是成员最近一次从oplog应用的上一次操作的timestamp。一个副本集成员不能成为primary除非它在副本集所有可见的成
33、员中拥有更高的（也就是最新的）optime连接如果复制集中的某个节点不能连接上其他多数节点，那么它将不能升职为主节点。在选举中，多数是指多数投票而不是多数节点个数。如果复制集是由三个节点组成的，且三个节点均可投票，只要其中两个节点能够互相沟通那么复制集就能选举出新的主节点。如果有两个节点不可用了，那么剩下的节点将为从节点，因为它不能与复制集中多数节点进行沟通。如果两个从节点不可用了，剩下的主节点将降职为从节点。网络隔离网络隔离影响了选举中多数选票的结构。如果主节点不可用了，且每个相互隔离的网络中都没有多数选票的出现，那么复制集将不会选举出新的主节点。复制集将变为只读的。为了避免这种情况的出现，
34、我们需要将多数节点置于主数据中心，少数节点放于其他数据中心,4.4 选举,当复制集中没有主节点可用的时候将触发选举：新复制集的初始化。一个从节点无法与主节点进行连接。当从节点们无法与主节点进行沟通的时候将会触发选举。主节点辞职了。（rs.stepDown(300)）,4.4 选举-Bully算法,Bully(欺负算法)最初集群有5个节点，节点5是一个公认的协调者。假设节点5挂了，并且节点2和节点3同时发现了这一情况。两个节点开始竞选并发送竞选消息给ID更大的节点。节点4淘汰了节点2和3，节点3淘汰了节点2。这时候节点1察觉了节点5失效并向所有ID更大的节点发送了竞选信息。节点2、3和4都淘汰了
35、节点1。节点4发送竞选信息给节点5。节点5没有响应，所以节点4宣布自己 当选并向其他节点通告了这一消息。,4.4 选举-降级,选举还有个前提条件，参与选举的节点数量必须大于副本集总节点数量的一半，如果已经小于一半了所有节点保持只读状态,4.5 Read-Preference与WriteConcern,复制集中的WriteConcernw2Replica Acknowledged默认w=2Read-PreferencePrimary只读主primaryPreferred优先主，主不可用读从Secondary只读从secondaryPreferred优先从，从挂读主Nearest网络延时最小,4.
36、6 复制集数据的一致性,数据读写的强一致性默认，读写都在primaryWriteConcern：w=1Read-Preference：Primary或者配置w参数，使得写操作在应用到所有从节点上才算成功完成（影响写性能）WriteConcern：w=nRead-Preference：secondaryPreferred最终一致性在从节点读，同时不要求写操作应用到从节点上才算成功WriteConcern：w=1Read-Preference：secondaryPreferred,4.7 rollback,回滚(rollback)发生在主节点的写操作没能成功在从节点上应用就辞职的情况下。当主节点重
37、新以一个从节点身份加入复制集时，它将对这部分数据进行“回滚”，使得其上的写操作与复制集中其他成员保持一致。/rollback300MB,5. 分片(Sharding),5.1 分片基本介绍5.2 片键5.3 chunk5.3 config5.4 mongos,5.1 分片基本介绍,什么是分片(sharding)?通过分割数据，负载到多个机器来解决单机存储能力，以及读写性能等瓶颈，达到横向扩展的目的分片针对的基本单位是集合,5.1 分片基本介绍,集群结构和基本流程configmongosshard(mongod/replica set)没有分片的集合存在哪？,5.2 chunk,什么是数据块(c
38、hunk)chunk的分裂chunk的默认大小chunk的迁移均衡迁移触发阈值,5.3 片键,什么是片键设计片键需要注意的问题小基数片键写热点范围查询片键字段需要索引，记录不能为空不能修改哈希片键,5.4 config,配置服务器(config)的作用保存了集群的信息元信息保存了集群的状态和组织结构.元信息包含每个分片保存的数据块信息以及每个数据块的范围,mongos会缓存这些信息用来做读写的路由分发.Chunk分裂、迁移后都会更新维护config上的元信息管理分布式锁配置服务器的可用性如果集群中一个或者两个配置服务器不可用,集群的元信息将变为可读,你还可以从分片中读写信息,但是数据块的迁移以
39、及数据块的分裂在所有配置服务器都恢复可用之前不能够进行.如果所有的三个配置服务器都不可用,在重启mongos之前集群依然可用.但是一旦试图重启mongos,集群将不能提供任何服务.,5.5 mongos,mongos的作用控制读写操作的路由分发（包括未分片集合数据）路由分发过程根据片键路由到部分分片广播所有分片控制chunk的分裂、迁移、均衡分裂（大小，限制）迁移、均衡（迁移阙值，均衡时间窗口）,6. 管理与监控,3.1 备份与恢复mongodump, mongorestoreops manager3.2 导入与导出mongoimport, mongoexport3.3 安全auth-nosc
40、ripting 或 security.javascriptEnabled3.4 监控mongostat, mongotopmms,7. 使用优化案例,7.1 优化索引7.2 优化数组count7.3 优化整型_id生成方式7.4 secondary同步索引操作bug7.5 滥用数组导致的问题7.6 副本集分布式一致性配置引发的性能问题,7.4 secondary同步索引操作bug,问题A系统一次上线过程中，同时进行了索引优化（删除有问题的索引，新建索引）。在这个过程中，系统所在mongod服务器负载飙升。https:/jira.mongodb.org/browse/SERVER-13304分析
41、db.currentOp发现很多长时间运行的读操作，未使用索引。Primary上检查对应读操作执行计划，发现都走索引。停掉secondary，恢复正常。检查程序，发现配置的读写分离。读操作访问的是secondary。登入secondary, 检查对应集合索引，发现在主上执行的创建索引操作并没有成功同步到secondary上。解决在从上手动建立对应缺失索引。,7.5 数组使用不当导致的问题,问题B系统关注、粉丝、喜欢相关接口性能低下。分析系统使用内嵌数组记录关注与粉丝列表、以及喜欢列表。由于关注、粉丝、喜欢的数据变化都比较大（会频繁add元素到数组），这可能导致在添加的过程中，文档预分配空间不足
42、，需要重新分配，影响写入性能。关注、粉丝、喜欢数量增加将有可能超过BSON大小限制。关注、粉丝、喜欢排序分页获取，查找、删除指定元素无法高效实现。程序中使用数组的$addToSet进行排重。解决改变数据结构，取消内嵌数组，使用单独的表逐行记录。,7.6 副本集分布式一致性配置引发的性能问题,问题C系统写入性能不好，各接入系统调用其写入接口频繁报读取超时。分析系统最大表数据1000多万，数据文件大小几GB，数据量不大。对应副本集配置：1primary + 2secondary + 1arbiter在对应副本集上进行监控：primary上写操作并发不高20-60ops，没有读取操作，无阻塞的操作s
43、econdary上有读取量但也不高，也大概只有几十ops，没有阻塞的操作检查程序中写关注和读偏向配置：REPLICAS_SAFE+secondaryPreferred写primary成功，并且1个secondary同步对应写操作成功，对应写请求才返回响应给客户端。读写分离。在高并发写的情况下，oplog增长太快，secondary无法迅速同步跟上primary，导致需要花费比较长时间才能返回写操作成功，影响写效率。根据业务介绍，有冷数据处理流程，程序里可能有没有加条件的update或remove操作，由于oplog的幂等型处理，对应的操作可能在oplog中生成大量记录，这同时也加剧了上面的分析。解决ACKNOWLEDGED + primary修改写关注为默认的主确认，加速写操作返回。取消读写分离，读写都在主库，保证数据一致性。取消一个从节点，减少复制开销，奇数投票节点mongodb3.x的wiredTiger引擎，已经支持行级别的读写锁（2.6是库级别），所以即使不读写分离，读写也不会相互影响很大。而且高并发写情况下，secondary因为要同步oplog，其实和primary面临差不多的写压力，再加上读操作，压力和不读写分离区别不大。,THANK YOU,
