While you can manually do this by creating and using more than one database for your data, DB is capable of partitioning your database for you. When you use DB’s built-in database partitioning feature, your access to your data is performed in exactly the same way as if you were only using one database; all the work of knowing which database to use to access a particular record is handled for you under the hood.

    Only the BTree and Hash access methods are supported for partitioned databases.

    You indicate that you want your database to be partitioned by calling before opening your database the first time. You can indicate the directory in which each partition is contained using the DB->set_partition_dirs() method.

    Once you have partitioned a database, you cannot change your partitioning scheme.

    There are two ways to indicate what key/data pairs should go on which partition. The first is by specifying an array of s that indicate the minimum key value for a given partition. The second is by providing a callback that returns the number of the partition on which a specified key is placed.

    For simple cases, you can partition your database by providing an array of DBTs, each element of which provides the minimum key value to be placed on a partition. There must be one fewer elements in this array than you have partitions. The first element of the array indicates the minimum key value for the second partition in your database. Key values that are less than the first key value provided in this array are placed on the first partition (partition 0).

    Note

    You can use partition keys only if you are using the Btree access method.

    For example, suppose you had a database of fruit, and you want three partitions for your database. Then you need a DBT array of size two. The first element in this array indicates the minimum keys that should be placed on partition 1. The second element in this array indicates the minimum key value placed on partition 2. Keys that compare less than the first in the array are placed on partition 0.

    All comparisons are performed according to the lexicographic comparison used by your platform.

    • ‘a’ - ‘f’ to go on partition 0

    • ‘g’ - ‘p’ to go on partition 1

    Then you would accomplish this with the following code fragment:

    The DB->set_partition() partition callback parameter must be if you are using an array of s to partition your database.

    Partitioning callback

    In some cases, a simple lexicographical comparison of key data will not sufficiently support a partitioning scheme. For those situations, you should write a partitioning function. This function accepts a pointer to the and the DBT, and it returns the number of the partition on which the key belongs.

    Note that actually places the key on the partition calculated by:

    Also, remember that if you use a partitioning function when you create your database, then you must use the same partitioning function every time you open that database in the future.

    The following code fragment illustrates a partition callback:

    The DB->set_partition() array parameter must be if you are using a partition call back to partition your database.

    Placing partition files

    When you partition a database, a database file is created on disk in the same way as if you were not partitioning the database. That is, this file uses the name you provide to the parameter.

    However, DB then also creates a series of database files on disk, one for each partition that you want to use. These partition files share the same name as the database file name, but are also number sequentially. So if you create a database named , and you create 3 partitions for it, then you will see the following database files on disk:

    All of the database’s contents go into the numbered database files. You can cause these files to be placed in different directories (and, hence, different disk partitions or even disks) by using the DB->set_partition_dirs() method.

    takes a NULL-terminated array of strings, each one of which should represent an existing filesystem directory.

    If you are using an environment, the directories specified using DB->set_partition_dirs() must also be included in the environment list specified by .

    If you are not using an environment, then the the directories specified to DB->set_partition_dirs() can be either complete paths to currently existing directories, or paths relative to the application’s current working directory.

    Ideally, you will provide with an array that is the same size as the number of partitions you are creating for your database. Partition files are then placed according to the order that directories are contained in the array; partition 0 is placed in directory_array[0], partition 1 in directory_array[1], and so forth. However, if you provide an array of directories that is smaller than the number of database partitions, then the directories are used on a round-robin fashion.

    You must call DB->set_partition_dirs() before you create your database, and before you open your database each time thereafter. The array provided to must not change after the database has been created.