- Considerations for replication environment
- Consideration for high availability (HA) and backup
- Considerations for designing table
- Limitation of partition table
- Considerations for Hardware preparation
- Not Support Feature
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.
90% performance level of a single server
Performance degradation compared to the Lazy method
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
③ 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.
|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.
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.
1. Consider minimizing the conversion cost of Native ßà Non-Native
(Native type [Integer, Double, BigInt] is more advantageous in terms of performance)
2. Double type is selected when the precision of the real type is not required.
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)
Consider that the type conversion does not occur if the column is a Join
③ 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
Considerations for Hardware preparation
The hardware-related considerations to the information above are summarized and explained in this section.
|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.|
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".