세상의 모든 Software 지식을 정리

https://www.digitalocean.com/community/tutorials/how-to-reset-your-mysql-or-mariadb-root-password

<service가 작동하는지 확인> sudo service mysql status <service 시작> sudo service mysql start <service 자동으로 시작> sudo update-rc.d mysql defaults <시작> * 사용자가 root이고 비밀번호가 있는 경우 mysql -u root -p -> 돈 계산시는 DEC(5,2)를 사용하는 것이 좋다. ->TIMESTAMP는 레코드를 입력한 시간이 들어간다. 예) ->ENUM타입은 String에 비해 메모리를 적게차지한다. -> 이것은 로컬의 csv파일을 불러와 서버측의 TEST테이블에 집어넣는 것.

-->첫번쨰 메소드에서 redirect:/user/list2를 사용하는 이유 만약 redirect를 사용하지 않는 다면, 사용자가 회원가입을 한 후 사용자 목록으로 넘어갔다고 하자. 결과 화면은 똑같다. 하지만 거기서 새로고침을 하면 계속해서 회원이 추가되며 URL은 /create에 머물러있다. -->브라우저가 결국 2번의 요청을 하게 됨. -->또한 HTTP프로토콜은 stateless프로토콜이므로 다음과 같이 하면안된다. list메소드에서 model.addAttribute("users",users)를 해야한다. 서버는 사용자 정보를 모르므로

RDB 대용량 테이블의 성능향상을 위한 팁 엔터프라이즈 어플리케이션에 있어서의 성능문제의 80%는 DB에서 발생하는것으로 알려져 있다. 인덱스 미설정에서 오는 Full Table Scan과 같은 단순한 문제라면 해결이 쉽지만 레코드수가 수억건에 이르는 대용량 테이블이 가져오는 성능저하는 어플리케이션 수정만으로는 대응이 쉽지 않은 경우가 많다. 이번 포스팅에서는 수억건 이상의 레코드를 지니는 대용량 RDB를 운영함에 있어서 적용 가능한 성능 향상 팁에 대해서 알아보고자 한다. 성능향상의 핵심은 밸런스 오라클, SQL Server, MySQL과 같은 관계형DB(이하 RDB) 성능을 좌우하는 세가지 요소는 I/O,  메모리, 그리고 CPU이다. RDB성능 튜닝은 이 세가지 자원에 걸리는 부하를 적절하게 분산시켜 비용대비 최적의 성능을 뽑아내는것이 핵심이다. I/O: 디스크에 파일 형태로 영속화된 데이터의 읽기/쓰기에 해당한다. 데이터베이스라는것이 결국 데이터를 찾아서 읽고 쓰는것이 주된 역할인 만큼 세가지 요소중에 가장 큰 비중을 차지한다. RDB에서 저장장치로 주로 사용되던 하드디스크의 경우 오랜기간 성능개선이 정체되어 있었는데 SSD의 등장으로 비약적인 발전을 이루고 있다.  메모리: 적절하게 설정된 메모리는 캐쉬를 통해 I/O의 부담을 크게 줄여주는 역할을 한다. 특히 빈번하게 발행되는 SQL의 경우 캐쉬 히트율 (Cache hit ratio)은 SQL성능을 결정적으로 좌우하는 경우가 많다. OS자체가 지닌 메모리와는 별도로 DB가 사용 가능한 메모리는 DB설정에 의존하므로 빈번히 실행되는 SQL임에도 불구하고 캐쉬 히트율이 낮을 경우는 반드시 DB서버 어플리케이션에 할당된 메모리 용량을 체크해 보아야 한다. CPU: CPU는 처리속도 전반에 관여하므로 당연히 성능에 주는 영향도 크다. 최근들어서는 멀티 코어 프로세스가 일반화 되어 처리속도가 크게 향상된 관계로 CPU로 인해 처리속도가 늦어...

참고하기: http://d2.naver.com/helloworld/1155

