메인으로

Altibase supports online, offline and utility backup solutions to prevent unexpected disasters such as data loss, data corruption, storage failure, etc.Backup CategoriesCategoryDescriptionBackup/Recovery ObjectNotesOnline BackupReal Time Backup ModeDatabase, Tablespaces, Loganchor FilesFull backup, Incremental backupOffline BackupManual Backup ModeDatabase, Tablespaces, Loganchor FilesUtility BackupTool Based BackupDatabase, TablespacesAexport, iLoader ToolsRecovery ProcessAltibase recovers data as follows:

Yes. Altibase has many tools used for SQL execution, migration, replication management, monitoring, query analysis, etc.CategoryUtilityNotesInteractive SQL& OEM ToolOrange,iSQL-Executes all the management functions in Altibase DBMSs-Information about table schemas, users, locks, connection statuses, and transactionsMigration TooliLoader, dataport,Aexport,Migration  Center-iLoader saves the data in text format and loads data-Aexport creates the script for backup, loading data and for the database schema. It can also migrate Altibase data between different platforms-GUI tool for migration tasksMonitoring andStatus Toolaltimon-Regular monitoring of performance views and system resources are written to log files-Logs created by altimon are used for basic information in system managementSQL Queries &Query Plan Analysis ToolaltiProfile-Checks SQL statements, bind values, plan information, query execution time, etc.Management Tool for ReplicationReplication manager-GUI monitors the replication of modified data between DB nodes in real time-Supports two different synchronization modes(Sync and Async)

Yes, Altibase supports SQL-92 and SQL:1999 as well as other SQL provided by other DBMSs. Furthermore, Altibase provides high compatibility with standard interfaces. As an SQL compliant DBMS, Altibase enables its customers to utilize a readily available pool of application developers and administrators at low cost.SQLFunctionAltibaseOracleSAP HANAIBM DB2HintSupportedSupportedSupportedSupportedIn-line ViewSupportedSupportedSupportedSupportedJoinSupportedSupportedSupportedSupportedOuter JoinSupportedSupportedSupportedSupportedHierarchical QuerySupportedSupportedSupportedSupportedGrouping SetSupportedSupportedSupportedSupportedParallel InsertSupportedSupportedSupportedSupportedArray ProcessingSupportedSupportedSupportedSupportedCost OptimizerSupportedSupportedSupportedSupportedTable AnalyzerSupportedSupportedSupportedSupportedBuilt-FunctionSupportedSupportedSupportedSupportedTPC-H QuerySupportedSupportedSupportedSupportedMoveSupportedNot supportedNot supportedNot supportedInterfaceFunctionAltibaseOracleSAP HANAIBM DB2JDBCSupportedSupportedSupportedSupportedOLE DBSupportedSupportedSupportedSupported.NET ProviderSupportedSupportedSupportedSupportedODBCSupportedSupportedSupportedSupportedPHPSupportedSupportedSupportedSupportedEmbedded SQLAPREPROCCPRESupportedCLICLIOCISupportedSupported

Working in a true hybrid environment provides significant benefits over both in-memory and disk-resident databases.To fully understand why it is important to understand the respective benefits of in-memory and disk-resident databases.In-memory databases are almost always significantly faster than any disk-resident database. In addition, the fact that the data resides directly in RAM means that response times and latency are extremely low (microsecond scale). However, the downside is that RAM is significantly more expensive than traditional hard disks, and also has a smaller storage capacity.In contrast, disk-resident databases generally have fairly poor performance. This is because disk I/O is very expensive, and the architecture of the database often spends a lot of CPU resources optimizing disk access patterns. However, disk-resident databases have immense storage capacity and this storage is fairly cheap.This is why a hybrid engine is so attractive. By combining an in-memory database and a disk-resident database into one solution, you effectively get all the benefits and eliminate all the disadvantages. Need high performance? Use memory tables. Need lots of storage? Use disk tables.Other database solutions try to emulate this architecture, sometimes by using a different IMDB as a caching layer for their disk database. But the implementation is often complex, buggy, and expensive due to the need to maintain multiple disparate database licenses.With Altibase, you get all of these advantages in one easy-to-use solution. In addition, the engine is truly unified in the sense that you can perform operations such as joins between memory tables and disk tables.This functionality is at the heart of why Altibase has so many satisfied customers worldwide. The following case studies have hybrid architecture usages of Altibase.Automated Taxi Dispatch Service – KOREA Transportation Safety Authority (TS) : operations for memory tables and disk tables without any additional solutionsSmart City Project – A Small City in South Korea : Altibase’s hybrid mode avoided extra license and maintenance fees. Altibase vs. Bundled Solution (In-Memory DB & On-Disk DB)CategoryAltibaseBundled Solution# of Engines12 (databases and servers)ManagementEasyComplex (problems with data synchronization)CostLowHigh(>double) 1 AltibaseVS.1 (In-Memory DB & On-Disk DB) bundled   Hybrid BenefitsIn-memory and on-disk in a single unified engineData management efficiency and optimizationAltibase’s Storage Manager combines and handles all data on in-memory database and on-disk database, providing transparency for direct management of multi-temperature dataReduced point of failureReduced CPU useReduced license and maintenance costs by purchasing one database vs. twoReduced operational costs and human resourcesLower TCO from a reduction in hardware investmentProblems with Bundling an In-Memory DB and an On-Disk DB:Bundling requires vendors to utilize a separate caching layer between an in-memory database and an on-disk database, which leads to many synchronization and latency issues.Moving multi-temperature data is complex and risky.Other vendors have predominantly acquired their in-memory DBMSs. As such, the underlying codebases for their memory and disk databases are different, complicating data management between the two database engines.Since two separate technologies that were not designed to work together are conjoined, a simpler way of looking at bundling is a commercial workaround.

