C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

헤드라인 뉴스
[297] Firebird, 2006년/이후 로드맵 발표
박지훈.임프 [cbuilder] 11649 읽음    2006-02-02 04:58
Firebird Future Development : What to Expect in 2006
- 드미트리 예마노프(Dmitry Yemanov)

파이어버드 2.0 리뷰


많은 파이어버드 사용자들이 파이어버드 1.5에서 공개된 새로운 기능들의 많은 숫자에 놀랐습니다. 솔직히 말하면, 저는 이 글을 준비하기 전까지 파이어버드 2.0의 새로운 기능들을 세어보지 않았고 이런 측면에서 1.5 버전보다 더 뛰어난지 아닌지에 대한 단서도 없는 상태였습니다. 하지만 제 생각에는 2.0 버전의 주요 이점은 기능들의 갯수가 아닙니다.

"그럼 뭐?"라고 물으실 것입니다. 저는 파이어버드 2.0을 "귀찮은 한계점들을 제거한 버전"이라고 표현하겠습니다. 지나치게 겸손하게 들릴 수도 있다는 것을 압니다. 이제 자세한 설명을 드리죠. 파이어버드가 뛰어난 멀티-제너레이셔널 아키텍처와 풍부한 SQL 언어, 그리고 임베디드 기능에다 좋은 성능까지 가지고 있다는 점은 의심할 여지가 없습니다. 하지만 저는 대부분의 사람들이 몇몇 내부적인 제한점들에 부딛혀보고 우려하거나 심지어는 충격까지 받았을 거라고 생각합니다. 몇몇을 나열하자면... (순서에 별 뜻은 없습니다)

  • 35GB의 테이블 크기 제한이 문서화되어 있지 않아 이 크기를 넘어설 경우 데이터 오류가 발생할 것임
  • 넌-셀렉티브(non-selective) 인덱스에서 (가비지 컬렉션을 하는) 노드들을 제거하는 작업이 극도로 느림
  • 페이지 캐시가 클 경우 성능이 낮아질 경우가 종종 있음
  • 많은 경우에 옵티마이저가 좋은 플랜을 선택하지 못할 수 있음
  • 다국어 지원이 취약하며 유니코드/MBCS 처리에서 많은 버그가 있음
  • 빠른 백업/리스토어 메커니즘이 부족함
  • 보안성이 약하며 많은 알려진 취약성이 있음
  • 참조 무결성 선언에 대해 배타적인 데이터베이스 액세스가 요구됨
  • 자체 내장 함수가 너무 적음
  • 데이터베이스 셧다운을 신뢰할 수 없음

    이중 일부는 여러분의 비즈니스에 결정적일 것이고 그외 일부는 단지 귀찮은 정도의 문제일 것입니다. 어쨌든, 저는 파이어버드 2.0이 위의 문제점들의 대부분을 제거했고 다른 문제점들도 현저하게 줄였다는 사실을 알려드릴 수 있게 되어 기쁩니다. 이것은 저에게 새로운 언어 기능을 제공하는 것보다 더 중요한 문제입니다. 하지만 엄청난 버그픽스들과 충분한 새로운 기능들을 고려하면, 파이어버드 2.0은 확실히 여러분이 좋아하는 RDBMS의 메이저 버전임에 틀림없습니다. 더 안정적이고, 더 완전한 기능들을 가추고 있으며, 더 빠르고 ASCII에 익숙하지 않은 사용자에게도 더 친숙합니다.

    물론, 아직 한계들은 남아있으며 아직 지원하지 않는 기능들도 많습니다. 하지만 앞으로 더 개선할 여지도 있어야겠지요? 잠시후에 앞으로의 개발 방향에 대해 논하겠습니다.

    그러나 저러나, 갯수에 관심있는 분들을 위해 WhatsNew 문서나 릴리즈 노트에서 각 버전별로 변경된 점들의 갯수를 세어보죠.

  • 버전 1.0: 32 개선, 55 버그픽스
  • 버전 1.5: 58 개선, 94 버그픽스
  • 버전 2.0: 82 개선, 140 버그픽스


    파이어버드 벌컨(Vulcan)


    우리의 주요 목표는 파이어버드 3.0을 발표하기 위해 파이어버드 2.0과 벌컨의 두가지 코드베이스를 통합하는 것입니다.
    이 작업은 벌컨 트리를 기초로 하고 모듈화된 아키텍처와 새로운 기능들을 포함할 것이며, 물론 파이어버드 2.0의 모든 개선점들도 포함될 것입니다.
    벌컨 코드베이스의 핵심적인 특징들은 다음과 같습니다.

  • 전체적으로 리팩토링된 코드
  • 잘 갈려진 멀티쓰레딩
  • 통합된 프로바이더 기반 아키텍처
  • 유연한 설정 메커니즘
  • 데이터베이스 레벨 인증 및 개선된 보안 관리
  • 내부 DSQL 구현


    파이어버드 3.0


    파이어버드 2.0과 파이어버드 벌컨의 발표는 모두 내년에 있을 예정인데, 아마도 여러분은 왜 3.0 버전이 주요 버전으로 번호가 매겨졌는지, 그리고 (두 코드베이스에서 이미 구현된 기능들을 제외한) 다른 어떤 기능들을 포함할지 궁금할 것입니다. 좋은 질문입니다. 우리는 3.0의 발표 사이클을 최대한 앞당기려고 하기 때문에, 이 버전에서는 어떤 완전히 새로운 개발도 이루어지지 않을 것입니다. 하지만 우리는 우리 사용자들이 계속 관심을 가지게 하기 위해 뭔가 새로운 것이 도입될 필요도 있죠.

    답은 간단합니다. 3.0 버전은 독립적인 브랜치로 구현된 모든 작업들을 통합할 것입니다.

    2006년과 이후의 파이어버드 로드맵


    일반적인 개발 우선순위를 간단히 설명하자면 다음과 같습니다.

    1. 신뢰성과 안정성 (버그 수정, 복원 보장, 보안 개선)
    2. 관리 및 모니터링 수단
    3. SQL 표준과의 호환성
    4. 성능 (알고리즘과 옵티마이저 판단 두가지 모두)
    5. 언어 개선

    일정은 대략 다음과 같습니다.

    2005:
  • 2.0 RC를 발표하고 2.0 HEAD를 포크하여 릴리즈 브랜치를 생성
  • 독립적인 트리들의 수정사항들 중 일부를 HEAD로 이식
  • 벌컨(Vulcan) HEAD를 포크하여 3.0 개발 브랜치를 생성

    2006년 1사분기
  • 파이어버드 2.0 파이널과 파이어버드 벌컨 파이널을 발표

    2006년 2사분기
  • 파이어버드 3.0 베타 발표
  • 3.0 HEAD를 포크하여 3.0+ 개발 브랜치를 생성

    2006년 3사분기
  • 파이어버드 3.0 파이널 발표

    2006년 4사분기
  • 파이어버드 3.0+ 베타 발표


    트리들에 숨어있는 개선점들


    아마 아시겠지만, 여러 파이어버드 개발자들이 작업한 몇몇 개선점들이 시간상의 제약 때문에 2.0 발표에 포함되지 않았습니다.
    그중 일부는 파이라클(Fyracle)에 포함되어 테스트되고 있으며 나머지는 아직 비공개 트리에 남아있습니다.
    또 야필(Yaffil: 파이어버드와 독립적으로 개발되다가 중단된 인터베이스 기반 DBMS)의 몇가지 기능들을 파이어버드로 역포팅하는 작업도 남아있습니다.
    위에서 언급한 모든 것들이 그대로 여러분이 3.0 버전에서 보게될 새로운 기능들입니다.
    이미 완료된 것들을 살펴봅시다.

  • CTE(Common Tables Expressions)와 재귀적인 쿼리 (SQL-99 호환)
    개발자: 폴 루이젠덜(Paul Ruizendaal)
    현재 상태: 완료

  • 전역 임시 테이블 (SQL-99 호환)
    개발자: 블라드 호순(Vlad Horsun)
    현재 상태: 완료

  • 외부 프로시저/함수 (SQL-99 호환)
    개발자: 유진 푸티린(Eugene Putilin), 로만 로키츠키(Roman Rokytskyy), 블라드 호순(Vlad Horsun)
    현재 상태: 일부 완료, 콜백 API에 대한 토의 필요

  • 새로운 내장 함수 (스트링, 수학, 바이너리, 날짜/시간)
    개발자: 올렉 로아(Oleg Loa)
    현재 상태: 완료, 일부 변경은 필요


    추가될 기능들


    우선순위 표시 - 높음, 중간, 낮음은 우리 사용자들이 얼마나 필요로 하는 기능인가의 정도를 나타냅니다. 이런 기준은 다양한 설문과 포럼/뉴스그룹 토론을 통해 정해졌으며, 경쟁 제품들로부터도 영향을 받았습니다.

    복잡도 표시 - 복잡도는 코어 팀에서 추정한 시간과 노력을 바탕으로 합니다.

    진행단계 표시
    없음
    필요한 모든 작업들이 이미 다른 코드 브랜치에서 완료되었으며 역포팅 및 테스팅만 필요한 상태
    구현
    이미 기능이 토의되고 합의되었으나 몇가지 세부 토의와 실제 코딩이 남아있는 상태
    설계/구현
    구현과 설계 사이의 상태
    설계
    기본적으로 합의했고 어떤 비전을 가지고 있으나, 아직 깊이 토의되지 않아서 구체적인 구현 계획이 없는 상태
    연구
    설계와 구현 명세를 토의하기 전에 심각하게 분석해야 할 필요가 있는 상태


    관리/트레이스/모니터링

    높음
    비동기 SQL문 실행 취소 / 타임아웃
    다음중 하나를 가능하게 한다. 실행중인 SQL문의 실행 취소, 트랜잭션의 롤백, kill an attachment. SQL문에 타임아웃 설정을 가능하게 한다. 최소한 API 레벨에서 지원되어야 함.
    높음
    API를 통한 모니터링과 특수 테이블
    엔진 내부의 작업에 대해 "스냅샷" 모니터링 실시(예를 들면 특정 순간에). 이런 모니터링의 대상은 데이터베이스, 첨부, 트랜잭션, 액티브 요청, 리소스(메모리/CPU) 사용 등이다.
    중간
    세부적인 SQL 트레이싱/프로파일링
    Show detailed access path (at the RSB tree level) for every retrieval, count rows (profile CPU time, etc) per every node. 런타임 통계가 더 늘어나야 한다.
    중간
    상세한 로깅/감사
    서버에서 일어나는 몇가지 이벤트를 로그할 수 있게 한다. 이런 이벤트에는 성공/실패한 인증 시도(클라이언트 호스트 정보 포함), 준비(prepare)나 실행된 SQL문, 커밋/롤백된 트랜잭션 등이 있다. 필요한 이벤트들을 설정하고 감사 로그를 가져오기 위한 API가 필요하다.
    중간
    DDL 레벨 및 글로벌 트리거
    ON CREATE/ALTER/DROP 트리거를 허용한다. Implement triggers attachment and transaction level triggers running in autonomous transactions.
    낮음
    PSQL 디버깅 확장/훅
    다음의 개념들을 도입하여 PSQL 디버깅을 가능하도록 한다. 루퍼 브레이크포인트, 핸들러 콜백, 컨텍스트 데이터 가져오기 등.

    유지보수 / 복원

    높음
    신뢰할 수 있는 논리적 백업
    물리적으로 깨진 백업의 경우에만 복원이 불가능해야 한다. 단순 객체들(제너레이터, UDF 등)은 시작 단계에서 복원되어야 한다. 계산 필드와 밸리데이션 제약은 마지막에 복원되어야 한다. 모순되는 데이터를 읽을 때 변경(예: 값없음 -> NULL)하는 대신 엔진이 거부해야 한다. GBAK은 스위치 등의 방법으로 부분 복원을 허용해야 한다.
    높음
    Point-in-time 복원
    엔진은 사용자 선택에 따라 마지막 논리적 백업에 작업하기 위한 리두(redo) 로그를 유지할 수 있어야 한다. 데이터 손실은 있어서는 안된다.

    보안

    높음
    임베디드 유저 / SQL 유저 관리
    데이터베이스 파일 내부에 유저 관리를 가능하게 한다.(벌컨에 구현되어 있음)
    높음
    메타데이터에 대한 유저 퍼미션
    모든 메타데이터를 보안 클래스로 보호한다. 메타데이터 레벨 퍼미션을 구현한다. BACKUP, DROP 같은 데이터베이스 레벨 퍼미션을 추가한다.
    중간
    플러그 가능한 인증 모듈
    사용자정의 인증 메커니즘을 사용할 수 있게 한다(예를 들어 네이티브 OS 인증 메커니즘을 이용하는 경우 등).
    중간
    보안 그룹
    기존의 롤 기반 보안 외에 추가로 그룹 기반의 보안을 설계한다.
    중간
    데이터베이스 암호화
    선택적으로 데이터베이스 파일을 암호화할 수 있게 한다. 키의 관리는 잦은 질문이다.

    성능 / 옵티마이저

    높음
    더 빠른 아우터 조인
    아우터 조인을 위해 머지 알고리즘을 구현한다.
    중간
    옵티마이저 개선
    알려진 버그들/한계들을 수정, 옵티마이저의 판단 개선, 더 많은 데이터 통계.
    중간
    더 효율적인 정렬
    FIRST 제한 쿼리의 속도를 높이기 위해 부분 정렬을 구현한다. 전체 로우들 대신 recno를 정렬하는 것을 고려한다.
    중간
    최적화된 네트워크 프로토콜
    불필요한 많은 데이터(buffer tails)를 전송하는 것을 피한다. 프로토콜 배치를 구현하는 것을 고려한다(예를 들면 prepare + info). 스페이스를 더 효율적으로 압축한다.
    중간
    더 많은 액세스 방법들
    해시 조인 / 해시 집합과 경쟁 DBMS에서 사용되는 다른 알고리즘을 구현하는 것을 고려한다.

    언어 확장

    높음
    임시 테이블 / 일시적 데이터셋
    임시 스키마 객체들과 데이터셋을 구현한다. SQL-99 호환성이 필요하며, 확장도 좋다. (파이라클에 일부 구현되어 있음)
    높음
    더 많은 내장 함수
    SQL-99 (혹은 이후 버전)에 기술된 내장 함수들은 반드시 가장 먼저 구현되어야 한다. 다음으로 다른 함수들에 대한 사용자들의 요구를 수용하여 구현한다.
    높음
    스키마/네임스페이스
    먼저, 이것은 짧은 메타데이터 이름들 관련 문제의 비용을 획기적으로 줄여준다. 두번째로, 여러 데이터베이스들을 단일 파일로 통합할 수 있게 해주어 관리를 쉽게 해준다. 세번째로, SQL92(기초 레벨)을 완벽하게 준수할 수 있게 해준다.
    높음
    네이티브한 긴 숫자 데이터 타입
    길고 정확한 숫자 데이터 타입(10진수 30자리 이상의 정도)과 그에 맞는 BCD 계산을 구현한다.
    중간
    재귀적인 쿼리
    재귀적인 호출을 위한 SQL을 구현하고 SQL 표준에 맞도록 한다.
    중간
    정규식
    정규식을 검색 조건에 사용할 수 있게 한다. 이를 위해 몇가지 특수 문법을 추가한다.
    중간
    CHAR/VARCHAR와 호환되는 TEXT BLOB
    BLOB SUB_TYPE TEXT를 스트링 데이터 타입과 호환 및 교체사용 가능하도록 한다. 텍스트 BLOB를 모든 내장 함수에서 사용할 수 있게 한다.
    중간
    도메인을 어디서나 사용
    PSQL 파라미터와 변수, 그리고 CAST 함수에서도 도메인을 사용할 수 있게 한다.
    중간
    더 긴 메타베이스 이름
    문자 길이는 유니코드로 최대 128.
    중간
    SQL 함수
    SQL-99를 따르는 CREATE/ALTER/DROP FUNCTION 문법
    낮음
    지연 제약
    SQL 표준에 따라 커밋시에 적용되는(commit-time) 제약(constraint) 체크를 구현한다.

    일반 / 아키텍처

    높음
    수퍼서버에서 SMP 지원
    수퍼서버 아키텍처에서 효율적인 멀티쓰레딩을 지원한다. (벌컨에 구현되어 있음)
    높음
    컴파일된 SQL문 캐시
    컴파일된 SQL문을 캐시하여 재사용할 수 있게 한다. (벌컨에 일부 구현되어 있음)
    높음
    외부 함수/프로시저
    PSQL이 아닌 언어로 작성된 프로시저/함수를 만들 수 있게 한다. 배포시에 몇가지 드라이버들(cdecl, Java, .NET)을 제공한다. (파이라클에 일부 구현되어 있음)
    높음
    외부 데이터 소스 / 데이터베이스 링크 / 크로스 데이터베이스 SQL
    외부 데이터 소스로부터 데이터를 가져올 수 있게 한다. 배포시에 몇가지 드라이버들(native FB, JDBC, ODBC)을 제공한다. 선언을 위한 DDL과 외부 데이터소스를 이용하기 위한 DML을 추가한다. 네이티브 데이터 소스를 가져오는 작업의 최적화를 구현한다.
    높음
    문/트랜잭션 일관성(consistency)
    verb/트랜잭션의 불일치를 해결한다. 이것은 INSERT/UPDATE/DELETE 문에서 blr_for 동작을 커버한다. 리드 커미티드 트랜잭션이 SQL 표준을 준수하도록 한다.
    중간
    양방향 인덱스
    DESC 정렬을 위해 ASC 인덱스를 이용하거나 그 반대를 위해 역 인덱스 네비게이션을 할 수 있게 한다.
    중간
    벌크 로드/임포트
    효율적인 대량 데이터 로드 기능을 구현한다. 임포트를 위해 다른 입력 포맷(csv, xml 스키마 등)을 사용할 수 있는 유틸리티/문법을 제공한다.
    중간
    인덱스 없는 참조 무결성
    인덱스에 강제되지 않는 외래키를 구현한다(선택적). 제약(constraint)을 위해 기존의 인덱스를 재활용하는 기능도 추가한다.
    중간
    풀 텍스트 서치
    엔진 내부에 FTS 기능을 구현하거나 혹은 외부 FTS 엔진을 플러그인할 수 있는 API 추가. 아마도 FB는 아직도 이 기능을 가지고 있지 않은 유일한 RDBMS일 것이다.
    중간
    클러스터링
    MySQL은 클러스터를 지원하며(내가 아는 바로는, 아직은 공유 메모리만 지원한다), PostgreSQL은 공유 디스크 구현을 진행중이다. 전세계에 이 기능에 대한 요구로 떠들썩하다.
    낮음
    양방향 커서
    엔진 내부에 스크롤 가능한 커서의 구현하거나, 이 기능을 캐싱으로 구현하기 위해 RSB 계층도의 가장 위에 엷은 레이어를 제공하는 것을 고려한다.
    낮음
    XML 통합
    최소한 XML로 페치하고 XML로부터 인서트하는 기능을 제공한다. BLOB SUB_TYPE XML을 추가하는 것과 XPath 쿼리를 구현하는 것을 고려한다.


    원문: http://www.firebirdsql.org/devel/engine/roadmap2006.html
    번역: 박지훈.임프
  • 박지훈.임프 [cbuilder]   2006-02-02 04:57 X
    참고: 벌컨(Vulcan)은 2005년 초부터 시작된 파이어버드 차기 버전 프로젝트입니다.
    벌컨에는 다음과 같은 기능들이 계획되었습니다.
  • 64비트 아키텍처 지원
  • SMP 아키텍처 지원(멀티 프로세서)
  • 설정가능한 보안 관리자
  • 각 데이터베이스에 인증 정보 소스 포함 (현재는 각 서버에 유저 데이터베이스가 존재함)
  • 유저를 create, update, drop하기 위한 SQL문
  • 새로운 설정 파일

    벌컨에 대한 더 자세한 정보는 다음의 문서를 참고하세요.

    벌컨 오버뷰
    http://www.ibphoenix.com/downloads/VulcanOverview.pdf

    벌컨 아키텍처
    http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=vul_architecture
  • 류종택 [ryujt]   2006-02-06 16:09 X
    음..  수고했다 ^^*

    + -
    이전글:  
    다음글:  
    Google
    Copyright © 1999-2015, borlandforum.com. All right reserved.