가을 채용 준비 - 데이터베이스

두 개의 데이터베이스

관계형 데이터베이스: MySQL, SQL Server, Oracle은 테이블에 저장됩니다.

비관계형 데이터베이스: MongoDB 및 Redis는 키-값 쌍으로 저장됩니다.

일반적으로 사용되는 자물쇠는 무엇입니까?

뮤텍스 잠금, 스핀 잠금, 읽기-쓰기 잠금, 낙관적 잠금, 비관적 잠금

세 가지 패러다임

제1정규형: 테이블의 각 열이 분할할 수 없는 원자 데이터여야 합니다.

두 번째 패러다임: 테이블의 각 열이 기본 키(복합 기본 키의 경우)에 완전히 종속되도록 요구하는 부분 종속성을 제거합니다. 즉, 기본 키의 일부에만 관련된 열이 없습니다.

세 번째 패러다임: 테이블의 각 열이 기본 키에 간접적으로 종속되지 않고 직접 종속되도록 요구하는 전이적 종속성을 제거합니다.

데이터베이스의 낙관적 및 비관적 잠금

비관적 잠금:

①Pessimistic lock은 항상 데이터가 다른 스레드에 의해 수정될 것이라고 생각하여 수정 전에 강제로 잠그므로 다른 스레드는 차단되고 대기하며 배타적이고 배타적인 특성이 강합니다.

② 전통적인 관계형 데이터베이스의 행 잠금, 테이블 잠금, 읽기 잠금, 쓰기 잠금 등은 물론 Java의 동기화 키워드는 모두 비관적 잠금의 구현입니다.

③ 비관적 잠금은 더 많은 쓰기가 읽고 더 적은 읽기(다중 쓰기 시나리오) 상황에 더 적합합니다.

비관적 잠금은 실제로 데이터 보안을 보장하는 "접근하기 전에 잠금을 해제"하는 보수적인 전략입니다.

낙관적 잠금:

① 낙관적 잠금은 일반적으로 데이터가 다른 스레드에 의해 수정되지 않으므로 수정 전에는 잠기지 않고 업데이트를 위해 데이터를 제출할 때 데이터 충돌 여부를 정식으로 감지합니다. 사용자에게 오류 메시지를 반환하고 사용자가 수행할 작업을 결정하도록 합니다.

② 낙관적 잠금은 데이터베이스 자체의 잠금 메커니즘을 의도적으로 사용하지 않고 버전 번호 필드, 타임스탬프, AtomicInteger 클래스의 CAS(비교 및 교환) 및 MySQL에서 InnoDB의 MVCC(다중 버전 제어) 메커니즘은 모두 낙관적 잠금의 구현입니다.

③ 낙관적 잠금은 읽기가 많고 쓰기가 적은 상황(더 많은 읽기 시나리오)에 더 적합합니다.

MySQL에서 명령문의 느린 쿼리에 대한 이유는 무엇입니까?

이유:

① 불충분한 컴퓨터 시스템 메모리;

② 네트워크가 갑자기 느려집니다.

③ 작성된 SQL 문은 최적의 솔루션이 아닙니다.

해결 방법: 둘이 하나보다 빠르고 Accurate가 전체 테이블보다 빠릅니다. 인덱스를 구축합니다.

Redis의 5가지 기본 유형

문자열 문자열, 목록 목록, 해시 해시(값 자체는 키-값 쌍임), 세트 컬렉션, zset 순서 컬렉션.

Redis의 두 가지 지속성 방법

1. RDB는 데이터베이스의 데이터를 정기적으로 스냅샷 형태로 디스크에 저장하고 이를 rdb에 저장하며 시작 시 자동으로 rdb 파일을 로드하여 지속성 요구 사항을 충족하며, 데이터 복구가 빠르다는 장점이 있지만 단점은 스토리지는 실시간으로 생성되지 않습니다. 설정한 시간 안에 저장됩니다.

2. AOF는 모든 작업을 파일에 기록하며, redis가 다시 시작되면 AOF 파일의 모든 작업을 실행하여 데이터 복구를 보장합니다. 전원을 켜야 하고 설정도 해야 하는데 장점은 쓴 데이터가 손실되지 않는다는 점이며 단점은 대용량 파일, 높은 에너지 소비, 빠른 데이터 복구 및 더 많은 중복성입니다.

Redis의 기본 지속성 방법은 RDB입니다.

Redis에서 전략 삭제

주로 세 가지 삭제 전략이 있습니다.

(1) 정기적인 삭제(공간을 위한 시간)
(2) 지연 삭제(메모리 사용량이 많음, 시간을 위한 공간)
(3) 정기적인 삭제(무작위 정리 및 삭제, 앞의 둘의 조합)

ACID의 4가지 특징

1. 원자성 : 원자성은 트랜잭션이 분할할 수 없는 작업 단위이며 트랜잭션의 모든 작업이 발생하거나 전혀 발생하지 않음을 의미합니다.

2. 일관성 : 데이터베이스는 항상 하나의 일관된 상태에서 다른 상태로 이동합니다. 일관성은 시스템이 세 번째와 네 번째 문 실행 사이에 충돌하더라도 트랜잭션이 결국 커밋되지 않고 모든 트랜잭션에서 수정된 내용이 저장되지 않기 때문에 이전에 실행된 첫 번째와 두 번째 문이 적용되지 않도록 합니다. 데이터베이스에.

3. 격리 : 트랜잭션 실행이 다른 트랜잭션을 방해할 수 없습니다. 즉, 트랜잭션 내에서 사용되는 작업 및 데이터는 다른 동시 트랜잭션과 격리되며 동시에 실행되는 트랜잭션은 서로 간섭할 수 없습니다.

