mongdb를 사용하여 어떤 애플리케이션 시나리오를 고려해야 합니까?

Mysql과 redis는 어떤 상황에서 이러한 도구를 버리고 데이터를 저장하기 위해 mongo를 사용하는 것을 고려해야 합니까?

추가:
현재 기사 유형 데이터의 저장을 탐색 중입니다. 검색 도구에 의한 콘텐츠 검색 기능을 파괴하지 않고 기사 콘텐츠의 스타일을 저장해야 합니다. 좋은 방안은 데이터베이스의 특성과 비교에 대한 정보를 반드시 사전에 확인하도록 하므로 단순히 데이터베이스의 특성을 비교하는 것이 아니라 실제 전투와 경험에 대한 답변이 편향되어 있을 수 있습니다.

저는 Mysql과 Redis를 사용하여 매일 수백만 건의 주문이 있는 APP 백엔드 작업을 해왔습니다. MySQL과 Redis는 일반적인 문제를 지원할 수 있습니다. Mongo가 유연한 데이터 유형을 사용하도록 강요하거나 권장하는 이유나 시나리오가 있습니까? 저장에 관해서는 현재 mongo가 로그 저장에 더 좋다고 생각합니다. 저는 기사형 웹사이트를 개발하는 초보자이므로 경험과 지도가 필요합니다. 미리 감사드립니다

답글 내용:

Mysql과 redis는 어떤 상황에서 이러한 도구를 버리고 데이터를 저장하기 위해 mongo를 사용하는 것을 고려해야 합니까?

추가:
현재 기사 유형 데이터의 저장을 탐색 중입니다. 검색 도구에 의한 콘텐츠 검색 기능을 파괴하지 않고 기사 콘텐츠의 스타일을 저장해야 합니다. 좋은 방안은 데이터베이스의 특성과 비교에 대한 정보를 반드시 사전에 확인하도록 하므로 단순히 데이터베이스의 특성을 비교하는 것이 아니라 실제 전투와 경험에 대한 답변이 편향되어 있을 수 있습니다.

저는 Mysql과 Redis를 사용하여 매일 수백만 건의 주문이 있는 APP 백엔드 작업을 해왔습니다. MySQL과 Redis는 일반적인 문제를 지원할 수 있습니다. Mongo가 유연한 데이터 유형을 사용하도록 강요하거나 권장하는 이유나 시나리오가 있습니까? 저장에 관해서는 현재 mongo가 로그 저장에 더 좋다고 생각합니다. 저는 기사형 웹사이트를 개발하는 초보자이므로 경험과 지도가 필요합니다. 미리 감사드립니다

적절한 사용법을 하나씩 나열하기는 매우 어려울 것 같습니다...

역으로 생각해보면, mangodb를 사용하기에 적합하지 않은 시나리오는 무엇인가요?

우리는 사용자 개인 센터를 가지고 있습니다:
사용자는 많은 친구를 가질 수 있고, 친구는 많은 메시지를 가질 수 있으며, 메시지는 많은 답장을 가질 수 있고, 메시지는 많은 좋아요를 가질 수 있습니다

mongodb를 사용하여 모델링하면 사용자가 있는 큰 json이고 사용자는 친구 배열, 메시지 배열, 답장 배열 및 좋아요 사용자 배열을 갖습니다. 조회 가능한 완전한 정보를 저장하세요. 모든 정보를 한 번에 받아보세요!

그러나 문제가 발생합니다
friend 배열의 친구 정보는 실제로는 사용자 정보이기 때문에 전체 정보를 저장하면 데이터 중복이 발생하므로 이 문제는 쉽게 해결할 수 있습니다. 즉, 배열에 id를 저장하면 됩니다. 그리고 ID에 따라 해당 데이터 소스의 데이터를 확인하세요.

그러나 mongodb에는 Join 연산이 없기 때문에 코드 레이어에서 Association 작업을 수동으로 해야 하는데, 이는 매우...

mongodb는 관계, 관계, 관계가 있는 데이터를 저장하는 데 적합하지 않은 것 같습니다.

MongoDB를 절대 사용하면 안되는 이유