This chapter describes things to consider when designing a DB or system using ALTIBASE. It is recommended to consider the following items and refer to the design because not only the impact on the design stage but also on the development stage and the operation stage is significant.
Considerations for replication environment
① ALTIBASE network-based replication method
ALTIBASE adopts a replication method of synchronizing data by sending/receiving change transaction logs based on the network. In other words, it is not a usual way to share disk that users commonly aware of. Therefore, it is necessary to design in consideration of the synchronization part due to data transmission delay, which must occur in a network environment.
There are two replication methods: The lazy method and the Eager method. The Lazy method allows the delay of data transmission, and on the other hand, the Eager method does not allow it. Therefore, the Lazy method is adopted for tasks that allow data transmission delay, and the Eager method is set and operated appropriately for each task if data does not necessarily need to be synchronized.
Comparison | Lazy Method | Eager Method |
|---|---|---|
Performance | 90% performance level of a single server | Performance degradation compared to the Lazy method |
Synchronization | This is a structure that checks only the success of transmission of the changed transaction log to another server, so it is a high performance, but synchronization may be delated. | To prevent data inconsistency on another server, performance is rapidly delayed because it is also committed locally on another server, but the synchronization is not delayed. |
② Consider measures to prevent data inconsistencies
In a dualized environment, if records with the same primary key are modified simultaneously with different values on both servers, unwanted data inconsistency may occur due to server conflicts. To prevent this, the following design considerations are required:
a. Business Logic Separation
Modification operations (Insert/Update/Delete) must be executed only on one server within the group, while the other server is used exclusively for read operations.
For example, assigning server A as read-only for real-time queries and server B as write-only for modification tasks can fundamentally reduce the risk of conflicts.
b. Data Responsibility Separation by Server
To avoid simultaneous updates to the same PK, divide and manage the PK range by server.
Example: Design so that odd-numbered member IDs can only be modified on server A, and even-numbered IDs only on server B.
③ Log-based replication method
Altibase replication is a form sending changed log of a transaction occurring on the local server. This means that even if one million statements are changed with one SQL statement, the same is the structure in which a million changed transaction logs are transmitted, not the same for one SQL statement transmitted to a remote server.
In addition, it is important to refer to the ALTIBASE technical documents "Efficient Replication Configuration Guide" and "Replication Constraints Guide" for major considerations of the replication environment.
Consideration for high availability (HA) and backup
Under normal circumstances, when a failure occurs and recovery is performed, replication automatically synchronizes data by sending a transaction log to the other side that has not yet sent to the point of failure. However, due to the nature of the network, it is necessary to consider whether there is a task that cannot perform a fail-over service immediately due to data inconsistency caused by the inability to transmit the change transaction log at the time of failure.
If the service is available only after the data is synchronized, ALTIBASE provides an offline replicator to reflect the undeferred data. However, there is a limitation that it can be used only when the disk of the failed server is accessible. (In order to use this function, it is recommended to build a shared disk device.)
If it is not an environment where the off-line replicator can be used, it is necessary to establish a HA policy that accumulates raw-data at the point of failure in the program and reflects it on the normal server as much as necessary. For example, in the case of securities companies, all data going to the world is managed by unique numbers. Since these numbers are the same in the external system and the DBs, in some cases, a business logic that reflects only the portion of the difference between the external system and the DB system in the normal server is used.
In addition to HA, it is necessary to establish a backup policy for data file damage caused by physical disk failure and failure caused by transaction log file corruption. The Altibase backup method provides both full and incremental backup methods using the archive mode.
Therefore, at the time of backup, the user (1) cold backup of all necessary files while offline, (2) full backup of database or tablespace units while online, (3) database or tablespace units when online. The user must choose one of the incremental backup methods.
The backup method should be one of the following types.
Method | Description |
|---|---|
iLoader Backup | Only snapshots of records are stored for each major table. Only data at the time of backup by iLoader is backed up
|
Archive Full Backup | Because the entire database image including transaction log files is backed up at the time of backup, recovery is possible to the point where there is no damage to the files.
|
Archive Incremental Backup | A full backup is performed once at the beginning, and only the changed image is backed up from the next time. Transaction log files are also backed up, so recovery is possible until there is no damage to the files. The more incremental backups, the longer it takes to recover, so a review is needed. |
Cold Backup | After the ALTIBASe process is executed, all necessary files are copied and stored, and the recovery is possible only up to the point of copying the files. |
For the backup, please refer to "Consideration for ALTIBASE Backup Policy Decision".
Considerations for designing table
① Select the storage location of the table according to the purpose
ALTIBASE supports both memory and disk tablespaces. The user should select which tables to place in the memory tablespace for tasks that require fast processing performance. That is, it is necessary to create a list of tables for each purpose to be located in the memory/disk tablespace.
However, because one table name cannot be located on the memory/disk at the same time, if the processing is stored in the memory table and previous processing is stored on the disk on the same day, the table is separated into two, and created in the form of EXEC_TABLE_MEM/EXEC_TABLE_DISK. When querying, it is designed to query each table as much as possible, and if two tables need to be queried at the same time, it can be queried by using UNION All or create a separate view. However, the processing speed when querying two tables separated into a memory and a disk table simultaneously depending on the processing performance of the disk table.
② Considerations for Column type
In the case of the numeric type provided by ALTIBASE, a type such as Numeric (9) can be sufficiently expressed as an integer type, but occupies 8 bytes of space. It occupies 4 bytes per record more than integer type. In terms of processing performance, numeric internally incurs the cost of converting back to native type, which is somewhat slower than the integer type.
It is recommended to the following when selecting a column type.
Consideration | Description |
Numeric Type | Altibase's numeric types are broadly classified into native types and non-native types. Native Types (Better performance, no internal conversion required)
Non-Native Type (Internal conversion occurs during storage, lower performance)
1. Prefer Native Types If the same data can be represented, choosing a native type reduces conversion cost and improves performance.
2. Integer Data Choose the smallest appropriate type among
3. Floating-Point Data Use
4. Consider Aggregation Operations For columns frequently used in |
Date Type | If the date-related operation is important, select the Date type. If it is limited to search and comparison operations, select the Char/Varchar type. (Date type is fixed at 8 bytes) |
Join | Columns used in JOIN conditions must be defined with the same data type. |
③ In the case of replication, it must have a primary key
④ Foreign key is not used because it degrades transaction performance.
Limitation of partition table
For the ALTIBASE partition table (as of version 6.3.1), partitioned local index and non-partitioned global index are supported, and partitioned global index is not supported. Therefore, it is recommended that the partition table uses historical data for the purpose of storage for each month and purports of business because a significant performance decrease occurs when querying in the form that excludes the partition key in the condition clause that queries the entire partition table.
Considerations for Hardware preparation
The hardware-related considerations to the information above are summarized and explained in this section.
Consideration | Description |
Replication | Because it uses a network, it is recommended that the connection is replicated between the servers by using a separate Giga-bit LAN car or using a private network.
|
Disk | When considering backup, in addition to the estimated DB capacity, disk space is required to store more archive log files along with the entire tablespace. |
In addition, the policy of ALTIBASE for redo log files can be viewed as infinite. It is recommended to allocate enough space on the disk where the redo log files will be stored, as there are cases where it is inevitable to create a large number of redo log files due to bulk change operations because the policy is to create a new redo log file instead of creating reusing redo log files.
For more detailed information, please refer to the "ALTIBASE Capacity Estimation Guide".
Not Support Feature
ALTIBASE complies with the SQL92 standard, but there are some differences compared to other DBMSs.
For more detailed information, please refer to the technical documents provided for each DBMS vendor. (Example: "ORACLE TO ALTIBASE Conversion Guide")