Drupal에서 MySQL, PostGRE SQL 또는 MSSQL에 비해 NoSQL (예 : MongoDB)을 실행하면 어떤 이점이 있습니까? 단순히 스토리지를 사용함으로써 얻을 수있는 이점이 있습니까? 아니면 일부 Drupal 구성을 변경해야합니까?
답변
MongoDB를 사용하면 대부분 또는 모든 엔티티를 문서 중심의 빠른 스토리지에 저장할 수 있습니다. 이러한 유형의 스토리지는 Drupal 코어에있는 표준 SQL 기반 스토리지 ( “필드 당 하나의 테이블”스키마를 기반으로 함)보다 훨씬 확장 성이 뛰어납니다.
Drupal 7의 현재 상태는 다음과 같습니다.
- SQL에 저장된 엔티티의 기본 테이블 (예 : users 테이블, node 테이블 등)
- SQL에 저장된 모든 필드
- 기본 테이블의 엔티티 속성이 MongoDB에 복제되었습니다.
이를 통해 MongoDB의 엔티티에 대한 빠른 쿼리와 Opensource SQL 데이터베이스가 지원하지 않는 복잡한 인덱스를 추가 할 수 있습니다 (테이블 간 인덱스 포함). 동시에 엔터티의 기본 테이블은 여전히 SQL에 저장되므로 여전히 SQL 전용 (예 : 플래그) 인 모듈에 의해 조인 될 수 있으므로 상호 운용성을 잃지 않습니다.
이러한 유형의 빠른 쿼리는 엔터티, 해당 속성 및 필드에 대한 추상적 인 방식으로 쿼리를 작성하는 방법 인 EntityFieldQuery 메커니즘 덕분에 사용할 수 있습니다. 코어의 기본 구현은 이러한 쿼리를 SQL로 변환하지만 MongoDB 모듈에는 MongoDB의 해당 쿼리를 직접 충족시킬 수있는 모든 기능을 갖춘 구현이 있습니다.
뷰 에 대한 EntityFieldQuery 백엔드 덕분에 익숙한 도구를 사용하여이 기능을 쉽게 활용할 수 있습니다. 유일한 단점은 관계가 지원되지 않는다는 것입니다 (그러나 실제로는 관계가 거의 필요하지 않습니다. 추가 데이터를 엔티티 객체로 푸시하고 엔티티의 추가 속성으로 노출시켜 추가하면 해결할 수 있습니다).
요컨대, 쿼리 성능이 프로젝트에서 문제가되는 즉시 중요한 데이터 세트를 갖 자마자 발생합니다 (예를 들어 주어진 엔티티 유형의 수만 개 엔티티에서 시작한다고 가정 해 봅시다) MongoDB는 순이익입니다 아주 적은 단점. 추천.
답변
MongoDB 등은 비교적 유연한 방식으로 구조적 (계층 적) 데이터를 저장하도록 설계되었습니다.
예를 들어에서 Drupal 7를 사용할 때 field_sql_storage모든 필드는 자체 테이블을 가져옵니다. 컨텐츠 유형에 10 개의 필드를 첨부하면 데이터베이스에 10 개의 테이블이 생깁니다. 해당 노드를로드하면 field_sql_storage필드 및 노드 당 (또는를 사용하는 경우 여러 노드) 쿼리를 실행합니다 node_load_multiple.
mongodb_field_storage 를 사용 하면 노드의 모든 필드를 단일 문서에 저장하고 단일 쿼리를 얻을 수 있습니다.
또한 감시, 세션, 캐시, 블록과 같은 다른 것을 MongoDB에 저장할 수 있습니다 .
그러나 여전히 MySQL이 필요하지만 MongoDB 는이를 대체하지 않습니다 (특정 부분 만 해당).
또 다른 장점은 MongoDB 를 사용하여 확장 하는 것이 더 쉽다 는 것입니다. 클러스터에 많은 서버를 추가하여 서버간에 데이터를 공유 할 수 있습니다.
답변
장점은 단점이 있습니다.
Drupal은 전체적으로 MongoDb로 전환 할 수 없으므로 두 데이터베이스를 지원하고 서로 잘 작동하는지 확인해야합니다.
많은 모듈이 mongodb와 함께 작동 할 수 없으므로 상호 운용성을 잃게됩니다.
시스템의 일부가 요청 수 또는 데이터 양에 대처하지 못하는 등 긴급한 요구가 없다면 전환하지 않을 것입니다. 한계에 다 다르기 시작하더라도 문제가 발생했을 때 하드웨어를 던지거나 전환하기 전에 튜닝하는 것을보십시오.
나는 전에 이것을 대답했다고 생각했는데, SO 에는 거의 중복이있다 .