This document contains frequently asked questions (FAQ) about data access, performance, management, modeling, and network issues for the IRIS DB distributed database. It discusses SQL and custom interfaces, data formats and bulk loading, performance scaling based on nodes and hardware, data duplication, recovery from failures, global and partitioned tables, documentation and support, and network configurations including direct client access.

1. FAQ - Data Access for IRIS DB
 Data Interfaces
 Standard SQL interface, JDBC Interface
 Custom loading/exporting via CLI (Command Line Interface)
 Data Format
 For low traffic - Simple JDBC connection would suffice.
 For high volume traffic – Bulk loader may treat data stored in files of 1m, 5m traffic.
 No specific restrictions/configuration for frequency – the size of the data chunk for bulk
loading is decided by the developer of the loader
 Data Access Mechanism
 Simple SQL interface is provided – for short term queries.
 CLI interface with some suite of loaders are provided for higher volume of data.
 Data export is done by CLI commands, producing file result.
 Standard FTP is used both ways for importing and exporting, with the help of CLI loaders.
 Simple Oracle/IRIS export tool is provided.
 Export/Import tools can be customized for other DBMS, if requested.
1

2. FAQ - Performance Consideration of IRIS DB
Performance Limitations
 Maximum performance is achieved as follows (SK Telecom)
 Number of nodes – 35 nodes (including active/standby masters)
 Each node with 256 GB RAM, 36 TB DISKs, 12 cores CPU, 2 x 1 Gbps
 10G switch x 1, 3 Racks
 Daily Traffic: 80 billion records per day.
 Performance depends on the number of nodes
 Per node – inserting 8.6 billion records (or 2.5 TB) per day (in 100% CPU Utilization)
 Sizing factors
 Number of duplication (usually 2)
 Traffic volume incoming (affects the CPU & Network capacity)
 Which kinds of real-time computation is required.
 How many summary operations per min/5min
 How long the data should be retained in the system. (90 days, or 6 months, etc)
 By default, all data is compressed, (ratio 50%~70%, doubling the available space.)
 Types of incoming queries.
 Time-ranged selection of complex joining & filtering queries
 Typical Setup for PoC
 Depends on the PoC requirement and the hardware set for the PoC
 Typical configuration would be,
 5 nodes, (1 master, 4 data)
 4 data nodes with 12 cores CPU, 64 GB RAM, 2 x 2TB HDD, 1 Gbps Net
 All packaged in 4 U Chassis
 1 external Gbps switch with 10G Uplink
 Accepting 2 billion records per day (roughly 640 GB per day)
 Provides on-premise cluster packaged in 4U chassis for PoC purpose.
2

3. FAQ - Data Management in IRIS DB
 Data Duplication & Recovery
 Users may choose duplication level, normally 2. (Hadoop default is 3)
 All data is to be stored in different nodes.
 Disk level failure (including server level failure) doesn’t cause service downtime, if the
failure level is within duplicated tolerance.
 Disk/Server failure is recovered by H/W replacement and additional data recovery
commands.
 Data recovery is done by manual operation, not automatic.
 Necessary command line toolset is provided.
 Recovery time is dependent on the amount of data affected.
 Network bandwidth is the deciding factor of recovery time – 1 Gbps internal bandwidth within
cluster.
 Missing data (lost by Disk/HW failure) is identified by the location management table.
 Location data is stored in master node.
 Location data can be recovered from data node, from scratch (even if master node is
completely failed – time-consuming.)
 Master node is secured by active/stand-by duplication.
3

4. FAQ - Data Model of IRIS DB
 Data Model
 It’s a distributed database, sharded/partitioned, shared-nothing.
 By default, all tables are potentially regarded as big tables.
 A big table is to be partitioned into distributed nodes
 JOIN inter big tables are not allowed.
 For JOIN like operations over big tables, we give special interface with open-source
adaptors with Hadoop & Spark, which enables every kinds of Map/Reduce jobs.
 Special purpose ‘global table’ needs user-specification at creation time.
 ‘Global tables’ are small tables duplications on all data nodes within cluster.
 JOIN is allowed between a big table and a global table.
 Global tables usually contain lookup data for configuration or similar.
 Users are required to specify ‘partition key’s.
 IRIS-DB is mostly same as traditional database, if not partitioning nature.
 Users may create tables by conventional CREATE SQL commands.
 With ‘HINT’ as the partitioning key specification.
4

5. FAQ - Support for IRIS DB
 Documentation & Support
 Documentation & support is done by support engineers in Mobigen, Seoul.
 Support and documentations are mostly in Korean, now.
 For English or other languages, we need some more work.
 Specific business condition is to be identified for more support other than in
Korean.
 Documents are mostly for developers & system administrators.
 For developers, a user guide on SQL and tool commands is provided.
 For admin, a user guide for system administration & data management is
provided.
 Most supporting issues recently raised from the customers are:
 Questions related to the specific SQL syntax for specific cases
 Data management issues (Data expiration & Storage management issues)
 Scale out planning issues (How much new nodes are required, for expected
traffic)
 Troubles related to H/W failures – DISK failure.
 H/W failures are handled by H/W supporting engineers from OEM manufacturer.
 S/W failures are handled by Mobigen engineers.
5

6. FAQ - Network Issues of IRIS DB
 Network Restrictions
 Normally a 10Gbps uplink, 1Gbps inner cluster network is used.
 If inner connections are required to be wider than 1 Gbps,
two 1Gbps lines are bonded and make 2Gbps bandwidth.
 L2 Switch is added as required by the number of data nodes grows.
 For higher bandwidth, a ‘direct-access’ is supported.
 In a ‘direct access mode’, external client may access not only the master nodes, but
also the data nodes directly.
 The direct access is controlled by the CLI command or the client JDBC library.
 For direct access mode, data nodes are to be visible outside the cluster.
 This requires the IP address to be visible from outside.
 From external view, the whole cluster is regarded as a single machine, under the
control of JDBC library or CLI commands.
 JDBC client library and CLI command accesses the (active) master node first, and
accesses the data nodes if necessary (on direct mode).
 If active node is shutdown, stand-by node is activated, and from the external view
point the downtime is observed as a session close. A reconnection may lead to the
connection to the secondary master. This retrial is done by the library.
6