언제 문서 대 관계형 대 그래프 데이터베이스를 사용해야합니까? [닫은]

토론을 위해 FourSquare 시나리오를 고려해 봅시다.

대본

엔티티 :

사용자
장소

관계 :

체크인 : 사용자 <-> 장소, 다 대다
친구 : 사용자 <-> 사용자, 다 대다

데이터베이스 디자인

이것들은 대부분 오류가있을 것입니다, 지적하십시오.

RDBMS

테이블 :

사용자
장소
체크인 (접합)
친구 (정션)

장점 :

CAP : 일관성, 가용성

단점 :

CAP : 분할 공차, 일명 샤딩
계획 = 융통성없는 구조
불량 복제?

그래프

사물:

사용자
장소

가장자리 :

친구 : 사용자 <-> 사용자
체크인 : 사용자-> 장소
- 타임 스탬프 포함

장점 :

CAP : 일관성, 가용성?
스키마가없고 쉽게 변경 가능한 객체와 가장자리
예를 들어 그래프 순회 쿼리
- 클러스터링
  - 친구 그룹 찾기
  - 비슷한 사람들이 좋아하는 음식점 찾기
- 다른 일반적인 / 유용한 쿼리가 있습니까?

단점 :

CAP : 파티션 공차?

문서 / 개체

3 개의 별도 데이터베이스?

사용자
- 친구 목록
체크인
- 타임 스탬프
- 사용자
- 장소
장소

장점 :

CAP : 가용성, 파티션 공차
스키마가없고 쉽게 변경 가능한 객체

단점 :

CAP : 일관성

질문

기록을 위해 그들은 MongoDB를 사용했습니다. 위의 모든 물음표 외에 :

문서 데이터베이스를 구현하는 방법을 잘 모르겠습니다.
문서 데이터베이스는 어떻게 파티션 허용 오차를 얻습니까?
단일 사용자의 체크인을 얻으려면 작업이 모든 체크인을 구문 분석하고 사용자 이름 (맵 + 필터)의 메타 데이터를 필터링한다고 가정합니다. 각 사용자에 대해 1,000,000 개 이상의 문서를 구문 분석하는 성능은 끔찍합니다. 이것이 올바른 행동이 아니라고 생각합니까?
다른 어떤 장단점이 있습니까?

— 무게
소스

(1) 비즈니스 용어로 두 테이블 사이의 현실을 설명해야합니다. 병렬 관계가있을 수 있기 때문입니다. 예를 들어, 사용자 <-> 사용자는 1mm 관계를 의미하지 않습니다. 예를 들면 : 사용자는 다른 사용자를 좋아하고 다른 사용자를 미워합니다. 이들은 두 가지 관계입니다. (2) '정확하게'원하는 것을 요약하면 도움이 될 것입니다.

— NoChance

@ EmmadKareem : (1) 시나리오를 복잡하게 만들고 싶지 않습니다. 내가 관심이있는 유일한 사용자 <-> 사용자 관계는 상호 관계이며 이는 많은 관계입니다. (2) 게시물 하단에 나열된 4 가지 질문에 답변하고 싶습니다.

— 23:52에

한 학기 동안의 대학 과정 주제가 될 수 있습니다. 관리 가능한 덩어리로 분류해야합니다. 따라서, 나는 단지 부분적인 답을 버리겠다.

사용할 데이터베이스 종류를 결정할 때 가장 먼저 고려해야 할 사항 중 하나는 어떤 종류의 쿼리를 실행할지 그리고 데이터베이스를 만들기 전에 모든 쿼리를 알고 있는지 여부입니다. SQL 데이터베이스는 데이터베이스의 모든 데이터에 대해 강력하고 유연한 쿼리라는 이점이 있습니다. 그래프 데이터베이스에는 그래프 데이터에 가장 적합하고 그래프 데이터가 아닌 데이터에는 실제로 좋지 않은 쿼리 기능이 있습니다 (그래프 데이터베이스는 SQL 데이터베이스의 구성 요소 일 수 있음). NoSQL 데이터베이스는 데이터를 검색하고 작동하는 기능이 훨씬 제한되어 있습니다.

다음은 ACID 속성에 대한 느낌입니다 : 원 자성, 일관성, 격리 및 내구성. SQL 데이터베이스는 모든 4에 대해 강력한 보증을 제공합니다. NoSQL 데이터베이스는 일반적으로 4 개를 모두 약속하지는 않으며, 데이터베이스를 떠나는 방법은 다양한 NoSQL 데이터베이스 구현을 차별화하는 주요 차이점 중 하나입니다. 반면, 파티션에 대해서는 일관성 및 가용성을 보장 할 수 없으므로 ( Brewer 's CAP thorem 참조) 파티션 에 대해 전체 가용성을 주장하는 경우 SQL 데이터베이스가 수행되지 않습니다. 개인적으로, 나는 0.0001 %의 데이터 손실이 용납 될 수없고 데이터 세트가 작기 때문에 파티션에 대해 걱정할 필요가없는 데이터로 작업하기 때문에 데이터베이스의 데이터 내구성에 많은 관심을 기울입니다. SQL 데이터베이스를 선호합니다.

서버 코드의 품질, 데이터베이스 관리자 및 프로그래머의 가용성, 발생하는 문제에 대한 지원 품질, 응용 프로그램을 데이터베이스에 연결하기위한 인터페이스 라이브러리의 품질 및 기타 등등을 고려해야합니다. MySQL은 거의 20 년 동안 존재 해 왔으며, 대부분의 버그가 해결되었으며, 매우 널리 사용되고 있으며, 직원의 뛰어난 지원과 가용성을 모두 갖추고 있으며, 향후 10 년 동안 지원 될 것입니다. 당신은 Riak에 대해 그런 말을 할 수 없습니다.

Google은 실제로 NoSQL 데이터베이스를 개발하여 전 세계 웹의 캐시 및 색인 버전을 저장할 수 있지만 여전히 MySQL을 사용합니다.

— 올드 프로
소스

나는 많이 묻는다는 것을 알고 있으므로 일반적인 대답은 좋을 것입니다. 핵심 질문은 다음과 같습니다. (1) 레인지 샤딩을 사용하여 로직에서 수평 샤딩을 구현할 수있는 경우 왜 샤딩을 위해 문서 데이터베이스를 사용해야합니까? (2) FourSquare 시나리오에서 사용할 문서 데이터베이스를 어떻게 설계하고 일반적인 용도 (사용자의 체크인 표시, 사용자의 친구 표시, 현재 체크인 한 장소의 사용자 표시)를 어떻게 처리합니까?

— wting

@William, Google을 통해 쉽게 액세스 할 수있는 수십 가지 기사가 있습니다. 여러 개의 스택 오버플로 만으로도 가능합니다. 너의 숙제를해라.

— Old Pro