SQL 분 표, 라 이브 러 리 파 티 션, 읽 기와 쓰기 분리 및 동기 화

분 표
분 표 는 수직 분 표 와 수평 분 표 로 나 뉜 다.
1. 수직 분 표
    수직 분 표 는 데이터베이스 디자인 의 문제 일 수 있 기 때문에 상대 적 으로 보기 드 물고 사용 되 지 않 는 다.만약 에 데이터베이스 에 표 의 일부 필드 가 거의 변경 되 지 않 지만 자주 조회 하 는데 일부 필드 의 데이터 가 자주 바 뀌 면 이런 디자인 은 같은 표 에 넣 으 면 합 리 적 이지 않 고 서로 영향 이 너무 크다.이미 상황 을 바 꾼 표 가 존재 할 때, 열 에 따라 표, 즉 수직 으로 나 누 는 것 을 고려 할 수 있다.
소스 시트 디자인 구조:

--    
CREATE TABLE [dbo].[DemoTab](
[Guid] [uniqueidentifier] NOT NULL,
[UserName] [nvarchar](30) NOT NULL,
[Password] [nvarchar](30) NOT NULL,
[UserAccount] [varchar](30) NOT NULL,
[Amount] [numeric](18, 4) NULL,
CONSTRAINT [PK_DemoTab] PRIMARY KEY CLUSTERED ([Guid])
)
GO
 
 
ALTER TABLE [dbo].[DemoTab] 
ADD CONSTRAINT [DF_DemoTab_Guid] DEFAULT (newsequentialid()) FOR [Guid]
GO
 
--          （         ）
CREATE VIEW [dbo].[VDemoTab]
AS
SELECT [Guid],[UserName],[Password],[UserAccount],[Amount]
FROM [dbo].[DemoTab]
GO

주: 분 리 된 후 각 표 의 메 인 키 는 모두 같 고 분 리 된 시 계 는 규범화 되 었 습 니 다.
현재 빈번 한 필드 와 빈번 하지 않 은 필드 에 따라 두 장의 표를 뜯 습 니 다.

--    【1】,    "  "，        "  "
CREATE TABLE [dbo].[DemoTab001](
[Guid] [uniqueidentifier] NOT NULL,
[UserName] [nvarchar](30) NOT NULL,
[Password] [nvarchar](30) NOT NULL,
CONSTRAINT [PK_DemoTab001] PRIMARY KEY CLUSTERED ([Guid])
)
GO
 
--            ,              
--ALTER TABLE [dbo].[DemoTab001] 
--ADD CONSTRAINT [DF_DemoTab001_Guid] DEFAULT (newsequentialid()) FOR [Guid]
--GO
 
--    【2】,"  "
CREATE TABLE [dbo].[DemoTab002](
[Guid] [uniqueidentifier] NOT NULL,
[UserAccount] [varchar](30) NOT NULL,
[Amount] [numeric](18, 4) NULL,
CONSTRAINT [PK_DemoTab002] PRIMARY KEY CLUSTERED ([Guid])
)
GO
 
--            ,              
--ALTER TABLE [dbo].[DemoTab002] 
--ADD CONSTRAINT [DF_DemoTab002_Guid] DEFAULT (newsequentialid()) FOR [Guid]
--GO
 
 
--                 （         ，     ON UPDATE CASCADE）
ALTER TABLE [dbo].[DemoTab002] 
ADD CONSTRAINT [FK_DemoTab002_DemoTab001_Guid] FOREIGN KEY ([Guid]) 
REFERENCES [DemoTab001]([Guid]) ON UPDATE CASCADE ON DELETE CASCADE
GO

만약 에 이전에 단일 표 나 보기 조작 이 었 다 면 분 리 된 후에 논리 층 이 많이 바 뀌 었 을 것 입 니 다. 변경 을 최소 화하 기 위해 연합 보기 로 조작 할 수 있 습 니 다.어떻게 연결 하 는 지 는 개인 상황 에 따라 결정 된다.

