C, C++, C#, JAVA, Python, R, HTML등의 다양한 IT 언어들이 만들어지고 사용되고 있는 시대에 살고 있다. 과거에는 영어, 스페인어, 중국어 등의 사람간의 대화를 위한 언어들에 집중 했다면 많은 소프트웨어의 개발과 자동화 작업으로 인하여 개발언어를 배우는 것은 자연스러운 일이 되어가고 있으며 초,중,고 정규 과정에서도 수업을 할정도로 중요해지고 있다.

 과거에는 이과에서도 컴퓨터 공학관련 학과에서만 개발언어에 대하여 공부하였으나 이제는 문과 이과 관계없이 모두 개발 언어를 공부하며 다양한 수익 창출을 발생시키고 있는 상황이다. 많은 유료 코딩 강의를 통하여  C언어, 자바, 파이썬 등의 언어를 과거에는 공부하였는데 요즘은 유튜브를 통하여 무료로 실력 좋은 분들이 무료로 강의를 많이 해주고 있어서 주요 사이트를 공유하려한다. 

 

무료 개발 언어공부, 코딩공부 유튜브 TOP5

 

1. 조코딩 22

- 코딩과 전혀 관련 없는 학과를 나와서 코딩공부를 시작한 분으로 문과생도 보고 따라할수 있을 정도로 강의 수준을 낮추어 코딩에 대한 이해를 시켜주고 있으며 실제로 단계별 강의와 실용성 있는 개발 소스 공유를 통하여 처음 코딩을 접하는 사람도 따라할수 있도록 좋은 자료를 공유하고 설명해주고 있다.

www.youtube.com/watch?v=k0FJeq5Uo_I

2. 생활코딩 22

- 생활코딩은 조코딩 보다 조금더 개발자적 성향으로 들어가서 실질적으로 생활 속에서 일반인들이 코딩을 쉽게 접할수 있도록 다양한 유형의 개발 언어 강의를 해주고 있다.

www.youtube.com/watch?v=1ttLx9MbrCI

 

3. 노마드 코더 23.8

- 노마드 코더는 컨텐츠가 외국인이 진행하는 개발에 대한 이야기로 한국어와 영어를 같이 들을수 있으며 자막이 있어 개발에 대한 이해를 하는데 큰 어려움 없이 참고해볼수 있다. 한국과 외국의 개발에 대한 이야기와 기술이 대한 설명을 들을수 있다.

www.youtube.com/watch?v=zGrTT4k1-yc

 

4. 나도코딩 13.7  

- 나도 코딩은 코딩을 쉽고 재미있게 일반인들이 시작할수 있도록 기초에서 부터 다양한 예제를 제공하여 내가 개발한 내역을 바로 시각적으로 확인하고 접할수 있도록 다양한 컨텐츠를 제공하고 있다. 

www.youtube.com/watch?v=kWiCuklohdY

 

5. 테크보이 워니 13.3

- 실리콘밸리 출신의 개발자로써 미국의 개발환경과 기술에 대하여 설명해주며, 개발에 대한 고찰과 테크트리등에 대한 실질적인 개발자로써의 다양한 경험에 대하여 이야기해주고 있다. 또한 기본적인 개발언어에 대한 기술공유 컨텐츠를 제공하고 있다.

www.youtube.com/watch?v=2q28JQ6SNSs

 

#코딩이란코딩 배우기코딩 자격증코딩 장난감뽀로로 코딩컴퓨터코딩 노트북코딩 프로그램코딩 독학코디엠코딩컴퓨터코디엠 주가코딩 교육코딩 교육이란코디엠 주가 전망코딩 로봇코딩파티코딩 학원코디아이코디엠 거래정지 이유코디오반정코딩테스트코딩도장코딩 사이트

#마이크로스테이션 개발 언어소프트웨어 개발 언어개발 언어안드로이드 개발언어웹개발 언어앱 개발 언어언어 교육과정 개발웹 개발언어개발 언어 종류개발 언어 xm응용 프로그램 개발 언어

