효율 키/값 표

키/값 쌍을 저장하기위한 테이블이 필요합니다 (예 : Windows 레지스트리). 내가 SQL 서버 2008 R2 2008을 사용하고효율 키/값 표

CREATE TABLE REG   
(      
    ID VARCHAR(255) NOT NULL, 
    DATA VARCHAR(1024), 
    PRIMARY KEY(ID)   
);

, 2005

사람이 키/값 쌍을 저장하는 더 effecient 아이디어를 제공 할 수 있습니다 : 여기에 내가 가진 것입니다.

나는이 같은 키를 저장하고 :

/USER/REX/AUTO_LOGIN = "T"

/USER/REX/메시지/1 = "이다 더 이상 메시지"

에서 약 10000 개의 레코드 이미 성능 문제가 있습니다.

출처

2012-04-27 GenuineRex

성능 문제? 기본 키가 ID로 설정되면 SQL Server는 해당 열을 인덱싱해야하며 쿼리는 여전히 10k 행에서 매우 빠릅니다. 물론 당신은 'SELECT * from reg WHERE id ='/ USER/REX/AUTO_LOGIN '와 같은 질의를하고 있다고 가정합니다. 일에 영향을 미칠 수있는 와일드 카드를 던지기 시작하면 ... – Windle

이 쿼리를 사용하고 있습니다 : SELECT DATA FROM REG WHERE ID =? – GenuineRex

및이 : UP REG SET DATA =? 여기서 KEY =? – GenuineRex

키 이름의 해시 인 추가 열을 도입 할 수 있습니다. 예 : "/ USER/REX/AUTO_LOGIN"은 102454로 해시 될 수 있습니다. 그런 다음 해시 열 (또는 해시 열 및 키 이름 열의 복합 인덱스)에 인덱스를 추가하고이를 쿼리의 where 절에 포함시킬 수 있습니다. int 열세요 예는

SELECT DATA 
FROM REG 
WHERE HASH = 102454 and ID = '/USER/REX/AUTO_LOGIN'

varcharID 열 질의보다 훨씬 더 효율적이어야하고 정합을 위해 검사 될 것이다 동일한 해시 값을 갖는 몇 행 좁히는 효과를 가져야 ID 값.

출처

2012-04-27 16:33:26 Adamski

미안하지만, 다음과 같은 이유로 나에게 좋지 않은 생각이 들린다. (1) 클러스터 된 테이블에서 보조 인덱스가 비싸다. (클러스터되지 않은 클러스터로 만들 수도 있지만 가격도있다.) (2) 어쨌든 (PK이므로) ID에 대한 색인을 피할 수 없으므로 왜 _it_를 사용하지 않는 것이 좋습니까? 나는 실제로 해쉬의 비 복합 인덱스가 실제로 더 빨라진다는 것을 확신하지는 않는다. (더 컴팩트하지만 "오탐 (false positives)"이있을 것이다.) OTOH, 해시 및 ID의 합성어는 전혀 이해가되지 않습니다. 실제로이 기술에 대한 실제 경험이 있습니까? 실제 데이터 양에 대한 벤치 마크를 수행 했습니까? –

내가 대신 고유 인덱스 말인가, 내 기본 키로 varchar(255)을 사용하지 않는 것 :

CREATE TABLE REG (
    id bigint identity not null, 
    key VARCHAR(256) NOT NULL, 
    DATA VARCHAR(1024), 
    PRIMARY KEY(ID) 
); 

create unique index reg_key on REG(key);

출처

2012-04-27 16:34:29 dasblinkenlight

나는 이것에 대해 생각했지만 키에 대한 인덱스가 필요하고 SELECT 쿼리는 키의 인덱스를 읽은 다음 기본 키를 기반으로 조회를 수행해야합니다. 그러나 이것은 일단 PK가 메모리에 있으면 업데이트를 더 빠르게 할 수 있습니다. – GenuineRex

@GenuineRex 필자는 어쨌든 시도해 볼 것입니다. 클러스터 된 PK 인덱스에서 다양한 길이의 큰 값을 사용하면 잘못된 것처럼 보일 수도 있지만 올바르게 보이지 않습니다. – dasblinkenlight

효율 키/값 표

답변

관련 문제