철자를 정정하세요. MongoDB여야 합니다. 각 데이터베이스에는 고유한 장점과 단점이 있으며 적용 가능한 상황도 다릅니다. 저는 MongoDB 편에 있고 위에서 MySQL과 HDFS를 언급한 사람이 있으므로 데이터 분석에서 MySQL과 HDFS에 비해 MongoDB의 장점을 분석해 보겠습니다. 질문자는 이러한 이점이 귀하가 원하는 것인지 확인한 다음 프로젝트의 실제 상황에 따라 결정을 내릴 수 있습니다. MySQL은 RDBMS의 공통 기능과 ACID를 완벽하게 지원하는 오랫동안 확립된 RDBMS입니다. 해당 기술은 장기간의 강수 및 적용 테스트를 거쳐 이미 비교적 안정적인 적용 단계에 도달했습니다. 실제 애플리케이션에서 NoSQL에 비해 RDBMS의 주요 장점은 강력한 트랜잭션입니다. 그러나 OLAP 애플리케이션에서 강력한 트랜잭션은 그다지 유용하지 않지만 분산 지원을 방해합니다. 완전한 개발을 전제로 하면 수평적 확장은 결국 MySQL 선택의 주요 병목 현상이 됩니다. 또한 크롤러와 같은 애플리케이션의 경우 구조화되지 않은 데이터가 일반적으로 크롤링되므로 관계형 모델의 저장 및 쿼리에 큰 제한이 있습니다. 하지만 관심 있는 웹사이트가 모두 동일한 유형의 웹사이트일 가능성도 있고, 웹페이지의 특정 콘텐츠에만 관심이 있어 구조화된 데이터로 구성할 수 있으므로 MySQL은 여전히 다음과 같은 분야에 적합합니다. 이 점에 관해서. 그러나 그럼에도 불구하고 향후 애플리케이션이 개발됨에 따라 데이터 스토리지의 유연성은 여전히 희생될 것입니다. 따라서 크롤러와 같은 애플리케이션의 경우 MySQL의 주요 문제점은 데이터 모델이 충분히 유연하지 않고 수평으로 확장할 수 없거나 어렵다는 것입니다. 위의 두 가지 주요 문제에 관한 한 HDFS는 실제로 이를 처리할 수 있습니다. 따라서 HDFS는 크롤러와 같은 애플리케이션에서 MySQL에 비해 장점이 있습니다. 마찬가지로 MongoDB도 이 두 가지 문제를 매우 잘 해결합니다. 그렇다면 HDFS에 비해 MongoDB의 장점은 무엇입니까? 매우 중요한 점은 MongoDB가 관계형 데이터베이스처럼 문서의 모든 필드에 보조 인덱스를 설정할 수 있어 분석 과정에서 인덱스가 가져오는 성능 이점을 극대화할 수 있다는 점입니다. 또한 HDFS는 파일 시스템과 유사한 기능을 제공하는 반면 MongoDB는 유연한 데이터베이스 기술을 제공하며 지리적 배포 및 만료된 문서 보관과 같은 작업을 MongoDB에서 쉽게 구현할 수 있습니다. 생태계 관점에서 볼 때 HDFS의 주변 도구는 결국 개발 역사가 어디에 있는지 더 풍부해야 합니다. MongoDB는 현재 주로 다음을 지원합니다.
BI 커넥터: MongoDB는 기존 BI 도구를 활용할 수 있도록 외부 세계에 PostgreSQL 또는 MySQL 인터페이스를 제공합니다.
Spark 커넥터: MongoDB가 Spark와 연결하여 계산
질문으로 돌아가면, 공평하게 말하면, 어떤 데이터베이스를 사용하더라도 올바르게 사용하면 성능에는 질적인 차이가 없습니다. 가용성 문제와 관련하여 MongoDB의 고가용성은 두 번째 수준의 오류 복구를 달성할 수 있습니다. MySQL에도 해당 솔루션이 있지만 운영 및 유지 관리가 더 복잡할 수 있습니다. 보안 측면에서는 회사 간 큰 차이가 없습니다.
이 경우 처리 플랫폼으로 Hadoop을 선택해야 합니다. 일반적으로 봄 축제 갈라 라이브 방송 중 공세와 같은 실시간 모니터링을 위해 기본 데이터 저장소는 MySQL의 .mangodb+hadoop 조합을 사용하는 것이 더 좋습니다. mongodb는 밀리초 수준의 데이터 쿼리, 실시간 분석을 지원합니다. Hadoop은 한 번 쓰고 여러 번 검색합니다. MySQL과 결합하면 프로젝트에 더 적합합니다. 보안은 실제로 거의 같습니다. 키 방화벽이 안전하면 괜찮습니다. 결국 데이터베이스는 격리됩니다. 따라서 MySQL을 선택하는 것이 좋습니다.
200w와 2000w 사이의 데이터량이 상대적으로 적습니다. 둘 중 어느 것이 더 친숙한지 생각해서 사용하시면 됩니다. 하지만 기본적으로 데이터베이스가 수천만 레벨에 도달하게 되면 쿼리 성능에 문제가 발생하게 되므로, 데이터가 계속 증가한다면 mongodb 사용을 고려해 볼 수 있습니다. 결국 mysql 클러스터보다 mongodb 샤드 클러스터를 구축하는 것이 훨씬 간단합니다. 그리고 처리하기가 더 유연합니다.
제가 일하는 회사가 이 분야에서 어떤 일을 했고, 그에 대한 책임은 제가 참고로 말씀드릴 수 있습니다. 제가 여기서 주로 하는 일은 로그 처리 및 아카이빙, 매일 생성되는 접속 로그에 대한 핫/콜드 통계 작성, 다양한 데이터 리포트 생성 등입니다. 사실 크롤러도 결국 비슷합니다. 처음에 MYSQL을 고려했는데, 수천만 개가 넘는 단일 MYSQL 테이블의 성능이 형편없어서 그때는 mongodb를 선택했습니다. 실제로 수행하는 작업은 매우 간단합니다. Python을 사용하여 정기적으로 로컬에서 일일 서버 로그를 캡처한 다음, 그룹 집계를 계산해야 하는 경우 Pandas 라이브러리를 사용하여 데이터를 구성하면 됩니다. , 그냥 집계하면 됩니다. 마지막으로 일일 데이터 결과가 mongodb에 저장됩니다. 현재 회사는 약 8KW의 mongodb 데이터를 보유하고 있으며, 데이터 검색 효율성은 여전히 만족스러운 수준입니다. mongodb에 데이터를 기록하는 것 외에도 운영 체제에 대한 데이터 통계 결과를 구체적으로 호출하기 위해 플라스크를 사용하여 편안한 API를 작성했습니다. 또한 Mongodb에서 통계를 수집하기 위해 MYSQL에 테이블을 생성합니다. 다시 한 번 전체 데이터로 계산되어 MYSQL에 배치되므로 API에서 데이터를 검색할 때마다 반복 집계 계산을 수행하기 위해 mongodb를 호출할 필요가 없습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
철자를 정정하세요. MongoDB여야 합니다.
각 데이터베이스에는 고유한 장점과 단점이 있으며 적용 가능한 상황도 다릅니다. 저는 MongoDB 편에 있고 위에서 MySQL과 HDFS를 언급한 사람이 있으므로 데이터 분석에서 MySQL과 HDFS에 비해 MongoDB의 장점을 분석해 보겠습니다. 질문자는 이러한 이점이 귀하가 원하는 것인지 확인한 다음 프로젝트의 실제 상황에 따라 결정을 내릴 수 있습니다.
MySQL은 RDBMS의 공통 기능과 ACID를 완벽하게 지원하는 오랫동안 확립된 RDBMS입니다. 해당 기술은 장기간의 강수 및 적용 테스트를 거쳐 이미 비교적 안정적인 적용 단계에 도달했습니다. 실제 애플리케이션에서 NoSQL에 비해 RDBMS의 주요 장점은 강력한 트랜잭션입니다. 그러나 OLAP 애플리케이션에서 강력한 트랜잭션은 그다지 유용하지 않지만 분산 지원을 방해합니다. 완전한 개발을 전제로 하면 수평적 확장은 결국 MySQL 선택의 주요 병목 현상이 됩니다. 또한 크롤러와 같은 애플리케이션의 경우 구조화되지 않은 데이터가 일반적으로 크롤링되므로 관계형 모델의 저장 및 쿼리에 큰 제한이 있습니다. 하지만 관심 있는 웹사이트가 모두 동일한 유형의 웹사이트일 가능성도 있고, 웹페이지의 특정 콘텐츠에만 관심이 있어 구조화된 데이터로 구성할 수 있으므로 MySQL은 여전히 다음과 같은 분야에 적합합니다. 이 점에 관해서. 그러나 그럼에도 불구하고 향후 애플리케이션이 개발됨에 따라 데이터 스토리지의 유연성은 여전히 희생될 것입니다. 따라서 크롤러와 같은 애플리케이션의 경우 MySQL의 주요 문제점은 데이터 모델이 충분히 유연하지 않고 수평으로 확장할 수 없거나 어렵다는 것입니다.
위의 두 가지 주요 문제에 관한 한 HDFS는 실제로 이를 처리할 수 있습니다. 따라서 HDFS는 크롤러와 같은 애플리케이션에서 MySQL에 비해 장점이 있습니다. 마찬가지로 MongoDB도 이 두 가지 문제를 매우 잘 해결합니다. 그렇다면 HDFS에 비해 MongoDB의 장점은 무엇입니까? 매우 중요한 점은 MongoDB가 관계형 데이터베이스처럼 문서의 모든 필드에 보조 인덱스를 설정할 수 있어 분석 과정에서 인덱스가 가져오는 성능 이점을 극대화할 수 있다는 점입니다. 또한 HDFS는 파일 시스템과 유사한 기능을 제공하는 반면 MongoDB는 유연한 데이터베이스 기술을 제공하며 지리적 배포 및 만료된 문서 보관과 같은 작업을 MongoDB에서 쉽게 구현할 수 있습니다.
생태계 관점에서 볼 때 HDFS의 주변 도구는 결국 개발 역사가 어디에 있는지 더 풍부해야 합니다. MongoDB는 현재 주로 다음을 지원합니다.
BI 커넥터: MongoDB는 기존 BI 도구를 활용할 수 있도록 외부 세계에 PostgreSQL 또는 MySQL 인터페이스를 제공합니다.
Spark 커넥터: MongoDB가 Spark와 연결하여 계산
질문으로 돌아가면, 공평하게 말하면, 어떤 데이터베이스를 사용하더라도 올바르게 사용하면 성능에는 질적인 차이가 없습니다. 가용성 문제와 관련하여 MongoDB의 고가용성은 두 번째 수준의 오류 복구를 달성할 수 있습니다. MySQL에도 해당 솔루션이 있지만 운영 및 유지 관리가 더 복잡할 수 있습니다. 보안 측면에서는 회사 간 큰 차이가 없습니다.
MySQL은 대용량 데이터를 처리할 때 매우 불안해집니다. 반대로 MongoDB는 클러스터를 통해 더 좋아질 것입니다.
사실 데이터베이스가 전혀 필요하지 않습니다. 이로 인해 크롤러에 IO 병목 현상이 발생할 수 있습니다.
Hadoop으로 HDFS를 사용해 볼 수 있습니다.
이 경우 처리 플랫폼으로 Hadoop을 선택해야 합니다. 일반적으로 봄 축제 갈라 라이브 방송 중 공세와 같은 실시간 모니터링을 위해 기본 데이터 저장소는 MySQL의 .mangodb+hadoop 조합을 사용하는 것이 더 좋습니다. mongodb는 밀리초 수준의 데이터 쿼리, 실시간 분석을 지원합니다. Hadoop은 한 번 쓰고 여러 번 검색합니다. MySQL과 결합하면 프로젝트에 더 적합합니다. 보안은 실제로 거의 같습니다. 키 방화벽이 안전하면 괜찮습니다. 결국 데이터베이스는 격리됩니다. 따라서 MySQL을 선택하는 것이 좋습니다.
이 정도의 데이터만 있으면 MySQL이나 MongoDB가 작동하지만 상대적으로 MongoDB가 더 유연합니다.
200w와 2000w 사이의 데이터량이 상대적으로 적습니다. 둘 중 어느 것이 더 친숙한지 생각해서 사용하시면 됩니다. 하지만 기본적으로 데이터베이스가 수천만 레벨에 도달하게 되면 쿼리 성능에 문제가 발생하게 되므로, 데이터가 계속 증가한다면 mongodb 사용을 고려해 볼 수 있습니다. 결국 mysql 클러스터보다 mongodb 샤드 클러스터를 구축하는 것이 훨씬 간단합니다. 그리고 처리하기가 더 유연합니다.
팀이 Hadoop 기술 스택에 익숙하지 않은 경우 200-2000W의 데이터 볼륨에 Hadoop을 사용할 필요가 없습니다.
제가 일하는 회사가 이 분야에서 어떤 일을 했고, 그에 대한 책임은 제가 참고로 말씀드릴 수 있습니다.
제가 여기서 주로 하는 일은 로그 처리 및 아카이빙, 매일 생성되는 접속 로그에 대한 핫/콜드 통계 작성, 다양한 데이터 리포트 생성 등입니다. 사실 크롤러도 결국 비슷합니다.
처음에 MYSQL을 고려했는데, 수천만 개가 넘는 단일 MYSQL 테이블의 성능이 형편없어서 그때는 mongodb를 선택했습니다.
실제로 수행하는 작업은 매우 간단합니다. Python을 사용하여 정기적으로 로컬에서 일일 서버 로그를 캡처한 다음, 그룹 집계를 계산해야 하는 경우 Pandas 라이브러리를 사용하여 데이터를 구성하면 됩니다. , 그냥 집계하면 됩니다. 마지막으로 일일 데이터 결과가 mongodb에 저장됩니다.
현재 회사는 약 8KW의 mongodb 데이터를 보유하고 있으며, 데이터 검색 효율성은 여전히 만족스러운 수준입니다.
mongodb에 데이터를 기록하는 것 외에도 운영 체제에 대한 데이터 통계 결과를 구체적으로 호출하기 위해 플라스크를 사용하여 편안한 API를 작성했습니다. 또한 Mongodb에서 통계를 수집하기 위해 MYSQL에 테이블을 생성합니다. 다시 한 번 전체 데이터로 계산되어 MYSQL에 배치되므로 API에서 데이터를 검색할 때마다 반복 집계 계산을 수행하기 위해 mongodb를 호출할 필요가 없습니다.