#Free IT development language study, coding study YouTube TOP5

#Estudio de lenguaje de desarrollo de TI gratuito, estudio de codificación YouTube TOP5

#無料IT開発言語研究では、符号化の研究ユーチューブTOP5

#免费的IT开发语言研究,编码研究YouTube TOP5

#मुफ्त आईटी विकास भाषा का अध्ययन, कोडिंग का अध्ययन YouTube TOP5

'1. IT Story > Development' 카테고리의 다른 글

heapSort  (0) 2012.04.04
selectionSort  (0) 2012.04.04
shellSort  (0) 2012.04.04
오픈 API를 이용한 간단한 번역프로그램  (0) 2012.03.29
ChatClient  (0) 2012.03.29
MultiChatServer  (0) 2012.03.29
MultiChatClient  (0) 2012.03.29
큐를 이용한 간단한 구직Pro  (0) 2012.03.29
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,
   

1. 동시성 제어를 위한 Locking 기법

가. Locking 기법의 정의

 - 트랜잭션이 사용하는 자원 (데이터 항목) 에 대하여 상호 배제 (Mutual Exclusive) 기능을 제공하는 기법

 - 상호 배제는 특정 트랜잭션이 데이터 항목에 대하여 잠금 (Lock) 을 설정하면, 잠금을 설정한 트랜잭션이 해제 (Unlock) 할 때까지 데이터를 독점적으로 사용할 수 있는 것

 

나. Locking 연산의 종류(일반적인 DBMS 모두 지원, Select/Update, Insert 등)

 - 공유 Lock (Shared Lock) : 공유 잠금한 트랜잭션은 데이터 항목에 대해 읽기(read)만 가능

 - 전용 Lock (Exclusive Lock) : 전용 잠금한 트랜잭션은 데이터 항목에 대해서 읽기(read)와 기록(write)가 모두 가능


2. 직렬성 보장을 통해 동시성을 제어하는 2Phase Locking 기법

가. 2Phase Locking의 개념도

 - 모든 트랜잭션들이 lock과 unlock연산을 확장Phase와 수축Phase로 구분하여 수행함 
 - 확장Phase : 트랜잭션은 lock 만 수행할 수 있고 unlock은 수행할 수 없는 Phase
 - 수축Phase : 트랜잭션은 unlock만 수행할 수 있고 lock은 수행할 수 없는 Phase

 

나. 2Phase Locking 기법의 문제 및 해결

 - 2Phase Locking 기법이 deadlock의 완전한 제거를 나타내지는 못함
 - 2Phase Locking 기법 상태에서 Cascading rollback이 가능함
 - 교착상태 예방과 교착상태 탐지로 해결

 

다. 기본적인 2Phase Locking의 문제점을 피하기 위한 Locking 기법

종류 내용 특징
Strict 2PLP - 2Phase Locking
- 모든 독점 lock(Lock-X)는 해당 트렌젝션이 완료될 때까지 unlock 하지 않음.  그대로 유지
- 연쇄복귀(Cascacding rollback) 문제 발생하지 않음
- Deadlock 회피 못함
Rigorous 2PLP - 2Phase Locking
- 모든 lock는 해당 트랜젝션 이 완료될
때까지 unlock 하지 않음.
- Strict 2PLP보다 더 제한적
- Deadlock 회피 못함
Static (Conservative) 2PL - Transaction 수행 전부터 해당 트렌젝션의 읽기 집합과 쓰기집합을 미리 선언하여 해당 트렌젝션이 접근하려는 모든 항목들에 Lock을 획득 - Dead lock 발생 하지 않음.
- 현실성 없음

 

블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,
   

1. 모든 속성을 만족할 수 없다는 CAP 이론