--           (INNER JOIN    )
ALTER VIEW [dbo].[VDemoTab]
AS
SELECT T1.[Guid],T1.[UserName],T1.[Password],T2.[UserAccount],T2.[Amount]
FROM [dbo].[DemoTab001] T1 LEFT JOIN [dbo].[DemoTab002] T2 ON T1.[Guid]=T2.[Guid]
GO

이때 문제 가 발생 했 습 니 다. 시 계 를 DML 조작 해 야 합 니 다. insert, update, delete 는 어떻게 해결 합 니까?메 인 키 가 여러 시계 에 분산 되 어 있 고 똑 같 아야 하기 때 문 입 니 다!
이 때 는 트리거 를 고려 해 일치 성 을 확보 할 수 밖 에 없 으 며, 트리거 는 보기 로 정의 되 며, 인 스 티 드 오 브 타 입의 트리거 를 사용 합 니 다.

insert 트리거:

보기 [VDmoTab] 의 [Guid] 는 시 계 를 삽입 합 니 다. 트리거 를 삽입 할 때 가상 시계 [inserted] 의 [Guid] 가 유일 하기 때문에 트리거 에서 이 [Guid] 를 여러 개의 분 표 에 동시에 사용 하여 여러 개의 분 표 의 [Guid] 가 같 음 을 보증 합 니 다!

--  insert    
CREATE TRIGGER [dbo].[tgr_VDemoTab_insert]
ON [dbo].[VDemoTab] 
INSTEAD OF INSERT
AS
BEGIN
 INSERT INTO [dbo].[DemoTab001]([Guid],[UserName],[Password])
 SELECT [Guid],[UserName],[Password] FROM inserted;
  
 INSERT INTO [dbo].[DemoTab002]([Guid],[UserAccount],[Amount])
 SELECT [Guid],[UserAccount],[Amount] FROM inserted;
END
GO

update 트리거:

마찬가지 로 업데이트 할 때 가상 표 deleted 와 inserted 와 관련 되 고 업 데 이 트 는 보기 [VDemoTab] 에 업 데 이 트 된 것 이기 때문에 가상 표 inserted 는 모든 필드 를 포함 하기 때문에 트리거 가 각각 여러 개의 분 표를 업데이트 해 야 합 니 다.

--  update    
CREATE TRIGGER [dbo].[tgr_VDemoTab_update]  
ON [dbo].[VDemoTab]   
INSTEAD OF UPDATE 
AS
BEGIN
 UPDATE T1 SET
 T1.[UserName] = T2.[UserName], 
 T1.[Password] = T2.[Password]
 FROM [dbo].[DemoTab001] AS T1, inserted AS T2 WHERE T1.[Guid] = T2.[Guid] 
 
 UPDATE T1 SET
 T1.[UserAccount] = T2.[UserAccount], 
 T1.[Amount] = T2.[Amount]
 FROM [dbo].[DemoTab002] AS T1, inserted AS T2 WHERE T1.[Guid] = T2.[Guid] 
END
GO

delete 트리거: 

보기 [VDmoTab] 기록 을 삭제 하고, 여러 테이블 과 관련 해 서 는 삭제 가 허용 되 지 않 으 므 로 '메 인 테이블' 기록 만 삭제 하면 되 며, 다른 테이블 은 직렬 로 삭 제 됩 니 다.

--  delete    
CREATE TRIGGER [dbo].[tgr_VDemoTab_delete]  
ON [dbo].[VDemoTab]   
INSTEAD OF DELETE 
AS
BEGIN
    DELETE FROM [dbo].[DemoTab001]
    WHERE [Guid] IN (SELECT [Guid] FROM deleted)
END
GO

디자인 이 거의 완성 되 었 으 니 지금 테스트 를 진행 합 니 다.

INSERT INTO [dbo].[VDemoTab]([Guid],[UserName],[Password],[UserAccount],[Amount])
SELECT NEWID(),'user01','pw01','account01',100
UNION ALL
SELECT NEWID(),'user02','pw02','account02',99
UNION ALL
SELECT NEWID(),'user03','pw03','account03',0
GO
 