Unlike other in-memory databases, Altibase leverages its hybrid architecture to eliminate limitations experienced by other in-memory database vendors. Altibase can store data in memory, on disk, or a combination of both.Altibase stores data according to the temperature of the data. Cold data (historical data) is stored on disk and hot data (frequently used data) is stored in memory. Through this hybrid architecture, Altibase enables real time access to large volumes of data while simplifying high-intensity data processing.Altibase was the first company in the world to develop and commercialize a true hybrid database back in 2005.The following case studies have hybrid architecture usages of Altibase.Integrated WEB SCADA System – KEPCO : Data past more than an hour is moved to disk tablesBusiness Intelligence System – Dongwon F&B : Store historical/less frequently used data on-disk tables. 

Altibase provides multiple durability[1] levels so that a user can select optimal durability with consideration of its business. For example, the Altibase Enhanced Durability level guarantees no data loss with abnormal DBMS shutdown while the Altibase Strict Durability level recovers 100% data without any data loss even with abnormal hardware shutdown including power failure.Durability depends on how to write transaction redo log on disk. The four durability levels are decided on the transaction redo log journal mechanism. The four durability levels are ‘No Durability’, ‘Relaxed Durability’, ‘Enhanced Durability’ and ‘Strict Durability’. With multiple durability levels, a user can control a balance between performance and durability.No DurabilityWhen a table is created in a volatile tablespace, this table works based on No Durability. A volatile tablespace is a kind of tablespaces Altibase supports in which all data is volatile so the data is not recoverable when Altibase restarts. No transaction redo log is written in No Durability. This shows the highest performance among the four durability levels.Relaxed DurabilityA transaction does not wait until logs have been written to disk and a memory log buffer is usedSet COMMIT_WRITE_WAIT_MODE and LOG_BUFFER_TYPE to 0 and 1, respectively. With this method, transactions store their update logs in a memory log buffer, and the log flush thread itself flushes the logs in the log buffer to the log file. Although there will be no data loss with the normal shutdown, there could be a bounded data loss with abnormal DBMS shutdown using this durability level.Enhanced DurabilityA transaction does not wait until logs have been written to disk and a kernel log buffer is used.Set COMMIT_WRITE_WAIT_MODE and LOG_BUFFER_TYPE to 0 and 0, respectively. With the default Altibase durability property settings, update logs are stored in the log buffer of the OS kernel area, and transactions do not wait until their update logs have been written to the log file. The Enhanced Durability level guarantees no data loss with abnormal DBMS shutdown, but there could be a bounded data loss when there is abnormal hardware shutdown such as power failure.Strict DurabilityA transaction waits until logs have been written to disk and a kernel log buffer is used.Set COMMIT_WRITE_WAIT_MODE and LOG_BUFFER_TYPE to 1 and 0, respectively. With this method, transaction update logs are stored in the log buffer of the OS kernel area, and logs for committed transactions are written directly to a log file. The Strict durability level recovers all of the data without any data loss even with abnormal hardware shutdown including power failure. This shows the lowest performance among the durability levels.[1] Durability, which is one of the four properties of a transaction, means that after a transaction has been committed, the committed transaction must be guaranteed, even if a database failure occurs before the changed data are physically written to disk.