가. CAP(Consistency, Availability, Partitioning)이론이란?
- 2002년 버클리 대학의 Eric Brewer 교수에 의해서 발표된 분산 컴퓨팅 이론으로, 분산 컴퓨팅 환경은 Consistency, Availability, Partitioning 3가지 특징을 가지고 있으며, 이중 두 가지만 만족할 수 있다는 (Pick two) 이론

- 분산 컴퓨팅 시스템이 보장해야 할 3가지 특징(일관성,가용성,부분 결함허용)을 정의하고,분산 시스템은 3가지 중 2가지만 보장할 수 있고(Pick two), 3가지 모두를 보장하는 것은 불가능 하다는 이론

CAP 이론 모형 C·A·P 설명
Consistency (일관성) - 모든 사용자는 동시에 항상 같은 데
이터를 조회 한다
Availability (가용성) - 모든 사용자는 항상 read/write 할 수 있다
- 몇몇 노드 장애 시에도 다른 노드들은
작동해야 한다
Partition Tolerance (부분 결함허용) - 물리적 네트워크 분할(Partition)에도
시스템은 정상 동작 해야 한다
Pick Two - CAP중 2가지만 선택 가능

 

2. CAP 이론 측면에서 RDB와 NoSQL DB

가. CAP 이론과 DBMS의 관계

 - 트위터와 같이 하루에 올라가는 수천만 건의 글을 감당할 수 있는 분산형 데이터베이스가 필요 하면서, ROI높고 성능 좋은 DBMS 필요

 - 일반적으로 NoSQL시스템은 관계형을 포기하거나 트랜잭션 구조를 느슨하게 함으로써 수평 확장이 가능하도록 하는데 주요 목적을 가짐

DBMS 설명 적용 사례
RDB - Consistency + Availability 선택 - 금융 서비스: 미션 크리티컬한 트랜잭션 보장
NoSQL DB - Consistency + Availability 포기

- 분산 확장성을 보장

