개발 일기장

[데이터 베이스] - 데이터를 보다 많이 - 데이터를 좀 더 빠르게 - 데이터를 보다 안전하게. 데이터 저장은 하드 디스크에 저장되어야 지속적 보관이 가능하다. 하지만, 디스크까지 접근 시 시간적 비용이 많이 들기 때문에 효율성을 위해 여러 방법이 필요하다. 데이터 베이스 구동 원리 요청 - Client에서 원하는 데이터를 요청한다. (쓰기, 읽기) 이때 버퍼 캐시는 데이터베이스의 서버 쓰레드가 처리하여 빠르게 요청에 대답을 전달한다. 캐싱 확인 - 만약 메모리(RAM)에 캐싱 되어 있는 상태라면 바로 요청에 응답하지만 캐싱이 안되어 있다면 하드디스크 에 접근한다. 쓰기는 데이터베이스에 접근하기 전 사용자에게 미리 완료여부를 전달한 후, 버퍼캐시에 Task(밀린 쓰기 작업)을 저장한다. 백그라운드 쓰레드..

USE BaseballData -- Sorting (정렬) 을 줄이자 ! -- O(N LogN) -> DB는 데이터가 어마어마하게 많다 -- 너무 용량이 커서 가용 메모리로 커버가 안 되면 -> 디스크까지 찾아간다. /* -- Sorting이 일어날 때 --1) Sort Merge Join -- 원인) 알고리즘 특성상 Merge하기 전에 Sort를 해야 함 2) ORDER BY 3) GROUP BY 4) DISTINCT 5) UNION 6) RANTKING WINDOWS FUNCTION 7) MIN MAX */ -- ORDER BY -- 원인) ORDER BY 순서로 정렬을 해야 하니까 Sort SELECT* FROM players ORDER BY college; -- GROUP BY -- 원인) 집게를..

NL(Nested Loop) , Merge 조인 USE BaseballData; SET STATISTICS TIME ON; SET STATISTICS IO ON; SET STATISTICS PROFILE ON; -- 조인 원리 -- 1) Nested Loop (NL) 조인 -- 2) Merge(병합) 조인 -- 3) Hash(해시) 조인 -- Nested Loop SELECT top 5* FROM players AS p INNER JOIN salaries AS s ON p.playerID = s.playerID; -- 상단 players에서 하나하나 salaries의 playerID를 비교하여 찾는 작업 -- 효율이 떨어질 수 있지만, top 5 같이 끊을 수 있는 작업에서 빠르게 작동시킬 수 있음. -..

USE Northwind; -- 북마크 룩업 -- Index Scan vs Index Seek -- Index Scan이 항상 나쁜 것은 아니고 -- Index Seek가 항상 좋은 것은 아니다. -- 인덱스를 활용하는데 어떻게 느릴 수 있을까? --NonClustered --Clustered --Heap Table -- Clustered의 경우 Index Seek가 느릴 수가 없다. -- NonClustered의 경우, 데이터가 Leaf Page에 없다. -- 따라서 한 번 더 타고 가야함 -- 1) RID -> Heap Table (Bookmark Lookup) -- 2) Key -> Clustered SELECT* INTO TestOrders FROM Orders; SELECT* FROM TestO..

USE Northwind; -- 인덱스 접근 방식 (Access) -- Index Scan vs Index Seek CREATE TABLE TestAccess ( id INT NOT NULL, name NCHAR(50) NOT NULL, dummy NCHAR(1000) NULL, ); GO CREATE CLUSTERED INDEX TestAccess_CI ON TestAccess(id); Go CREATE NONCLUSTERED INDEX TestAccess_NCI ON TestAccess(name); GO DECLARE @i INT; SET @i = 1; WHILE(@I 실제 데이터를 찾기 위해 페이지 수 SET STATISTICS TIME ON; SET STATISTICS IO ON; -- INDEX..

USE Northwind; -- 인덱스 종류 -- Clustered(영한 사정) vs Non-Clustered(색인) -- Clustered -- Leaf Page = Data Page -- 데이터는 Clustered Index 키 순서로 정렬 -- Non-Clustered ? (사실 Clustered Index 유무에 따라서 다르게 동작) -- 1) Clustered Index가 없는 경우 -- Clustered Index가 없으면 데이터는 Heap Table이라는 곳에 저장 -- Heap RID -> Hwap Table에 접근 데이터 추출 -- 2) Clustered Index가 있는 경우 -- Heap Table이 없음. Leaf Table에 실제 데이터가 있따. -- Clustered Index의..

인덱스 확인 USE Northwind; --DB 정보 살펴보기. --데이터에 대한 정보 (이름, 용량, 경뢰 등등) EXEC sp_helpdb 'Northwind'; -- 임시 테이블 만들기 (인덱스 테스트용) CREATE TABLE Test ( EmployeeIDINT NOT NULL, LastNameNVARCHAR(20) NULL, FirstNameNVARCHAR(20) NULL, HireDataDATETIME NULL ); GO INSERT INTO Test SELECT EmployeeID, LastName, FirstName, HireDate FROM Employees; SELECT * FROM Test; -- FILLFACTOR (리프 페이지 공간 1%만 사용) -- PAD_INDEX (FILL..

USE BaseballData; -- 윈도우 함수 -- 행들의 서브 집합을 대상으로, 각 행별로 계산을 해서 스칼라(단일 고정)값을 출력하는 함수 -- 느낌상 GROUPING이랑 비슷한가? -- SUM, COUNT, AVG 집계 함수 SELECT* FROM salaries ORDER BY salary DESC; SELECT playerID, MAX(salary) FROM salaries GROUP BY playerID ORDER BY MAX(salary) DESC -- 윈도우 함수 -- ~OVER([PARTITION] [ORDER BY] [ROWS]) -- 전체 데이터를 연봉 순서로 나열하고, 순위 표기 SELECT *, ROW_NUMBER() OVER (ORDER BY salaryDESC),-- 행#번..

변수 USE BaseballData -- 변수 DECLARE @i AS INT = 10; DECLARE @j AS INT; SET @j = 10; DECLARE @firstName AS NVARCHAR(15); DECLARE @lastName AS NVARCHAR(15); SET @firstName = (SELECT TOP 1 nameFirst FROM players AS p INNER JOIN salaries AS s ON p.playerID = s.playerID ORDER BY s.salary DESC); -- SQL SERVER SELECT TOP 1 @firstName = p.nameFirst, @lastName = p.nameLast FROM players AS p INNER JOIN sala..

특이사항 = 조직문화에 따라서 사용유무가 갈린다. /* TRANSACTION ALL OR NOTING 유저간의 거래 A의 인벤토리에서 아이템 제거 (제거가 안되고) B의 인벤토리에 아이템 추가 (추가가 되었을 경우) A의 골드 감소 강화는 일어났는데 무기강화가 연동되지 않아, 무기 강화는 안된것. 이런 문제점을 막기 위해 사용한다. BEGIN TRAN; COMMIT; ROLLBACK; EX) 메일 = BEGIN TRAN; 보낼것인가? = COMMIT; 취소할 것인가? = ROLLBACK; 성공 / 실패 여부에 따라 COMMIT(= COMMIT을 수동으로 하겠다.) */ ROLLBACK 적용하여도 ROLLBACK을 했기 때문에, COMMIT을 하지 않음. COMMIT 했을 경우는 데이터를 등록에 허가하므로..