Engineering_S/W & H/W

 안녕하세요. 알렉스 입니다. 이번에는 8-1 ~ 8-3까지 배운 이론을 실제 MySQL에 적용해 보도록 하겠습니다. 해당 테이블의 인덱스 상태를 확인합니다. $ SHOW INDEX FROM [Table Name] copy 사진1) 테이블 생성후 인덱스 확인 사진1에서 테이블 을 생성할때 col1은 PRIMARY, col2는 UNIQUE로 지정하였습니다. 사진1에서 나온 인덱스 결과는 col1, col2만 나왔는데 col3는 아무것도 지정하지 않았기 때문입니다.   여기서 col1은 PRIMARY KEY(클러스터형 인덱스)이고 col2는 보조 인덱스 입니다. 사진2) 테이블 Record 생성 사진2에서 테이블의 Record를 생성할때 col1은 순서없이 INSERT하였습니다. 하지만 SELECT 구문을 사용하여 출력할때는 정렬이 되 있는것을 알수 있습니다. 이렇든 PRIMARY로 지정이 되면 MySQL에서 자동 정렬을 수행합니다.   그러나 Record수가 적을때는 쉽게 하지만 만약 Record수가 수만, 수십만이게 되면 DB입장에서 PRIMARY키를 정렬하는데도 상당한 시간이 걸립니다. 따라서 PRIMARY키는 Record가 없는 초기때 생성하는 것이 성능향상에 도움이 많이 됩니다. 사진3) 고유보조인덱스 생성 컬럼에 고유인덱스 생성 $ CREATE UNIQUE INDEX [Key_name] ON [Table Name] ([Column Name]) copy 사진4) 인덱스 삭제 컬럼에 인덱스 삭제(컬럼삭제가 아님) $ DROP INDEX [Key_name] ON [Table Name] copy 사진5) 보조인덱스 추가 사진5에서 인덱스를 설정했음에도 되지 않는 이유는 해당 테이블을 분석하지 않았기 때문입니다.  컬럼에 인덱스(중복가능) 생성 $ CREATE INDEX [Key_name] ON [Table Name] ([Column Name]) copy 해당 테이블의...

 균형트리구조를 이용하여 조회를 할때 속도면에서 많은 이득이 있었습니다. 하지만 삽입, 수정, 삭제를 할시 DB의 성능에 영향을 줄수 있습니다.  사진1) 이전 글에서 사용한 균형트리 이제 사진1에서 저는 210, 211, 212를 추가하고 싶습니다. 그러면 일단 아래와 같이 추가를 할수 있습니다. 사진2) 210, 211, 212추가 사진2와 같이 3개의 데이터를 추가했는데 200페이지에 지나치게 많은 데이터가 몰렸습니다. 그럼 이때 중간의 페이지를 늘려줘야 합니다. 사진3) 트리구조 변경  사진3처럼 효율적으로 데이터를 찾기 위해 트리 구조가 변경 되었습니다. 210 ~ 212를 쉽게 찾기 위해 중간에 211 페이지가 추가 되었고 200 ~ 211에는 210이 211 ~ 224에는 211, 212가 배정되었습니다.   이렇듯 INSERT를 하게 되면 트리구조의 변경이 생기기 때문에 성능에 문제가 생길수 있습니다. 이는 UPDATE나 DELETE도 마찬가지 입니다. 데이터가 변경이 되면 인덱스는 검색하기 효율적인 방법으로 구조를 재편하게 됩니다. 하지만 인덱스량이 많으면 그만큼 시간이 걸립니다.  이전글 :  DBMS MySQL - SQL8-2: 인덱스 내부 동작 원리 이후글 :  DBMS MySQL - SQL8-4: 인덱스 SQL 사용하기

 MySQL의 클러스트형과 보조형 인덱스는 균형트리로 만들어집니다. 이는 자료구조 내용에서 나오는 데이터 구조 입니다.  사진1) 균형트리 구조  사진1의 균형트리 구조가 나무를 거꾸루 세온 것이라고 할수 있습니다. 위쪽은 시작지점인 뿌리가 있고 다음 중간이 있고 다음 잎은 피라미드처럼 넓어 집니다.  그럼 간단하게 균형트리에 대해서 표로 그려보도록 하겠습니다. 사진2) 균형트리 구조(표)  사진2에서는 3단계로 균형트리를 구성하였습니다. 가장 위쪽에는 100, 200, 300이 있고 그 밑으로 숫자가 규칙적으로 나열되 있는 것을 알수 있습니다. 이때 저는 232의 숫자 데이터를 알고 싶습니다. 이때 MySQL에서 어떤식으로 검색하는지 알아보겠습니다. 사진3) 루트에서 200선택  처음 232의 데이터를 찾을때 루트에서 3개의 선택지가 있습니다. 그런데 232 > 200 AND 232 < 300이기 때문에 200 페이지에 있다는 것을 알수 있습니다. 사진4) 중간에서 225 선택 이제 중간도 마찬가지로 232 > 225 AND 232 < 250이기 때문에 232페이지를 선택합니다.  사진5) 232조회 완료  이제 225페이지에서 순서대로 조회하면 232를 찾을수 있습니다. 만약 인덱스를 사용하지 않으면 100번부터 232번까지 133번을 조회해야 하지만 균형트리 구조를 사용하면 4번만에 찾을수 있습니다. 균형트리는 조회하는데 속도에 도움을 많이 주지만 INSERT, DELETE, UPDATE할시 성능에 악영향을 줄수 있습니다.  악영향에 대해서는 다음 글에서 설명 드리도록 하겠습니다. 이전글 :  DBMS MySQL - SQL8-1: 인덱스 개념 이후글 :  DBMS MySQL - SQL8-3: 인덱스 사용시 악영향(INSERT, UPDATE, DELETE)

 안녕하세요. 알렉스 입니다. 이번에는 DBMS에서 인덱스에 대해서 글을 작성하도록 하겠습니다. 이번 글에서는 기본적인 인덱스에 대한 개념을 설명하고 다음 글에서는 실제 MySQL에서 인덱스를 이용하여 정렬및 검색을 하는지 알아보겠습니다. 사진1) 인덱스 예시  인덱스는 일종에 검색을 편하기 위한  '찾아보기'로 생각하시면 됩니다. 만약 인덱스가 없다면 특정 정보를 찾기 위해서 책을 처음부터 끝까지 찾아봐야 합니다. 만약 검색 정보가 맨 앞에 있으면 금방 찾지만 가장 뒤에 있으면 가장 오랜 시간이 걸립니다.  설사 인덱스를 만든다 하더라도 인덱스 사용유무는 MySQL에서 판단합니다. 만약 인덱스를 사용하지 않는다면 DB성능을 위해서 인덱스를 제거하는 것이 좋습니다. 사진2) DB와 통신  인덱스를 이용하여 DB를 조회하면 빠르게 검색이 가능합니다. 하지만 인덱스가 많아지게 되면 DB성능에 문제가 생길수 있습니다.  사진3) 클러스터형과 보조 인덱스  MySQL에서 인덱스를 크게 클러스터형과 보조형 인덱스로 나눌수 있습니다. 클러스터형 인덱스는 사전과 비슷합니다. 그리고 한개의 Table에서 column 하나만 생성할수 있습니다. 클러스터형 인덱스를 생성하면 해당 컬럼은 자동으로 정렬이 됩니다.  반면 보조 인덱스는 일종의 색인과 같습니다. 따라서 클러스터형 인덱스처럼 자동으로 정렬하지 않습니다. 하지만 검색시 도움을 줍니다. 하지만 인덱스는 DB의 성능에 영향을 줄수 있습니다. 인덱스는 테이블의 약 10%의 데이터 공간을 차지하고 기존의 테이블에 인덱스를 생성할시 시간이 걸립니다. 특히 SELECT(조회)외 INSERT, UPDATE, DELETE를 자주 하게 되면 성능이 나빠집니다. 이는 다음 글에서 설명하도록 하겠습니다. 이후글 :  DBMS MySQL - SQL8-2: 인덱스 내부 동작 원리

 안녕하세요. 알렉스 입니다. 저번에는 부모 엘리먼트(parent element)에 자식 엘리먼트(child element)를 추가하는 방법에 대해서 알았습니다. 이번에는 제거를 하는 방법에 대해서 알려 드리겠습니다. 이전 글의 코드를 바탕으로 짰으니 참고 부탁드립니다. appendChild를 이용하여 li 늘리기 1번 appendChild를 이용하여 li 늘리기 2번 이전 코드에서 test()함수 안에 2줄만 존재합니다. 엘리먼트를 가져오는 'listID'와 제거하기 위한 '.removeChild'입니다. 여기서 ( )안에 'listID.children[0]'이 있는데 '[0]'은 #List에 자식 엘리먼트 0번째 <li>를 말하는 것입니다.  이전에 작성한 HTML문서를 보면 '<li>List1</li>'부분이 첫번째 리스트 입니다. 따라서 버튼을 누르면 1개가 삭제가 되는데 리스트의 첫번째 부분이 삭제 된다는 이야기 입니다. 물론 인덱스를 이용하여 2번째 것도 제거할수 있습니다.