- 트랜잭션 ACID를 느슨하게 유지
- C + P 형: 대용량 분산파일시스템 à 성능 보장형
(Bigtable, Hypertable, Hbase

- A + P 형: 비동기식 서비스, SNS 서비스
(Dynamo: Amazon, Apache Cassandra: Twitter

 - NoSQL DB 제품은 CAP 중에서 C 또는 A를 일부 포기함으로써 분산 확장을 택함

나. CAP 이론 측면에서 RDB와 NoSQL DB 비교

구분 RDB NoSQL
특징 - JOIN
- ACID 트랜잭션
- 고정된 스키마
- Update/Delete 잘 사용되지 않음 -> Insert로 대체
- 강한 Consistency 불 필요
- 노드의 추가/삭제, 데이터 분산에 유연
- 모델링(Key-value, 계층형/그래프 데이터 등)
- Query 유연
장단점 - 데이터 무결성, 정합성 보장
- 정규화된 Table, 작은 크기의 트랜잭션
- Web 환경의 다양한 정보 검색 및 저장에 강함
단점 - 확장성 한계
- 클라우드 분산 환경에 적합하지 않음
- 데이터 무결성, 정합성 보장하지 않음

 

3. 클라우드 컴퓨팅 환경에서 NoSQL DB 필요성 (RDB 제약) 

가. NoSQL DB(Not Only SQL DB)의 개념
 - 관계 데이터베이스(RDB) 한계를 극복하기 위해, Join이 없고, 고정된 스키마를 갖지 않는 새로운 형태의 데이터 저장소

 

나. 클라우드 환경에서 NoSQL DB 필요성(RDB 제약)
 - 클라우드 컴퓨팅/웹 환경의 대량의 데이터를 저비용으로 처리할 수 있는 DB 필요
 - 네트워크 발전으로 인해 발생하는 많은 양의 데이터를 처리하기 위해 클라우드 컴퓨팅 등 분산 처리 시스템이 도입되면서 기존 RDB의 확장성 한계로 인해 NoSQL DB가 대안으로 대두되고 있음

'1. IT Story > Basic Studies' 카테고리의 다른 글

데이터 품질관리의 Data Profiling  (0) 2020.12.24
MMDB(Main Memory Data Base)  (0) 2020.12.24
DB 샤딩(Sharding)  (0) 2020.12.24
CI(Continuous Integration)  (0) 2019.11.21
테스트자동화  (0) 2019.09.22
V&V(Verification & Validation)  (0) 2019.09.20
빅데이터(Big Data)  (0) 2019.09.19
3D프린팅  (0) 2019.09.17
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,
   

1. 정합성 체크를 통한 데이터 품질향상, 데이터 프로파일링의 개요

가. 데이터 프로파일링(Profiling)의 정의
 - 데이터에 기반한 정합성을 체크하여 데이터를 구조화하고 보정하는 분석 기법

나. 데이터 프로파일링의 목적

  - 데이터정확성 : 비즈니스 사용자에게 정확한 데이터 제공

  - 데이터 제어 : 이름, 주소 등 비즈니스 데이터에 대한 정제, 표준화, 보강 및 중복제거

  - 데이터 모니터링 : 분석기능을 통한 지속적인 데이터 품질평가 및 변경 내역에 대한 모니터링 제공

2. 데이터 프로파일링 개념도 및 기법

가. 데이터 프로파일링 개념도

- 소스데이터를 효과적으로 분석하기 위해서 데이터 프로파일을 통해서 데이터 오류를 식별
- 데이터 크린싱(Cleansing)을 통해서 검출된 오류 데이터를 변경 및 수정 실행

 

나. 데이터 프로파일링 절차 및 기능요소

 - 대상선정 : 데이터 프로파일링에 필요한 데이터를 선정

 - 데이터 탐색 : 데이터의 값이 업무 규칙과 정합성을 유지하는지 확인

 - 구조 탐색 : 테이블 사이의 무결성과 데이터 레코드 내의 구조적 이상확인

 - 관계 탐색 : 컬럼과 테이블간 관계(Relation)의 관계분석

 - 결과 리포트 : 발견된 데이터 오류정보를 사용자 및 Cleansing모듈에 전달

 

다. 데이터 프로파일링 기법

 - 컬럼속성분석 :  하나의 컬럼에 저장된 값 분석

 - 구조 분석  : 테이블을 서로 어떤 관련인지를 정의한 룰 사용

 - 단순데이터 룰 분석 : 값의 결합이 가능한 비즈니스 객체의 여러 컬럼에 걸친 값을 다루는 룰을 분석하여 보다 유용한 것을 찾는 것

 - 복잡한 데이터 룰 분석 : 여러 비즈니스 객체에 연관된 데이터 룰에 부합하는 값을 요구하는 것 보다 복잡한 룰

 - 값 룰 분석 : 합당하지 않는 집계 값에서 부정확한 데이터의 존재를 찾는 것

 

'1. IT Story > Basic Studies' 카테고리의 다른 글

CAP(Consistency, Availability, Partitioning) 이론  (0) 2020.12.24
MMDB(Main Memory Data Base)  (0) 2020.12.24
DB 샤딩(Sharding)  (0) 2020.12.24
CI(Continuous Integration)  (0) 2019.11.21
테스트자동화  (0) 2019.09.22
V&V(Verification & Validation)  (0) 2019.09.20
빅데이터(Big Data)  (0) 2019.09.19
3D프린팅  (0) 2019.09.17
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,
   

1. 실시간 대용량 트랜잭션 처리를 위한 MMDB의 개요

가. MMDB(Main Memory DataBase)의 정의

- 데이터베이스 전체를 주기억장치에 상주시켜 데이터베이스 연산을 처리하는 고성능 DB
- 데이터베이스 Start-up과 동시에 데이터베이스를 Memory에 상주시켜 관리 및 운영하는 DB

 

나. MMDB의 등장배경

 - 기존 DBMS처리 성능한계 메모리 가격 하락과 64Bit 운영체제 등장
 -  실시간 데이터 처리 요구 증가, 고객의 마인드 변화

2. 기존 Disk기반 DB와의 비교

디스크 기반 DB MMDB
버퍼만 메인메모리에, DB테이블은 디스크 메인 메모리 내에 DB테이블, 인덱스 등 존재

나. Disk 기반 DB와의 특징 비교

구분 디스크 기반 DB MMDB
데이터 저장 장치 디스크 주기억장치 (메인 메모리)
운영목표 데이터의 안정적 운영 트랜잭션의 빠른 수행
동시성 제어 데이터 접근 트랜잭션 중심 인덱스에 대한 동시성 제어
DBMS 프로세스구성 멀티 프로세스 멀티 스레드
처리속도 1배 (DB연산 + 데이터 전송 연산) 10~50배 빠름 (DB 연산 시간)
시스템 설계방향 Disk 접근횟수 최소화
데이터 Clustering 향상
CPU처리 시간 최소화
메모리 공간 사용 최소화

 

3. MMDB의 단점극복을 위한 기술 및 활용현황

가. MMDB의 단점극복 기술

 - 용량제한 → 무제한화 (TB급까지 구현)
 - 안정성 → Disk에 Log 및 Check Point 기록 구현
 - Memory와 Disk 이중기록으로 인한 성능저하 → Memory 성능향상 부분이 Disk I/O 성능 감소부분 보다 월등하도록 설계하여 해소
 - 복구 시 Disk 내용 메모리 로딩 시 소요시간 → 병렬 회복기법 기반 획기적 개선

 

나. MMDB의 활용현황

 - 차세대 빌링 : 이동통신사의 사용자 인증/빌링을 위한 대용량 고속처리 위해 사용
 - 증권사 : 실시간 주식의 시세 분석, 차트 등 다양한 분석에서 사용됨
 - 유선통신 : NGN기반의 대용량 트랜잭션 처리를 위해 활용
 - 이동통신 : 중앙집중적 일괄처리를 위해 메모리DB의 활용

 

'1. IT Story > Basic Studies' 카테고리의 다른 글

CAP(Consistency, Availability, Partitioning) 이론  (0) 2020.12.24
데이터 품질관리의 Data Profiling  (0) 2020.12.24
DB 샤딩(Sharding)  (0) 2020.12.24
CI(Continuous Integration)  (0) 2019.11.21
테스트자동화  (0) 2019.09.22
V&V(Verification & Validation)  (0) 2019.09.20
빅데이터(Big Data)  (0) 2019.09.19
3D프린팅  (0) 2019.09.17
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,
   

1. 데이터베이스 확장을 위한 샤딩의 개요


가. 샤딩(Sharding)의 개념

  - 관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서 데이터를 파티셔닝 하는 기술
  - 샤딩은 DBMS 레벨에서 데이터를 나누는 것이 아니고 데이터베이스 자체를 수평분할 방식으로 분산저장하고 조회하는 방법

나. 샤딩(Sharding)의 장점

1) 성능개선: 큰 데이터를 압축, 개별테이블은 각샤드에서 더 빠른 작업을 지원
2) 신뢰성개선: 한 샤드가 실패하더라도 다른 샤드는 데이터서비스를 제공
3) 위치추상화: 애플리케이션 서버에서 어떤 데이터가 어떤 데이터베이스에 위치해 있는지 알 필요가 없음

 