UPDATE [VDemoTab] SET [Password]='pw',[Amount]='10'
WHERE [Amount] >=0 AND [Amount]<100 AND [UserName] LIKE '%3'
GO
 
DELETE FROM [VDemoTab] WHERE [UserName] = 'user03'
GO
 
SELECT * FROM [dbo].[DemoTab001] 
SELECT * FROM [dbo].[DemoTab002] 
SELECT * FROM [dbo].[VDemoTab]

기본 조작 은 모두 정상 입 니 다!수직 분 표 완성!
성능 이 어때요?

Guid 를 메 인 키 로 사용 하기 때문에 NEWSQUENTIALID () 가 아 닌 NEWSQUENTIALID () 를 사용 합 니 다. 기록 을 추가 할 때 색인 을 모 아 많은 데 이 터 를 다시 정렬 할 수 있 습 니 다.

분 표 이후 한 데이터 페이지 에 저장 할 수 있 는 데이터 가 더 많아 졌 지만 여러 표 로 나 뉘 어 데이터 페이지 도 많아 졌 고 Guid 는 표 마다 존재 하기 때문에 데 이 터 를 조회 할 때 IO 가 더 많 을 것 이다.

데 이 터 를 업데이트 하 는 데 있어 트리거 에서 두 개의 표 가 동시에 업데이트 되 고 그 중의 한 개의 표를 업데이트 하 더 라 도 다른 분 표 는 영향 을 줄 수 있다.표를 나 눈 후에 동시에 업데이트 되 지 않 으 면 트리거 에서 if (update (col) 를 사용 하여 업 데 이 트 된 열 을 판단 할 수 있 습 니 다. 해당 하 는 기본 표를 업데이트 하면 됩 니 다. 다른 분 표 는 업데이트 되 지 않 습 니 다.

가장 좋 은 상황 은 분 리 된 표 가 모두 '독립 적' 이 고 연합 보 기 를 사용 하지 않 아 도 되 며 조회 와 변경 이 모두 독립 되 어 논리 층 을 바 꿔 야 한 다 는 것 이다.

2. 수평 분 표
그 중의 한 열 에 있 는 데이터 값 범위 에 따라 각 구성원 표 간 에 데 이 터 를 나 누 어 표시 합 니 다.각 구성원 표 의 데이터 범 위 는 표 에 따라 열 에 따라 지정 한 CHECK 제약 조건 에서 정 의 됩 니 다.그리고 UNION ALL 을 사용 하여 선택 한 모든 구성원 표를 하나의 결과 집합 으로 조합 합 니 다.이 보기 의 SELECT 문 구 를 참조 하여 열 에 따라 검색 조건 을 지정 한 후, 검색 유 틸 리 티 는 CHECK 제약 정 의 를 사용 하여 어떤 구성원 표 가 해당 줄 을 포함 하 는 지 확인 합 니 다.
SqlServer 파 티 션 보기 수준 표 구현
2. 표 분할 (즉, 라 이브 러 리)
1. 수평 분할

표 분 구 란 무엇 입 니까

일반적인 상황 에서, 우리 가 데이터베이스 테이블 을 만 들 때, 테이블 데 이 터 는 모두 한 파일 에 저장 된다.
그러나 파 티 션 시트 라면 표 데 이 터 는 지정 한 규칙 에 따라 서로 다른 파일 에 나 누 어 져 큰 데이터 파일 을 여러 개의 작은 파일 로 나 누고 이 작은 파일 들 을 서로 다른 디스크 에 두 고 여러 cpu 로 처리 할 수 있 습 니 다.이런 파일 의 크기 는 분할 에 따라 줄 어 들 고 하드웨어 시스템 의 강 화 를 받 아 자 연 스 럽 게 우리 가 데 이 터 를 조작 하 는 데 큰 유리 하 다.
따라서 빅 데이터 양의 데이터 시트 는 파 티 션 에 대한 수요 가 필요 합 니 다. select 효율 을 높 일 수 있 고 역사 데이터 에 대해 줄 을 통 해 압축 파일 을 구분 할 수 있 기 때 문 입 니 다.그러나 데이터 양 이 적은 데 이 터 는 이런 떠들썩 함 을 만 들 지 마라. 왜냐하면 표 분 구 는 데이터 베이스 에 불필요 한 비용 을 발생 시 키 고 성능 을 제외 하면 실현 대상 의 관리 비용 과 복잡성 을 증가 시 킬 수 있 기 때문이다.
SQL Server 테이블 파 티 션 
SQL Server 파 티 션 테이블
2. 수직 파 티 션 (수직 라 이브 러 리 라 고도 함)
수직 분 고 는 업무 수요 에 따라 분 고 를 하 는 것 이다. 예 를 들 어 교육 시리즈 의 경우 정보, 과정, 사용자 (학생, 학교) 세 개의 데이터 베이스 로 나 눌 수 있다.예 를 들 어 전자상거래 의 경우 주문, 상품, 사용자 (업 체, 소비자) 세 개의 데이터 베이스 로 나 눌 수 있다.
3. 데이터베이스 읽 기와 쓰기 분리 와 데이터 동기 화
생산 환경 에서 우 리 는 자주 이런 상황 을 만 날 수 있다.
전단 의 oltp 업 무 는 매우 바 쁘 지만 이러한 운영 데이터 에 대해 olap 를 진행 해 야 합 니 다. 전단 의 정상 적 인 업무 에 영향 을 주지 않 기 위해 서 는 데이터 베 이 스 를 읽 기와 쓰기 로 분리 해 야 합 니 다.
여기 서 저 는 읽 기와 쓰기 가 분 리 될 수 있 는 몇 가지 방안 을 정리 하 겠 습 니 다. 여기 서 데이터 베 이 스 를 사용 할 수 있 는 지 를 고려 하지 않 고 읽 기와 쓰기 가 분 리 된 장면 만 을 대상 으로 합 니 다. 방안 자 체 는 우열 이 없고 업무 사용 장면 에 적합 한 지 만 볼 수 있 기 때문에 몇 가지 방안 의 특징 만 나열 하고 구체 적 인 문제 가 발생 할 때 자신의 수요 와 환경 을 종합 적 으로 고려 한 다음 에 취사선택 을 합 니 다.
 
읽 기와 쓰기 분리 방안
실시 간 동기 화
던 전 데 이 터 를 직접 읽 을 수 있 습 니까?
부본 수
최소 입도
던 전 색인 만 들 기
환경.
결점.
거울 상
예.
여부 (스냅 샷 을 켜 야 합 니 다. 읽 기 전용)
1
창고.
아니.
도 메 인 / 비 도 메 인 (인증서 사용)
높 은 안전 모드 에서 메 인 라 이브 러 리 성능 에 어느 정도 영향 을 미친다.
로그 배 송 (로그 전송)
아니.
네.
N
창고.
아니.
UNC 방식 접근 가능 
던 전 라 이브 러 리 는 resostre 를 만 들 때 연 결 된 사용자 연결 을 끊 습 니 다. 일반적인 로그 백업 에 영향 을 줄 수 있 습 니 다.
구독 발표 (트 랜 잭 션 복사)
예.
예.
N
표 (조회)
예.
도 메 인 / 비 도 메 인
메 인 라 이브 러 리 에 대량의 DML 작업 이 있 을 때 배포 서버 에 어느 정도 영향 을 미 칠 수 있 고 구독 데이터 베 이 스 는 데이터 동기 화 지연 이 있 을 수 있 습 니 다.
always on
예.
네.
4(sql 2012) 8(sql 2014)
창고.
아니.
영역
비 도 메 인 환경 사용 불가
SQL Server 2012 의 AlwaysOn 시도