To achieve optimal transaction performance, again, proper modeling is essential:
Avoid "relational" designs that split a business object into a multitude of "flat" documents. Updating a business object would require the updating of multiple documents, thus impairing performance. In some cases, however, it may be necessary to split a large business object into several documents. A Boeing 747, for example, can certainly be seen as a single business object, but representing its parts list in a single document would certainly lead to performance problems (see next paragraph).
Avoid "all-in-one" documents. Very large documents are slow to update because parsing and writing them may take a long time. Also, when a single document contains several business objects, you may run into performance problems due to locking conflicts. Because locks are set at the document level, you would lock all business objects contained in the updated document, even if a certain business object is not affected by the update. This prohibits other users from concurrently accessing or updating these business objects (depending on the isolation level).
