Buffering Hints 

To decide if you will use buffering, you should consider the following issues:

●      Are the inconsistencies that may arise between different cluster nodes within a buffer synchronization period acceptable?

●      Is the table mostly used for reading or for writing?

●      How large is the buffered part of the table?

You can use the following general hints when deciding if you want your table buffered:

...

       1.      You should buffer tables that are mostly read and rarely changed, which is why certain inconsistencies are acceptable. Buffering is recommended for smaller tables. Large tables are usually indexed.

       2.      Choose the buffer granularity for the table carefully. This depends on the following issues:

○       The expected size of the table. Full buffering is not recommended for large tables.

○       Read accesses. To use the buffer you have to provide the defined key range – that is, the generic key and the primary key.

○       Non-existent data. With single records buffering each not found record is stored as an entry. For generic area buffering an entry is stored for each not found generic area. The potential overload is avoided when you use full buffering. We recommend that you use full buffering for empty tables with frequent write accesses.

       3.      It is important to choose an appropriate generic key. A short generic key may lead to a large number of buffered records. A large generic key usually means a small number of buffered records. The queries then often will bypass the buffer and buffering will not be efficient.