Altibase is the world’s first company to develop a hybrid partitioned table. A hybrid partitioned table is a table that is partitioned in a way that data can be effectively and efficiently sorted out and stored in corresponding storage mediums according to the temperature of the data in a hybrid database. The purpose is to enhance performance enhancement particularly when a table has to process large sets of data. A hybrid database refers to a database that combines an in-memory database and a disk-resident database in a single unified engine. In the hybrid architecture, data can be stored and manipulated in the main memory, on disk, or a combination of both. When you have frequently used (hot) data and need more speed, you store the data in memory and have an order of magnitude performance enhancement. When you have huge rarely accessed historical (cold) data, you store the data on disk and enjoy the low cost and economical storage scalability of traditional hard disks. However, in many cases, hot and cold data is mixed in a large table. If you need to create multiple tables to handle data of various attributes that originated from one table, you would have to deal with complex process logic, which would increase the complexity of programming. A hybrid partitioned table is to cope with this problem in a hybrid database when hot data and cold data are mixed in one large table. A hybrid partitioned table is a method of logically grouping a memory table and a disk table into one table where data is sorted out and stored in memory partition(s) or disk partition(s) according to the user specification for partitions of a table.By effectively processing hot data and cold data in one logical table, it provides a huge advantage in the form of efficacy and efficiency in a writing program with a net result of over performance enhancement. 

With Altibase, there is no need to purchase separate caching solutions. Altibase can be utilized as a persistent in-memory cache which eliminates common issues associated with commercial caching solutions.The following case studies include related stories.Global Cloud Authentication Service – Samsung Electronics : Altibase is used instead of Oracle Coherence.Yield Management System – Samsung Electronics : Altibase volatile memory table is used for parametric statistics task of YMS.Caching is a good strategy to use when specific query results need to be returned quickly. However, using this method does not give full flexibility for increasing performance amongst all data and operations:Caching is only useful for common read operations; any DML (INSERT, UPDATE, and DELETE) that is executed will run at low, disk-based speeds. When used in an in-memory only mode, Altibase stores all data in memory, so any query that is run on the data will perform at cached speeds, including DML.Unlike many commercial caching solutions, Altibase does not lose data when shut down or restarted. Altibase adheres to full, real time ACID compliance that guarantees data durability. Altibase’s persistent cache is a default setting, and can recover all data without any issues.Since Altibase combines an in-memory database and an on-disk database in a single unified database, strict durability is possible and so is complete data durability.Altibase provides MOVE technology, allowing DBAs to decide which sets of data should be high-speed and which are designated for long-term storage.Altibase is a single database solution that meets all needs in any use case. With persistent in-memory and on-disk in a single database, flexibility and data integrity are given.Representative Use Cases That Can Take Advantage of Altibase’s Persistent Cache Solution?Any business that needs high performance can take advantage of it instantly:Risk ManagementFraud DetectionSecurity IntelligenceSupply Chain TrackingTelecom/Media Revenue LeakageService DeliveryOnline GamingInventory ForecastingTransportation Operation ManagementSoftware-as-a-ServiceReal time AnalyticsProfitability AnalysisGlobal Web CommerceSales Incentive Promotions Management 3 Types of Altibase’s Partitioning Description:List partitioning: Each partition is defined and selected based on the membership of the column value in one of lists composed of discrete values.Range partitioning: Each partition contains rows for which the partitioning expression value lies within a given range.Hash partitioning: Used to ensure an even distribution of data

Altibase can scale vertically and horizontally without any issues. Altibase can automatically account for the addition of new RAM and faster processors. In doing so, there will be an immediate performance increase. Altibase also can scale out horizontally via sharding. Please refer to the manual “Altibase Sharding Guide” for further information.Vertical ScalingAltibase’s products are designed for optimal vertical scalability. A key feature is Altibase’s ability to auto-extend in-memory tables. Horizontal Scaling via Sharding Altibase sharding utilizes both server-side and client-side sharding architecture.Applications do not need to change anything.Applications only need to know the IP and port of the meta DB of Altibase sharding.Altibase sharding is fast.A shard connection gives the execution order of a distributed query directly to a shard node without any intervening middleware.Altibase sharding supports SQL standard.distributed querynon-distributed query

Yes. Data partitioning is the division of a large database object into several small pieces for easier management of very large data sets. Objects can be partitioned in three ways: list, range, and hash.Altibase’s Partitioning TechnologyThese three ways of partitioning can be selectively used according to data size, data type, data usage, data density, and other database requirements.