수평 분할과 샤딩 수평 분할(Horizontal Partitioning)이란 스키마(schema)가 같은 데이터를 두 개 이상의 테이블에 나누어 저장하는 디자인을 말한다. 가령 같은 주민 데이터를 처리하기 위해 스키마가 같은 '서현동주민 테이블'과 '정자동주민 테이블'을 사용하는 것을 말한다. 인덱스의 크기를 줄이고, 작업 동시성을 늘리기 위한 것이다. 보통 수평 분할을 한다고 했을 때는 하나의 데이터베이스 안에서 이루어지는 경우를 지칭한다. 샤딩은 물리적으로 다른 데이터베이스에 데이터를 수평 분할 방식으로 분산 저장하고 조회하는 방법을 말한다. '주민' 테이블이 여러 DB에 있을 때, 서현동 주민에 대한 정보는 A DB에, 정자동 주민에 대한 정보는 B DB에 저장되도록 하는 방식을 말한다. 여러 데이터베이스를 대상으로 작업해야 하기 때문에 경우에 따라서는 기능에 제약이 있을 수 있고(JOIN 연산 등) 일관성(consistency)과 복제(replication) 등에서 불리한 점이 많다. 예전의 샤딩은 애플리케이션 서버 레벨에서 구현하는 경우가 많았다. 최근에는 이를 플랫폼 차원에서 제공하려는 시도가 많다. 크게 분류하면  Hibernate Shards 와 같이 애플리케이션 서버에서 동작하는 형태, CUBRID SHARD, Spock Proxy, Gizzard와 같이 미들티어(middle tier)로 동작하는 형태,  nStore 나  MongoDB 와 같이 데이터베이스 자체에서 샤딩 기능을 제공하는 형태로 나누어볼 수 있다. 참고: http://d2.naver.com/helloworld/14822 4. MySQL Sharding 샤딩은 물리적으로 다른 데이터베이스에 데이터를 수평 분할 방식으로 분산 저장하고 조회하는 방법을 말한다. 여러 데이터베이스를 대상으로 작업해야 하기 때문에 경우에 따라서는 기능에 제약이 있을 수 있고(JOIN 연산 등) 일관성(consistency)과 복제(...

1. 레인지 파티션 파티션키의 연속된 범위로 파티션을 정의하는 방법, 다른 파티션방법과는 달리 MAXVALUE라는 키워드를 이용해 명시되지 않은 범위의 키 값이 담긴 레코드를 저장하는 파티션을 정의 할 수 있다. CREATE TABLE employees(  id INT NOT NULL,  first_name VARCHAR(30),  last_name VARCHAR(30),  hired DATE NOT NULL DEFAULT '1970-01-01',  ....)ENGINE=INNODB PARTITION BY RANGE (YEAR(hired))(  PARTITION p0 VALUES LESS THAN(1991) ENGINE=INNODB,  PARTITION p1 VALUES LESS THAN(1996) ENGINE=INNODB,  PARTITION p2 VALUES LESS THAN(2001) ENGINE=INNODB,  PARTITION p3 VALUES LESS THAN MAXVALUE ENGINE=INNODB ); ****레인지 파티션 주의사항*******  레인지 파티션에서 NULL은 어떤 값보다 작은 값으로 간주된다. 만약 Employees파티션 테이블에 hired칼럼이 NULL인 레코드가 INSERT된다면 이 레코드는 입사 일자가 가장작은 값을 저장하는 p0파티션으로 저장된다. 날짜 칼럼의 값으로 파티션을 만들경우, 다음과 같은 파티션 키를 상요하는 파티셔닝은 피하는 것이좋다. UNIX_TIMESTAMP()를 이용한 변환 식을 파티션 키로 사용 날짜를 무자열로 포맷팅한 형태('2011-12-30')의 파티션 키 YEAR()나 TO_DAYS()함수 이외의 함수가 사용된 파티션 키

참고: http://joshuayoon705.tistory.com/28 데이터베이스 확장 하나의 데이터베이스로 다룰 수 없을 만큼 많은 데이터를 저장하고 조회하려면 당연히 여러 데이터베이스를 이용하는 방식을 모색해야 할 것이다. Cassandra나 Dynamo처럼 분산 환경을 고려하여 만들어진 데이터베이스도 있지만, 범위 검색에 취약하거나 JOIN 연산을 사용할 수 없는 등 기능에 제약이 많다. 따라서 상대적으로 풍부한 기능을 사용하면서 데이터 확장을 꾀할 수 있는 방법은 RDBMS를 샤딩(sharding)하여 사용하는 것이 유리하다. **** 지금까지의 RDB에서는 정규화라는 이름의 과정을 거친 정형화된 데이터를 보관해두고  SELECT 라는 엄청난 부가적인 기능을 제공하는 쿼리문을 사용하여 자신이 원하는 다양한 형태로 데이터를 가져올 수 있었습니다. 하지만 카산드라는 조금 예시가 다릅니다. 카산드라는 항상 원하는 형태로 데이터를 이미 보관하고 있다가 있는 그대로를 꺼내주게 됩니다. 이러한 형태의 설계가 가능한점은 카산드라는 읽기보다 쓰기가 더 빠르기 때문입니다. 쓰기가 엄청나게 빠르게 때문에 읽기 쉬운 형태로 데이터를 가공하여 저장을 해둔후에 그대로 꺼내 쓰기 때문에 결과적으로 읽기에도 엄청나게 큰 이득을 얻게 됩니다. 결과적으로 카산드라는 인덱스 생성킷이 됩니다. 이것이 무슨말이냐 하면 쓰기가 유용하기 때문에 언제든지 읽고 싶은 형태로 저장을 해도 됩니다. 언제 어떻게 쓰일지 모르는 RDB의 인덱스들에 비해서는 설계를 어떻게 하느냐에 따라 엄청나게 큰 효과를 얻을 수 있습니다.