2. 샤딩의 개념도 및 데이터베이스 분할방법

(Sharding)

가. MongoDB의 샤딩 개념도

- 샤드키로 설정된 칼럼의 범위를 기반으로 각각의 값 에 맞는 Shard에 저장
- 사용하는 Application단에서는 MongoS라는 라우팅 프로세스만 연결하므로 Shard의 구조에 대해서는 알 필요도 없고, 구조 변경에 따른 수정도 필요 없음

 

나. 샤딩의 데이터베이스 분할방법

방법 설명
Vertical Partitioning - 테이블 별로 서버를 분할하는 방식
Range based Partitioning - 하나의 feature나 table이 점점 거대해지는 경우 서버를 분 리 하는 방식
Key or Hash Based Partitioning - 엔티티를 해쉬함수에 넣어서 나오는 값을 이용해서 서버를 정하는 방식
Directory Based Partitioning 파티셔닝메커니즘을 제공하는추상화된 서비스를 생성

 

3. 샤딩 적용시 가이드라인

구분 주요내용
데이터 재분배 - 서비스 정지없이 scale-up 할 수 있어야 함
조인 파티션 - Sharding-db 간에 조인이 불가능하기에 처음부터 역정규화도 고려해야함
- shard 해쉬함수 설계가 중요

트랜잭션
Global  Unique Key
데이터는 작게
- Global Transaction을 사용하면 shard DB간의 트랜잭션도 가능

