Skip to end of metadata
Go to start of metadata


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

If records with the same primary key are changed to different values at the same time on both servers, the changes to a different record occur in the replication method. In this case, because the user does not want the data inconsistency, the business requirements are sufficiently grasped to place the program so that the change task occurs only on one server within the group consisting of replication or the record with the same PK is changed within the group consisting of duplication. The placement must be done so that this does not happen simultaneously.
For example, if an L4 switch is used, programs for each task are placed on different servers, and programs accessed from the 192.168.1.X network connect to DBMS Server 1, and programs accessed from 192.168.2.X network are 2, it will be possible to configure the form of performing connection to DBMS server. Alternatively, the user can explicitly specify the IP in the DBMS connection part of the service program.

③ 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

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.
3. If Sum/Avg is used, select Double/BigInt type

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

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

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")

  • No labels