Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Fri, 02 Mar 2012 15:18:20 -0000
Message-ID: <20120302151820.18318.17061@eos.apache.org>
Subject: 
 =?utf-8?q?=5BCouchdb_Wiki=5D_Update_of_=22Performance=22_by_AndreyNiakhai?=
 =?utf-8?q?chyk?=
Auto-Submitted: auto-generated

Dear Wiki user,

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

The "Performance" page has been changed by AndreyNiakhaichyk:
http://wiki.apache.org/couchdb/Performance?action=3Ddiff&rev1=3D16&rev2=3D17

  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.
+ =

+ =3D DELETE operation =3D
+ When you delete a document the database will create new revision of it wh=
ich 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 datab=
ases.
+ Such documents will affect on views calculation time, PUT and DELETE requ=
ests 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 million=
s of deleted document the database may start working much slower. In this c=
ase you may regular recreate database to fix this. If you really need datab=
ase for documents with short period of life, we recommend to use another No=
SQL 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.
  =

  =3D File size =3D
  The smaller your file size, the less I/O operations there will be, the mo=
re of the file can be cached by CouchDB and the operating system, the quick=
er it is to replicate, backup etc.  Consequently you should carefully exami=
ne the data you are storing.  For example it would be silly to use keys tha=
t are hundreds of characters long, but your program would be hard to mainta=
in if you only used single character keys.  Carefully consider data that is=
 duplicated by putting it in views.