source

MS SQL Server 대신 MongoDB를 사용하는 경우의 장단점

factcode 2023. 7. 18. 22:00
반응형

MS SQL Server 대신 MongoDB를 사용하는 경우의 장단점

NoSQL 세계에 처음 와서 MS SQL Server 데이터베이스를 MongoDB로 교체할 생각입니다.내 지원서(에 작성됨).NetC#)는 IP 카메라와 상호 작용하여 카메라에서 수신되는 각 이미지에 대한 메타데이터를 MS SQL 데이터베이스에 기록합니다.평균적으로 저는 각 카메라에 대해 하루에 약 86400개의 레코드를 삽입하고 있으며 현재 데이터베이스 스키마에서 별도의 카메라 이미지를 위한 별도의 테이블을 만들었습니다. 예를 들어 Camera_1_Images, Camera_2_Images...Camera_N_Images.단일 이미지 레코드는 단순한 메타데이터 정보로 구성됩니다.예를 들어 AutoId, FilePath, CreationDate 등입니다.여기에 더 많은 세부 정보를 추가하기 위해 내 응용 프로그램은 각 카메라에 대해 별도의 프로세스(.exe)를 시작하고 각 프로세스는 데이터베이스의 상대 테이블에 초당 1개의 레코드를 삽입합니다.

