- 1hive相关命令_hive关闭命令
- 2PyTorch最佳实践和代码编写风格指南_background generator dataloader
- 3最全AI领域知识星球：GoAI的学习社区_人工智能相关的知识星球
- 4Spring Boot(八十一)：Sa-Token快速实现API接口签名安全校验
- 5Android插件化之DexClasssLoader动态加载apk(Java代码和资源文件)_dexloader模块
- 6【蓝桥杯预备营集结三】软件类 C/C++ 预备试题分析及解答_rddddddddddddd
- 7合合信息大模型“加速器”重磅上线
- 8图解大模型计算加速系列：Flash Attention V1，从硬件到计算逻辑
- 9贪心算法举例详解_假设以下列贪心思想解决最小顶点覆盖问题:重复选择度数最高的顶点,并去 掉所有邻
- 10Proteus仿真实例_基于STM32单片机的电子密码锁系统（仿真文件+程序）24-32f-37_stm32仿真文件
mongodb2.0的改进
赞
踩
dream feature coming from mongodb 2.0
2011-09-14 15:35:49| 分类： MongoDB | 标签：mongodb 2.0 feature |字号 订阅
mongoDB 2.0已经发布,带来了许多令人振奋的特性,越来越像企业级的数据库了.
下面简单的介绍一下,
1. compact command
compact 命令主要的功能是重组collection,重建索引，类似整理碎片。2.0以前需要通过repair database来达到同样的目的，因此会中断全库的操作。compact 只中断单个collection的操作。同时compact操作不会被复制，因此在replica set环境，SLAVE节点也需要做同样的操作才能达到整理碎片的目的。
3. default stack size
默认stack size值降低到1MB或者小于系统默认设置，当数据库被连接数量很大（如>1000个连接）是可以减少mongod线程的内存开销。
4. index performance enhancements
mongoDB2.0的索引比以前来说，空间占用约减少25%，性能提升25%。在建立索引的时候需要加上{v:1}的标记位。如果不想使用新的索引格式，标记为{v:0}。因此如果加了{v:1}从2.0降级到1.8需要重建索引。
5. sharding authorizaiton
以前sharding是不支持auth的，会产生BUG。现在支持了。
6. replica set enhancements
6.1 priorities
以前replica set支持的优先级只有0和1，即0不提升为primary，1可以提升为primary。现在的优先级范围是0到1000的浮点型数值。
例如：
A的优先级是4 （primary）
B的优先级是2
C的优先级是3
当A挂掉了，或者不可用。选举发生的时候，如果B和C的up-to-date一致 (并且与primary的数据差异在10秒内)。那么C会被选举为primary。
如果C和A的差异超过了10秒，那么B将被选举为PRIMARY。如果B和C都进入了up-to-date状态，但是B比较接近A，那么还是C被选举为PRIMARY。而B将产生一个ROLLBACK文件，需要手工ROLLBACK超过C的部分数据。
这里算是高可用的一个折中方案吧。对于数据要求严谨的可能不太适用。
6.2 datacenter awareness
这是一个令人期待的特性，在做系统架构设计时，可以考虑到数据库节点的地域分布，机架分布。给replica set里的每个member都打上1个或者多个TAG。
利用这些TAG，和getLastError，可以控制这条DML操作需要在多少个打了某个你需要的TAG的MEMBER里面成功之后才返回。
例如，
Make sure there are at least three copies of the data and it is present on at least two continents.
All of the rules up until now have only had one condition, but you can include as many and-conditions as you want. Suppose we have the following:
| Server | Tags |
| S1 | {"continent" : "nAmerica", "copies" : "S1"} |
| S2 | {"continent" : "nAmerica", "copies" : "S2"} |
| S3 | {"continent" : "Europe", "copies" : "S3"} |
| S4 | {"continent" : "Africa", "copies" : "S4"} |
| S5 | {"continent" : "Asia", "copies" : "S5"} |
Then create a mode like:
level : {copies : 3, continent : 2}
Note that modes can contain as many clauses as you need.
{ _id : replSetName, members : [ { “_id” : 0, “host” : S1, “tags” : {"continent" : "nAmerica","copies" : "S1"} }, ... ], settings : { getLastErrorModes : { level : {copies : 3,continent : 2} } } }
使用下面的命令插入数据时，确保数据至少有3个拷贝，并且在2个地域被写入。
db.foo.insert(doc, {w : "level"})
6.3 w:"majority"
majority可以认为是少数服从多少的意思，如5个节点的replica set。majority就是3。
db.foo.insert(doc, {w : "majory"})
在5个节点的replica set环境。表示至少有3个节点被写入才返回正常。
7. journal 增强
7.1 journal压缩后写入磁盘，缩短了写入时间，降低磁盘占用。
7.2 2.0开始，journalCommitInterval支持配置，默认是100MS。配置范围2到300毫秒。
其实这个journal有点类似PostgreSQL在配置了synchronous_commit = off 时的wal_writer_delay 参数。
间隔多少时间做一次FSYNC,把journal的缓存写入到磁盘。
7.3 {j: true}
DML操作时可以使用这个参数，使用之后journal会被立即写入到磁盘，不必等待journalCommitInterval的发生。使用这个参数那么这笔DML操作即达到了ACID的D的要求。
其他的可以参看release notes.
【参考】
http://www.mongodb.org/display/DOCS/2.0+Release+Notes
| Index Performance Enhancements Reconfiguration with a minority up Primary checks for a caught up secondary before stepping down Extended shutdown on the primary to minimize interruption New ContinueOnError option for bulk insert Output to a sharded collection · See Also Although the major version number has changed, MongoDB 2.0 is a standard, incremental production release and works as a drop-in replacement for MongoDB 1.8. However, there are a few changes you must be aware of before attempting to upgrade: 1 If you create new indexes in 2.0, then downgrading to 1.8 is possible but reindexing the new collections will be required. 2 mongoimportand mongoexport now correctly adhere to the CSV spec for handling CSV input/output. This may break existing import/export workflows if they relied on the broken behavior. For more information see the related JIRA case. 3 Journalingis enabled by default in 2.0 for 64-bit builds. If you still prefer to run without journaling, start mongod with the --nojournal option. Otherwise, the journal files will be created on startup. The first time you start mongod with journaling, you will see a delay while the new files are being created. In addition, you may see reduced write throughput. · 2.0 processes can talk to 1.8 processes and vice versa, so you can upgrade various parts of a cluster in any order. · To upgrade a standalone server. Shutdown the old mongod and then restart with the new mongod binary. You can download the v2.0 binaries from the MongoDB Download Page. · To upgrade a replica set. Upgrade the secondaries first one at a time, then stepDown the primary and upgrade the primary. Using the stepDown command is better than simply shutting it down since the failover will happen quicker. To avoid losing the last few updates on failover you can temporarily halt your application (failover should take less than 10 seconds) or change your application code to confirm that each update reaches multiple servers. Note, after upgrading to 2.0 you can use the shutdown command to shutdown the primary without losing any safe updates. · To upgrade a sharded cluster. Upgrade config servers one at a time, in any order. Since config servers use two phase commit, shard configuration metadata updates will halt until all are up and running. mongos routers can be upgraded in any order. A compact command is now available for compacting a single collection and its indexes. Previously, the only way to compact was to repair the entire database. When going to disk, the server will yield the write lock if the data being acted upon isn't likely to be in memory. The initial implementation of this feature now exists: (SERVER-2563) The specific operations yield in 2.0 are: · Updates by _id · Removes · Long cursor iterations The default stack size has been reduced. This can reduce total memory usage when there are many (e.g., 1000+) client connections, as there is a thread per connection. While portions of a thread's stack can be swapped out if unused, some operating systems do this slowly enough that it might be an issue. The stack size will be set to the lesser of the system setting or 1MB. Index Performance Enhancements v2.0 includes significant improvements to the index structures. Indexes are often 25% smaller and 25% faster (depends on the use case). When upgrading from previous versions, the benefits of the new index type are realized only if you create a new index or re-index an old one. Dates are now signed, and the max index key size has increased slightly from 819 to 1024 bytes. Once you create new indexes, downgrading to 1.8.x will require a re-index of any indexes created using 2.0. Authentication can now be used with sharded clusters. Each replica set node can now have a priority value consisting of a floating-point from 0 to 1000, inclusive. Priorities let you control which member of the set you prefer to have as primary: the member with the highest priority that can see a majority of the set will be elected primary. For example, suppose we have a replica set with three nodes:
During normal operation, B will always be chosen as primary. If B goes down, A will be elected primary. See the priorities documentation for more information. You can now "tag" replica set members to indicate their location. You can use these tags to design custom write rules across data centers, racks, specific servers, or any other architecture choice. For example, a DBA could define rules such as "very important write" or "customerData" or "audit-trail" to be replicated to certain servers, racks, data centers, etc. Then in the application code, the developer would say: > db.foo.insert(doc, {w : "very important write"}) which would succeed if it fulfilled the conditions the DBA defined for "very important write". See the tagging documentation for more information. Your driver may also support tag-aware reads. Instead of simply specifying slaveOk, you specify slaveOk with tags indicating which data-centers you want to read from. See your driver for details. You can also set w to "majority" to ensure that a write has been propagated to a majority of nodes, effectively committing it. The value for "majority" will automatically be adjusted as you add or remove nodes from the set. See the majority docs for more information. Reconfiguration with a minority up If the majority of servers in a set has been permanently lost, you can now force a reconfiguration of the set to bring it back online. See more information on Reconfiguring a replica set when members are down. Primary checks for a caught up secondary before stepping down To minimize time without a primary, the stepDown command will now fail if the primary does not see a secondary within 10 seconds of its latest optime. You can force the primary to step down anyway, but by default it will return an error message. See also Forcing a Member to be Primary. Extended shutdown on the primary to minimize interruption When you call the shutdown command the primary will refuse to shut down unless there is a secondary whose optime is within 10 seconds of the primary. If such a secondary isn't available, the primary will step down and wait up to a minute for the secondary to be fully caught up before shutting down. Note that to get this behavior, you must issue the shutdown command explicitly; sending a signal to the process will not trigger this behavior. You can also force the primary to shut down, even without an up-to-date secondary available. When repair or compact is run on a secondary, the secondary will automatically drop into "recovering" mode until the operation is finished. This prevents clients from trying to read from it while it's busy. Indexing is now supported on documents which have multiple location objects, embedded either inline or in nested sub-documents. Additional command options are also supported, allowing results to be returned with not only distance but the location used to generate the distance. See the Geospatial documentation for further information. Polygonal $within queries are also now supported for simple polygon shapes. Details are here. · Journaling is now enabled by default for 64-bit platforms. Use the --nojournal command line option to disable it. · The journal is now compressed for faster commits to disk. · A new --journalCommitInterval command line option exists for specifying your own group commit interval. 100ms is the default (same as in 1.8). · A new getLastError {j: true} option is available to wait for the group commit. The group commit will happen sooner when a client is waiting on {j: true}. If journaling is disabled, {j: true} is a no-op. New ContinueOnError option for bulk insert When this flag is set (see your driver on how to set it), bulk insert will continue to insert any remaining documents even if an insert fails (due, for example, to a duplicate key). The getLastError command will report whether any doc inserts have failed (not just last one). If multiple errors occur, only the most recent will be reported by getLastError. See OP_INSERT. Output to a sharded collection Using the new flag "sharded" it is possible to send the result of a map/reduce to a sharded collection. Combined with the "reduce" or "merge" flags, it is possible to keep adding data to very large collections from map/reduce jobs. See documentation of output options. Map/reduce performance will benefit from the following: · larger in-memory buffer sizes, reducing the amount of disk I/O needed during a job · larger javascript heap size, allowing for larger objects and less GC · supports pure JS execution with the jsMode flag. Allows the dot (.) to match all characters including new lines. This is in addition to the currently supported i, m and x. See Using regular expressions in queries. A special boolean $and query operator is now available. The output of the Validate Command and the documents in the system.profile collection have both been enhanced to return information as BSON objects with keys for each value rather than as free-form strings. You can define a custom prompt for the mongo shell. You can change the prompt at any time by setting the prompt variable to a string or a custom JavaScript function returning a string. See the documentation for examples. On startup, the shell will check for a .mongorc.js file in the user's home directory. The shell will execute this file after connecting to the database and before displaying the prompt. If you would like the shell not to run the .mongorc.js file automatically, start the shell with --norc. See .mongorc.js documentation. |