*파티션이란 MySQL서버 입장에서는 데이터를 별도의 테이블로 분리해서 저장하지만 사용자 입장에서는 여전히 하나의 테이블로 읽기와 쓰기를 할 수 있게 해주는 솔루션이다. <파티션을 사용하는 이유> 1. 하나의 테이블이 너무 커서 인덱스의 크기가  물리적인메모리보다 훨씬 크거나 2. 데이터의 특성상 주기적인 삭제 작업이 필요할 경우 파티션이 필요하다. *테이블의 데이터가 10GB이고 인덱스가 3GB라고 가정하자. 하지만 대부분의 테이블은 13GB전체를 항상 사용하는것이 아니라 그중에서 활발하게 사용하는 부분을 주로 다시 사용한다. 즉, 회원이 100만명이라더라도  그중에서 활발하게 사용하는 회원은 2~30%수준이라는 것이다. 거의 대부분의 테이블데이터가 이런형태로 사용된다고 볼 수 있는데 ,활발하게 사용되는 데이터를 워킹 셋이라고 표현한다. 테이블의 데이터를 워킹 셋과 그렇지 않은 부류로 파티셔닝 할 수 있다면 상당히 효과적으로 성능을 개선할 수 있을것이다. <이력데이터의 효율적인 관리> 로그데이터는 단기간에 대량으로 누적됨과 동시에 일정기간이 지나면 쓸모없어진다. <파티션 테이블의 인덱스 스캔과 정렬> MySQL의 파티션 테이블에서 인덱스는 전부 로컬 인덱스에 해당한다. 즉 모든 인덱스는 파티션 단위로 생성되며, 파티션에 관계없이 테이블 전체 단위로 글로벌하게 하나의 통합된 인덱스는 지원하지 않는다는 것을 의미한다. 실제 MySQL 서버는 여러 파티션에 대해 인덱스 스캔을 수행 할 때, 각 파티션으로부터 조건에 일치하는 레코드를 정렬된 순서대로 읽으면서 우선순위 큐에 임시로 저장한다. 그리고 우선순위 큐에서 다시 필요한 순서(인덱스의 정렬순서)대로 데이터를 가져가는 것이다. 결론적으로 파티션 테이블에서 인덱스 스캔을 통해 레코드를 읽을 때 MySQL서버가 별도의 정렬 작업을 수행하지는 않는다. 하지만 일반 테이블의 인덱스 스캔처럼 결과를 바로 반환하는 것이 아니라 내부적으로 ...

<조인의 종류> 1. INNER JOIN -->INNER JOIN은 어느 테이블을 먼저 읽어도 결과가 달라지지 않으므로 MySQL 옵티마이저가 조인의 순서를 조절해서 다양한 방법으로 최적화를 수행 할 수있다. 네스티드-루프 방식만 지원한다. 네스티드-루프란 일반적으로 프로그램을 작성할 때 두 개의 FOR나 WHILE과 같은 루프 문장을 실행하는 형태로 조인이 처리되는 것이다. FOR(recor1 IN TABLE1)  //외부루프(OUTER) {   FOR(record2 IN TABLE2)  //내부 루프(INNER)    {      IF(record1.join_column==record2.join_column)       {           join_record_found(record1.*,record2.*);       } else{           join_record_notfount();       }  } } 2. OUTER JOIN --->하지만 OUTER JOIN은 반드시 OUT가 되는 테이블을 먼저 읽어야 하기 떄문에 조인순순서를 옵티마이저 선택 할 수 없다. FOR(recor1 IN TABLE1)  //외부루프(OUTER) {   FOR(record2 IN TABLE2)  //내부 루프(INNER)    {      IF(record1.join_column==record2.join_column)       {           join_record_found(record1.*,recor...

