Couchdb may not be very comfortable to use.

Recently I spent one weeks studying NoSQL, I have a 4 million record MySQL speed is slow, ready to migrate to NoSQL, because the main is some JSON format of the document, originally serialized in MySQL, because of the look of Erlang, known as the very ox x platform, Pick in the COUCHDB, but import 400,000 effective test data, in the local run time, found that the speed is particularly slow (the local machine is 2011 years of imac, equipped with 16G of memory, is not weak), and the query function is very weak, may not be ripe.

COUCHDB Features:

For the document database, do not need a paradigm, directly stored JSON can, couchdb default will generate _id,_rev two keys, _id is a record (document) Unique identification, if not provided _id,_id will be automatically generated, you can manually specify _id, such as the phone number of the master key:

{' _id ': ' +86186***** ', Name: '}

_rev is its version number, and the _rev is automatically changed every time it is updated, in the format

5-6a8617596d2adfea245662df0df611ao

, identify the 5th version, followed by a hash signature, you can find all the historical version through _rev, so it should be very good to do the document system that needs to store the version, such as multi-person collaboration to modify a document and other applications.

COUCHDB provides restful interface access, which requires only the HTTP request to perform the redaction function, and the advantage is that only the command line curl is ready to work and no special drivers are required, such as: Get a document:

Curl-x GET http://127.0.0.1:5984/dbname/_id

You can, and the downside is that the HTTP protocol is not efficient, especially if the execution of a page requires multiple requests, with MySQL can be common with an open link can continue to execute the query, and with HTTP? To think about how to get HTTP to reuse a socket link, so the more simple to start , the more trouble is behind!

Couchdb query function is very weak, couchdb how to execute the query? Unlike MySQL, you can throw a SQL in the past. To create a View,view format for each query:

{"Map": "function (DOC) {Emit (key, value);}"}

, the function in this must be a string, not a legitimate JavaScript statement, so you write a slightly more complex statement, you have to make sure to debug in the Node/console, and then convert him into a string, And then construct a valid JSON string to post the past, this process is very painful. And this view in the first query when the speed will be slow scare, 400,000 data, the time required to execute about 5 minutes or so, 4 million, I dare not test, but StackOverflow on a Netizen said he ran 4 hours have not run out of results, Because this map can not exist what optimization of the place, map is a run, so no matter what query, all to traverse all doc, can not slow it!

In addition, the view is actually like other common records in the real database, can be seen through _utils, view is not able to transfer variables (temporary view can), such as in a library exists member data has name, email, city, etc., need to query City for "Shenzhen" of the member, then how to do? The first uses the temporary View:temp_view, constructs the dynamic query map statement:

Curl Http://127.0.0.1:5984/dbname/_temp_view?include_docs=true-H ' Content-type:application/json '-d ' {"Map": "  Function (DOC) {if (Doc.city.match (/shenzhen/)) emit (doc._id, 1); }" }‘

It is best to store this _temp_view as a permanent view, otherwise each query a new city will be very slow, once executed once the query, the subsequent access will be faster, but the premise is: You have to execute a query!

But if stored as a permanent view, you need to write dead Shenzhen This string in the view, this method of passing variables is obviously undesirable, very stiff, I would like to query a city for Shenzhen to create a new view, so many cities nationwide, Do you want to create a new city for every one of them? View this way query is really stupid!

In addition to Temp_view, in the end there is no way to dynamically transfer parameters? Can ah Startkey and EndKey Ah, but these two parameters light from the name can see how stupid design.

Ok so query, first create a view, save as Member/city_query

' {' Map ': function (DOC) {emit ([Doc.city, doc._id], 1); }" }‘

Then you can check it out:

Curl Http://127.0.0.1:5984/dbname/_design/member/_view/city_query?startkey=[shenzhen]&endkey=[shenzhen]-h ' Content-type:application/json '

This statement cannot be run, and you need to escape the brackets [] manually. Look, it's so boring.

The process of execution is this: Startkey passed an array parameter, only one value Shenzhen, in the view map, emit is no longer a normal key, but an array, startkey the first value corresponds to the first parameter in emit Doc.city, the result will be retrieved the value of the city >=shenzhen, and then specify a endkey OK Ah! You can think of this map to traverse all the records!

This kind of design is very low, and very bad, if I want to query the regular match what to do? Create a new view honestly? The result is that if your query is more diversified, the view may be more than the data!

Finally, I concluded that don't try couchdb on big data, don't use couchdb where you need frequent queries, don't use COUCHDB where you need a lot of aggregated, analytical data, he's only fit for a small blog with up to thousands of data, a small document system, and doesn't require a variety of fancy-type queries. , his performance is not as good as the thought of, and couchdb internal storage is a real file, no optimization, improve query speed is not couchdb recent goals, they pay more attention to function rather than performance. And Couchdb's development was intended to be an Apache Foundation's wishful thinking, not engineering needs, so if you choose NoSQL, try to find the database that was developed in the engineering needs.

Couchdb may not be very comfortable to use.