Changes in MySQL cache in NoSQL

MySQL, a database generated by the Internet, is used by countless websites and games. It is said that google, tencent, and taobao are all using it. During the rapid development of the Internet, because of the needs of high-speed cache and the difficulty of dealing with massive writes in traditional databases, all kinds of NoSQL solutions have come out. The most classic is Memcached and redis, memcached itself does not support persistence, but the actual requirement may be persistence. In the face of data persistence and caching, various combinations of solutions are also available, and redis supports persistence, A friend of sina made a Memcachedb through Memcached + berkeleydb, and also made a Memcachedb through MySQL + Memcached. It was too troublesome to update it manually. Later, MySQL + udf was used to update Memcached, later, the artifact MySQL + handler socket emerged. It was said that it could reach qps, which shocked the industry. At that time, I was wondering that MySQL would sooner or later be compatible with a set of key: value interfaces. We can see that MySQL supports the Memcached interface. In this case, how many intermediate solutions have vanished? MySQL + Memcached, which can be used by experts before, is no longer necessary in the face of MySQL integrated with Memcached, however, this is still in the experimental version for the time being. I tried it and it is not very efficient. I hope it will be officially released soon.

MongoDB is also a freak in various NoSQL environments. I was forced to use it in the previous project. From the usage perspective, I am not optimistic about it. The advantage is that it has some advantages, that is, the read/write speed is okay, but that is, it is faster than MySQL. I think it is definitely better than MySQL that provides the Memcached interface, but there are many disadvantages. It is too space-consuming and cannot afford to hurt, I used 1.8 at first, and then changed 2.0 to consume more space, which is about 10 times that of MySQL storage. In fact, if I used indexes, the occupied space increased dramatically, in addition, the json query syntax is really weird. It takes a little time to adapt to it. In addition, the _ id is also very uncomfortable, with 24 bytes, as a string and as an OID are not the same. It is easy to use errors. For most applications, if MongoDB is used as MySQL, I advise you not to play it. Although this item looks very popular and some early adopters are using it, it has not been used very aggressively so far. I think that with the various changes in traditional databases, some of MongoDB's previous advantages have no advantage or even become a disadvantage. MongoDB may be just a flash product, or it may survive for a long time, but it will not be able to get rid of the fate of the niche, select with caution.

In the Internet age, new technologies and new solutions are emerging in an endless age. The choice requires great wisdom. You have to choose a good solution that has been nourishing for 2 to 3 years.