|
mysqlfs 라고 들어 본적이 있는가?
아주 MySQL 에 관심이 깊은 사람이고, 메일링 리스트를 열심히 보는 분이라면 들어 본적이 있을 것이다. 이것은 엄격히는 filesystem 은 아니다. CORBA 를 이용하여 MySQL 디비를 filesystem 처럼 mount 하여 사용하는 것이다. mount 한 후에는 각각의 테이블은 디렉토리가 되고, 각각의 필드들은 해당 디렉토리의 file 처럼 여겨지게 된다. 그리하여 filesystem 을 다루는 ls/cat 등등의 명령어로 DB 의 내용을 조회할 수 있게 된다.
이것의 이점이 있는가?
현재로서는 실험 단계로서 그렇게 큰 이점을 가지지 못한다. 단지 shell script 정도에서 마음대로 디비 내용을 불러 사용할 수 있을 것이라고 기대 하는 정도 일까. 하지만 이것이 CORBA filesystem 의 full functionality 를 가지게 된다면 이야기는 달라진다. 약간의 패치로서 손쉽게 distributed DB system 을 구현할 수 있을 것이다. 그리고 관념적인 RDBMS 가 가지는 여러가지 단점중 일부는 이로서 해결 가능해 질 것이다.
단점도 만만찮게 많다. 일단 보안이 문제가 될 소지가 크며, 시스템 접근성으로 인한 DB fault 도 전용 시스템 보다는 커질 소지가 크다. 트랜젝션의 문제도 해결하기 만만찮아 질 것이다. 기타 등등 여러가지 단점을 가지게 될 공산이 크다.
그러나 개인적으로 이런 미완의 문제점을 제쳐 두고 그 시도만큼은 아주 훌륭한 것으로 판단하고 있으며, 많은 문제점을 해결한 뒤에는 우리가 예상치 못한 선물을 던져 줄 지도 모른다는 기대감으로 소개의 글을 적어 본다.
이곳에서는 CORBA 파일 시스템에 대한 여러가지 기술적인 문제는 논하지 않겠다. 단지 mount 시키는 법 사용법에 대해서만 간단히 적고자 하며, 자세한 기술적인 문제는 글의 마지막에 소개하는 참조 사이트를 기본으로 해서 구현해 보기 바란다.
어떻게 할것인가?
단순히 일반적으로 파일 시스템을 mount 시키듯이 하면 된다.
root@localhost/root]# mount -t corbafs -o `cat /tmp/mysqlcorbafs.ior` none /mnt/mysql/
[root@localhost/root]# mount
/dev/hda3 on / type ext2 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /mnt/win type vfat (rw,mode=777)
/dev/hda4 on /mnt/linux type vfat (rw,noexec,nosuid,nodev,mode=777)
none on /mnt/mysql type corbafs (rw,IOR:01e50d401b00000049444c3a436f72626146532f46696c6553797374656d3a312e3
00000010000000000000030000000010100000a0000003132372e302e302e3100080418000
000000000009224bc335663462a01000000ef7ae13c0943c59f)
[root@localhost/root]#
[root@localhost/root]# ls -la /mnt/mysql/
total0
-r-xr-xr-x 1 root root 4096 dets 29 22:21 .uptime
dr-xr-xr-x 1 root root 4096 dets 29 22:21 test
dr-xr-xr-x 1 root root 4096 dets 29 22:21 mysql
[root@localhost/root]#
[root@localhost/root]# cat /mnt/mysql/.uptime
1994
[root@localhost/root]#
[root@localhost/root]# cat /mnt/mysql/mysql/user/Host
cpq.spam.ee
cpq.spam.ee
localhost
localhost
localhost
localhost
localhost
localhost
[root@localhost/root]#
[root@localhost/root]# cat /mnt/mysql/mysql/user/Insert_priv
N
N
N
N
N
N
Y
Y
[root@localhost/root]#
[root@localhost/root]# umount /mnt/mysql/
[root@localhost/root]#
재미있지 않은가?
왜 사용하는가?
앞서 서론에서 언급했듯이 아직은 미완의 대기이며, 단지 실험성이 돗보이는 방법에 지나지 않는다고 생각할 수도 있다. 하지만 어떤 면에서 이러한 생각들은 우리가 디비를 다루는데 많은 편리함을 더해 줄 수도 있을 것이다. Filesystem 이나 MySQL 이나 둘다 데이터베이스이다. Filesystem 은 전형적인 file-based database 로 생각할 수 있으며, 그 객체로서 파일/디렉토리 등등을 가지게 되는 것이다. 약간만 더 확장해서 생각해 보면 이 파일시스템과 데이터베이스가 크게 다르지 않다는 것을 이해할 수 있을 것이다.
언젠가 약간의 세월이 더 흘러서 OS 상에서 파일 시스템을 Object-oriented 방식으로 지원하는 OS 가 나온다면 아마도 다음과 같은 시나리오가 가능할 것이다.
dir=readdir
dir.list
dir.file1.size
이런식의 출력이 가능할 것이다. MySQL 도 그 개념은 마찬가지다. 파일 시스템과 데이터베이스의 차이점은 엄연히 존재하며, 서로서로 장단점이 존재한다. 만약 이러한 mysqlfs 의 실험이 성공한다면 서로의 장점만을 가진 시스템의 구현이 가능할 수도 있는 것이다. filesystem 의 대표적인 장점은 사용자가 access 하기 쉽다는 것이다. 그리고 익숙해져 있는 환경이라는 것이 큰 장점이다. 사용자가 객체(디렉토리, 파일)의 이름만 안다면 쉽게 접근해서 내용을 보고 얻고자 하는 정보를 쉽게 얻을 수 있다. 또한 아무리 초보라도 파일을 move/copy/rename/delete 시키는 방법은 누구나 배우고 숙지하게 된다. 이러한 명령어가 데이터베이스에 그대로 적용이 가능해 지며, 또한 이러한 동작의 결과가 DBMS 를 통해 데이터베이스 그대로 반영이 가능해 지는 것이다.
대부분의 초보 사용자들은 move/copy/rename/delete 명령어를 배워서 이미 알고 있는 경우가 대부분이지만 SQL 명려어는 대부분 응용프로그램 내부에 가려져 있는 경우가 많으므로 사용자들이 그 사용법을 모르는 경우가 허다하기 때문에 여기서 파일시스템의 장점이 또다시 부각되는 것이다.
즉 mysqlfs 는 이러한 SQL 을 좀더 사용자 수준에 더 가깝게 해주는 역할을 충분히 해 줄수 있다. 사용자는 그들이 평소에 잘 아는 방식으로 MySQL 에 접근할 수 있으며, 이러한 방법은 어떤 platform 이든지 상관없이 가능한 것이다. 그리고 응용프로그램 개발자의 입장에서도 파일 시스템을 다루는 명령어와 함수만으로 데이터베이스의 취급이 가능해 진다.
그리고 현재는 network 을 통해 DBMS 로 접근할려면 당연히 특별한 protocol 을 이용해야만 한다. 하지만 mysqlfs 는 이러한 경우 특별한 프로토콜이 필요하지 않고, CORBA 에서 제공하는 네트워크 프로토콜만으로 넷트워크 데이터베이스의 구성이 가능해 지는 것이다. 물론 filesystem 에 물린 후에는 NFS 등을 통해서, MySQL 이 포팅되지 않은, 서로 다른 이기종간에도 쉽게 디비의 공유가 가능해 지는 것이다.
백업과 version control 이 쉽게 해결될 수 있다. 파일시스템의 기존의 수 많은 백업 시스템을 갖추고 있으며, 버전 컨트롤 시스템 또한 여러가지 훌륭한 프로그램들이 많이 존재한다. 하지만 DBMS 는 그렇지 아니하다. 아직 기본적인 수준의 백업 시스템만을 제공하고 있는 수준이며, 버전 컨트롤은 아예 꿈도 꾸지 못하고 있는 실정이다. 하지만 이러한 것들이 손쉽게 해결될 열쇠를 제공해 줄 수도 있다.
데이터베이스로 부터 간단한 정보를 불러 내는 응용프로그램을 생각해 보자. 아무리 간단해도 다음과 같은 단계는 거쳐야 한다.
1. DBMS 로 접근한다.
2. 데이터베이스를 선택한다.
3. 원하는 정보를 select 하기 위한 SQL 구문을 실행한다.
4. 결과를 불러와서 retrieve 해야 한다.
5. DBMS 연결을 닫는다.
그런데 파일시스템을 이용하는 경우를 가정해 보자.
1. 원하는 정보가 든 파일을 읽어 들인다.
2. 결과를 retrieve 한다.
훨씬 간단하지 않은가?
나는 개인적으로 데이터베이스에 입력하는 과정을 SQL 구문을 통해서가 아니고 vi 에서 텍스트를 작성하는 것으로 끝냈으면 하는 바램을 가진 사람이다. 이것이 가능할 것 같지 않은가?
Performance
이것은 정확히는 운용하는 파일시스템의 속도와 그리고 여러분들이 하고자 하는 작업의 종류에 따라 다를 것이라고 생각한다. 사실 아직까지는 그렇게 빠르지 아니하다. 기존의 MySQL DBMS 를 사용하는 것보다 훨씬 느린 결과를 보여주고 있다. 하지만 일련의 SQL 작업들 보다는 filesystem 작업이 더 빠른 경우가 많으므로 이것은 앞으로 충분히 수정될 수 있는 것으로 판단된다. 개인적인 생각으로는 응용프로그램의 작성시 filesystem 함수와 native SQL function 을 같이 사용한다면 훨씬 더 간단히 많은 작업을 할수 있을 것으로 판단된다.
현재까지 어느 정도 수준으로 구현되어 있는가?
모든 테이블형식 (MyISAM, DBD, HEAP, ISAM)을 다 지원하고 있다. 그러나 안타깝게도 read-only procedure 만 가능하다. 곧 read-write 가 모두 가능해 질 것으로 판단된다.
MySQL 은 그 구조상 record number 를 가지지 않으므로, 앞으로의 구현 계획은 primary key 가 테이블에 존재해야 하며, 이 primary key 를 디렉토리 이름으로 하며, 그 필드의 내용은 각각의 분리된 파일로 강구하는 방법으로 구현되어 있다. 하지만 앞으로는 약간 바뀔 가능성도 있다.
/mnt/mysql/mydata/invoice/1/invoice_id
/mnt/mysql/mydata/invoice/1/invoice_no
/mnt/mysql/mydata/invoice/1/payee
/mnt/mysql/mydata/invoice/2/invoice_id
/mnt/mysql/mydata/invoice/2/invoice_no
/mnt/mysql/mydata/invoice/2/payee
/mnt/mysql/mydata/invoice/3/invoice_id
/mnt/mysql/mydata/invoice/3/invoice_no
/mnt/mysql/mydata/invoice/3/payee
그리고 여러가지 정보를 저장해 주는 객체들도 해당 파일로 구현될 예정이라고 한다. 즉 다음과 같은 접근법이 가능해 지는 것이다.
/mountpoint/.version
/mountpoint/.last_insert_id
/mountpoint/.uptime
/mountpoint/database/.raid
/mountpoint/database/.type
/mountpoint/database/.tables
/mountpoint/database/table/.created
/mountpoint/database/table/.last_updated
/mountpoint/database/table/.last_checked
/mountpoint/database/table/.count
그리고 앞으로 특정 디렉토리에 SQL 명령어를 가지는 파일을 저장하면 그것이 SQL 명령어로서 실행될 수 있도록 구현할 생각이라고 한다. 이것은 획기적인 생각이다. SQL 명령어를 파일시스템에서 사용할 수 있는 방법이 열리는 것이다.
/mountpoint/database/.command/
라는 디렉토리를 만들어서 이 디렉토리 내에 SQL 명령어를 파일 이름 또는 파일의 내용으로 저장 시키면 명령어가 실행되는 방식의 구현을 생각중이라고 한다.
사용자 인증 문제는 보안과 직결된 문제인데, 이 부분은 할수 없이 Unix 시스템 사용자와 MySQL 디비 사용자가 동일해야 하며, 서로 동일한 권한을 가지는 것으로 가정하고 구현할 계획이라 한다. 이는 filesystem 의 특성상 할 수 없는 부분 같다.
MySQL fs 는 현재 개발중으로 아직 MySQL 배포본에는 포함되지 않은 방식이다. 이는 4.0 정식이 나오기 전에는 정식적으로 포함되지 않을 것으로 판단된다.
mysqlfs 는 korbit (http://korbit.sourceforge.net/) 에 의존하고 있다. 이를 기반으로 개발된 filesystem 이다. korbit 는 아직 Linux 에 정식적으로 포함된 커널 패치는 아니다. 현재는 2.4.0 에서만 이용가능한 패치가 배포되고 있다. 곧 표준 리눅스 커널 패치로서 포함될 계획이다.
결론
이 방식은 많은 가능성을 내포한 것이다. 이것은 MySQL 이 data 를 저장하는 방식을 바꿀수는 없다. 오로지 사용자가 MySQL data 로 접근하는 방식을 다양화 시키는 것에 지나지 않는다. MySQL 디비 시스템 자체가 변하지는 않을 것이다.
참고 사이트
korbit homepage : http://korbit.sourceforge.net/
Slashdot 에서 행해지 mysqlfs 에 대한 토론 : http://slashdot.org/article.pl?sid=01/01/16/1855253&mode=thread&threshold=1
Tonu Samuel homepage : http://no.spam.ee/~tonu/index.html
그외 mysqlfs 프로젝트와 관련된 잡다한 참고사이트들....
|
