본문 바로가기

Database

(38)
sql Index 고려사항 1. 인덱스 대상 후보컬럼 선정 기준 분포도가 좋은 컬럼인가? 분포도의 기준은 1%이내 ex) 주문 테이블의 ‘배송여부’ 컬럼은 Y/N으로 분포도는 50%이다. 논리적식별은 50%이지만 대부분의 실데이터는 Y가 될것이고 분포도가 한쪽으로 극단적으로 쏠리기 때문에 인덱스 후보로 해도된다. ex) 고객 테이블의 성별은 남자/여자 로 50%이다. 하지만 이는 변하지 않는 데이터 이며, 50%의 분포도를 가지므로 인덱스가 딱히 필요치 않다 결합 인덱스의 경우도 해당 결합된 데이터의 분포도를 추산하여 인덱스를 선정한다. 갱신이 자주 발생하지 않는 컬럼인가? update가 발생하면 index를 갱신하기 때문에 성능에 좋지 않지만! 꼭 필요한 경우에는 복합인덱스로 해야 한다. ( 검색 조건에 필요한 경우에 ) 조건절..
Field 'ssl_cipher' doesn't have a default value ERROR 1364 (HY000): Field 'ssl_cipher' doesn't have a default value Mysql 버전이 높아지면서 보안관련 인한 오류 User 생성시 Host, User ,Password, ssl_cipher, x509_issuer, x509_subject 를 입력 필수 ssl_cipher, x509_issuer, x509_subject 값은 '' 빈값을 입력. $ insert into user (Host, User, Password, ssl_cipher, x509_issuer, x509_subject ) values('localhost','사용자명',password('비밀번호'),'','',''); ERROR 1364 (HY000): Field 'authenticat..
mysql only_full_group_by SET sql_mode = '' or set global sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
mysql int bigint mysql을 사용하면서 몰랐던 정보들을 알아서 적어본다. int / bigint 에 관한 내용인데 먼저 int / bigint 의 최대값은 unsigned 일 경우 각각 4억과 4천경이다(저만큼 넣을 데이터가 있는건가..)...... int는 4바이트(자릿수 10자리) bigint는 8바이트로 (자릿수 20자리) 로 생각면 된다. 자세한 사항은 공식 홈피 확인 https://dev.mysql.com/doc/refman/5.5/en/integer-types.html 두번째로 대부분 많은 분들이 테이블 선언시 int(4) 하면 4자리까지만 들어간다고 생각하실수도 있는데 (실은 내가 그랬다.) 만일 3자리 숫자 999 를 넣었다면 출력될때 0999 로 해당 4자리이하일때 앞에 0을 붙여서 내보낸다. (zero..
mysql workbench 작업시 fk 칼럼 속성 변경시엔 확인을 잘해야합니다. 재미있는것을 발견( 지금까지 몰랐던것을 발견)!! 테이블간의 관계인 fk( Foreign Key Constraint) 가 설정되어 있을때 fk 생성시 해당 칼럼을 not null 속성을 넣지 않았다. (이건 가능함)헌데 not null 속성을 넣을려면 먼저 해당 fk 를 지운후 alter 로 notnull 속성을 넣어준후 다시 fk 속성을 넣어줘야 한다. 여기까진 문제가 없다. 이번엔 unsigned 속성을 넣어보려 한다. 헌데 fk의 기본이 되는 pk 속성중에 unsigned 속성이 없다면 어떻게 되느냐?! 아까와 같이 "먼저 해당 fk 를 지운후 alter 로 unsigned 속성을 넣어준후 다시 fk 속성을 넣어줘야 한다. "에서 unsigned 속성을 넣은후 다시 fk 속성을 넣을 때 에러가 발생..
spark maven error spark 내 maven 으로 하둡관련 설치 시 아래와 같이 에러가 난다면 [WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireMavenVersion failed with message: Detected Maven Version: 3.0.5 is not in the allowed range 3.3.3. [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] Spark Project Parent POM .......................... FAILURE [2:25.599s] [INFO] S..
mongodb Replica Set replica set(이하 리플리카셋)은 여러 대의 서버에 원본을 복사해 두고,장애가 발생시 자동으로 장애 이외의 디비 중 하나를 선택하여 원본 디비처럼 사용할 수 있도록 있습니다. 이로 인해 서비스를 끊기지 않고 지속적으로 유지할 수 있습니다. 리플리카셋에서 첫번째 입력을 담당하는 서버를 primary 서버라 부르며 그밖의 서버를 secondary 서버라 부릅니다. 프라이머리 서버는 세컨더리 서버를 2초 마다 상태 체크하여 데이터 동기화를 하기 위해 HeartBeat(일종의 ping 확인)를 확인합니다. 이때 세컨더리서버가 사용할수 없더라도 프라이머리 서버는 살아있으므로 서비스는 유지 됩니다. 만일 프라이머리 서버에 이상이 생길 경우 세컨더리서버 끼리의 선거를 통해 프라이머리서버를 선출하여 작동하게 됩..
mongodb sharding mongodb sharding( 이하 샤딩으로 표기) 은 mongodb끼리의 데이터 복제함으로서 다른 서버와의 동기화 및 빅데이터를 저장하기 위해서 분산 저장을 하는것이 샤딩의 목적입니다. 샤딩은 mongodb 두대로도 가능하지만 최소 3대를 권장하며, 실질적인 데이터 복제가 아닌 mongodb내의 oplog에 의한 명령어를 복사/ 실행함으로서 데이터를 유지합니다. 여기서는 한 컴퓨터에서 서버를 3대를 실행합니다.먼저 저장소가 서로 다르게 되어야 하므로 폴더를 따로 만들어 줍니다.$ mkdir shard1 shard2 shard3 $ sudo ./mongod -shardsvr -dbpath /data/shard1 -port 40001$ sudo ./mongod -shardsvr -dbpath /data/..