@@ -20,7 +20,7 @@ msgstr ""
20
20
# f14076a40ed7482fbcf10ab9a9628c1a
21
21
#: ../source/core/data-model-operations.txt:3
22
22
msgid "Operational Factors and Data Models"
23
- msgstr ""
23
+ msgstr "MongoDB特性和数据模型的关系 "
24
24
25
25
# dd06504f1172476486ca2536f4c9a763
26
26
#: ../source/core/data-model-operations.txt:7
@@ -31,6 +31,9 @@ msgid ""
31
31
"throughput of insert and update operations, or distribute activity to a "
32
32
"sharded cluster more effectively."
33
33
msgstr ""
34
+ "MongoDB的数据建模不仅仅取决于应用程序的数据需求,也需要考虑到MongoDB本身的一些特性。"
35
+ "例如,有些数据模型可以让查询更加有效,有些可以增加插入或更新的并发量,有些则可以更有效"
36
+ "地把事务均衡到各个分片服务器上。"
34
37
35
38
# 39804f49724b483285f1e71c983485f9
36
39
#: ../source/core/data-model-operations.txt:13
@@ -41,11 +44,16 @@ msgid ""
41
44
"operations </core/read-operations>` and :doc:`write operations </core/write-"
42
45
"operations>` in conjunction with the following considerations."
43
46
msgstr ""
47
+ "这些因素是和MongoDB的 *运行* 相关的,并不完全基于应用程序的需求,但是却对"
48
+ "应用程序的性能会有直接的影响。当进行建模设计时,在分析应用程序所有的"
49
+ " :doc:`读操作 </core/read-operations>` 和 :doc:`写操作 </core/write-"
50
+ "operations>` 的前提下,你还需要考虑下述几个因素。"
51
+
44
52
45
53
# e513be50123b41798716e6159da8439e
46
54
#: ../source/core/data-model-operations.txt:23
47
55
msgid "Document Growth"
48
- msgstr ""
56
+ msgstr "文档增长性 "
49
57
50
58
# 3afc6cb77214444cb8ff51245515af0d
51
59
#: ../source/core/data-model-operations.txt:35
@@ -54,6 +62,8 @@ msgid ""
54
62
"growth, you may want to refactor your data model to use references between "
55
63
"data in distinct documents rather than a denormalized data model."
56
64
msgstr ""
65
+ "举例来说,如果你的程序的更新操作会导致文档大小增加,那么你可能要重新设计下数据模型,"
66
+ "在不同文档之间使用引用的方式而非内嵌、冗余的数据结构。"
57
67
58
68
# bbc7429c52734b0ca4fcd1d615026b03
59
69
#: ../source/core/data-model-operations.txt:40
@@ -64,18 +74,22 @@ msgid ""
64
74
"Reports Use Case </use-cases/pre-aggregated-reports>` for an example of the "
65
75
"*pre-allocation* approach to handling document growth."
66
76
msgstr ""
77
+ "MongoDB会自动调整空白填充的大小以尽可能的减小文档迁移。你也可以使用一个"
78
+ " *预分配* 策略来防止文档的增长。 具体关于使用 *预分配* 来处理文档增长的例子可以参见"
79
+ " :ecosystem:`预聚合报表案例 </use-cases/pre-aggregated-reports>` "
67
80
68
81
# e89a437e3d7f49b3becf1c5772c13ef2
69
82
#: ../source/core/data-model-operations.txt:47
70
83
msgid ""
71
84
"See :doc:`/core/storage` for more information on MongoDB's storage model and"
72
85
" record allocation strategies."
73
86
msgstr ""
87
+ "关于MongoDB's 存储模式和记录分配策略的更多信息,请参见 :doc:`/core/storage`。"
74
88
75
89
# 2fac3cab68ae4c80a566808c5d69584e
76
90
#: ../source/core/data-model-operations.txt:54
77
91
msgid "Atomicity"
78
- msgstr ""
92
+ msgstr "原子性 "
79
93
80
94
# ae6124ad6f2c4f489bff1715a108f194
81
95
#: ../source/core/data-model-operations.txt:56
@@ -88,6 +102,11 @@ msgid ""
88
102
"If the application can tolerate non-atomic updates for two pieces of data, "
89
103
"you can store these data in separate documents."
90
104
msgstr ""
105
+ "在MongoDB里面,所有操作在 :term:`document` 级别具有原子性. 一个 "
106
+ "**单个** 写操作最多只可以修改一个文档。 即使是一个会改变同一个集合中多个文档的命令,"
107
+ "在同一时间也只会操作一个文档。 [#record-atomicity]_ 尽可能保证那些需要在一个原子操作内"
108
+ "进行修改的字段定义在同一个文档里面。如果你的应用程序允许对两个数据的非原子性更新操作,"
109
+ "那么可以把这些数据定义在不同的文档内。"
91
110
92
111
# 2b19e9a31c4c4b01b2be0fa42157f47c
93
112
#: ../source/core/data-model-operations.txt:65
@@ -97,13 +116,17 @@ msgid ""
97
116
"related pieces of data, the application must issue separate read and write "
98
117
"operations to retrieve and modify these related pieces of data."
99
118
msgstr ""
119
+ "把相关数据定义到同一个文档里面的内嵌方式有利于这种原子性操作。对于那些使用引用来关联"
120
+ "相关数据的数据模型,应用程序必须再用额外的读和写的操作去取回和修改相关的数据。"
121
+
100
122
101
123
# 4b1834b946674518b90eebd8e2e7f597
102
124
#: ../source/core/data-model-operations.txt:71
103
125
msgid ""
104
126
"See :ref:`data-modeling-atomic-operation` for an example data model that "
105
127
"provides atomic updates for a single document."
106
128
msgstr ""
129
+ "关于原子性操作更新单个文档的例子,参见 :ref:`data-modeling-atomic-operation`。 "
107
130
108
131
# 236516daec9e4edca6cae4f283ee9fbd
109
132
#: ../source/core/data-model-operations.txt:74
@@ -112,11 +135,13 @@ msgid ""
112
135
"MongoDB document record: operations that affect multiple sub-documents "
113
136
"within that single record are still atomic."
114
137
msgstr ""
138
+ "文档级原子性操作包含所有针对于一个文档的操作: 即便是涉及到多个子文档的多个操作,只要是"
139
+ "在同一个文档之内,这些操作仍旧是有原子性德。"
115
140
116
141
# abf5cfa786244d6d93080d7c397c6e9d
117
142
#: ../source/core/data-model-operations.txt:80
118
143
msgid "Sharding"
119
- msgstr ""
144
+ msgstr "分片 "
120
145
121
146
# 0f1c46264b894707a5c3a4a88b64987e
122
147
#: ../source/core/data-model-operations.txt:82
@@ -127,6 +152,9 @@ msgid ""
127
152
"database to distribute the collection's documents across a number of "
128
153
":program:`mongod` instances or :term:`shards <shard>`."
129
154
msgstr ""
155
+ "MongoDB 使用 :term:`sharding` (分片)来实现水平扩展。使用分片的集群可以支持海量的数据"
156
+ "和高并发读写。用户可以使用分片技术把一个数据库内的某一个集合的数据进行分区,从而达到把数据"
157
+ "分布到多个 :program:`mongod` 实例(或分片上)的目的。"
130
158
131
159
# faf0cfc9bb6b4a519232a419f554f05e
132
160
#: ../source/core/data-model-operations.txt:89
@@ -137,18 +165,22 @@ msgid ""
137
165
" prevent query isolation and increased write capacity. It is important to "
138
166
"consider carefully the field or fields to use as the shard key."
139
167
msgstr ""
168
+ "Mongodb 依据 :ref:`分片键 <shard-key>` 分发数据和应用程序的事务请求。 选择一个合适的"
169
+ "分片键会对性能有很大的影响,也会促进或者阻碍MongoDB的定向分片查询和增强的写性能。"
170
+ "所以在选择分片键时候要仔细考量分片键盘所用的字段。"
140
171
141
172
# 1d0e0d83902b45eab5f065ddbd217c30
142
173
#: ../source/core/data-model-operations.txt:96
143
174
msgid ""
144
175
"See :doc:`/core/sharding-introduction` and :doc:`/core/sharding-shard-key` "
145
176
"for more information."
146
177
msgstr ""
178
+ "更多信息请参见 :doc:`/core/sharding-introduction` 及 :doc:`/core/sharding-shard-key`"
147
179
148
180
# 6cf286141d2c4bf6ad544225faae32b7
149
181
#: ../source/core/data-model-operations.txt:102
150
182
msgid "Indexes"
151
- msgstr ""
183
+ msgstr "索引 "
152
184
153
185
# c4ec41b3e83749eaa0cc0dbe4895e8c3
154
186
#: ../source/core/data-model-operations.txt:104
@@ -158,16 +190,18 @@ msgid ""
158
190
"sorted results. MongoDB automatically creates a unique index on the ``_id`` "
159
191
"field."
160
192
msgstr ""
193
+ "对常用操作可以使用索引来提高性能。对查询条件中常见的字段,以及需要排序的字段创建索引。"
194
+ "MongoDB会对 ``_id`` 字段自动创建唯一索引。"
161
195
162
196
# f54f2a9ad20e41af87e0991f0128f3b3
163
197
#: ../source/core/data-model-operations.txt:109
164
198
msgid "As you create indexes, consider the following behaviors of indexes:"
165
- msgstr ""
199
+ msgstr "创建索引时,需要考虑索引的下述特征: "
166
200
167
201
# 72231468638344049cea37901bc98b8c
168
202
#: ../source/core/data-model-operations.txt:111
169
203
msgid "Each index requires at least 8KB of data space."
170
- msgstr ""
204
+ msgstr "每个索引需要至少8KB的空间。 "
171
205
172
206
# 8a95b086358b4b81b646e64b5967dbd5
173
207
#: ../source/core/data-model-operations.txt:113
@@ -176,13 +210,17 @@ msgid ""
176
210
"For collections with high write-to-read ratio, indexes are expensive since "
177
211
"each insert must also update any indexes."
178
212
msgstr ""
213
+ "每增加一个索引,就会对写操作性能有一些影响。对于一个写多读少的集合,索引会变得很费时"
214
+ "因为每个插入必须要更新所有索引。"
179
215
180
216
# 05e68b2601d742028b516d4a80acaad6
181
217
#: ../source/core/data-model-operations.txt:117
182
218
msgid ""
183
219
"Collections with high read-to-write ratio often benefit from additional "
184
220
"indexes. Indexes do not affect un-indexed read operations."
185
221
msgstr ""
222
+ "每增加一个索引,就会对写操作性能有一些影响。对于一个写多读少的集合,索引会变得很费时"
223
+ "因为每个插入必须要更新所有索引。"
186
224
187
225
# ade269abce404e31952d1ed33eaef26d
188
226
#: ../source/core/data-model-operations.txt:120
@@ -191,6 +229,8 @@ msgid ""
191
229
"significant and should be tracked for capacity planning, especially for "
192
230
"concerns over working set size."
193
231
msgstr ""
232
+ "每个索引都会占一定的硬盘空间和内存(对于活跃的索引)。索引有可能会用到很多这样的资源,"
233
+ "因此对这些资源要进行管理和规划,特别是在计算热点数据大小的时候。"
194
234
195
235
# b347391d6c0f4815b4f9e3899d0d698d
196
236
#: ../source/core/data-model-operations.txt:124
@@ -200,18 +240,24 @@ msgid ""
200
240
":doc:`database profiler </tutorial/manage-the-database-profiler>` may help "
201
241
"identify inefficient queries."
202
242
msgstr ""
243
+ "关于索引的更多信息请参见 :doc:`/applications/indexes` 以及 "
244
+ ":doc:`/tutorial/analyze-query-plan/`。另外, MongoDB的 "
245
+ ":doc:`database profiler </tutorial/manage-the-database-profiler>` 可以帮你"
246
+ "找出一些使用索引不当而导致低效的查询。"
247
+
203
248
204
249
# 87fe1d3332af44e58acc2e945ed63d02
205
250
#: ../source/core/data-model-operations.txt:132
206
251
msgid "Large Number of Collections"
207
- msgstr ""
252
+ msgstr "集合的数量 "
208
253
209
254
# c3f260f33ef54976aa5c2a431741c974
210
255
#: ../source/core/data-model-operations.txt:134
211
256
msgid ""
212
257
"In certain situations, you might choose to store related information in "
213
258
"several collections rather than in a single collection."
214
259
msgstr ""
260
+ "在某些情况下,你可能会考虑把相关的数据保存到多个而不是一个集合里面。"
215
261
216
262
# 82fc7a0c6070408ca0fec2e655f8ba7d
217
263
#: ../source/core/data-model-operations.txt:137
@@ -220,6 +266,9 @@ msgid ""
220
266
"environment and applications. The ``logs`` collection contains documents of "
221
267
"the following form:"
222
268
msgstr ""
269
+ "我们来看一个样本集合 ``logs`` ,用来存储不同环境和应用程序的日志。 "
270
+ "这个 ``logs`` 集合里面的文档例子:"
271
+
223
272
224
273
# 63d089aadd5f48b5ad69038e0340a45f
225
274
#: ../source/core/data-model-operations.txt:152
@@ -228,25 +277,28 @@ msgid ""
228
277
"performance penalty and results in very good performance. Distinct "
229
278
"collections are very important for high-throughput batch processing."
230
279
msgstr ""
280
+ "一般来说,很大的集合数量对性能没有什么影响,反而在某些场景下有不错的性能。"
281
+ "使用不同的集合在高并发批处理场景下会有很好的帮助。"
231
282
232
283
# e8b2797d0de1439da9b0f34876fe96e6
233
284
#: ../source/core/data-model-operations.txt:156
234
285
msgid ""
235
286
"When using models that have a large number of collections, consider the "
236
287
"following behaviors:"
237
288
msgstr ""
289
+ "当使用有大量集合的数据模型时,请注意一下几点:"
238
290
239
291
# 1413106c08a04db18c322077985311af
240
292
#: ../source/core/data-model-operations.txt:159
241
293
msgid "Each collection has a certain minimum overhead of a few kilobytes."
242
- msgstr ""
294
+ msgstr "每一个集合有几个KB的额外开销。 "
243
295
244
296
# 00f7f72745a642e78d8f4d28b33d7c1c
245
297
#: ../source/core/data-model-operations.txt:161
246
298
msgid ""
247
299
"Each index, including the index on ``_id``, requires at least 8KB of data "
248
300
"space."
249
- msgstr ""
301
+ msgstr "每一个索引,包括默认的 ``_id`` 索引, 需要至少8KB的空间。 "
250
302
251
303
# ea25c6ecc5bd4333a869258996532cba
252
304
#: ../source/core/data-model-operations.txt:164
@@ -256,6 +308,9 @@ msgid ""
256
308
"its own entry in the namespace file. MongoDB places :limit:`limits on the "
257
309
"size of namespace files <Size of Namespace File>`."
258
310
msgstr ""
311
+ "每一个MongoDB的 :term:`database` 有一个且仅一个命名文件(namespace file)(i.e. ``<database>.ns``) 。"
312
+ "这个命名文件保存了数据库的所有元数据。每个索引和集合在这个文件里都有一条记录。"
313
+ "这个文件的大小是有限制的,具体信息请参见: :limit:` 命名文件大小限制 <Size of Namespace File>`。"
259
314
260
315
# e500fa36f29e4b1ea21913ba396a8b18
261
316
#: ../source/core/data-model-operations.txt:170
@@ -266,13 +321,18 @@ msgid ""
266
321
"get the current number of namespaces, run the following in the "
267
322
":program:`mongo` shell:"
268
323
msgstr ""
324
+ "MongoDB 的命名文件有大小的限制: :limit:`limits on the number of namespaces <Number of "
325
+ "Namespaces>`。 你可能希望知道当前命名文件的限制 - 你可以通过在"
326
+ " :program:`mongo` shell: 下面执行下述命令:"
269
327
270
328
# b22716f4be444370aceb2d8589eb5f69
271
329
#: ../source/core/data-model-operations.txt:182
272
330
msgid ""
273
331
"The limit on the number of namespaces depend on the ``<database>.ns`` size. "
274
332
"The namespace file defaults to 16 MB."
275
333
msgstr ""
334
+ "一个命名文件中可以容纳的命名记录数取决于命名文件 ``<database>.ns`` 文件的大小。 "
335
+ "命名文件默认的最大文件是16 MB。"
276
336
277
337
# ae287cd6e7574ec885ec1c2c8c102de7
278
338
#: ../source/core/data-model-operations.txt:185
@@ -284,27 +344,36 @@ msgid ""
284
344
"impacts and considerations on running :method:`db.repairDatabase()`, see "
285
345
":dbcommand:`repairDatabase`."
286
346
msgstr ""
347
+ "如欲指定*新的*命名文件的大小,使用下述参数启动 mongod: "
348
+ " :option:`--nssize \\ <new size MB\\ > <--nssize>`。针对于已有的数据库"
349
+ "在使用参数 :option:`--nssize` 启动之后, 再在 :program:`mongo` 下面运行命令"
350
+ " :method:`db.repairDatabase()` 。 运行 :method:`db.repairDatabase()` 的时候"
351
+ "有一些注意事项,详情请参见 :dbcommand:`repairDatabase` 。"
287
352
288
353
# f1194abdcdad498095a4f9a9fcd266cf
289
354
#: ../source/core/data-model-operations.txt:194
290
355
msgid "Data Lifecycle Management"
291
- msgstr ""
356
+ msgstr "数据生命周期 "
292
357
293
358
# 853f694f41c7479b9acaa1f9a43d1527
294
359
#: ../source/core/data-model-operations.txt:196
295
360
msgid ""
296
361
"Data modeling decisions should take data lifecycle management into "
297
362
"consideration."
298
363
msgstr ""
364
+ "在做数据建模方面的决定时我们也需要考虑数据的生命周期。"
299
365
300
366
# 845eba8d052c475faca7a7ea53b526e0
301
367
#: ../source/core/data-model-operations.txt:199
302
368
msgid ""
303
- "The :doc:`Time to Live or TTL feature </tutorial/expire-data>` of "
369
+ "MongoDB :doc:`Time to Live or TTL feature </tutorial/expire-data>` of "
304
370
"collections expires documents after a period of time. Consider using the TTL"
305
371
" feature if your application requires some data to persist in the database "
306
372
"for a limited period of time."
307
373
msgstr ""
374
+ "MongoDB集合的 :doc:`Time to Live or TTL feature </tutorial/expire-data>` 功能 "
375
+ "可以用来自动删除一些有效期到期的数据。 如果你的应用程序中有这样一些数据,他们只需要在"
376
+ "数据库中保留一段时间,比如说几个小时或者几天,那么你可以考虑采用 TTL 功能来实现这一点。"
308
377
309
378
# 3961ee91cb3849e694ef634be25d2725
310
379
#: ../source/core/data-model-operations.txt:204
@@ -314,6 +383,10 @@ msgid ""
314
383
"in-first-out* (FIFO) management of inserted documents and efficiently "
315
384
"support operations that insert and read documents based on insertion order."
316
385
msgstr ""
386
+ "另外,如果你的应用程序只需要使用最近一段时间插入的文档,你也可以考虑使用 ``封顶集合`` "
387
+ " (:doc:`/core/capped-collections`)。 封顶集合采用先进先出 *first-"
388
+ "in-first-out* (FIFO) 的策略管理插入的文档。它对插入文档和按插入顺序读文档的操作"
389
+ "有非常好的支持。"
317
390
318
391
#: ../source/core/data-model-operations.txt:25
319
392
msgid ""
@@ -326,6 +399,12 @@ msgid ""
326
399
"allocations <record-allocation-strategies>` to minimize the likelihood of "
327
400
"relocation, data models should avoid document growth when possible."
328
401
msgstr ""
402
+ "有一些更新操作会导致文档的大小增加,例如添加元素到数组 (i.e. :update:`$push`) "
403
+ "以及在文档内添加新的字段等。 加入文档的大小超出原先分配给它的空间, MongoDB会把这个"
404
+ "文档迁移到硬盘的另外一个位置。迁移文档比 *原位更新* 要耗时,也会因此而导致磁盘的碎片问题。"
405
+ "虽然MongoDB会采取一些手段去尽可能防止这种迁移的发生,如在文档插入时候会对其"
406
+ " :ref:`额外分配填充空间 <record-allocation-strategies>`,"
407
+ "在做数据建模的时候还是要考虑尽可能做到减少文档的增长。"
329
408
330
409
#: ../source/core/data-model-operations.txt:146
331
410
msgid ""
@@ -334,6 +413,9 @@ msgid ""
334
413
" such as ``logs_dev`` and ``logs_debug``. The ``logs_dev`` collection would "
335
414
"contain only the documents related to the dev environment."
336
415
msgstr ""
416
+ "如果文档的总数不是很大,你可以把文档按类型进行分组。在日志这个应用场景,不同的环境可以"
417
+ "考虑使用不同的集合,如``logs_dev`` 及 ``logs_debug`` 等。 其中 ``logs_dev`` 集合"
418
+ "包含所有dev环境中的文档。"
337
419
338
420
#~ msgid ""
339
421
#~ "Some updates to documents can increase the size of documents. These updates "
0 commit comments