ElasticSearch
강좌 추천 →: "Elasticsearch 전체 텍스트 검색 실습"(실습 영상)
MongoDB, Redis에 비하면 1년 뒤에 출시된 ES는 덜 알려졌을지 모르지만, 검색 엔진 분야에서 ES의 명성은 확실히 울려퍼지고 있습니다. 다른 고급 데이터베이스 제품과 비교할 때 ES는 훨씬 더 소박한 배경을 가지고 있습니다.
ES의 창시자 Shay Banon은 한때 실업자였던 프로그래머였습니다. 할 일이 없을 때 아내의 레시피 검색을 용이하게 하기 위해 ES를 만들었습니다(물론 당시에는 ES라고 불리지 않았습니다). 뜻밖에도, 의도하지 않은 개입으로 인해 오늘날 가장 인기 있는 검색 엔진 데이터베이스가 만들어졌습니다. 물론, 프로그래머가 일하는 가장 큰 동기는 여자입니다!
ES도 자체 Elastic 회사를 설립하여 수억 달러의 자금을 조달받았습니다. 당시 diaosi 프로그래머였던 Shay Banon은 이미 CEO가 되기 위해 반격하여 인생의 정점에 도달했습니다. 프로그래머 여러분, 이 이야기를 읽고 나면 이미 CEO가 되어 Bai Fumei와 결혼하는 날을 상상하기 시작하셨나요?
ES의 특징은 이름 그대로 검색입니다. 엄밀히 말하면 ES는 데이터베이스가 아니라 검색 엔진이며 ES의 모든 측면은 검색을 중심으로 설계되었습니다. ES는 전체 텍스트 검색을 지원합니다. 전체 텍스트 검색이 무엇인지 간략하게 설명하면 다음과 같습니다. "나는 베이징에 있는 인터넷 회사에서 근무합니다"와 같은 데이터에 대해 "베이징", "인터넷" 및 "인터넷"과 같은 키워드를 검색하면 다음과 같습니다. "일"을 치면 됩니다. 데이터가 있으면 이것이 전문 검색입니다. 매일 사용하는 바이두나 구글은 전문 검색입니다.
ES의 전체 텍스트 검색은 중국어에 대한 지원도 훌륭하다는 점을 언급할 가치가 있습니다(중국어 단어 분할기가 많이 있음). 이는 중국에 있는 대부분의 사람들의 전체 텍스트 검색 요구를 확실히 충족할 수 있습니다. 검색 외에도 ES는 고성능 복합 집계 쿼리를 달성하기 위해 모든 필드를 자동으로 인덱싱합니다. 따라서 데이터가 ES에 저장되어 있는 한 집계 쿼리가 아무리 복잡하더라도 좋은 성능을 얻을 수 있습니다. 더 이상 다양하고 복잡한 인덱스를 생성하는 방법에 대해 걱정할 필요가 없습니다.
ES의 장점을 많이 이야기하고 나니 ES가 거의 만능이라고 생각하시나요?
안타깝게도 ES에는 필드 유형을 수정할 수 없고 쓰기 성능이 낮으며 하드웨어 리소스 소비가 높다는 단점도 많이 있습니다. 앞서 언급했듯이 ES는 자동으로 인덱스를 생성합니다. 이는 전체 텍스트 검색 및 쿼리 집계에 많은 이점을 제공하고 인덱스 구축의 수고를 덜어줄 수 있지만 이 기능은 많은 문제를 가져오기도 합니다.
ES는 필드를 생성하기 전에 매핑을 미리 설정해야 합니다. 매핑에는 각 필드의 유형 정보가 포함되어 있습니다. ES는 매핑을 기반으로 필드에 적합한 인덱스를 설정해야 합니다. 이 매핑이 존재하기 때문에 ES의 필드 유형은 일단 생성되면 수정할 수 없습니다.
(예를 들어, 작성한 데이터 테이블의 필드에 전체 텍스트 검색을 추가하는 것을 잊었습니다. 임시로 추가하고 싶지만 테이블이 이미 작성되어 있고 많은 데이터가 있습니다. 어떻게 해야 합니까? 죄송합니다. 그냥 데이터 테이블 전체를 삭제하고 다시 빌드하면 됩니다!)
따라서 ES는 데이터 구조 유연성 측면에서 MySQL보다 높지만 MongoDB보다 훨씬 열등합니다. ES의 단점은 이에 국한되지 않습니다. 자동 인덱스 생성은 MongoDB에 비해 현저히 낮은 ES의 쓰기 성능에도 영향을 미칩니다.
동일한 데이터에 대해 ES가 차지하는 저장 공간은 MongoDB에 비해 훨씬 크고(공간을 차지하지 않고 이렇게 많은 인덱스를 구축할 수 있을까요?) 하드웨어 리소스 소모도 64G 메모리+SSD로 매우 높습니다. 기본적으로 대용량 데이터에 대한 표준입니다. 데이터베이스에서는 귀족적인 서비스라고 볼 수 있으므로 상사가 매우 인색한 경우 ES를 선택할 때 조심해야 합니다!
ES의 전체 텍스트 검색 기능은 검색 엔진 구축을 위한 강력한 도구입니다. 또한 ES는 복잡한 집계 쿼리를 매우 잘 지원하므로 ES는 데이터 분석에 매우 적합합니다.
사실 ES는 로그 수집부터 데이터 시각화 분석까지 원스톱 서비스를 제공하기 위해 특별히 자체 ELK 제품군도 만들었습니다. 이는 확실히 고급 데이터 분석 플랫폼을 구축하는 데 강력한 도구입니다.
그러나 ES의 높은 비용과 낮은 쓰기 성능이라는 단점도 데이터 값이 높지 않고 쓰기 성능이 요구되며 데이터 양이 크고 비용이 제한되는 시나리오에서는 사용하기에 부적합합니다.
Redis
Redis는 현재 가장 인기 있는 키-값 데이터베이스입니다. 2009년 MongoDB와 함께 출시되었으며 초기 빅데이터 시대의 데이터베이스 걸작이기도 합니다.
Redis의 가장 큰 특징은 물론 키-값 저장소가 제공하는 단순성과 고성능입니다. 소위 키-값 저장이란 테이블, 필드 등의 기존 데이터베이스 없이 각 레코드에 데이터 조회를 위한 키와 데이터 저장을 위한 해당 값만 포함되어 있음을 의미합니다. 에서는 모든 쿼리가 키 값에만 의존합니다.
그러므로 키-값 데이터베이스는 데이터베이스에서 가장 간단한 데이터 구조라고 할 수 있습니다. Redis는 모든 데이터를 메모리에 로드하므로 Redis는 읽기 및 쓰기 성능이 훨씬 뛰어납니다. 이러한 유형의 기존 데이터베이스 성능. 물론 Redis의 기능은 키-값 저장만큼 단순하지는 않습니다. 이전의 키-값 Memcached에 비해 Redis는 데이터 지속성, 목록 및 집합과 같은 다양한 데이터 구조, 마스터와 같은 일련의 기능도 지원합니다. -슬레이브 복제 및 백업 따라서 Redis는 확실히 가장 포괄적이고 사용하기 쉬운 키-값 데이터베이스입니다.
Redis의 키-값 스토리지는 성능 이점을 제공하지만 복잡한 쿼리에는 많은 제한 사항도 제공합니다. 데이터 테이블, 필드 등 중요한 기능이 제거되고, 모든 쿼리가 키에 의존하기 때문에 Redis는 기존 데이터베이스가 갖고 있는 다중 컬럼 쿼리, 섹션 쿼리 등 복잡한 쿼리 기능을 제공할 수 없습니다.
동시에 Redis는 데이터를 메모리에 저장해야 하기 때문에 Redis가 저장할 수 있는 데이터의 양도 크게 제한되며, 이는 또한 Redis가 대규모 데이터 규모의 애플리케이션 시나리오에서 사용하기 어렵다고 결정합니다.
Redis는 뛰어난 성능 향상을 위해 기존 데이터베이스의 데이터 테이블, 복잡한 쿼리 및 기타 기능을 희생했습니다. 특히 읽기 및 쓰기 성능에 대한 요구 사항이 매우 높고 간단한 데이터 테이블 구조(키-값, 목록)를 가진 사용자에게 적합합니다. , 설정 등), 쿼리 조건도 간단한 응용 시나리오입니다.
데이터 테이블 구조가 매우 복잡하고 복잡한 쿼리 작업을 자주 수행해야 하는 경우 MongoDB 또는 SQL을 사용하는 것이 좋습니다.
더 많은 Redis 관련 지식을 알고 싶으시면 Redis 사용법 튜토리얼 칼럼을 방문해 주세요!
위 내용은 es와 redis의 차이점의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!