동운 HMI 태그 저장 방식 개선

동운 HMI를 최초에 설계할 당시 태그값을 데이터베이스에 저장하기 위한 스키마를 어떻게 구성할 것인가를 두고 여러 가지로 고민했습니다. 어찌했든 데이터베이스 쿼리가 늘어날 수록 성능은 저하되므로 태그값 저장 대상은 되도록 한번에 삽입(INSERT) 할 수 있으면 최적이겠다 싶었습니다. 그렇지만, 태그가 늘어나거나 삭제, 변경되는 경우 융통성있게 대응하기 어렵다는 문제때문에 결국 성능 보다는 프로그래밍의 효율성에 초점을 맞추어 데이터베이스 스키마를 생성했습니다.

그래서, 동운 HMI의 기존 스키마는 위의 그림과 같이 데이터 타입별로 태그명과 일자, 값을 저장하는 방식으로 시스템 전체적으로 보면 공간 효율성이 떨어지는 결과를 낳을 수 있었습니다.

또한, 프로세스 측면에서도 Prepared Statement를 사용해서 데이터베이스 쿼리의 효율성을 높이려고 하지만 각 태그별로 데이터베이스 저장 작업을 수행하기 때문에 태그가 늘어 날 수록 그만큼 성능은 급격히 저하될 수 밖에 없는 구조였습니다.

그래서 이번에 수행한 태그 저장 방식 개선은 데이터베이스 스키마를 데이터 타입별 테이블이 아니라 초단위 저장 주기별 테이블로 구성하고 해당 테이블에는 서로 다른 데이터 타입의 태그가 같이 저장되도록 했습니다. 

데이터베이스 스키마 변경에 따른 프로세스 변경으로 태그 개수의 증가나 삭제, 변경이 있어서 전체적인 성능에는 별 영향이 없는 구조가 되었습니다. 초 단위 저장 주기로 데이터베이스 쿼리는 1회로 끝나기 때문입니다. 문제는 태그의 추가, 삭제 및 변경에 따른 데이터베이스 스키마의 대응인데 이 문제를 동적으로 스키마를 조정하는 방식으로 해결 했습니다. 태그가 추가되면 해당 저장주기별 테이블의 컬럼을 추가합니다. 태그의 데이터 타입이 변경되는 경우에는 일부의 경우 기존 데이터를 살릴 수 있지만 프로그램에서는 해당 컬럼을 삭제했다가 새로운 타입으로 추가하는 방식을 적용했습니다. 

만약에 태그의 데이터 타입 변경에도 불구하고 기존 로그 자료를 살리고 있다면 기존 자료를 임시 테이블에 저장해 두었다가 스키마 변경후 수작업으로 데이터를 업데이트 하면 됩니다. 태그를 삭제한 경우에는 데이터베이스 컬럼에 별다른 조치를 취하지 않은 방식으로 기존 데이터를 보존하도록 했습니다.

이번에 변경에 작업에 영향을 미치는 클래스들은 다음과 같습니다.

• 글로벌 클래스
  태그명을 강제로 대문자로 일원화 처리 등
  TagGbl.cs

• 클라이언트 DB 드라이버 클래스
  태그 기록 조회, 트렌드 조회 방식 변경
  CliCubrid.cs, CliFirebird.cs, CliMemory.cs, CliMySQL.cs, CliOracle.cs, CliSQLite.cs, CliSQLServer.cs, CliTibero.cs

• 서버 DB 드라이버 클래스
  태그 저장 방식 변경DBCubrid.cs, DBFirebird.cs, DBMemory.cs, DBMySQL.cs, DBOracle.cs, DBSQLite.cs, DBSQLServer.cs, DBTibero.cs

동운 HMI에서는 큐브리드, 파이어버드, 내장 메모리, MySQL(MariaDB), 오라클, SQL 서버, 티베로, SQLite DBMS에 대한 드라이버를 지원하고 있는데, 금번 작업에 대하여 SQLite의 경우에는 제약 사항이 한가지 있습니다. SQLite DBMS의 경우에는 컬럼 추가 DDL은 존재하지만 컬럼 삭제 DDL은 지원하지 않기 때문에 타입이 변경되는 경우 해당 태그는 저장하지 않는 방식으로 적용했습니다(태그 타입의 변경은 지원하지 않음). 만약 기존 태그 값을 보존하면서 태그 타입을 변경하려면 테이블 전체를 삭제하거나 데이터 타입을 변경할 컬럼을 삭제한 다음 동운 HMI를 가동 시키면 자동 적용 됩니다.

(주)동운시스템 전화 041-358-3760

동운 HMI 소개 바로가기

[온라인 문의 및 견적요청]