- DBMS에서 제공하는 auto-increment를 사용하면 key가 중복될 수 있기 때문에, Table의 단위를 레벨에서 가능한 GUID를생성해야함 작게 만들어야 함

 

'1. IT Story > Basic Studies' 카테고리의 다른 글

CAP(Consistency, Availability, Partitioning) 이론  (0) 2020.12.24
데이터 품질관리의 Data Profiling  (0) 2020.12.24
MMDB(Main Memory Data Base)  (0) 2020.12.24
CI(Continuous Integration)  (0) 2019.11.21
테스트자동화  (0) 2019.09.22
V&V(Verification & Validation)  (0) 2019.09.20
빅데이터(Big Data)  (0) 2019.09.19
3D프린팅  (0) 2019.09.17
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,
   

 Amazon AWS의 Aurora(오로라) DB에 대하여 간략한 기능과 Q&A 사항을 정리하였다. Aurora(오로라) DB는 탈oracle의 분위기가 커지고 있는 시장에서 사용이 증가되고 있는 PostgreSQL을 자체적으로 추가 개선하여 세팅된 DB로 수동으로 스크립트를 작성하여 관리하던 PostgreSQL을 보다 편리하게 제공하고 있으며, disk 영역(스토리지)에서 데이터를 찾거나 변경할때 아마존 AWS 자체 스토리지 처리 기술을 적용하여 조금더 속도 개선을 진행한 기술로 간단히 이해하고 있다.

 장점으로는 AWS CLI를 통하여 미리 Slave 확장이나 자동화 처리(데이터 스냅샷)를 작성해 놓은 상태라면 언제든지 빠르게 서버를 확장할수 있으며 다양한 스펙의 장비를 선택하고 설정할 수 있다는 부분이 가장 큰 장점으로 보여진다.

 단점으로 아마존 AWS(클라우드)로 들어가게 되면 기존에 On-Premise 방식과는 다르게 DB의 구성 및 파라미터 세팅에 대한 제약이 발생되며, AWS 계약의 종류에 따라 갑자기 서버가 내려가거나 장애가 발생했을때 아무 원인이나 조치내역을 공유 받지 못한는 경우도 발생하는 것 같다.

 또한 긴급하게 대량으로 slave를 확장할 경우, AWS 서버를 할당 받는 zone에서 서버가 없는 경우가 있어 종종 지연이 발생되는 경우가 있으며, AWS -> AWS 안에서 데이터를 전송하는 것은 큰 문제가 없는데 AWS -> 외부 서버로 데이터를 전송 해야할 때 많은 비용이 증가하는 점이 있다.

 

[기본 정보]
- AWS Aurora(PostgreSQL) 11버전 지원, Master 1대당 Slave 15대 까지 가능
- RDS slave는 5대로 제한
 

1. AWS Aurora DB사용시 사용자기 임의로 파라미터를 수정가능 여부


