요즘 IT쪽에 보안 문제가 큰 화두가 되고있습니다. 물론 보안은 아주 기본적인 요구사항입니다. 하지만 제 경험상 보안 솔루션 도입은 비용과 운용상의 불편함을 이유로 검토 후 보류해버리는 경우가 많았습니다.
요즘 수 많은 사건사고로 인해서 보안 솔루션 도입에 꽤 적극적이 된 회사의 모습을 보면, 역시 어디서 한 건 터지고, 법으로 규제해야 기업체가 돈을 쓴다는걸 다시한번 머리속에 새깁니다. (기업이 돈을 많이 남기면 재투자하고, 고용을 확대해서 서민 경제가 좋아진다는 얘기는 어느나라 얘기일지...)
티베로 엔지니어를 통해서 확인한 티베로를 지원하는 DBMS 접근제어 솔루션들입니다.
1. 피앤피시큐어의 DBSafer
2. 웨어벨리의 Shakra(샤크라) 샤크라 맥스는 아직 티베로를 지원하지 않고 샤크라만 티베로를 지원한다고 합니다.
그리고 제작사측에서 티베로를 지원한다고 연락이 온 DBMS 접근제어 솔루션이 있습니다. 1. 신시웨이의 Petra(페트라)
MySQL Storage Engine들을 비교해볼 일이 생겨서 자료를 찾아봤습니다. 5.1 버전과 5.5 버전의 영문 메뉴얼을 보면서 정리한 내용입니다. MySQLKorea의 5.1버전 한글 번역판도 참고 했습니다.
1. MyISAM
Transaction을 지원하지 않지만 기본 Storage engine이며 많이 사용되고 있다. Table을 각각 독립적인 File에 저장한다. 5.5. 버전을 기준으로 256 TB까지 저장할 수 있다. Transaction을 지원하지 않는 대신 빠르고, 디스크 공간을 덜 차지하며, Update를 위한 메모리 공간도 적게 사용한다. Transaction을 지원하지 않는 MyISAM 때문에 MySQL은 RDBMS로 인정해주지 못하겠다는 의견도 있었습니다. ("그러면 엑셀도 DB냐??"같은 의견이었죠.) 이제는 InnoDB같이 Transaction을 지원하는 Engine도 기본으로 설치되고 (설치는 되지만 여전히 사용 여부는 운영자의 판단이죠.), Transaction 지원을 포기한 대신에 빠른 속도와 가벼운 시스템 부하 등도 하나의 컨셉으로 받아들여지는것 같습니다. 하지만... Transaction을 지원하지 않는것은 큰 약점이라고 생각합니다. DB에서 처리해줄 Transaction을 Application상에서 구현해줘야 하니까요.
2. Memory
Table을 Memory에 저장하는 engine이다. 서버 재기동시 모든 data가 삭제된다. 5.5 버전 기준으로 RAM의 여유공간만큼 저장할 수 있다. Hash index를 지원한다. Memory상에 Table이 직접 올라가 있으니 조회 속도는 엄청 좋을거라 생각합니다. 물론 시스템 부하가 얼마나 걸리는지, 과연 비싼 서버 메모리 비용을 부담할 만큼의 이점이 있는지는 실제 테스트를 한뒤 결정해야한다고 생각합니다.
3. Merge
여러개의 Table을 하나의 Table처럼 사용할 수 있게 해주는 Storage engine이라고 한다. 이부분은 음... 어떻게 보면 재밌게 쓸 수 있을거 같은데, 다음에 좀더 알아보고 정리하겠습니다.
4. InnoDB
Transaction을 지원하는 Storage engine이다.(기본 설정은 Auto commit이다) Foregine key 제약 사항, Clustered index, Row level lock을 지원하며 최대 64 TB까지 저장할 수 있다. Oracle과 유사하게 Tablespace에 data를 저장한다. 기본으로 설치용 바이너리 배포판에 포함되어 있다. SUN Microsystems가 Oracle에 인수되기 이전에 이미 Oracle사에 인수되어서 한때 MySQL 진영에서 InnoDB를 대체할 Storage Engine을 개발하려는 움직임이 있었죠.
5. BDB
BDB는 BerkeleyDB의 약자이다. InnoDB와 마찬가지로 Tarnsaction을 지원하는 storage engine이다. 다른 점이 있다면 Table을 저장할 때 MyISAM처럼 Table별로 독립된 File을 생성해서 저장한다는 점이다. 5.5 버전의 문서에 지원하는 Storage engine에서 제외된 걸로 봐서 앞으로의 공식 지원은 불투명한 상태이다. (뭐 이건 주관적인 생각입니다.) BerkeleyDB 역시 InnoDB와 마찬가지로 Sun Microsystems 인수 이전에 Oracle에 인수되었죠.(맞을겁니다.) MySQL과 별도로 단독으로 Application에 내장되어서 파일 기반의 DB로도 사용 가능합니다. 활용도가 높다고 생각합니다. 앞으로 어떻게 될지는 지켜봐야 겠네요.
6. Archive
대용량의 데이타를 인덱스 없이 저장하기 위한 Storage engine이다. INSERT, SELECT는 지원하지만, DELETE, UPDATE는 지원하지 않는다. 저장할 수 있는 크기에 제한이 없다.
7. CSV
Text file에 data를 저장하는 storage engine이다. 저장된 data file을 MS Excel이나 OpenOffice Calc같은 spreadsheet에서 열 수 있다. Index를 지원하지 않고, NULL도 저장할 수 없다. 이거... 성능만 나쁘지 않다면 꽤 유용하게 쓸 수 있지 않을까요?!?! 이걸 어떻게 써먹을지 궁리를 좀 해봐야 겠습니다. 그리고 성능이 얼마나 나오는지도 확인해봐야 겠죠?
이상 너무 간단하지만, MySQL Storage Engine들에 대한 정리를 마칩니다. 영문 메뉴얼을 좀더 읽어보고, 실제로 Test도 해본뒤에 좀더 유용한 자료를 만들면 다시 올리겠습니다. 그럼 이만...
STRING 함수의 첫번째 인자값이 X이면 영문자 대문자와 숫자를 섞어서 무작위로 추출을 하고, A이면 영문자 대소문자를 섞어서 무작위로 추출을 합니다. 두번째 인자값은 문자열을 몇 자리로 할건지 지정해주는 인자입니다. 자세한 내용은 참고 문서의 내용을 확인해보시기 바랍니다. Oracle에 대한 문서이긴한데... Tibero에 적용해도 별 문제는 없네요.
