迷茫2017-04-17 11:34:43
The fundamental reason why writing operations in MongoDB is faster than traditional databases is the memory mapping technology used by Mongo - when writing data, it can be returned to the application as long as it is completed in the memory, so the amount of concurrency is naturally high. The operation of saving to hardware is completed asynchronously in the background. Note that MongoDB has been written to be secure by default in 2.4 (the specific implementation is in the driver), so some students above answered that "unsafe by default" should be based on 2.2 or previous versions.
The reasons why MongoDB is fast in reading operations are: 1) The design of MongoDB requires that your commonly used data (working set) can be loaded in memory. In this way, most operations only require reading memory, which is naturally very fast. 2) Document pattern design generally means that the data you need are relatively concentrated together (memory or hard disk). As we all know, the most time-consuming hard disk reading and writing is the head positioning time generated by random reading and writing. If the data is concentrated together, Reduces the random reading time required for relational databases to find data from various places (and then join)
The other one is that as @王子婷 mentioned, Mongo is a distributed cluster so it can be expanded in parallel. At present, the general concurrency of millions of times is achieved simultaneously through clusters of dozens or hundreds of nodes. This is basically impossible for MySQL to do (or it will cost a lot of customization)
迷茫2017-04-17 11:34:43
I can’t say so absolutely. In many cases, mongo is not necessarily faster than MySQL
ringa_lee2017-04-17 11:34:43
Don’t talk about the scenario, business, or background, just talk about why mongo is faster than mysql? Have you used both? You are here to hack mysql. Go learn how to ask questions!
巴扎黑2017-04-17 11:34:43
MySQL is a relational database, which stores tables one by one. Distributed storage requires the tables to be split and stored in different disks
Do you take it apart vertically or horizontally? If you split a normal query vertically, you need to join
Horizontal splitting is not that troublesome, but if your statement has a join, no matter which disk the record you are looking for is in, it will traverse all disks to generate the join result
Can it be slow?
怪我咯2017-04-17 11:34:43
Simple and clear:
