기존의 관계형 데이터베이스에 비해 MongoDB는 비관계형 데이터베이스의 대표주자 중 하나입니다. MongoDB를 언제 사용해야 하는지 알려면 먼저 MongoDB가 어떤 기능을 가지고 있는지, 무엇을 할 수 있고 무엇을 할 수 없는지 알고, 구체적인 상황에 따라 사용할지 여부를 결정해야 합니다. MongoDB의 가장 중요한 기능을 나열하고 거의 모든 다른 기능이 이러한 기능을 중심으로 돌아가는 공식 문서의 소개 부분을 먼저 읽는 것이 좋습니다. 이러한 기능은 MongoDB 채택 여부를 결정하는 주요 요소인 경우가 많습니다. 선택 방법을 간략하고 대략적으로 소개한 글입니다. 그러나 기술이 발전하면서 소위 "관계형"과 "비관계형" 사이의 경계가 점점 모호해지고 있습니다. 한편으로는 Postgre, MySQL과 같은 전통적인 RDBMS가 비관계형을 지원하기 시작했습니다. 한편, JSON과 같은 관계형 모델도 MongoDB JOIN이 지원되기 시작했고, 앞으로는 트랜잭션까지 지원될 예정입니다. 이제는 경계가 모호해져서 언제 어떤 기술을 쓸지 일반화할 수 없게 되면서 이것저것 쓸 수 있다는 비교 결과가 나오는 경우가 많습니다. 그러나 프로젝트에 특정 기술을 사용하면 실제로 얻을 수 있는 것과 잃는 것이 무엇인지 비교할 수 있으며, 얻은 부분이 손실된 부분을 보완할 수 있는지 여부를 따져보고 최종적으로 이 기술을 채택할지 여부를 결정할 수 있습니다.
데이터 구조가 확실하지 않은 경우 mongodb를 사용하는 것이 가장 좋습니다. 예를 들어 SQL 데이터베이스에서는 모든 필드의 유형, 이름, 길이 등을 먼저 정의해야 합니다. mongodb에서는 유연성이 부족합니다. 특정 분야에는 존재하지 않는데, 그냥 없는 척 하세요.
예를 들어 서버가 시스템 이벤트를 데이터베이스에 저장하려고 한다고 가정해 보겠습니다. 특정 사용자가 어떤 작업을 수행할 때 쿼리를 위해 보낸 게시물의 원래 본문 내용을 기록해야 하는 경우도 있고 그렇지 않은 경우도 있습니다. 그런 다음 게시물 내용을 기록할 필요가 없는 경우 SQL에 문자열을 정의하면 됩니다. 길이가 1000이면 이 공간이 낭비되지만 mongodb는 그렇지 않습니다. 그리고 이 레코드를 가져올 때 SQL 데이터베이스는 필드 중 하나가 비어 있어도 정의한 구조를 반환하고 mongodb는 저장할 때 빈 필드를 포함하지 않으며 가져올 때에도 같은 일이 발생하지 않습니다.
또한 mongodb는 다양한 json 구조를 매우 잘 지원합니다. 물론 이것이 mongodb를 사용하는 주요 목적이 되어서는 안 됩니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
예를 들어보세요:
mysql: 테이블에 5개의 필드가 있습니다. 프로그램이 작성된 다음 여기에 두 개의 필드를 추가해야 하므로 먼저 데이터베이스로 이동하여 테이블 구조를 수정하고 필드를 추가한 다음 SQL 코드를 수정하는 프로그램입니다.
mongodb: 객체에는 5개의 속성이 있습니다. 프로그램이 작성되었습니다. 그런 다음 여기에 두 개의 속성(필드)을 추가하면 됩니다.
관계형 데이터베이스에서 레코드는 행이고, 필드는 열이며, 데이터는 행과 열의 교차점에 있습니다. 여러 행과 열은 동일한 2차원 구조를 따라야 합니다.
비관계형 데이터베이스, 속성은 객체에만 속합니다. 객체는 서로 독립적입니다.
장기 업무에는 mysql+memcache 조합을 사용하고, 통계 로그 업무나 PM 이마의 임시 트랜잭션에는 mongodb+redis 조합을 사용합니다.
mongodb의 장점은 유연성이고, 단점도 유연성이 있으며, 안정성이 mysql만큼 좋지는 않습니다.
기존의 관계형 데이터베이스에 비해 MongoDB는 비관계형 데이터베이스의 대표주자 중 하나입니다. MongoDB를 언제 사용해야 하는지 알려면 먼저 MongoDB가 어떤 기능을 가지고 있는지, 무엇을 할 수 있고 무엇을 할 수 없는지 알고, 구체적인 상황에 따라 사용할지 여부를 결정해야 합니다. MongoDB의 가장 중요한 기능을 나열하고 거의 모든 다른 기능이 이러한 기능을 중심으로 돌아가는 공식 문서의 소개 부분을 먼저 읽는 것이 좋습니다. 이러한 기능은 MongoDB 채택 여부를 결정하는 주요 요소인 경우가 많습니다.
선택 방법을 간략하고 대략적으로 소개한 글입니다.
그러나 기술이 발전하면서 소위 "관계형"과 "비관계형" 사이의 경계가 점점 모호해지고 있습니다. 한편으로는 Postgre, MySQL과 같은 전통적인 RDBMS가 비관계형을 지원하기 시작했습니다. 한편, JSON과 같은 관계형 모델도 MongoDB JOIN이 지원되기 시작했고, 앞으로는 트랜잭션까지 지원될 예정입니다. 이제는 경계가 모호해져서 언제 어떤 기술을 쓸지 일반화할 수 없게 되면서 이것저것 쓸 수 있다는 비교 결과가 나오는 경우가 많습니다. 그러나 프로젝트에 특정 기술을 사용하면 실제로 얻을 수 있는 것과 잃는 것이 무엇인지 비교할 수 있으며, 얻은 부분이 손실된 부분을 보완할 수 있는지 여부를 따져보고 최종적으로 이 기술을 채택할지 여부를 결정할 수 있습니다.
데이터 구조가 확실하지 않은 경우 mongodb를 사용하는 것이 가장 좋습니다. 예를 들어 SQL 데이터베이스에서는 모든 필드의 유형, 이름, 길이 등을 먼저 정의해야 합니다. mongodb에서는 유연성이 부족합니다. 특정 분야에는 존재하지 않는데, 그냥 없는 척 하세요.
예를 들어 서버가 시스템 이벤트를 데이터베이스에 저장하려고 한다고 가정해 보겠습니다. 특정 사용자가 어떤 작업을 수행할 때 쿼리를 위해 보낸 게시물의 원래 본문 내용을 기록해야 하는 경우도 있고 그렇지 않은 경우도 있습니다. 그런 다음 게시물 내용을 기록할 필요가 없는 경우 SQL에 문자열을 정의하면 됩니다. 길이가 1000이면 이 공간이 낭비되지만 mongodb는 그렇지 않습니다. 그리고 이 레코드를 가져올 때 SQL 데이터베이스는 필드 중 하나가 비어 있어도 정의한 구조를 반환하고 mongodb는 저장할 때 빈 필드를 포함하지 않으며 가져올 때에도 같은 일이 발생하지 않습니다.
또한 mongodb는 다양한 json 구조를 매우 잘 지원합니다. 물론 이것이 mongodb를 사용하는 주요 목적이 되어서는 안 됩니다.