4. 지속성 : 트랜잭션이 커밋되면 데이터베이스의 데이터에 대한 변경 사항은 영구적이어야 합니다. 이후의 다른 작업이나 실패는 실행 결과에 영향을 미치지 않아야 합니다.

트랜잭션을 위한 4가지 격리 수준

1. 직렬화: 격리 수준이 직렬화인 경우 사용자는 현재 트랜잭션을 순차적으로 실행합니다. 이 격리 수준은 트랜잭션 간의 최대 격리를 제공합니다.

2. 반복 읽기: 이 격리 수준에서는 트랜잭션이 시퀀스로 처리되지 않습니다. 그러나 현재 실행 중인 트랜잭션의 변경 사항은 외부에서 볼 수 없습니다. 즉, 사용자가 다른 트랜잭션에서 동일한 SELECT 문을 여러 번 실행하면 결과는 항상 동일합니다. (실행 중인 트랜잭션에서 발생하는 데이터 변경 사항은 외부에서 볼 수 없기 때문입니다.)

3. 읽기 커밋: READ COMMITTED 격리 수준은 REPEATABLE READ 격리 수준보다 덜 안전합니다.
   READ COMMITTED 수준 의 트랜잭션은 다른 트랜잭션에 의해 수정된 데이터를 볼 수 있습니다. 즉, 트랜잭션 처리 중에 다른 트랜잭션이 해당 테이블을 수정하면 동일한 트랜잭션에 대해 여러 SELECT 문이 다른 결과를 반환할 수 있습니다. "더러운 읽기"를 유발하기 쉽습니다.

4. 커밋되지 않은 읽기: READ UNCOMMITTED는 트랜잭션 간에 최소한의 격리를 제공합니다. 팬텀 읽기 작업과 반복 불가능한 읽기 작업이 발생하기 쉬운 것 외에도 이 격리 수준의 트랜잭션은 다른 트랜잭션에서 커밋되지 않은 데이터를 읽을 수 있습니다. 이 트랜잭션이 다른 트랜잭션의 커밋되지 않은 변경 사항을 계산의 기준으로 사용하는 경우 커밋되지 않은 커밋된 변경 사항은 상위 트랜잭션에 의해 실행 취소되어 많은 데이터 변경이 발생합니다.

클러스터형 인덱스와 비클러스터형 인덱스의 차이점

1. 클러스터형 인덱스

별도의 인덱스 타입이 아닌 데이터 저장 방식입니다. 테이블에 클러스터형 인덱스가 있는 경우 테이블의 데이터 행은 인덱스 트리의 리프 페이지에 저장됩니다. 서로 다른 두 위치에 데이터 행을 배치하는 것은 불가능하므로 테이블에 하나의 클러스터형 인덱스만 허용됩니다. InnoDB의 클러스터형 인덱스는 실제로 동일한 B-Tree에 인덱스와 데이터를 저장합니다. InnoDB는 기본 키를 통해 데이터를 집계합니다. 기본 키가 정의되어 있지 않으면 InnoDB는 비어 있지 않은 고유한 인덱스를 대신 선택합니다. 그러한 인덱스가 없으면 InnoDB는 묵시적으로 기본 키를 클러스터형 인덱스로 정의합니다.

2. 클러스터되지 않은 인덱스

보조 인덱스라고도 합니다. 보조 인덱스의 리프 노드에 저장되는 것은 행에 대한 물리적 포인터가 아니라 행의 기본 키 값입니다. 보조 인덱스를 통해 행을 조회할 때 스토리지 엔진은 보조 인덱스에서 해당 리프 노드를 찾고 해당 행의 기본 키 값을 얻은 다음 기본 키를 사용하여 클러스터형 인덱스에서 데이터 행을 찾아야 합니다. 두 개의 B-Tree 조회가 필요합니다.

왼쪽 조인 및 오른쪽 조인

Left Join: LEFT JOIN의 왼쪽 테이블에 있는 모든 데이터를 체크 아웃하고, 오른쪽 데이터는 ON 이후에 적격한 데이터만 체크 아웃하고, 비호환 데이터는 NULL로 대체합니다.

내부 조인: 왼쪽 조인과 오른쪽 조인의 병합과 동일하며 NULL을 포함하는 모든 데이터 행을 제거하고 나머지는 쿼리된 데이터입니다. 사실 양쪽의 테이블이 조건을 충족해야 합니다.

메시지 큐

카프카

장점: 처리량이 매우 크고 성능이 매우 우수하며 클러스터의 가용성이 높습니다.

단점: 데이터 손실, 단일 기능

사용 시나리오: 로그 분석, 빅 데이터 수집

토끼MQ

장점: 높은 메시지 신뢰성 및 포괄적인 기능.

단점: 처리량이 상대적으로 낮고 메시지가 누적되면 성능에 심각한 영향을 미칩니다. Erlang 언어는 사용자 정의하기가 쉽지 않습니다.

사용 시나리오: 소규모 시나리오.

RocketMQ(알리바바 제품)

장점: 높은 처리량, 고성능, 고가용성 및 매우 포괄적인 기능.

단점: 오픈 소스 버전의 기능은 클라우드의 상용 버전만큼 좋지 않습니다. 공식 문서와 주변 생태계가 충분히 성숙하지 않았습니다. 클라이언트는 자바만 지원합니다.

시나리오 사용: 거의 모든 시나리오.

리눅스에 대한 친숙함

이 수업을 수강한 후 시스템을 설치하고 몇 가지 간단한 명령, 다중 사용자 및 다중 작업 운영 체제를 알고 있습니다.