Redis 튜토리얼(1): Redis 소개

1. 소개:

지난 몇 년간 NoSQL 데이터베이스는 높은 동시성, 대용량 데이터 저장 솔루션의 대명사가 되었고, 이에 상응하는 제품도 비가 내린 뒤 버섯처럼 솟아올랐습니다. 하지만 Redis, MongoDB, BerkeleyDB, CouchDB 등 많은 제품 중에서 눈에 띄는 제품은 소수에 불과합니다. 각 제품마다 특성이 다르기 때문에 적용 시나리오에도 특정 차이점이 있습니다.

1) BerkeleyDB는 매우 인기 있는 오픈 소스 임베디드 데이터베이스입니다. 예를 들어, BerkeleyDB는 Oracle에 인수되기 전에 MySQL의 스토리지 엔진으로 사용되었으며, 이 제품은 동시성 확장성이 뛰어나고 트랜잭션 및 중첩 트랜잭션을 지원하며 대용량 데이터를 저장하는 등 중요한 기능을 제공할 것으로 예상됩니다. 실시간 데이터 저장에 있어 활용 가치가 매우 높습니다. 그러나 이 제품의 라이센스는 GPL이므로 모든 경우에 무료로 사용할 수는 없다는 점을 지적해야 합니다.

2) MongoDB는 BerkeleyDB와 달리 Oriented-Document 데이터베이스 서버로 정의되며, 이 데이터베이스는 독립적으로 실행될 수 있으며 다른 관계형 데이터베이스 서버와 마찬가지로 관련 데이터 서비스를 제공합니다. 이 제품의 공식 문서를 통해 MongoDB가 주로 동시성이 높은 포럼이나 블로그 웹사이트에 적합하다는 것을 알 수 있습니다. 이러한 웹사이트의 주요 특징은 높은 동시 방문, 더 많은 읽기 및 더 적은 쓰기, 많은 양의 데이터, 단순한 논리적 관계입니다. 및 문서를 기본 데이터 소스로 사용합니다. BerkeleyDB와 마찬가지로 이 제품의 라이센스는 GPL입니다.

3) 일반적인 NoSQL 데이터베이스 서버인 Redis는 BerkeleyDB에 비해 서비스 프로그램으로 자체 서버 호스트에서 독립적으로 실행할 수 있습니다. 많은 사람들은 Redis를 키/값 데이터베이스 서버로 간주하지만 현재 버전에서는 Redis가 키/값 외에도 List, Hash, Set 및 Ordered Set과 같은 데이터 구조도 지원합니다. , 그래서 용도도 더 넓습니다. 이러한 오해에 대해 Redis 공식 웹사이트에서도 이에 상응하는 해명을 제공했습니다. 위의 두 제품과 다르게 Redis의 라이선스는 Apache 라이선스로 현재 완전 무료입니다.

4) memcached, 데이터 캐싱 서버. 이 제품에 대한 설명이 여기에 나와 있는 이유는 무엇입니까? 매우 간단합니다. 사용법 측면에서 Redis와 가장 유사하다고 생각하기 때문입니다. 결국 이것은 Redis에 대한 기술 블로그 시리즈이므로 이를 고려하여 이 두 제품을 간략하게 비교해 보겠습니다. 먼저, 이들 간의 가장 큰 차이점에 대해 말씀드리자면, Memcached는 데이터 캐싱 서비스만을 제공하며, 서버가 다운되면 이전에 메모리에 캐시되어 있던 데이터는 모두 사라지게 되므로 어떠한 형태의 캐싱도 제공하지 않는다는 것을 알 수 있습니다. 데이터 지속성 기능은 Redis가 제공하는 기능입니다. 또한 Redis는 Hash 및 Set과 같은 더욱 풍부한 데이터 저장 구조를 제공합니다. 유사점은 두 가지입니다. 하나는 완전히 무료라는 것이고, 다른 하나는 그들이 제공하는 명령 형식이 매우 유사하다는 것입니다.

2. Redis의 장점:

1) Redis는 다른 NoSQL 제품에 비해 사용이 매우 간편하므로 유사한 제품을 사용해 본 경험이 있는 개발자라면 Redis를 사용하여 다음 작업을 수행할 수 있습니다. 하루나 이틀, 심지어 몇 시간 안에 나만의 플랫폼을 구축하세요.
2) 많은 일반적인 문제를 해결하는 동시에 인덱싱 엔진, 통계 순위, 메시지 대기열 서비스 등과 같은 일부 개인화된 문제에 대한 관련 솔루션도 제공합니다.

3. 현재 버전의 Redis의 주요 문제점:

1) 정식 버전에서는 Windows 플랫폼 지원이 없으며, 출시된 정식 버전은 Unix 계열과 MacOSX만 지원합니다. 플랫폼.
2) 클러스터 지원은 제공되지 않으나, 공식 홈페이지에 따르면 이 기능은 버전 2.6에 추가될 예정이라고 합니다.
3) 발행/구독 기능에서는 마스터가 다운되면 슬레이브가 자동으로 마스터로 승격되지 않습니다.

4. 관계형 데이터베이스와의 비교:

Redis의 현재 버전(2.4.7)에서는 5가지 데이터 유형을 지원하며, 그 중 문자열 유형만 Key-Value 구조로 간주할 수 있고 다른 데이터 유형은 다음과 같습니다. 각각의 특성에 적용되는 애플리케이션 시나리오를 다루고 있으며, 이 시리즈의 후반부 블로그에서 구체적인 세부 사항을 설명할 것입니다.
관계형 데이터베이스에 비해 Redis는 상대적으로 단순한 저장 구조로 인해 복잡한 논리적 관계를 제대로 지원하지 못합니다. 그러나 Redis에 적용할 수 있는 시나리오에서는 이를 통해 효율성이 크게 향상됩니다. 그럼에도 불구하고 Redis는 동일한 연결에서 다른 데이터베이스를 열도록 선택할 수 있는 것과 같이 데이터베이스가 가져야 하는 몇 가지 기본 개념을 제공합니다. 그러나 차이점은 Redis의 데이터베이스 이름은 기본적으로 숫자로 지정된다는 것입니다. 열린 데이터베이스는 0입니다. 프로그램이 실행되는 동안 데이터베이스를 전환하려는 경우 Redis select 명령을 사용하여 select 1과 같은 다른 데이터베이스를 열 수 있습니다. 나중에 기본 데이터베이스로 다시 전환하려면 select 0을 실행하면 됩니다.
데이터 저장 측면에서 Redis는 기존 NoSQL 데이터베이스의 주류 아이디어를 따릅니다. 즉, Key는 데이터 검색을 위한 고유 식별자로 간단히 관계형 데이터베이스의 인덱스 키로 이해하면 됩니다. 값은 데이터 저장소로 사용됩니다. 기본 개체인 각 값에는 연결된 키가 있으며, 이는 인덱스의 물리적 데이터가 데이터 테이블에 저장되는 위치와 같습니다. Redis에서 Value는 Json, XML, 직렬화된 객체의 바이트 스트림 등 모든 형식의 데이터를 저장하는 데 사용되는 바이너리 바이트 스트림으로 간주되므로 RDB의 BLOB 유형 필드로 상상할 수도 있습니다. 데이터 쿼리를 수행할 때 쿼리 조건으로 Key만 사용할 수 있다는 것을 알 수 있습니다. 물론 Redis에서 제공하는 일부 기술을 적용하여 Value를 다른 데이터의 키로 사용할 수도 있습니다. 다음 블로그를 소개합니다.

5. 메모리 데이터를 유지하는 방법:

기본적으로 Redis는 현재 데이터베이스의 데이터 수정 횟수를 참조하고 특정 임계값에 도달하면 다음의 스냅샷을 저장합니다. 디스크의 데이터베이스에서는 구성 파일을 통해 임계값을 설정할 수 있습니다. 일반적으로 Redis가 정기적으로 저장하도록 설정할 수도 있습니다. 예를 들어 1,000개 이상의 주요 데이터가 수정되면 Redis는 60초마다 데이터 지속성 작업을 수행합니다. 기본 설정은 데이터 수정이 9개 이하인 경우 Redis가 15분마다 지속된다는 것입니다.
위에서 언급한 솔루션을 보면 이 방법을 채택하면 Redis의 런타임 효율성이 매우 효율적이라는 것을 알 수 있습니다. 새로운 데이터 수정이 발생할 때마다 메모리에 캐시된 데이터만 수정되며, 이러한 변경 사항은 디스크에 즉시 유지되지 않으므로 대부분의 수정 작업에서 디스크 IO가 방지됩니다. 그러나 상황에는 양면이 있는 경우가 많습니다. 이 방법을 사용하면 효율성은 향상되지만 데이터 신뢰성은 떨어집니다. 메모리 스냅샷이 디스크에 유지되기 전에 Redis가 위치한 서버가 다운되면 디스크에 기록되지 않은 수정된 데이터가 모두 손실됩니다. 데이터의 높은 신뢰성을 보장하기 위해 Redis는 또 다른 데이터 지속성 메커니즘인 추가 모드도 제공합니다. Redis 서버가 이러한 방식으로 구성되면 데이터 수정이 발생할 때마다 즉시 디스크에 유지됩니다.

위 내용은 Redis Tutorial(1): Redis 소개의 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!