*MySQL에서는 인덱싱이나 검색 방식에 따라서 스토리지 엔진을 선택해야 할 수도 있기 때문에 여전히 인덱스에 대한 기본 지식은 중요하며, 쿼리 튜닝의 기본이다. *데이터베이스의 성능 튜닝은 어떻게 디스크 I/O를 줄이느냐가 관건인 것들이 상당히 많다. <랜덤 I/O와 순차 I/O> ->랜덤 I/O라는 표현은 디스크 드라이브의 플래터(원판)을 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것을 의미하는데, 사실 순차 I/O 또한 이 작업은 같다. 순차 I/O는 3개의 페이지(16*3kb)를 디스크에 기록하기 위해 1번 시스템 콜을 요청하지만 랜덤 I/O는 3개의 페이지를 디스크에 기록하기 위해 3번 시스템 콜을 요청한다. 즉, 디스크헤드를 3번 움직이는 거시다. 즉, 순차 I/O는 랜덤 I/O보다 거의 3배정도 빠르다고 볼 수 있다. 즉, 디스크의 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한번에 기록하느냐에 의해 결정된다고 볼 수 있다. 그래서 여러 번 쓰기 또는 읽기를 요청하는 랜덤 I/O작업이 훨씬 작업의 부하가 커지는 것이다. 일반적으로 쿼리를 튜닝한다는 것은 랜덤 I/O 자체를 줄여 주는 것이적이다. 여기서 랜덤 I/O를 줄인다는 의미는 쿼리를 처리하는데 꼭 필요한 데이터만 읽도록 쿼리를 개선하는 것이다. <인덱스란?> 칼럼(칼럼들)의 값과 해당 레코드가 저장된 주소를 키와 값의 쌍(Key-value Pair)로 인덱스를 만들어 두는 것이다. DBMS의 인덱스도 칼럼의 값을 주어진 순서로 미리 정렬해서 보관한다. 그래서 INSERT, UPDATE, DELETE문장 처리가 느리다.하지만 이미 정렬된 "찾아보기"용 표(인덱스)를 가지고 있어서 SELECT문장은 매우 빠르게 처리 할 수 있다. B-Tree: 칼럼의 값을 변형시키지 않고 (물론 값의 앞부분만 잘라서 관리한다)인덱스 내에서 항상 정렬된 상태를 유지하고 ...

*트랜잭션은 꼭 여러개의 변경 작업을 수행하는 쿼리가 조합됐을 때만 의미 있는 개념은아니다. 트랜잭션은 하나의 논리적인 작업 셋에 하나의 쿼리가 있든 두 개이상의 쿼리가 있든 관계없이 논리적인 작업 셋 자체가 100%적용되거나 (Commit 실행했을 때) 또는 아무것도 적용되지 않아야(ROLLBACK  또는 트랜잭션을 ROLLBACK 시키는 오류가 발생했을 때)함 을 보장해주는 것이다. 1. MyISAM vs InnoDB 두 엔진에 똑같은 테이블을 생성한다. mysql> CREATE TABLE tab_myisam(           fdpk INT NOT NULL PRIMARY KEY(fdpk) )ENGINE=MyISAM;           mysql> INSERT INTO tab_myisam (fdpk) VALUES(3); mysql> CREATE TABLE tab_innodb(           fdpk INT NOT NULL PRIMARY KEY(fdpk) )ENGINE=INNODB ;           mysql> INSERT INTO tab_innodb (fdpk) VALUES(3); 이와 같이 각각 저장 후,AUTO-COMMIT 모드에서 다음 커리 문장을 각각테이블에서 실행한다. mysql>INSERT INTO tab_myisam (fdpk) VALUES(1),(2),(3); mysql>INSERT INTO tab_innodb (fdpk) VALUES(1),(2),(3); 그 결과 myisam에는 1,2,3이 다 들어가있지만 innodb는 3만 들어갔다.

