MongoDB2.6 release-KellyStirman interview

Abstract: For NoSQL users, MongoDB does not need to be introduced. KellyStirman, marketing director of MongoDB, answered related questions about the latest stable version 2.6. Finally, apart from other updates, we also obtained further information about the set-Level Lock, which is the most concerned in the MongoDBjira tracking system... For NoSQL users, MongoDB does not

Abstract: For NoSQL users, MongoDB does not need to be introduced. Kelly Stirman, marketing director of MongoDB, answered related questions about the latest stable version 2.6. Finally, apart from other updates, we also obtained further information about the set-Level Lock, which is the most concerned in the MongoDB jira tracking system... For NoSQL users, MongoDB does not

Summary: For NoSQL users, MongoDB does not need to be introduced. Kelly Stirman, marketing director of MongoDB, answered related questions about the latest stable version 2.6. Finally, in addition to other updates, we also obtain further information about the set-Level Lock, which is the most concerned in the MongoDB jira tracking system...

For NoSQL users, MongoDB does not need to be introduced. Kelly Stirman, marketing director of MongoDB, answered related questions about the latest stable version 2.6. Finally, in addition to other updates, we also obtained further information about the set-Level Lock, which is a feature request with the highest degree of attention and the most votes in the MongoDB jira tracking system.

In MongoDB, storage fragments can cause unexpected delays when updates force the engine to move documents in BSON storage. Could you explain how version 2.6 helps ease this problem?

If there is enough space, the data will be updated in the original place when the document is updated in MongoDB. If the size of the updated document is greater than the allocated space, the document will be overwritten in a new location. MongoDB will eventually reuse the original space, but this may take time and the space may be excessively allocated.

In MongoDB 2.6, the default space allocation policy is powerOf2Sizes, which has been provided since MongoDB 2.2. The size of the space allocated by MongoDB is rounded up to the power of 2 (for example, 2, 4, 6, 8, 16, 32, 64, etc ). This setting reduces the chances of moving documents and makes the space more efficient for reuse. The result is less space for Excessive allocation and more predictable performance. You can still use the exact matching allocation policy. If the document size does not increase, this policy saves more space.

Index data can be of great help to SQL and NoSQL-based databases, but sometimes it may be difficult to extend the write performance. Can you explain how to reduce the number of required indexes in "index interp" of version 2.6?

For example, consider a sales report application: the product manager wants to find all customers who have ordered a specific part number that exceeds a specified number. Using index crossover, you can combine (Cross) part numbers and quantity of existing indexes to optimize queries without the need for separate composite indexes. This also reduces the workload overhead and makes updates more efficient.

Currently, index crossover supports the intersection of two indexes and is best used when the candidate result set is large to equal. This is especially true for queries that can be processed from "covered indexes. When you know the multi-field predicates in advance, you can use composite indexes to process queries faster.

For some operations on a single index, index crossover can also improve their performance, which can be called "self-interps )". When using an operator such as in or all, MongoDB 2.6 may scan the index multiple times and then obtain the intersection of the result. This significantly reduces the number of complete documents that must be returned when processing queries.

"Orphaned documents" may lead to incorrect results for some queries. Can you elaborate on how version 2.6 helps us solve this problem?

Under normal circumstances, there are no isolated documents in the system. However, some failure situations during block migration may leave isolated documents. The existence of isolated documents may lead to incorrect results for some queries. Isolated documents can be safely deleted. In versions earlier than 2.6, there is no simple way to do so. In MongoDB 2.6, we implemented a new management command for database sharding cluster: cleanupOrphaned (). This command deletes isolated documents from shards within a single range of data. One of our support engineers wrote a good blog on this topic.

MongoDB is increasingly used in enterprises. In terms of Enterprise adoption, how does MongoDB locate in the NoSQL ecosystem and what key features have MongoDB 2.6 improved?

MongoDB is widely used in many organizations, including 30 Fortune 100 organizations. We can see that organizations want to standardize several database systems, while many organizations choose MongoDB because it can be used in a variety of applications, this is due to its flexible data model, rich indexing, scalability, and greatly increased the productivity of the development team.

MongoDB 2.6 provides many security enhancements, which are critical for enterprises. These features include LDAP, x.509 and Kerberos authentication, SSL encryption, user-defined roles, audit, and field-level security. IBM Guardium also provides integration with MongoDB, which provides broader audit capabilities.

Another important trend related to enterprises is the scale of our ecosystem, which now includes more than 400 partners. Many of these partners provide integration with MongoDB, including Informatica, Microstrategy, QlikTech, Pentaho, and Talend.

Full-text search has always been a feature with a large number of requests. Although the 2.4 version has already had an experimental implementation, it is precisely submitted by Eliot itself, the $ text operator was added in version 2.6. How mature is full-text search in version 2.6, and how does it face the competition in the NoSQL database field?

Over the past year, we have worked closely with the community to test text search and integrate its capabilities into other features. Apsaradb for MongoDB 2.6 text search is now available in the production environment and provides new features, including:

It is integrated with the MongoDB query engine, so text search can be used with common query operators to provide richer queries by limiting, skipping, sorting, and filtering results. For example, a user can search for a specific phrase in a blog collection, but use an additional condition to limit the search to a blog in the past seven days; multi-language documentation is supported; text Search statements can be used in "Aggregation Framework" to provide more in-depth analysis by counting and grouping matched texts.

Other NoSQL vendors provide integration with individual dedicated Search engines, such as SOLR and Elastic Search. This method increases deployment complexity and costs, requires additional skills, and these indexes are inconsistent with the underlying data. We believe that native text search is easier to deploy and at a lower cost, and can make full use of existing skills while maintaining consistency with underlying data. However, some features provided by dedicated search engines are not provided by MongoDB, But we provide similar options for integration with these products, just like other NoSQL vendors. With MongoDB, you can select one of the two methods.

More fine-grained locks may be the most requested feature. What is your further roadmap compared to the database level? What are the main further obstacles compared with the set-Level Lock?

It is important to remember that the locks in MongoDB are very similar to the latch in RDBMS-they are very simple and usually hold for 10 microseconds or less. MongoDB 2.2 introduced a more advanced lock concession algorithm, significantly reducing the number of issues we saw in the community related to lock contention. However, we realize there is another opportunity to improve concurrency, including finer-grained locks.

MongoDB 2.8 will have document-level locks. We believe that, compared with set-level locks, this will significantly improve the concurrency of wider applications. However, more fine-grained locks are only part of improving concurrency. We will improve other aspects of the database to provide greater concurrency as a whole. MongoDB 2.6 includes some improvements (see the following section). MongoDB 2.8 will bring more improvements.

Does MongoDB 2.6 help solve other lock problems?

Yes, many enhancements help improve concurrency. For example, index crossover reduces the number of indexes required by many applications and improves write scalability. Many of the work we used to do within the lock is now executed outside the lock, such as parsing and _ id generation. We have done a lot of work to improve the operation log writing concurrency, including making each write faster and changing the lock working mechanism. This work improves the concurrency of version 2.6, which is required before finer granularity locks are available, otherwise these things will soon become the next bottleneck.