데이터베이스에서의 Full Scan? (필드 순서에 따른 효율?)
글쓴이: 해밝 / 작성시간: 월, 2004/03/22 - 6:42오후
+----------------+----------------+----------------+ | key | field 1 | field 2 | ....... field n +----------------+----------------+----------------+
프로젝트를 하다가 데이터베이스 스키마를 건드릴 일이 있었습니다. 보통 데이터베이스는 위처럼 필드들로 구분 되고 그중에 필드 한두개가 Key 역할을 하는데 제가 잘 모르는 딴지가 걸려서 질문을 올립니다.
1. key는 의미가 없더라도 String으로 하는 것보다 Number 형으로 하는 것이 사용하기 편하고 조인 등의 연산에 효율이 좋다.
2. SELECT 쿼리를 줄 때 검색이 빈번한 필드일수록 앞쪽에 두어야 효율이 좋아진다.
1번은 그렇게 생각해오고 계속 이런식으로 작성하였는데, 쓸데 없는 숫자형 Key를 왜 두느냐는 딴지가 걸렸습니다. 그래서 조인등 연산에 좋다하니 쓸데없는 필드 낭비니 없애라더군요. 제대로된 반박의 근거가 없어서 입다물었습니다만 뭔가 석연찮은 구석이 있네요.
2번은 파일이나 프로그램으로 구현한 자료 구조가 아닌, 데이터베이스 서버를 쓰는데도 필드 순서를 굳이 따져야 하느냐는 의문입니다. 그리고 필드 순서에 따라 검색 효율이 다르다는 말도 처음 들었구요.
정말 그런가요? --;;;;
혹시 확실한 근거 자료 같은걸 구할 수 있을런지...
PS. 제 생각은 그렇지 않을 것이다라는 생각이 지배적이지만, 실제로 그렇다 하더라도 전체 성능에 미치는 영향은 매우 미미할 것이라고 생각하고 있습니다.
Forums:
좀 헷깔리네요...
1. 은 오히려 큰 상관이 없을 것 같습니다. 스트링이 디비에 저장될 때는
변환 작업이 없이 그대로 저장되고, Numeric 계열은 변환 작업을
거쳐서(약간의 연산을 거쳐서) 저장이 됩니다. 읽어 오는 데에는
미세한 차이가 있을 수 있겠지만, Join에서의 성능 차이가 날지는
잘 모르겠네요.
2. 맞기도 하고 틀리기도 할 것 같습니다. 자주 검색 되는 결과 필드(Result
Set을 구성할 필드)가 레코드 앞 쪽에 있으면 그만큼 덜 읽어도 될 테고,
파싱도 약간 덜 하게 될테니까요.(그렇지만 이것도 정말 미세한 차이일
테고...) 디비에 따라서는 사용자가 테이블 만들 때 적어준 순서와는
무관하게 디비 지가 순서를 바꿔서 저장하는 놈도 있습니다. 그런 경우는
말짱 꽝이죠. 이거를 알려면, 실제로 테이블에 데이터를 넣고 저장한 다음,
binasy editor 또는 hex editor로 읽어서 순서를 보는 방법 밖에는
없을 것 같네요.
결론은 잘 모르겠다는 거구요... 차이가 있더라도 미세한 차이를 보일 것 같네요..
감사합니다.
Re: 데이터베이스에서의 Full Scan? (필드 순서에 따른 효율?)
1. key는 의미가 없더라도 String으로 하는 것보다 Number 형으로 하는 것이 사용하기 편하고 조인 등의 연산에 효율이 좋다.
numeric type 과 string type field ...
numeric type 을 key 로 하는 것이 효율적인 것이 맞습니다.
말씀하신 대로 조인 연산 시에도 효율이 좋은 것은 맞는데요, 궁극적인 원인은 numeric type index 와 string type index 의 성능차입니다.
Join 연산 시 필드에 인덱스가 걸려 있으면 인덱스를 이용하여 조인 연산을 수행합니다.
numeric type index 의 경우 index search 시에 두 개의 숫자만 ( a == 3 ) 비교하면 되지만, string type index 의 search 시에는 string 길이만큼의 byte 를 비교해야 합니다.
DBMS research 분야에서 string type index 의 검색 효율을 높이기 위한 여러가지 알고리듬이 제안되어 있는데요, 그건 어디까지나 string type index 에 대한 성능 향상을 위한 것들입니다.
numeric type 필드를 선언하고 인덱스를 걸어서 사용할 수 있다면 당연히 그렇게 하는 것이 성능 면에서 이득입니다.
2. SELECT 쿼리를 줄 때 검색이 빈번한 필드일수록 앞쪽에 두어야 효율이 좋아진다.
테이블 생성 시에 검색이 빈번할 것으로 예상되는 필드를 앞에 두어야 한다는 말씀인 것 같습니다만, 그것은 성능과는 상관 없습니다.
대신, 여러가지 타입의 필드가 섞여 있는 경우 테이블 생성 시 필드의 순서에 따라 저장 효율이 달라지는 경우는 있습니다만, 그 것은 아주 미미한 차이이기 때문에 DBMS 사용자 입장에서는 크게 고려할 사항이 아닙니다.
성능을 생각하신다면, 검색이 빈번한 필드에는 인덱스를 걸어두셔야 합니다.
위 두 가지를 정리해서 말씀드리자면 아래와 같습니다.
1. 인덱스를 걸어두는 필드는 가능한 한 numeric type으로 하시는 게 성능면에서 좋습니다.
2. 테이블 스키마에서의 필드 순서는 성능과 관련 없습니다. 대신 SQL 질의문에서 WHERE 절에 빈번히 들어가는 필드는 index 를 걸어주십시오.
데이터베이스에서의 Full Scan?
1번과 2번의 내용중에서 2번은 제가 확인할 수 없는 내용 같구요....
1번의 경우에는 key를 숫자로 잡는 이유가 데이타베이스 어플리케이션을 하는 입장에서는 DBMS설계의 어떤 원칙에 해당하기 때문이라고 생각됩니다. 모든 프라이머리키는 의미가 없으면 없을 수록 좋다. 와 같은 이유 때문 입니다. 예를 들면 상품마스터의 상품코드(또는 id)가 6자리 자리라고 하면 옛날에 설계한 상품 마스터는 2자리씩 3개의 필드로 나누어서 처음 두자리는 대분류, 다음 두자리는 중분류, 마지막 두자리는 소분류 등의 의미를 두어 사용하는 경우가 많았습니다. 이경우 처음에는 그런대로 사용할 만 합니다. 상품코드만 보아도 대충 무슨상품인지도 알고... 하지만 시간이 지나고 상품 가짓수가 늘어나는 경우에는 정말로 끔찍한 일이 발생합니다. 고작 99개의 분류로는 상품을 등록하기가 불가능한 경우가 생기고 이에 따른 혼란은 말로 표현도 못합니다. 그래서 이러한 마스터의 코드(또는 id)는 전혀 의미가 없는 일련번호로 표시하는 경우가 많습니다. 근래들어서는 DBMS도 이 기능을 지원하고 있구요. ( Sequence, auto increment 등등 ) 제가 보기에는 시스템의 속도나 Performance에 따른 것이라기 보다는 실제 프로그램에서의 확장성 때문에 숫자로 처리하는 것이 낫다는 경우라고 봅니다. 그리고 의미없는 필드는 제거하라는 얘기도 중간에 있던데 저의 경험상으로는 반드시 있는게 99% 유용하리라 생각됩니다.
Re: 데이터베이스에서의 Full Scan? (필드 순서에 따른 효율?)
맞습니다. 여기에 대해서는 잘 설명하셔서 드릴 말씀이 없네요.
맞습니다. 다른 DB는 모르겠습니다만 Oracle에서는 차이가 있습니다. 이것에 관해서는 기사들을 검색해 보시면 찾아보실 수 있습니다.
2번 컬럼과 20번 컬럼의 조회는 속도에서 차이가 있습니다. 벤치마크 기사나 퍼포먼스 튜닝 기사를 찾아보세요. 또는 DB 컨설팅 회사의 팁과 같은 기사에서도 찾아보실 수 있습니다.
하지만! 그 속도 차이보다는 생각하기 쉬운 컬럼 순서 예를 들면...
접수관련컬럼들 -> 처리관련컬럼들 -> 부가적인컬럼들
이런식으로 잘 모아두시는게 차라리 생각하기 쉽고 읽기 쉽고 잘 안 잊어버리고 더 장점이 많습니다. 컬럼 순서에 따른 미세한 속도 차이를 위해 투자하는 시간을 차라리 디스크 I/O 분석, 한 테이블에 집중된 프로세스 분산, DB setting 튜닝 등등 훨씬 효율성 있고 가치 있는 것에 투자하시는게 좋을 것 같습니다.
2번에 대해서..DBMS를 어떤걸 쓰시는 지 모르겠지만.. 대부분 쿼
2번에 대해서..
DBMS를 어떤걸 쓰시는 지 모르겠지만.. 대부분 쿼리 옵티마이저의 판단에 따라 검색순서가 정해집니다. 가장 효율적이라고 판단되는 인덱스를 먼저 검색하게 합니다. 옵티마이저가 잘못된 판단을 할때는 각 DBMS마다 나름대로의 꽁수가 있습니다..
오라클의 경우에는 꽁수가 아니라 인덱스 힌트를 줄 수 있고 다른 DBMS에서는 가장 분포가 잘 되어 있고 데이터의 타입에 맞는 인덱스 타입(예를 들면 순차적인 숫자로 되어 있는 컬럼에 btree인덱스)를 먼저 검색하게 한다던지 하는 꽁수가 있겠죠..
검색조건의 순서가 영향을 미치는 DBMS도 있고 그렇지 않은 DBMS도 있습니다.. 영향을 미치는 DBMS라면 데이터의 분포를 예측하고 인덱스 사용을 고려해서 SQL문을 작성하는 것이 좋을 것입니다.
1. key는 의미가 없더라도 String으로 하는 것보다 Number
1. key는 의미가 없더라도 String으로 하는 것보다 Number 형으로 하는 것이 사용하기 편하고 조인 등의 연산에 효율이 좋다.
좋을겁니다. 실제로 key는 검색시 이용되기때문에 그것이 스트링인것보다는
넘버형이효과적으로 비교될수 있습니다.
2. SELECT 쿼리를 줄 때 검색이 빈번한 필드일수록 앞쪽에 두어야 효율이 좋아진다.
이문제에대해서는 애매한점이 있기는하나 한마디로 고려할필요는 없다고봅니다.
단쿼리문에서 조건필드의 순서에따라 검색룰이 달라지므로 그부분을 신경써서 하셔야합니다.
----------------------------------------------------------------------------
댓글 달기