다음과 같은 우려 사항에 대해 (MongoDB) 전문가의 제안이 필요합니다.

  1. MongoDB가 이러한 데이터를 보유하기에 좋은지 여부를 알려주는 것은 결국 시간 범위에 대해 쿼리됩니다(예: 지정된 시간 사이에 특정 카메라의 모든 이미지 검색).제 사례에 대한 문서 기반 스키마 설계에 대해 제안할 사항이 있습니까?

  2. 서버 사양(CPU, RAM, 디스크)은 어떻게 해야 합니까?무슨 제안이 있습니까?

  3. 이 시나리오에 대해 샤딩/복제를 고려해야 합니까(복제 세트 동기화에 대한 쓰기 성능을 고려해야 합니까?

  4. 동일한 컴퓨터에서 여러 데이터베이스를 사용하여 한 데이터베이스에 모든 카메라의 현재 이미지를 저장하고 두 번째 데이터베이스를 사용하여 전날 이미지를 보관할 수 있는 이점이 있습니까?저는 읽기와 쓰기를 별개의 데이터베이스에서 나누는 것과 관련하여 이것을 생각하고 있습니다.모든 읽기 요청은 두 번째 데이터베이스에서 처리되고 첫 번째 데이터베이스에 쓰기 때문입니다.도움이 될까요, 안 될까요?"예"인 경우, 두 데이터베이스가 항상 동기화되는지 확인합니다.

다른 제안은 환영합니다.

저는 NoSQL 데이터베이스의 시작자입니다.그래서 저는 잠재적인 반대표를 희생하면서 이것에 답하고 있지만, 저에게 좋은 학습 경험이 될 것입니다.

귀하의 질문에 최선을 다해 답변하기 전에 MS SQL Server가 귀하에게 잘 작동하고 있다면 그대로 유지해야 합니다.당신은 문서 지향적인 db로 알게 된 것 외에 당신이 MongoDB를 사용하고자 하는 타당한 이유를 언급하지 않았습니다.또한 각 카메라에 대해 캡처 중인 메타데이터 세트가 거의 동일하다는 것을 알 수 있습니다. 즉, 스키마가 동적입니다.

  • MongoDB가 이러한 데이터를 보유하기에 좋은지 여부를 알려주는 것은 결국 시간 범위에 대해 쿼리됩니다(예: 지정된 시간 사이에 특정 카메라의 모든 이미지 검색).제 사례에 대한 문서 기반 스키마 설계에 대해 제안할 사항이 있습니까?

MongoDB는 문서 지향적인 DB로, 집계(문서라고 함) 내에서 쿼리를 잘 수행합니다.이미 각 카메라의 데이터를 자체 테이블에 저장하고 있으므로 MongoDB에서는 각 카메라에 대해 별도의 컬렉션이 만들어집니다.다음은 날짜 범위 쿼리를 수행하는 방법입니다.

  • 서버 사양(CPU, RAM, 디스크)은 어떻게 해야 합니까?무슨 제안이 있습니까?

모든 NoSQL 데이터베이스는 범용 하드웨어에서 스케일아웃할 수 있도록 구축되었습니다.그러나 질문하신 대로라면 스케일업을 통해 성능을 향상시킬 생각을 하고 계실 수도 있습니다.합리적인 시스템으로 시작할 수 있으며 로드가 증가함에 따라 서버를 계속 추가(스케일 아웃)할 수 있습니다.고급 서버를 계획하고 구입할 필요가 없습니다.

  • 이 시나리오에 대해 샤딩/복제를 고려해야 합니까(복제 세트 동기화에 대한 쓰기 성능을 고려해야 합니까?

MongoDB는 단일 쓰기에 대해 전체 DB를 잠급니다(단, 다른 작업에 대한 산출량). 쓰기보다 읽기가 많은 시스템을 대상으로 합니다.이는 시스템 상태에 따라 달라집니다.샤딩에는 여러 가지 방법이 있으며 도메인별로 지정해야 합니다.일반적인 답변은 불가능합니다.그러나 지리적, 가지 등에 의한 샤딩과 같은 몇 가지 예를 들 수 있습니다.

CAP 정리에 대한 간단한 영어 소개도 읽습니다.

샤딩에 대한 의견에 대한 답변으로 업데이트됨

설명서에 따르면 다음과 같은 경우 샤드 클러스터 배포를 고려해야 합니다.

  • 데이터 세트가 시스템의 단일 노드 스토리지 용량에 근접하거나 초과합니다.
  • 시스템의 활성 작업 세트 크기가 곧 시스템의 최대 RAM 용량을 초과합니다.
  • 시스템에 대량의 쓰기 작업이 있으며, 단일 MongoDB 인스턴스는 수요를 충족할 만큼 빠르게 데이터를 쓸 수 없으며, 다른 모든 접근 방식은 경합을 줄이지 못했습니다.

그래서 마지막 요점을 근거로 예.자동 셰이딩 기능은 쓰기 크기를 조정할 수 있도록 제작되었습니다.이 경우 데이터베이스가 아닌 하드웨어별 쓰기 잠금이 있습니다.하지만 저의 대답은 이론적인 것입니다.저는 당신이 10gen.com 그룹에서 상담을 받는 것을 제안합니다.

MongoDB가 이러한 데이터를 보유하기에 좋은지 여부를 알려주는 것은 결국 시간 범위에 대해 쿼리됩니다(예: 지정된 시간 사이에 특정 카메라의 모든 이미지 검색).

이 질문은 제가 대답하기에는 너무 주관적입니다.수많은 SQL 솔루션(아이러니하게도 MS SQL이 아님)에 대한 개인적인 경험으로 볼 때, 올바르게 수행된다면 두 솔루션 모두 동등하게 우수하다고 말할 수 있습니다.

또한:

서버 사양(CPU, RAM, 디스크)은 어떻게 해야 합니까?무슨 제안이 있습니까?

사용자만 알고 있는 변수가 너무 많기 때문에 일반 하드웨어의 작은 클러스터가 매우 잘 작동합니다.저는 이 질문에 대해 사실적인 답변을 드릴 수 없으며 그것은 당신의 테스트로 귀결될 것입니다.

스키마에 대해서는 다음과 같은 구조의 문서를 구하겠습니다.

{
    _id: {},
    camera_name: "my awesome camera",
    images: [
        { 
            url: "http://I_like_S3_here.amazons3.com/my_image.png" ,
            // All your other fields per image
        }
    ]
}

그러나 쿼리에 따라 약간의 문제가 발생할 수 있기 때문에 이 문제를 더 깊이 포함하지 않는 한 유지 관리 및 업데이트하기가 매우 쉬울 것입니다.

만 아니라 가 다 을 할 때도 좋을 것 같습니다._id당신은 아마도 여기서 완벽한 설정을 할 수 있을 것입니다.

이 시나리오에 대해 샤딩/복제를 고려해야 합니까(복제 세트 동기화에 대한 쓰기 성능을 고려해야 합니까?

아마도 많은 사람들이 실제로는 데이터베이스를 설계하는 데 있어 더 지능적이어야 할 때 셰이딩이 필요하다고 생각할 것입니다.MongoDB는 매우 자유로운 형식이기 때문에 잘못된 방법이 많이 있지만, 그렇다고 해도 올바른 방법도 많이 있습니다.저는 개인적으로 계속해서 샤딩을 염두에 두고 있습니다.복제도 매우 유용할 수 있습니다.

동일한 컴퓨터에서 여러 데이터베이스를 사용하여 한 데이터베이스에 모든 카메라의 현재 이미지를 저장하고 두 번째 데이터베이스를 사용하여 전날 이미지를 보관할 수 있는 이점이 있습니까?

MongoDBs 쓰기 잠금이 (현재) DB 수준에 있지만, 저는 "아니요"라고 말할 것입니다.적절한 문서 구조와 적절한 샤딩/복제(필요한 경우)는 단일 DB 아래의 단일 문서 기반 컬렉션에서 이를 처리할 수 있어야 합니다.뿐만 아니라 클러스터 내의 쓰기 및 읽기를 특정 서버로 유도하여 클러스터 내의 특정 컴퓨터 간에 동시성 상황을 만들 수도 있습니다.DB분리에 대한 MongoDBs 동시성 기능의 올바른 사용을 촉진하고자 합니다.

편집

질문을 다시 읽은 후, 저는 당신이 하루에 각 카메라에 80,000개 이상의 이미지를 삽입한다는 것을 제 해결책에서 빠뜨렸습니다.는 임베디드 에 내된옵션대실이행만것다라는 것입니다.images 그다에음.cameraSQL에서처럼 수집 및 쿼리를 수행할 수 있습니다.

를 합니다.images수집은 그만큼 쉬워야 합니다.camera_id.

또한 서버에 대한 작업 설정을 고려해야 합니다.

MongoDB가 이러한 데이터를 보유하기에 좋은지 여부를 알려주는 것은 결국 시간 범위에 대해 쿼리됩니다(예: 지정된 시간 사이에 특정 카메라의 모든 이미지 검색).제 사례에 대한 문서 기반 스키마 설계에 대해 제안할 사항이 있습니까?

MongoDB는 이것을 할 수 있습니다.성능 향상을 위해 시간 필드에 색인을 설정할 수 있습니다.

서버 사양(CPU, RAM, 디스크)은 어떻게 해야 합니까?무슨 제안이 있습니까?

램과 디스크가 중요할 것 같습니다.

  • 여러분이 면싫다기를 ,shardingscale out모든 데이터를 저장할 수 있도록 더 큰 크기의 디스크를 고려해야 합니다.
  • 핫 데이터는 RAM에 적합해야 합니다.그렇지 않으면 MongoDB의 성능은 주로 RAM에 의존하기 때문에 더 큰 RAM을 고려해야 합니다.

이 시나리오에 대해 샤딩/복제를 고려해야 합니까(복제 세트 동기화에 대한 쓰기 성능을 고려해야 합니까?

당신이 가지고 있는 카메라가 많은지는 모르겠지만, 총 1000대의 카메라가 있는 초당 1000개의 인서트라도 MongoDB는 여전히 쉬울 것입니다.삽입 성능에 관한 것이라면 샤딩을 할 필요가 없다고 생각합니다(데이터 크기가 너무 커서 여러 기계로 분리해야 하는 것을 제외하고).

또 다른 문제는 프로그램의 읽기 빈도입니다.이 값은 매우 높습니다. 그러면 여기서 샤딩 또는 복제를 고려할 수 있습니다.또한 시간 범위에서 한 대의 카메라에만 쿼리를 실행할 경우 (타임스탬프 + camera_id)를 샤딩 키로 사용할 수 있습니다.

동일한 컴퓨터에서 여러 데이터베이스를 사용하여 한 데이터베이스에 모든 카메라의 현재 이미지를 저장하고 두 번째 데이터베이스를 사용하여 전날 이미지를 보관할 수 있는 이점이 있습니까?

테이블을 두 개의 컬렉션으로 분리할 수 있습니다(archive그리고.current) 및 인덱스만 설정합니다.archive날짜만 조회하는 경우archive인덱스 생성의 오버헤드 없이,current삽입하면 수집에 도움이 됩니다.

그리고 당신은 매일 프로그램을 작성하여 쓰레기를 버릴 수 있습니다.current에 대한 자료.archive.

언급URL : https://stackoverflow.com/questions/13190468/pros-and-cons-of-using-mongodb-instead-of-ms-sql-server

반응형