The acquisition and loss of MongoDB

Http://www.aliyun.com/zixun/aggregation/13461.html ">mongodb also has many areas to improve, such as global write locks (now just a database-level write lock). This article focuses on how to scale to cope with large data, where the volume of large data is 100GB.

It will be more meaningful when you look at the implementation of the underlying storage. Basically, MongoDB consists of a bunch of Bson document MMAP (Memory-mapped) lists that use a simple B-tree index and a basic log as a storage durability mechanism. Eventually the OS writes to the disk and reads the results of data loaded into memory by the operating system in the page.

Originally called the killer advantage of the speed aspect, in fact, just use the page caching effect. Soon you'll realize that "this is just mmap," and all BS architecture-related optimizations just make your work set more fit for RAM, which can have a significant impact if you delete, add records, etc. on a fragment. Os doesn't know you're running the database, it just knows that you want to mmap something and give it the best access effect. Luckily, the algorithm is written by some very smart people, so as long as the search results can be cached and run well, the OS scheduling writes will not take into account your storage layout or even the difference between your index and data. This, of course, does not infer what data is kept in the cache or preloaded, as it does not know what your data is or where it is.

In fact, there are a lot of geniuses like MongoDB Tao, and most databases use some very good ideas: Cassandra consistency protocols, Redis crazy data structures, or Hadoop data processing capabilities. MongoDB owns Mmap, eliminates the need to design your own caching algorithms or write strategies, and leverages everything as simple as possible, allowing you to quickly get into the market and focus on your sales benchmarks, your competitors, or concurrent learning. Before you compare, you will be more attractive. By that time you may have been able to cash in or write a database in a real sense, and in any case your client will be locked into a position to adapt to your design decisions. But don't overlook the coincidence that you're looking at Oracle and IBM.

As mentioned above, there are many areas of mongodb that need to be improved. The concern is that when you focus on the storage engine and ignore the broader persistence strategy issues, killer apps should be similar to working with user data in online gaming: Having a consistent set of working sets in a given time period is likely to be small relative to the entire database, with read and write operations occurring on the same working set. You have a lot of reading. The client does a lot of computing for you, and if you want to get a more flexible data structure pattern, you can convert it into a relational model, use a hstore or JSON column to populate the graph, or use blobs/like HBase or Cassandra. Text to store the document, but it's never as bad as using MongoDB.