저는 SQL Server를 사용하여 각 사용자에 대한 몇 가지 정보를 저장하고 있습니다. 일부 항목 (예 : 사용자 이름/비밀번호)은 거의 변경되지 않지만 몇 초마다 (예 : 경도/위도) 변경되는 항목은 거의 변경되지 않습니다.SQL Server에서 동일한 행을 계속 업데이트하는 것이 좋지 않습니까?
나는이 시스템이 몇 hundered 사용자들에 의해 대부분의 근무일 동안 사용되기를 기대합니다. 따라서 은 사용자 당 하루 10,000 업데이트 순으로이 테이블에 저장됩니다.
지속적으로 변화하는 정보와 대부분 정적 정보를 동일한 행에 저장하는 것이 단점입니까? 정적 정보를 한 테이블에 보관하고 다른 테이블의 정보를 변경해야합니까?
논리적으로 함께있는 한 모든 정보를 하나의 테이블에 보관할 수 있습니다. 낙관적 잠금은 대부분의 경우 작동하지만 사용자 행에 대한 잠금은이 방법으로 위험합니다.
그러나 업데이트 할 필드 만 업데이트해야합니다. 테이블에있는 다른 데이터 항목에 대한 이러한 별도의 요구 사항이있는 경우 특수 데이터 액세스를 작성하여 해당 데이터 항목에 대한 업데이트 루틴을 작성해야합니다.
이점은 데이터베이스에서 /로 필요한 데이터 만 전송하므로 네트워크, 클라이언트 및 데이터베이스의 대기 시간과로드가 줄어 듭니다.
업데이트 및 로그인이 동시에 발생하는 경우 현재 솔루션에서 확장 할 때 문제가 발생할 수 있습니다. 부적절한 SELECT * 문을 사용하는 경우 로그인 성능이 저하되거나 잠금 상태가 될 수도 있습니다.
위도/경도를 업데이트하는 것이 여러 소스에서 완전히 동적 인 경우 새 테이블에 저장하고 각 업데이트에 대해 새로운 행을 만들 수도 있습니다. 여러 소스가 지속적으로 동일한 행을 업데이트하는 경우 확실히 성능/잠금 관련 문제에 직면하게됩니다. 새 행을 만들면 직관이 어둡지 만 여러 소스의 데이터를 거의 동시에 도입하고 타임 스탬프 등으로 해당 데이터를 쿼리하여 업데이트 쿼리를 매우 간결하고 빠르게 유지하면서 최신 업데이트를 찾을 수 있습니다. 가지 치기는 시간 소인으로 자동 및 신속하게 수행 될 수 있습니다.
각 사용자는 하나의 행만 업데이트하며 해당 사용자 (즉, 하나의 기기) 만 해당 행을 업데이트하므로 거기에 잠금 문제가 없어야합니다. – Wilka
이 데이터베이스에 액세스하는 응용 프로그램의 사용법에 따라 자주 단일 레코드를 업데이트하려는 경우 잠금 문제가 발생할 수 있습니다. 또한 정성, 유지 관리 및 확장 성을 위해 normalization을보고 싶을 것입니다.
업데이트하는 열이 클러스터링 인덱스의 일부인 경우 (존재하는 것으로 가정) SQL Server에 대해 테이블 / 인덱스 구조를 재정렬하기 때문에 상당한 오버 헤드가 발생할 것입니다. 클러스터링 시퀀스. 클러스터되지 않은 인덱스의 일부인 경우 인덱스 구조를 유지 관리하는 데 오버 헤드가 발생합니다.
두 경우 모두 통계가 적용됩니다. 통계가 오래되어서 쿼리/저장 프로 시저가 최적이 아닌 실행 계획을 세우게됩니다. 그렇지 않으면 업데이트 통계를 실행하는 횟수를 늘릴 수 있습니다.
데이터 행의 크기가 변경되지 않기 때문에 색인에 참여하지 않는 고정 길이 열을 업데이트해야합니다. 인덱스에 참여하지 않는 가변 길이 또는 널 (NULL) 입력 가능 컬럼을 갱신하면 데이터 행의 길이가 변경 될 때 페이지 분할이 발생할 수 있습니다 (페이지 분할로 인한 인덱스 유지 보수 오버 헤드는 말할 것도 없습니다).
LAT/LON을 현재 값으로 덮어 쓰면 잠재적으로 가치 있고 유용한 데이터가 손실됩니다.더 나은, 생각, 단순히 PersonLocation 테이블에 새 행을 삽입하려면 :
id autoincrementing integer
personid int fk references persons(id) [indexed non-unique to speed queries on person location history)
lat float
lon float
asof datetime default getdate()
편집 : 자주 현재 위치를 확인해야하는 경우에 복합 인덱스 (personid, 날짜)을 고려할 수 있습니다.
+1 정보가 자주 변경되는 데이터베이스가있는 경우 결국 사용자는 기록을 원할 것입니다. –
이 시계열 정보에 대해 가능한 비즈니스 용도가 있고 저장소 크기가 문제가되지 않는 한 좋은 조언입니다. –
@Joel : 수레와 ints는 많은 공간을 차지하지 않으며, 종종 데이터의 유용성이 오늘날 분명하지는 않습니다. 그러나 OP 계획보다 많은 사용자가있을 수 있으므로 귀하의 요점은 잘 받아 들여집니다. 사용자가 현재 위치를 추적하는 데 문제가 없으므로 위치 기록에 문제가 없다고 가정합니다. 다른 좋은 충고는 사용자의 위치 추적 권한을 얻는 것입니다. – Tim
하루에 10,000 건의 업데이트가 걱정할 필요가 없습니다. 1 분에 1 만 건이 업데이트 될 수 있습니다. 데이터베이스를 단순하게 유지하고 성능상의 이유로 모델에 대해 열중하지 않도록 데이터베이스를 모델링하십시오. 업데이트되는 빈도에 관계없이 여전히 대역폭을 존중하기를 원하기 때문에 업데이트 볼륨이 무엇이든 관계없이 변경되는 열만 업데이트하는 것에 대한 Oded의 조언은 확실합니다.
이 질문에 정확히 답변하지는 못하지만 너무 많은 쓰기 요청이 필요하다는 것을 알고 있습니까? 작업 부하를 줄이기 위해 작성 여부에 차이 트리거 유형을 사용할 수 있습니까? – Hawxby
@Hawxby, 아주 좋은 지적입니다. 다행히도 그것이 나에게 충분히 빨리 일어 났을 것입니다. 내가 무엇을하기로 결심 했든간에, 나는 이것을 할 것입니다. – Wilka