Allow Multiple Tag
테이블 지원기존 버전에서는 한개의 Tag 테이블만 생성할 수 있는 문제를 해결하였다.
다중 Tag 테이블을 지원함으로써 다양한 스키마 형태로 들어오는 PLC 데이터를 효과적으로 저장할 수 있게 되었다.
테이블 이름 또한 자유롭게 지정할 수 있고 SYS가 아닌 일반 유저로 생성 가능하다Tables
The problem that only one tag table could be created in the previous version was solved.
By supporting multiple tag tables, it became possible to effectively store incoming PLC data in various schema types.
Table names can also be freely designated and can be created as a general user other than 'SYS'.
Code Block | ||||
---|---|---|---|---|
| ||||
CREATE TAG TABLE tag (tagid VARCHAR(50) PRIMARY KEY, time DATETIME BASETIME, value DOUBLE SUMMARIZED); CREATE TAG TABLE imotbl (tagid VARCHAR(20) PRIMARY KEY, time DATETIME BASETIME, value DOUBLE SUMMARIZED, imo INTEGER, machine VARCHAR(10)) TAG_PARTITION_COUNT = 1, TAG_DATA_PART_SIZE = 20000000; CREATE TAG TABLE shi985 (tagid VARCHAR(20) PRIMARY KEY, time DATETIME BASETIME, value DOUBLE SUMMARIZED, level INTEGER, itime DATETIME, strval VARCHAR(256)) TAG_PARTITION_COUNT = 2; Mach> show tables; USER_NAME DB_NAME TABLE_NAME TABLE_TYPE ----------------------------------------------------------------------------------------------------------------------------------------------- SYS MACHBASEDB IMOTBL TAGDATA SYS MACHBASEDB SHI985 TAGDATA SYS MACHBASEDB TAG TAGDATA SYS MACHBASEDB _IMOTBL_DATA_0 KEYVALUE SYS MACHBASEDB _IMOTBL_META LOOKUP SYS MACHBASEDB _SHI985_DATA_0 KEYVALUE SYS MACHBASEDB _SHI985_DATA_1 KEYVALUE SYS MACHBASEDB _SHI985_META LOOKUP SYS MACHBASEDB _TAG_DATA_0 KEYVALUE SYS MACHBASEDB _TAG_DATA_1 KEYVALUE SYS MACHBASEDB _TAG_DATA_2 KEYVALUE SYS MACHBASEDB _TAG_DATA_3 KEYVALUE SYS MACHBASEDB _TAG_META LOOKUP [13] row(s) selected. |
TAG 데이터 저장 구조 변경
디스크 사용량 감소를 위해 데이터 압축방식(delta compress)을 추가하고 칼럼단위로 저장하도록 데이터 구조가 변경되었다.
기존 version 대비 데이터사용량 비교 테스트 결과 디스크 사용량이 최대 37% 감소하였다.
Tag 10,000건
RowCount: 10억건Change The TAG Data Storage Structure
To reduce disk usage, a data compression method (delta compress) is used and the data structure was changed to store in column units.
As a result of the data usage comparison test compared to the previous version, the disk usage was reduced by up to 37%.
Test Environment | Disk Usage Change | Decrease Rate |
---|---|---|
Tag 10 thousands RowCount: 1 billion Rollup(O) | 11,105 MB -> 6,907 MB | 37.80% 감소reduced |
Tag 10,000건10 thousands RowCount: 10억건1 billion Rollup(O) | 11,007 MB -> 8,987 MB | 18.35% 감소reduced |
Tag 10,000건10 thousands RowCount: 10억건1 billion Rollup(O) | 14,836 MB -> 12,752 MB | 14.05% 감소reduced |
Reduce Tag Table Index Memory
사용량 절감TAG테이블 생성 시 Memory를 Index Build를 위한 Index Memory를 고정적으로 과도하게 할당하여 Memory를 효율적으로 사용할 수 없는 문제가 있어
Index Memory를 필요한 시점에 필요한 만큼의 Memory만 동적으로 할당하는 방식으로 변경하여 복수의 TAG태이블을 생성 및 동작이 가능하도록 하였다.
7.0에서는 아래와 같은 테스트 환경에서 기존 version에 비해 최대 Memory 사용량이 약 40%가량 감소 했다.
- 테스트환경: Tag 테이블 1개(partition 4개), Tag 10,000건 / 데이터 10억건 성능 테스트, PROCESSUsage
When creating the TAG table, there is a problem that the memory cannot be used efficiently because the memory for the index build is fixed and excessively allocated.
It is possible to create and operate multiple TAG tables, by changing the index memory to a method of dynamically allocating only the required amount of memory at the required time.
In 7.0, the maximum memory usage was reduced by about 40% compared to the previous version in the following test environment.
- Test environment: 1 tag table (4 partitions), 10,000 tags / 1 billion data performance test, PROCESS_MAX_SIZE 4GB
결과적으로As a result, when PROCESS_MAX_
SIZE를 16GB로 설정 시 TAG 테이블(PARITITION 4개 기준)을 2개만 생성할 수 있었으나, 7.0에서는 동일설정 하에서 TAG테이블을10개 이상 생성하여 사용할 수 있게 되었다.
운영환경에 따른 메모리 설정 가이드
초당 최대 입력 건수: append application은 TAG 테이블 수만큼 동작하는 상황에서 모든 append application의 초당 입력하는 데이터 합
(테이블당 append application 1개씩 동작)
Tag 수
(append 포함
SIZE is set to 16 GB, only two TAG tables (based on 4 PARTITIONs) could be created in previous version.
But more than 10 tag tables can be created and used at version 7 in same conditions.
Memory setting guide according to the operating environment
Maximum number of input per second: Sum of data input per second of all append applications when the append application operates as many as the number of TAG tables
(Operates one append application per table)
Operating Environment | Minimum Setting for System | Test Environment | ||||||||
Number of Tag Tables | Tag number per Table | Maximum append per second | Session Number (include append) | TAG_DATA_ PART_SIZE | TAG_PARTITION _COUNT | PROCESS_MAX_ SIZE | TAG_CACHE_MAX_ MEMORY_SIZE | CPU | MEM | DISK |
1 | 100,000 | 1,200,000 / sec | 4 | 16 M | 1 | 2 GB | 128 MB | 16 cores | 64 GB | SSD 1 TB |
1 | 100,000 | 1,000,000 / sec | 4 | 4 M | 1 | 1 GB | 32 MB | 16 cores | 64 GB | SSD 1 TB |
1 | 100,000 | 800,000 / sec | 4 | 1 M | 1 | 512 MB | 8 MB | 16 cores | 64 GB | SSD 1 TB |
8 | 100,000 | 4,000,000 / sec | 11 | 16 M | 1 | 8 GB | 256 MB | 16 cores | 64 GB | SSD 1 TB |
32 | 40,000 | 6,000,000 / sec | 35 | 16 M | 1 | 16 GB | 1024 MB | 16 cores | 64 GB | SSD 1 TB |
32 | 40,000 | 4,000,000 / sec | 35 | 4 M | 1 | 8 GB | 256 MB | 16 cores | 64 GB | SSD 1 TB |
64 | 20,000 | 4,000,000 / sec | 67 | 4 M | 1 | 8 GB | 512 MB | 16 cores | 64 GB | SSD 1 TB |
64 | 20,000 | 1,000,000 / sec | 67 | 1 M | 1 | 4 GB | 128 MB | 16 cores | 64 GB | SSD 1 TB |
128 | 10,000 | 4,000,000 / sec | 131 | 4 M | 1 | 8 GB | 1024 MB | 16 cores | 64 GB | SSD 1 TB |
128 | 10,000 | 1,000,000 / sec | 131 | 1 M | 1 | 4 GB | 256 MB | 16 cores | 64 GB | SSD 1 TB |
Tip |
---|
The TAG_CACHE_MAX_MEMORY_ |
SIZE value should be increased in proportion to the number of TAG tables, and if TAG_CACHE_MAX_MEMORY_ |
테이블 생성이 실패하게 된다.
적정SIZE is not sufficient when creating the TAG table, table creation may fail.
|
|
|
크게 설정 해야 한다.
|
TAG_CACHE_MAX_MEMORY_SIZE가 부족한 경우 테이블 생성을 실패시 다음과 같은 에러메시지가 출력 된다.
Code Block | ||
---|---|---|
| ||
++ create tag table tag1 (name varchar(20) primary key, time datetime basetime, value double summarized) tag_partition_count=1;
[ERR-01423: TAG cache exhausted, increase TAG_CACHE_MAX_MEMORY_SIZE(32768)]
Mach> |
TAG ID기반 통계값 생성 / 조회
Tag별 통계값 조회시 응답시간이 너무 긴 문제가 있으며 이를 개선하기 위해 Tag별 통계를 사전에 구성해 놓고,
조회의 편의성을 위해 view와 같은 형태로 조회 기능을 제공한다.
기존 version에서는 TAG통계조회시 data scan으로 인해 응답시간이 길었으나, 7.0에서는 필요한 통계정보를 사전에
구성함으로써 응답시간이 크게 단축 되었다.
Tag 통계 정보Create / Select of Statistic Data by TAG ID
There is a problem that the response time is too long when searching for statistical values by tag.
To improve this, statistics for each tag are configured in advance, and a search function is provided in the form of a view for convenience.
In the previous version, the response time was long due to data scan when selecting about TAG statistics.
But in 7.0, the response time was greatly reduced by configuring the necessary statistical information in advance.
Information of Tag Statistic
column | description |
---|---|
USER_ID | tag table user ID |
TABLE_NAME | tag table name |
TAG_ID | 통계 정보의 Tag ID (사용자 관점에서는 Name이 출력된다of Statistic Information (From the user's point of view, Name is returned) |
MIN_TIME | 현재까지 입력된 시간값의 최소치 (입력순서와 관계 없음Min time value inserted until now (regardless to input order) |
MAX_TIME | 현재까지 입력된 시간값의 최대치 (입력순서와 관계 없음Max time value inserted until now (regardless to input order) |
MIN_VALUE | 해당 tag의 Summarized 컬럼의 최소 값Min Value for the matched tag's Summarized column |
MIN_VALUE_TIME | Time value that is inserted with min_value와 같이 입력된 timevalue |
MAX_VALUE | 해당 tag의 Summarized 컬럼의 최대 값Max Value for the matched tag's Summarized column |
MAX_VALUE_TIME | Time value that is inserted with max_value와 같이 입력된 timevalue |
ROW_COUNT | 해당 Tag ID의 Row 개수Numbers of row maches to the Tag ID |
RECENT_ROW_TIME | 마지막에 입력된 Row의 Basetime 컬럼값 |
- query
Column value of the Last inserted row |
- query
Whenever a tag table is created, a view that stores statistical information is created together. When you want to inquire statistical information, it is searched from view.
view table name : "V$name_STAT" . (name 은 is tag 테이블 이름table name)
Code Block | ||
---|---|---|
| ||
-- ex) SELECT min_time, max_time FROM v$tag_stat WHERE tagid = 'tag-01'; -- ex) 여러개의multi tag SELECT min_time, max_time FROM v$tag_stat WHERE tagid IN ('tag-01', 'tag-02', 'tag-03'); |
If user wants to know value inserted in min_time (또는 or max_time) 에 입력된 value 를 알고싶다면 아래와 같이 조회가 가능하다, user can inquire as follow.
Code Block | ||
---|---|---|
| ||
SELECT value FROM tag WHERE tagid = 'tag-01' AND time = (SELECT min_time FROM v$tag_stat WHERE tagid = 'tag-01') |
Support JSON
타입 지원지원 배경
최근 TEXT 타입의 데이터를 전송하는 장비도 사용되고 있다.
JSON 타입을 지원하면, TEXT 타입 뿐만 아니라 임의의 데이터 타입을 전송할 수 있다.
따라서, 칼럼의 갯수나 구조가 비정형으로 가능하기 때문에 확장성이 매우 높아지는 효과를 기대할 수 있다.
장점
- 별도의 확장 칼럼을 추가할 필요가 없기 때문에, 스키마 제약이 사라진다.
- 사용자가 임의의 데이터 타입을 마음대로 넣을 수 있다.
- JSON 데이터 특성으로 사용성 및 편의성이 높고, 데이터를 분리할 필요가 없다.
데이터 범위
JSON data 길이Type
support background
Recently, equipment for transmitting TEXT type data is also being used.
If the JSON type is supported, not only the TEXT type but also any data type can be transmitted.
Therefore, since the number or structure of columns can be irregular, the effect of very high scalability can be expected.
Advantages
- Since there is no need to add a separate extension column, the schema constraint disappears.
- Users can input arbitrary data types as they want.
- Due to the characteristics of JSON data, usability and convenience are high, and there is no need to separate data.
Data range
- JSON data length : 1 ~ 32768 (32K)
- JSON path 길이 length : 1 ~ 512
데이터 생성
JSON 키워드를 사용하여 JSON 타입의 칼럼을 지정할 수 있다Creating data
- User can specify a JSON-type column using the JSON keyword.
Code Block | ||
---|---|---|
| ||
CREATE TABLE jsontbl (name VARCHAR(20), jval JSON); |
데이터 삽입
Inserting data
- You can insert data by entering TEXT that matches the JSON format.
- If it does not match the JSON format, ERROR is printed.
Code Block | ||
---|---|---|
| ||
-- Single INSERT INTO jsontbl VALUES("name1", '{"name":"test1"}'); -- Multi INSERT INTO jsontbl VALUES("name2", '{"name":"test2", "value":123}'); -- Nested INSERT INTO jsontbl VALUES("name3", '{"name":{"class1": "test3"}}'); -- Array INSERT INTO jsontbl VALUES("name4", '{"myarray": [1, 2, 3, 4]}'); |
데이터 추출
JSON 관련 함수를 사용하거나,Selecting data
- You can partially extract JSON data by using JSON-related functions or by using Operator (->)를 사용하여 JSON 데이터를 부분적으로 추출할 수 있다.
Code Block | ||
---|---|---|
| ||
-- 함수 사용Using JSON-related function SELECT name, JSON_EXTRACT(jval, '$.name') FROM jsontbl; SELECT name, JSON_EXTRACT_INTEGER(jval, '$.myarray') FROM jsontbl; SELECT name, JSON_TYPEOF(jval, '$.name.class1') FROM jsontbl; -- Using Operator(->) 사용 SELECT name, jval->'$.name' FROM jsontbl; SELECT name, jval->'$.myarray' FROM jsontbl; SELECT name, jval->'$.name.class1' FROM jsontbl; |
JSON 관련 함수
-related function
Function name | Description | Note |
---|---|---|
JSON_EXTRACT(JSON 칼럼명column name, 'json path') | 해당 값을 string type으로 출력한다. (해당 객체가 없을 경우 ERROR를 출력한다Returns the value in string type. (If the object does not exist, ERROR is returned.) |
|
JSON_EXTRACT_STRING(JSON 칼럼명column name, 'json path') | 해당 값을 string type으로 출력한다. (해당 객체가 없을 경우 NULL을 출력한다.) Returns the value in string type. (If the object does not exist, NULL is returned.) Same results as operator(->)와 같은 결과를 출력한다. |
|
JSON_EXTRACT_INTEGER(JSON 칼럼명column name, 'json path') | 해당 값을 64비트 integer type으로 출력한다. (해당 객체가 없을 경우 NULL을 출력한다Returns the value in 64 bits integer type. (If the object does not exist, NULL is returned.) |
|
JSON_EXTRACT_DOUBLE(JSON 칼럼명column name, 'json path') | 해당 값을 부동소수점 64비트 double type으로 출력한다. (해당 객체가 없을 경우 NULL을 출력한다Returns the value in floating-point 64 bits double type. (If the object does not exist, NULL is returned.) |
|
JSON_TYPEOF(JSON 칼럼명column name, 'json path') | 해당 값의 타입을 반환한다Return the type of value. |
|
JSON_IS_VALID('json string') | json string이 json format에 유효한지 확인한다 Check if json string is valid in json format. |
|