Q. 파라미터를 사용자가 편하게 변경 가능한지
A. 변경 가능한 것도 있음, 기본적으로 cost 파라미터 등은 변경 가능하나 변경 불가사항도 존재함
 
    구조가 기본적으로 엑사와 비슷
    Application —> 분산하여 storage에 내려씀 (병렬)
    스토리지 노드는 6개
       
    장점 - shared node로 사용 가능 (스트림노드로 연결은 함, dirty block 때문에), writing 이 많은 서비스에 이득, CPU 사용율 기준으로 Auto - scale 가능
    단점 - CPU 를  20~30% 를 기본적으로 더 사용, 스토리지를 어플리케이션 레벨에서 병렬로 성능이 빠름

 

 

 

 

2.  AWS Aurora DB에서 Parallel 기능 사용 가능 여부

Q. Parallel  기능 여부
A. 버전 마다 달라서 확인 가능, 패러럴 작업시 스토리지 레벨까지 내려감 (특정 버전에서)
 

3. AWS Aurora DB에서 Vaccum동작에 따른 Slave 세션 끊김 없이 처리 가능한지 여부

Q. 슬래이브의 select 작업시 vaccum 이슈로 select 시 접속 fail

ERROR: canceling statement due to conflict with recovery

Detail: User query might have needed to see row versions that must be removed


A. 속도가 빠르고 CPU 작업이 빠르기 때문에 기존 대비하여 극단적으로 발생할 확률 축소
 

4. AWS Aurora DB에서 쓰기가 많은 서비스일때 어느정도까지 서비스에 무리가 없는지 문의

Q. Write 중심적인 서비스에서 DML가 많을 때의 이슈
A. 하루에 1억건 정도라면 크게 문제없음
 

5. AWS에서 발생되는 갑작스러운 서버 장애시 고객사에서 장애 원인과 조치내역에 대하여 공유 받을수 있는지 문의

Q. 서버 장애시 케이스(SR)가 공유가 가능한지
A. 계약이 필요한 사항, aurora에서는 슬래이브가 죽을 경우 스토리지를 사용해서 1분정도 안에 자동 재기동 가능

 

# Amazon AWS Aurora DB construction Q&A summary

# Resumen de preguntas y respuestas sobre la construcción de Amazon AWS Aurora DB

# Amazon AWS Aurora DB構築Q&Aまとめ

# Amazon AWS Aurora数据库构建问答

# अमेज़ॅन AWS अरोरा DB निर्माण क्यू एंड ए सारांश

블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,
   

1. MySQL hard/soft parse 

답)

1) mysql 5.7.19 에서 hard/soft parse에 대한 기능이 있는지 문의
 -  MySQL 은 ORACLE 에서 의미하는 hard/soft parse 에 대한 개념이 없습니다.
 -  모든 쿼리는 parse 단계 이후 (prepared statement 의 사용유무에 따라 다름), 실행계획을 세우는 단계를 모두 거친 후 실행이 됩니다.
    ○ MySQL 의 query cache 가 ORACLE 의 hard/soft parse 와 비슷한 기능 (parse 및 실행계획을 세우는 단계가 없이 결과를 바로 return) 을 가지고 있지만, MySQL 의 query cache 는 ORACLE 과 다르게 "결과값"도 저장하고 있어 완전히 다른 cache 임을 알려드립니다. MySQL query cache 는 테이블의 데이터가 한건이라도 변경되면 관련된 cache 를 모두 해제하게 됩니다.

2) mysql에서 쿼리 작성 시에 bind 변수 처리하여 작성하는 것과 static 변수로 작성하는 방법 간의 차이점이 있는지 문의
 -  쿼리는 일반적으로 MySQL 에 4가지 단계를 거치게 됩니다.
A) parsing
   SQL 구문을 문법에 맞게 분류하는 작업을 진행합니다. (SELECT, WHERE, GROUP BY...)
B) resolution
분류된 SQL 에 대한 정합성을 체크합니다. (관련 table 에 column 이 존재하는지에 대한 유무, subquery 혹은 join 되는 쿼리의 컬럼 정합성 체크)
C) optimization
실제 실행계획은 세우는 단계
D) execution
실제 쿼리가 실행되는 단계

