Tablespaces Definition and Structure
Tablespaces Definition and Structure#
This section describes what a tablespace is. It also examines the relationship between tablespaces and databases, and describes the respective structures of disk tablespaces, memory tablespaces, and volatile tablespaces.
What Is a Tablespace?#
A tablespace is a logical storage space for storing tables, indexes, and other database objects. A database usually requires at least one tablespace in order to operate correctly. The system tablespaces are created automatically when a database is created. In addition, the user can also create user-defined tablespaces as desired.
In Altibase, user-defined tablespaces are classified as disk tablespaces, in which database objects reside on disk, memory tablespaces, in which the objects reside in memory, and volatile tablespaces, in which the objects reside in memory and for which logging is not performed. The user determines which kind of tablespace to use depending on the characteristics of the data to be stored in the tablespace.
Disk tablespaces are an appropriate choice for large volumes of data, such as for example historical data, while memory tablespaces are suitable for small volumes of data that are accessed frequently, and volatile tablespaces are appropriate for storing data temporarily so that they can be processed quickly.
The Relationship between a Database and Tablespaces#
When a database is created, four system tablespaces are automatically created: system dictionary tablespaces, system data tablespaces, system undo tablespaces, and system temporary tablespaces.
In addition, the user can create user-defined tablespaces (disk, memory, or volatile tablespaces) as needed. The user can create user-defined tablespaces either on disk or in memory, depending on the characteristics of the data.
The Structure of Disk Tablespace#
A disk tablespace is a tablespace where all data are stored on disk. It is physically organized into data files and logically organized into segments, extends, and pages.
Disk Tablespace Physical Structure#
Disk tablespaces are closely related to data files and segments. [Figure 6-2] shows the relationship between disk tablespace and data files and segments.
Disk tablespaces, data files, and segments have the following characteristics: A disk tablespace consists of one or more data files, which exist in the form of files supported by the operating system. A segment is stored in a tablespace logically and in a data file physically. A segment is wholly contained within a particular disk tablespace, but segments can refer to segments that are stored in other disk tablespaces.
Disk Tablespace Logical Structure#
A disk tablespace logically consists of segments, extents, and pages. The relationships between them are shown in [Figure 6-3].
-
Segment
A segment is a set of extents that contains all of the data for an object within a tablespace. Segments are units that allocate tables or indexes within a tablespace. A single table or index is logically the same as one segment. The types of segments used in Altibase are as follows:
[Table 6-1] Segment Type
Segment Type Description Table Segment This segment type is the most basic means of storing data within a database.
All of the data in a table, or, in the case of a partitioned table, all of the data in a partition, are stored in a single table segment.
When a table is created, Altibase allocates this table segment in a tablespace.Index Segment A single index segment contains all of the data for one index, or for one partition of a partitioned index. The purpose of an index is to assist in locating data in a table based on some particular key.
When an index is created, Altibase allocates an index segment to a tablespace.Undo Segment Undo segments are used by transactions that change the database.
Before a table or index is changed, the value before the change (i.e. the "before-image") is stored in an undo segment so that the change can be undone if the associated transaction is rolled back.TSS Segment These are used for managing Transaction Status Slots, which are managed internally within Altibase. They are allocated within system undo tablespace. Each segment internally maintains a free extent list and a full extent list. When there are not enough free extents, a request is made to add one or more additional extents to a tablespace
-
Extent
In disk tablespace, an extent is a unit by which contiguous pages, which are the resource required for storing data objects, are assigned. When saving data, if there are not enough free pages available to save the data, additional pages are allocated in extent units.
By default, a single disk tablespace extent consists of 64 pages (512KB). In Altibase, the extent size can be specified individually for each tablespace.
-
Page
The smallest unit for storing records in tables and indexes is called the page, which is also the smallest unit for performing I/O. In Altibase, the page size is 8KB. (The simultaneous use of multiple page sizes isn't supported in Altibase.)
There are several kinds of pages, including data pages, index pages, and undo pages, corresponding to the kind of data that are stored in the pages.
The basic structure of pages, as well as how to store data in them, are described below.
-
Page Structure
A page has a header for storing basic information about the page, free slots (this is the only instance of the term "Free slot" in this document), and the like. Records are stored in the remaining space. A page is internally divided into 5 areas, as shown below:
[Figure 6-4] The Structure of a Page in Disk Tablespace -
Physical Header
This area contains information that is common to all data pages, regardless of type.
-
Logical Header
This area contains information that is necessary depending on the type of page.
-
Free Space
This area is used to save new data.
-
Stored Procedure Data
Rows, indexes, or undo records are stored here depending on the type of page.
-
Page Footer
This area is located at the end of the page, and contains information that is used to check page integrity.
-
-
How Records are Stored in a Page
The records in a page are stored in free space, starting from the end of the page and working towards the beginning of the page.
The logical header of the page is saved extending toward the end of the page. Its size is variable.
[Figure 6-5] How Records are Stored in a Page
-
The Structure of Memory Tablespace#
A memory tablespace is a tablespace in which all data are stored in memory. The physical structure consists of checkpoint image files and logically consists of pages and page lists.
Memory Tablespace Physical Structure#
Memory tablespaces are closely related to checkpoint image files. [Figure 6-6] shows the relationship between a memory table space, tables, and checkpoint image files.
Memory tablespaces, tables, and checkpoint image files have the following characteristics:
A memory tablespace, unlike a disk tablespace, stores data in linear memory space rather than in data files.
Because a continuous memory space is divided into pages, a table can be thought of as a list of pages. In the interests of managing disk I/O expense and tables containing large amounts of data, disk tablespaces are managed in units of extents, not pages. A segment is, conceptually, a way of managing a list of extents.
However, because the purpose of memory tablespace is to provide faster access to data than managing large amounts of data, the concept of segments and extents is not necessary. Therefore, tables in a memory tablespace are managed using lists of pages.
Memory tables are physically backed up in checkpoint image files when checkpointing occurs. The purpose of checkpoint image files is different from that of data files in a disk tablespace. Data files in a disk tablespace are for storing objects, whereas checkpoint image files are for backing up objects in a memory tablespace. Checkpoint image files are not directly required for the operation of the database. However, they are required in order to reduce the amount of time taken to perform backup and recovery.
When checkpointing occurs, pages in memory are stored in files of a type supported by the operating system. In Altibase, so-called "ping-pong checkpointing" is implemented, which means that two sets of checkpoint image files (namely, #0 and #1) are maintained, and used alternately when checkpointing takes place. In addition, each checkpoint image can be divided into several small files, with the goal of distributing disk I/O expenses.
Memory Tablespace Logical Structure#
The elements that logically constitute memory tablespace are page lists and pages. The relationship between these elements is shown in [Figure 6-7].
-
Page List
The concept of a page list explains how tables are logically configured in a memory tablespace. A page list is a list of pages, which are the unit into which the memory occupied by a memory tablespace is divided.
Tables are the only memory tablespace objects for which page lists are maintained. Because the object of indexes is not to maintain database consistency, they do not use page lists. When the system is restarted, memory table indexes are rebuilt, which eliminates the load that would otherwise be imposed by performing index logging while the database is running.
-
Page
The characteristics of memory tablespaces are different from those of disk tablespaces with respect to the structure of pages and the way that data are stored.
Unlike disk tablespaces, when dealing with memory tablespaces, there is no need to consider disk I/O expense, and thus the method of updating records is so-called "out-place update".
In the out-place update, the existing record image is not directly changed; rather, record space is allocated for the new version of the record. This update process consists of deleting the existing record and inserting a new record, thereby eliminating the cost of rearranging the record that currently exists. In addition, it allows direct access to existing data, ensuring fast performance in highly concurrent applications.
The Structure of Volatile Tablespace#
The structure of a volatile tablespace is identical with that of a memory tablespace in that all data are stored in memory. The difference between them is that, in a volatile tablespace, there is no checkpoint image file on disk. The data in a volatile tablespace reside only in memory.
Since tasks that are conducted in a volatile tablespace are not accompanied by disk logging and are not subjected to checkpointing, they entail absolutely no disk I/O. As a result, volatile tablespaces are useful in applications requiring fast performance. Logically, they consist of page lists and pages.
Volatile Tablespace Physical Structure#
The structure of volatile tablespaces is identical with that of memory tablespaces in that database objects reside in memory. However, volatile tablespaces do not have checkpoint image files.
Volatile Tablespace Logical Structure#
Just like memory tablespaces, the constituent elements of volatile tablespaces are page lists and pages.