분산 데이터베이스가 무엇인지 이해하는 방법-일반적인 문제-php.cn

분산 데이터베이스에는 다음이 포함됩니다. 1. 단일 노드 또는 여러 노드에 존재할 수 있는 Elasticsearch 데이터베이스 2. 풍부한 데이터 유형을 지원하는 Redis 데이터베이스 3. 보다 편리하게 데이터를 얻을 수 있는 Mongodb 데이터베이스 , 고가용성.

분산 데이터베이스가 무엇인지 이해하는 방법

분산 데이터베이스에는 다음이 포함됩니다.

1. Elasticsearch 데이터베이스

강좌 추천 →: "Elasticsearch 전체 텍스트 검색 실습"(실습 동영상)

강좌에서" 천만"급 데이터 동시성 솔루션(이론+실기)》

1. Elasticsearch 소개

분산 실시간 파일 저장, 각 필드를 색인화하여 검색 가능, 분산 실시간 분석 검색 엔진

확장 가능 수백 대의 서버로 PB 수준의 정형 또는 비정형 데이터 처리

2. Elasticsearch 응용 시나리오

분산 검색 엔진 및 데이터 분석 엔진, 전체 텍스트 검색, 정형 검색, 데이터 분석

대규모 데이터 처리 준실시간 처리 , 현장 검색(전자상거래, 채용, 포털 등), IT 시스템 검색(OA, CRM, ERP 등), 데이터 분석

3. Elasticsearch의 장점과 단점

단점: 사용자 인증이 없습니다. 그리고 권한 제어, 트랜잭션 개념이 없고 롤백이 지원되지 않으며 실수로 삭제한 경우 복원이 불가능하며 Java 환경이 필요합니다.

장점: 문서를 여러 컨테이너나 샤드로 분할하고 단일 노드 또는 샤드가 있을 수 있습니다. 다중 노드

각 샤드를 복사하면 하드웨어 문제로 인한 데이터 손실을 방지하기 위해 데이터 백업이 제공됩니다.节 획득한 데이터가 필요한 데이터인지 확인하기 위해 클러스터에 있는 모든 노드의 상호 요청을 라우팅합니다. 클러스터가 샤딩을 늘리거나 다시 할당하면 새 노드가 손실된 노드 조각 데이터를 복원할 수 있도록 멈추지 않습니다.

4.lasticsearch 지속 솔루션

gateway는 Elasticsearch 인덱스의 영구 저장 방식을 나타냅니다. 기본적으로 Elasticsearch는 인덱스를 먼저 메모리에 저장한 후 메모리가 가득 차면 하드 디스크에 지속시킵니다. Elasticsearch 클러스터가 종료되거나 다시 시작되면 게이트웨이에서 인덱스 데이터를 읽습니다. Elasticsearch는 로컬 파일 시스템(기본값), 분산 파일 시스템, Hadoop의 HDFS 및 Amazon의 S3 클라우드 스토리지 서비스를 포함한 다양한 유형의 게이트웨이를 지원합니다.

ElasticSearch는 먼저 인덱스 내용을 메모리에 저장한 다음 메모리가 부족할 때 인덱스를 하드 디스크에 유지합니다. 동시에 시스템이 부족할 때 인덱스를 하드 디스크에 자동으로 쓰는 대기열도 있습니다. 유휴 상태입니다.

2. Redis 데이터베이스

1. Redis 소개

redis는 문자열, 해시 구조, 연결 목록 및 집합을 저장하는 데 사용할 수 있는 오픈 소스 BSD 라이선스 고급 키-값 저장 시스템(NoSQL)입니다. 따라서 일반적으로 데이터 구조 서비스를 제공하기 위해 Redis는 데이터 지속성을 지원합니다. 데이터를 디스크에 저장하고 다시 시작할 때 사용할 수 있습니다. 간단한 키-값 유형 데이터를 지원하며 list, set, zset 및 hash와 같은 데이터 구조의 저장도 제공합니다. Redis는 데이터 백업, 즉 마스터-슬레이브 모드의 데이터 백업을 지원합니다.

2.Redis 적용 시나리오

A) 정기 계산: 팬 수, Weibo 수

B) 사용자 정보 변경

C) 캐시 처리, mysql 캐시

D) 우선 순위 대기열 시스템으로 구축된 대기열 시스템 , 로그 수집 시스템

3. Redis의 장점과 단점

장점:

(1) HashMap과 마찬가지로 데이터가 메모리에 저장되므로 속도가 빠릅니다. 검색 및 연산의 시간 복잡도가 O라는 것입니다. (1)

(2) 다양한 데이터 유형 지원, 문자열, 목록, 집합, 정렬된 집합 지원

(3) 트랜잭션 지원, 작업은 모두 원자성입니다. 소위 원자성은 데이터에 대한 모든 변경 사항이 있음을 의미합니다. 실행되거나 모두 실행되지 않습니다

(4) 풍부한 기능: 캐싱, 메시징, 키로 만료 시간 설정에 사용할 수 있으며 만료 후 자동으로 삭제됩니다.

단점:

(1) Redis에는 자동 기능이 없습니다. 내결함성 및 복구 기능, 호스트 및 슬레이브 시스템의 가동 중지 시간으로 인해 일부 프런트엔드 읽기 및 쓰기 요청이 실패할 수 있습니다. 복구하려면 머신이 다시 시작될 때까지 기다리거나 수동으로 프런트엔드 IP를 전환해야 합니다. 2) 호스트 시스템이 다운되었습니다. 일부 데이터가 다운타임 이전에 슬레이브 시스템에 동기화되지 못했습니다. IP를 전환하면 데이터 불일치 문제가 발생하여 시스템 가용성이 저하됩니다.

(3) Redis의 마스터-슬레이브 복제는 전체 복제를 채택합니다. 복제 프로세스 중에 호스트는 메모리 스냅샷을 만들기 위해 하위 프로세스를 포크하고 하위 프로세스를 복사합니다. 프로세스의 메모리 스냅샷은 파일로 저장되고 슬레이브에 전송됩니다. 호스트에 충분한 여유 메모리가 있는지 확인하세요. 스냅샷 파일이 크면 클러스터의 서비스 성능에 더 큰 영향을 미치게 되며, 슬레이브 머신이 클러스터에 새로 합류하거나 슬레이브 머신과 호스트 네트워크의 연결이 끊어졌다가 다시 연결될 때 복제 프로세스가 수행됩니다. , 네트워크 변동으로 인해 호스트와 호스트가 다시 연결될 수 있습니다. 슬레이브 시스템 간의 전체 데이터 복사는 실제 시스템 작동에 많은 문제를 야기합니다

(4) Redis는 온라인 확장을 지원하기 어렵습니다. 클러스터 용량이 상한에 도달하면 온라인 확장이 매우 복잡해집니다. 이 문제를 방지하려면 운영 및 유지 관리 담당자는 시스템이 온라인 상태가 될 때 충분한 공간이 있는지 확인해야 하며 이는 막대한 자원 낭비를 초래합니다.

4. Redis 지속성 솔루션

redis는 지속성을 위한 두 가지 방법을 제공합니다. 하나는 RDB 지속성(메모리에 있는 Reids의 데이터베이스 레코드를 주기적으로 디스크의 RDB 지속성으로 덤프하는 것임)이고, 다른 하나는 RDB 지속성입니다. AOF(append only file) 지속성(추가 방식으로 Reids의 작업 로그를 파일에 기록하는 것이 원칙).

RDB 지속성은 지정된 시간 간격 내에 메모리에 있는 데이터 세트의 스냅샷을 디스크에 쓰는 것을 의미합니다. 실제 작업 프로세스는 하위 프로세스를 포크하고 먼저 데이터 세트를 임시 파일에 쓴 다음 교체하는 것입니다. 쓰기가 성공한 후 파일은 바이너리 압축을 사용하여 저장됩니다.

3. MongoDB 데이터베이스

1. MongoDB 소개

MongoDB 자체는 비관계형 데이터베이스입니다. 각 레코드는 문서이고 각 문서는 키-값 쌍 집합으로 구성됩니다. MongoDB의 문서는 JSON 객체와 유사합니다. Document의 필드 값에는 다른 Document, 배열 등이 포함될 수 있습니다.

2.Mongodb 적용 시나리오

mongodb의 주요 목표는 키/값 저장 방식(고성능 및 높은 확장성 제공)과 기존 RDBMS 시스템(풍부한 기능) 간의 장점을 통합하여 연결하는 것입니다. 일체. Mongo는 다음과 같은 시나리오에 적합합니다:

a. 웹사이트 데이터: Mongo는 실시간 삽입, 업데이트 및 쿼리에 매우 적합하며 웹사이트의 실시간 데이터 저장에 필요한 복제 및 높은 확장성을 갖추고 있습니다.