위와 같은 과정에서, prepared statement (bind 변수 처리) 를 사용하신다면 A),B) 의 단계를 스킵할 수 있습니다.

 

2. MySQL 파티션 테이블 생성시 주의사항

답)
1) auto_increment 설정시, 주의사항 (복합 key를 사용할 경우)
     - InnoDB : 복합 primary key 생성시에 첫번째 컬럼으로만 사용 가능 
     - MyISAM : 복합 primary key 생성시에 두번째 컬럼으로도 사용 가능

2) virtual column 생성 및 주의사항
     - 아래와 같은 문법으로 테이블 생성시 사용 가능
     - virtual column으로 partition key로 잡아 사용할 수 없음
예)
 # `emp_dt` int(8) generated always as (DATE_FORMAT(emp_date, '%Y%m%d')) virtual
 #comment 'emp_dt 가상컬럼',

3) auto_increment + partition table 생성시, 주의사항
     - auto_increment 컬럼이 primary key의 첫번째로 오는 것이 기본
     - auto_increment 컬럼을 첫번째에 두지 않을 경우에는 key(인덱스)를 별도로 생성해서 테이블을 만들어야함

4) partiton table에서 date, datetime으로 partiton key를 잡을 경우, 주위사항
     -아래와 같이 2가지 형태로 사용이 가능
     -partition by range (to_days()) ~ partition emp values less than (to_days('2017-08-01 00:00:00')),..
     -partition by range columns () ~ partition emp values less than ('20170801'),..

 

3. MySQL metadata lock과 일반 lock의 차이관련

답)
 - 일반 잠금은 row level lock, table level lock 등
 - 메타 데이터 잠금은 DDL 문만 허용금지 (물리적 블록에 look을 거는 것이 아님)


4. MySQL 5.7.19 SQL HINT 사용

답)
 - use index (IX_EMP01)" 인덱스를 지정하는 hint(USE|FORCE|IGNORE Index)를 사용할 떄
 - 기존에 IX_EMP01 인덱스가 생성되어 있지 않으면 쿼리 수행시 error code: 1176(not exist)이 발생된다.


5. MySQL open_files_limit 파라미터 설정
(8.0.22-commercial MySQL Enterprise Server)

1) /etc/security/limits.conf

mysql hard nofile 65535
mysql soft nofile 65535

2)
[mysql_m:/mysql_data/tmp]$ulimit -Sn
65535
[mysql_m:/mysql_data/tmp]$ulimit -Hn
65535

3) my.cnf

[mysqld_safe]
open_files_limit = 8192

위와 같이 mysql 파라미터가 8192로 설정되어 있습니다.

해당 DB로 접근하여 조회해보면 65535으로 확인되는데
open_files_limit를 설정할 때 my.cnf 를 보고 세팅되지 않고 os 세팅을 기준으로 설정되는 것인지 문의드립니다.

mysql> show global variables like 'open%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 65535 |
+------------------+-------+

답)
-> root로 기동할 경우, my.cnf 에 적용된 값에 따라서 open_files_limit 값이 적용되나 아래의 조건을 따르게 됨
우선적으로는 my.cnf 에 명시된 값으로 설정되지만 그 값이 아래 조건보다 낮으면 아래 조건 중 큰 수로 설정이 됨 
- 10 + max_connections + (table_open_cache * 2)
- max_connections * 5
- open_files_limit value specified at startup, 5000 if none

-> mysql 유저로 기동할 경우 my.cnf 관계없이 OS설정값으로 설정됨(버그여부확인 필요)

 

#Oracle MySQL Q&A Summary (2020)

#Resumen de preguntas y respuestas de Oracle MySQL (2020)

#Oracle MySQL Q&Aまとめ(2020)

#Oracle MySQL问答摘要(2020)

#Oracle MySQL Q & A सारांश (2020)

블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,