Overview MySQL 요구가 전보다 급증하고 있습니다. 이제 친숙해서 사용하는 간단한 소용량 DBMS 이 아닌, 많은 대형 업체에서도 사용되고 있기 때문에 많은 이슈가 되고 있습니다. 트위터, 페이스북, 구글, 야후 뿐만 아니라 최근들어 SNS 열풍으로 국내에도 MySQL 관련하여 엄청난 붐이 시작되려는 찰나인 듯 하네요. KTH에 입사를 한 당시에 주력 DB는 Oracle이었습니다. 그러나 라이선스 비용 문제로 주력 DB 선정을 위한 저울질이 시작되었고, 그중 일반 개발자에게도 친숙한 MySQL을 선택했습니다. MySQL 세가지 특성? MySQL 3.X 버전으로 광고 시스템을 만든 적이 있습니다. 꽤나 오래된 얘기.. 지금 생각하면 당시 광고 시스템에서 DB에 날리는 쿼리는 간단하기는 했지만, 상당한 트래픽을 무난히 견디는 것을 보고 감탄을 금치 않았습니다. 와~! 이거 물건인데? 제 첫 사용 소감이었습니다.하지만 “과연 MySQL에 대한 중요한 특성을 잘 알고 있었을까?”  라는 생각이 들었습니다.그때부터였다. MySQL이라는 녀석과 진지한 악수를 한번 해보고 싶다는 생각을 한 것이.. 그래서 여기저기 해외 사례도 기웃거리고, 서적도 진지하게 읽기 시작했죠. 읽으면서 틈틈이 벤치마킹도 수행해보고 나름의 지식 베이스를 늘려갔습니다. 단일 코어에서 Nested Loop Join 처리 다양한 스토리지 엔진 데이터 복제(Replication) 기능 1) 단일 코어에서 Nested Loop Join 처리 MySQL에서는  모든 SQL 처리를 단일 코어에서 Nested Loop Join 방식으로만 데이터를 처리 합니다. 병렬 처리라는 것은 없습니다. 물론 일부 3rd스토리지 엔진을 플러그인으로 설치를 하면 병렬 처리가 가능하다고는 하지만, 기본적인 스토리지 엔진에는 단일 코어 수행합니다. 그렇기 때문에 MySQL 입장에서는 CPU코어 개수를 늘리는 Scale-Out보다는 오히려 단위 처리량이 좋은 C...

참고: http://ojava.tistory.com/25 InnoDB Storage Engine 현재 Oracle에서 가장 밀고 있는 스토리지 엔진으로 In-Memory 특성을 가지고 있습니다. 메모리에 인덱스/데이터 모두 올려서 데이터를 처리하기 때문에 데이터 접근 속도가 상당히 빠릅니다. 메모리가 많이 허용되면 엄청난 퍼포먼스를 발휘하는 엔진이죠. 게다가 트랜잭션을 제공하고, 동시 데이터 처리 시에도 행 단위 잠금으로 처리하기 때문에 실제적으로  InnoDB Storage Engine은 OLTP 성 대용량 처리에 가장 적합한 스토리지 엔진 이라고 볼 수 있습니다. <InnoDB에서의 잠금 방식> 비관적 잠금: 현재 트랜잭션에서 변경하고자 하는 레코드에 대해 잠금을 흭득하고 변경작업을 처리하는 방식을 비관적 잠금이라 한다. 이 처리방식에서 느낄 수 있듯이 현재 변경하고자 하는 레코드를 다른 트랜잭션에서도 변경 할 수 있다. 라는 비관적인 가정을 하기 때문에 먼저 잠금을 흭득한 것이다. 그래서 비관적 잠금이라고 부른다.일반적으로 높은 동시성 처리에는 비관적 잠금이 유리하다고 알려져있으며 InnoDB는 비관적 잠금 방식을 택하고있다. 낙관적 잠금: 각 트랜잭션이 같은 레코드를 변경할 가능성은 상당히 희박할 것이라고 가정한다. 그래서 우선 변경 작업을 수행하고 마지막에 잠금 충돌이 있었는지 확인해 문제가 있었다면 ROLLBACK 처리하는 방식을 의미한다. <InnoDB의 잠금 종류> 레코드락: 레코드 자체만을 잠그는것 중요한것은 InnoDB스토리지 엔진은 레코드 자체가 아니라 인덱스의 레코드를 잠그는 것이다.  갭 락(Gap Lock): 레코드와 인접한 레코드 사이의 간격을 잠그는 것 넥스트 키락: 레코드락과 갭락을 합쳐 놓은 형태의 잠금.