b. 캐싱: mongo는 고성능으로 인해 정보 인프라의 캐싱 계층으로도 적합합니다. 시스템이 다시 시작된 후 mongo가 구축한 영구 캐시는 기본 데이터 소스가 과부하되는 것을 방지할 수 있습니다.

c. 큰 크기, 낮은 가치의 데이터: 기존 관계형 데이터베이스를 사용하여 일부 데이터를 저장하는 것이 더 비쌀 수 있습니다. 이전에는 많은 프로그래머가 저장을 위해 기존 파일을 선택하는 경우가 많았습니다.

d. 높은 확장성 시나리오: mongo는 수십 또는 수백 개의 서버로 구성된 데이터베이스에 매우 적합합니다.

e. 객체 및 JSON 데이터 저장에 사용: mongo의 BSON 데이터 형식은 문서 형식 저장 및 쿼리에 매우 적합합니다.

3. Mongodb의 장점과 단점

장점:

(1) 약한 일관성(최종 일관성), 이는 사용자 액세스 속도를 더 잘 보장할 수 있습니다.

(2) 문서 구조의 저장 방법으로 더 편리하게 데이터를 얻을 수 있습니다

(3) 내장 GridFS, 대용량 저장 지원

(4) 수천만 개의 문서 객체, 거의 10G의 데이터 사용 사례에서 인덱스 ID에 대한 쿼리는 mysql보다 느리지 않지만 비- 인덱스 필드의 쿼리는 전반적인 승리입니다.

단점:

(1) 지원하지 않음

(2) 너무 많은 공간을 차지하여 디스크 낭비가 발생함

(3) 독립 실행형 신뢰성이 상대적으로 낮음

(4) 많은 양의 데이터가 지속적으로 삽입, 쓰기 성능 변동이 심함

4. MongoDB의 지속성 솔루션/예외 처리

쓰기 작업이 수행되면 MongoDB는 정확한 디스크 위치와 변경된 바이트를 포함하는 저널을 생성합니다. 따라서 서버가 갑자기 충돌하는 경우 시작 시 저널은 충돌 전에 디스크에 플러시되지 않은 모든 쓰기 작업을 재생합니다.

데이터 파일은 기본적으로 60초마다 디스크에 플러시되므로 저널은 60초 이내에 작성된 데이터만 보관하면 됩니다. 저널은 이 목적을 위해 /data/db/journal에 _j.0, j.1 등의 이름을 가진 여러 개의 빈 파일을 미리 할당합니다.

MongoDB를 오랫동안 실행하면 저널 디렉터리에 _j.6217, _j.6218 및 _j.6219와 유사한 파일이 표시됩니다. 이 파일은 현재 저널 파일이며 MongoDB가 항상 실행 중이라면 이 숫자는 계속 증가합니다. MongoDB가 정상적으로 종료되면 이러한 로그가 더 이상 필요하지 않기 때문에 이러한 파일은 지워집니다.

서버가 충돌하거나 kill -9가 발생하면 mongodb가 다시 시작될 때 저널 파일이 재생되고 길고 이해하기 어려운 확인 라인이 출력되어 정상적인 복구를 나타냅니다.

4. Mysql 분산 클러스터

1. Mysql 분산 클러스터 소개

MySQL 클러스터는 무공유 분산 노드 아키텍처 스토리지 솔루션으로, 내결함성과 고성능을 제공하는 것을 목표로 합니다.

데이터 업데이트는 읽기 커밋 격리 수준을 사용하여 모든 노드의 데이터 일관성을 보장하고 2단계 커밋 메커니즘을 사용하여 모든 노드가 동일한 데이터를 갖도록 보장합니다(쓰기 작업이 실패하면 업데이트가 실패합니다).

비공유 피어 노드를 사용하면 한 서버의 업데이트 작업이 다른 서버에 즉시 표시됩니다. 업데이트 전파는 네트워크 전체에서 높은 처리량을 제공하도록 설계된 복잡한 통신 메커니즘을 사용합니다.

여러 MySQL 서버를 통해 로드를 분산하여 프로그램 성능을 극대화하고 데이터를 서로 다른 위치에 저장하여 고가용성과 중복성을 보장합니다.

2. Mysql 분산 클러스터 적용 시나리오

Jingdong B2B에서 사용하는 Mysql 분산 클러스터와 같은 대용량 저장 문제를 해결합니다.

수십억 PV의 DB 접근에 적합합니다.

3. Mysql 분산 클러스터의 장점과 단점

장점: