최근 O2O 플랫폼 프로젝트(관리, 예약, 결제, 위챗 접속 등)를 진행했는데, 처음에는 인력, 비용 등을 고려하여 표준 MEAN을 기술 선택으로 선택했습니다. 정말 빠르지만 프로젝트 요구 사항의 반복으로 인해 이 기술 선택, 특히 mongodb에는 주로 다음과 같은 많은 제한 사항이 있다고 느낍니다.
1. Mongodb는 조인 작업을 지원하지 않으며 확장만 가능합니다. 단순히 채우기를 통해서만 크로스 테이블 쿼리와 통계를 수행하는 것은 매우 번거로운 일입니다. 이제 데이터 중복성, 즉 단순히 여러 컬렉션에 데이터 필드를 저장하는 방식으로 많은 작업을 수행합니다.
2. Mongodb는 트랜잭션을 지원하지 않으므로 이제 비즈니스 동기화 프레임워크에서 많은 롤백 작업을 처리하며 코드가 매우 중복되며 본질적으로 여전히 진정한 롤백이 아닙니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
일부 프로젝트에 조인 문제가 발생했습니다. 내 솔루션은 해당 ObjectId를 저장하고 mongodb의 집계를 통해 조인 목적을 달성하는 것입니다. WiredTiger 엔진을 사용하여 많은 양의 읽기 및 쓰기 중에 데이터베이스가 잠기는 문제를 해결했습니다. 또한 데이터베이스를 디자인할 때 전통적인 SQL 디자인 사고와 개발 논리를 피하십시오. 컬렉션은 하나의 이벤트에 대응해야 합니다. 이후 프로젝트 확장으로 인해 작업자 개발 모델을 도입하고 논리 계층 간의 관계를 독립적인 스레드가 있는 작업자로 변경했으며 현재는 온라인 연결 없이 많은 수의 동시성을 처리하는 데 좋은 효과가 있습니다. 온라인에 있는 사람 없이 빨간 봉투를 잡는 효과와 유사합니다. 단지 참고용으로 조금 겸손한 의견입니다.
또한 mongodb의 한계는 SQL 개발 모델에 익숙한 사람들에게는 매우 불편할 것입니다. 하지만 빅데이터 시대에 mongodb의 장점은 분명합니다. 현재 내 프로젝트의 기본 구조는 다음과 같습니다.
서버: nginx+mongodb+php-fpm+ubuntu
주 프로그램: MVC(php) // 값은 논리적 관계 교환을 제공합니다
보조 프로그램: 작업자 // 데이터베이스 상호 작용을 위한 논리적 관계에 해당하는 멀티 스레드 처리
기술을 선택할 때 고려하지 않으셨나요? mongo만 사용할 필요가 없으며 여러 라이브러리가 공존할 수 있습니다
여러분 사실 제 질문은 몽고가 불량인지 교체해야 하는지가 아닙니다. 오히려 데이터베이스가 전환되지 않는다고 가정하면 위의 문제에 대한 해결책이 있을까요? 업계에는 이러한 문제를 직면하고 해결한 다른 사람들도 있을 것이라고 확신합니다.
Mongodb는 이런 유형의 프로젝트에는 적합하지 않으며, 관계가 강한 프로젝트의 경우 여전히 관계형 데이터베이스를 사용합니다.