couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "Performance" by AndreyNiakhaichyk
Date Fri, 02 Mar 2012 15:18:20 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "Performance" page has been changed by AndreyNiakhaichyk:
http://wiki.apache.org/couchdb/Performance?action=diff&rev1=16&rev2=17

  With up to tens of thousands of documents you will generally find CouchDB to perform well
no matter how you write your code.  Once you start getting into the millions of documents
you need to be a lot more careful.
  
  Many of the individual wiki pages mention performance when describing how to do things.
 It is worthwhile refreshing your memory by revisiting them.
+ 
+ = DELETE operation =
+ When you delete a document the database will create new revision of it which contains _id,
_rev, _deleted fields. This revision will be stayed even after a [[Compaction#Database_Compaction|database
compaction]]. The reason of it to ensure that deletion of document will be replicated to other
databases.
+ Such documents will affect on views calculation time, PUT and DELETE requests time and size
of database on disk. If you use CouchDB for sessions for example (which is not recommended),
you will find that after a few millions of deleted document the database may start working
much slower. In this case you may regular recreate database to fix this. If you really need
database for documents with short period of life, we recommend to use another NoSQL solution.
+ 
+ You also may be interested in [[Purge_Documents|purging deleted documents]] but we recommend
this is only for information because this solution have much more side effects than advantages.
  
  = File size =
  The smaller your file size, the less I/O operations there will be, the more of the file
can be cached by CouchDB and the operating system, the quicker it is to replicate, backup
etc.  Consequently you should carefully examine the data you are storing.  For example it
would be silly to use keys that are hundreds of characters long, but your program would be
hard to maintain if you only used single character keys.  Carefully consider data that is
duplicated by putting it in views.

Mime
View raw message