MongoDB가 이렇게 빠른 이유

MongoDB가 이렇게 빠른 이유

저는 동료에게 MongoDB 대 SQL 2008의 성능 벤치마크를 보여주고 있었는데, 그는 MongoDB가 더 빠르다고 믿지만 어떻게 가능한지 이해하지 못합니다.그의 논리는 SQL이 수십 년 동안 존재해 왔고, 가장 똑똑한 사람들이 작업하고 있다는 것이었습니다. 그리고 어떻게 MongoDB가 성능 면에서 그렇게 뛰어날 수 있을까요?저는 확실하고 기술적인 답변을 드릴 수 없었습니다. 여러분이 도움이 되길 바랍니다.

MongoDB는 웹 스케일 때문에 빠릅니다!

이 비디오는 재미있고 모두가 볼 가치가 있지만 MongoDB와 같은 대부분의 noSQL 엔진이 강력하지 않고 충돌 및 기타 중단에 탄력적이지 않다는 질문에 답합니다.이러한 보안은 속도를 높이기 위해 희생하는 것입니다.

MongoDB는 전통적인 관계형 데이터베이스와는 다릅니다.SQL이나 문서 기반이 아니며, 약한 일관성 보장을 제공하며 SQL과 같은 일관성을 보장할 필요가 없습니다.

SQL은 많은 작업을 수행해야 하며 Mongo는 비트를 Disk에 떨어뜨리기만 하면 됩니다(거의).

앞서 언급했듯이 MongoDB는 생성되지 않으며 SQL 데이터베이스와 동일하게 사용되어서는 안 됩니다.SQL(및 기타 관계형 데이터베이스)은 관계형 데이터를 저장합니다. 즉, 테이블 X의 데이터가 테이블 Y의 정보와 직접적인 관계를 갖도록 설정할 수 있습니다.MongoDB에는 이 기능이 없으므로 오버헤드를 많이 줄일 수 있습니다.따라서 MongoDB는 일반적으로 관계가 아닌 목록을 저장하는 데 사용됩니다.

아직은 ACID를 제대로 준수하지 않으며(처음 도입된 이후로 큰 발전을 이루었지만) 속도 차이의 상당 부분을 차지합니다.

다음은 실제 사이트에서 전체 트랜잭션 모델과 해당 모델 간의 차이점입니다.

실제로 MongoDB의 비 트랜잭션 모델은 다음과 같은 의미를 갖습니다.

• 롤백 금지.코드는 롤백 없이 작동해야 합니다.첫 번째 데이터베이스 쓰기 작업을 수행하기 전에 모든 프로그래밍 상태를 확인합니다.가장 중요한 작업이 마지막에 수행되도록 쓰기 작업을 정렬합니다.
• 명시적 잠금.작업을 수행할 때 코드가 개체를 명시적으로 잠글 수 있습니다.따라서 애플리케이션 프로그래머는 필요할 때 "직렬화 가능성"을 보장할 수 있습니다.잠금 기능은 MongoDB의 후기 알파/초기 베타 릴리스에서 사용할 수 있습니다.
• 시작 시 데이터베이스를 확인합니다.데이터베이스가 비정상적으로 종료되는 경우(희귀한 경우), 데이터베이스 검사 절차는 시작 시 자동으로 실행됩니다(fschk와 유사함).

다른 답변들은 흥미롭지만, 적어도 벤치마크에서 MongoDB가 "매우 빠른" 이유 중 하나는 다음과 같습니다.write concern.

여기에서 다양한 쓰기 문제에 대해 자세히 읽을 수 있지만 기본적으로 데이터를 쓸 때 원하는 "보안" 수준을 정의할 수 있습니다.

이전에 사용된 기본 수준은 입니다. 즉, 쓰기 작업이 트리거되었지만 드라이버가 성공적으로 수행되었는지 여부를 확인하지 않습니다.그것은 더 빠르지만, 훨씬 덜 신뢰할 수 있습니다.

약 1년 전에 로 바꿨습니다. 하지만 여전히 대부분의 벤치마크는 더 나은 결과를 위해 '미승인' 모드를 사용하고 있다고 생각합니다.

성능 면에서 차이를 보고 싶다면 이 기사를 확인할 수 있습니다(조금 오래되었지만 여전히 아이디어가 있습니다).

MongoDB는 다음과 같은 이유로 fast™입니다.

1. 산이 아님: 가용성은 일관성보다 우선합니다.
2. 비동기식 삽입 및 업데이트:즉, MongoDB는 삽입 쿼리가 처리되는 즉시 DB에 데이터를 삽입하지 않고 일정 시간이 지나면 데이터를 플러시합니다.업데이트도 마찬가지입니다.
3. 오버헤드 조인 없음:그들이 MongoDB가 문서 데이터베이스라고 말할 때, 그들이 의미하는 것은, 그것은 자급자족하고 모든 정보가 실제 문서처럼 내장된 데이터베이스라는 것입니다.

MongoDb가 더 빠른 이유: 1.트랜잭션 없음; 2.테이블 간의 관계 없음;

SQL 서버에서 동일한 논리를 정확하게 수행하려고 하는 경우: 1. 잠금과 함께 선택; 2를 사용하지 마십시오.테이블 간의 관계 없음;SQL Server와 MongoDB 간의 속도 차이는 그리 크지 않을 것입니다.SQL이 대기열에서 삽입 및 업데이트 테이블을 수행하고 트랜잭션에서 MondoDB에서 비동기적으로 발생하기 때문에 기록을 쓰고 업데이트하는 단 한 곳만이 확실히 더 빨라집니다.제 예상으로는 SQL SERVER와 MongoDB의 속도에 큰 차이가 없었습니다. 비즈니스 로직이 두 프로젝트 간에 매우 유사했기 때문입니다.MongoDb의 실질적인 속도 향상은 입찰 데이터가 있는 Analytical 프로젝트나 신문, 온라인 상점 등의 빅 콘텐츠 관리 엔진에서 얻을 수 있습니다.MongoDB에 대한 최적화는 없으며 SQL 서버에 대한 최적화는 이러한 데이터베이스를 거의 동일하게 만들 수 없습니다.

Mongo는 ACID를 준수하지 않으므로 DB에 넣으려는 내용이 나중에 다시 나올 수 있도록 하기 위해 거의 "쓰레기"를 처리할 필요가 없습니다.

일부 기능이 손실되고 데이터가 손실되어도 상관없다면 Mongo는 좋습니다.데이터 무결성을 보장하거나 복잡한 조인 요구사항이 있는 경우 페스트와 같은 Mongo 유형 시스템을 사용하지 마십시오.

또 다른 차이점은 속도보다는 개념화에 더 가깝다는 것입니다(문제에 참여할 수 있는 공간이 적기 때문에 속도에 도움이 될 수도 있다고 생각합니다). 문서 기반 스토리지는 객체 지향적 사고방식과 매우 유사하다는 것입니다.

문서 기반이 완벽하게 ACID는 아닐 수도 있지만, MongoDB는 SQL DB의 모든 조인을 방해하고 잘못된 조인을 감수하는 것보다 문서 전체를 가져오는 것만으로 원하는 것을 얻는 것이 더 쉽다고 생각합니다.

모든 SQL 열성 팬들에게 사과드립니다.

MongoDB의 웹사이트에 따르면, MongoDB는 사용자가 원하는 확장성과 유연성, 그리고 필요한 쿼리와 인덱싱을 갖춘 문서 데이터베이스입니다.

이것이 실제로 무엇을 의미하는지 이해해 보겠습니다.MongoDB는 문서 기반이므로 JSON과 같은 필드 값 쌍의 데이터 구조인 문서에 데이터를 저장합니다.또한 기존 관계형 데이터베이스와 같이 테이블의 행 대신 이러한 문서에 데이터를 저장합니다.따라서 NoSQL 데이터베이스이며 관계형 데이터베이스가 아닙니다.

또한 MongoDB에는 확장성이 내장되어 있어 앱이 점점 더 많은 사용자를 확보하고 엄청난 양의 데이터를 생성하기 시작함에 따라 여러 컴퓨터에 데이터를 매우 쉽게 배포할 수 있습니다.그래서 여러분이 무엇을 하든, MongoDB는 여러분이 성장할 수 있도록 매우 쉽게 해줄 것입니다.

MongoDB의 또 다른 큰 특징은 뛰어난 유연성입니다.데이터로 채우기 전에 문서 데이터 스키마를 정의할 필요가 없습니다. 즉, 각 문서는 필드 수와 유형이 다를 수 있습니다.그리고 우리는 이 필드들을 항상 바꿀 수도 있습니다.이 모든 것은 실제 비즈니스 상황과 일치하므로 매우 유용할 수 있습니다.

MongoDB는 내장된 데이터 모델, 인덱싱, 샤딩, 제가 믿는 유연한 문서, 네이티브 복제 등과 같은 기능 덕분에 매우 성능이 뛰어난 데이터베이스 시스템이기도 합니다.그리고 그것은 SSPL 라이선스 하에 출판된 자유-오픈 소스 데이터베이스입니다.

요약하자면, MongoDB는 다양한 유형의 확장 가능하고 유연한 웹 애플리케이션을 구축할 수 있는 훌륭한 데이터베이스 시스템이라고 할 수 있습니다.실제로 Mongo는 노드 JS에서 가장 많이 사용되는 데이터베이스일 것입니다.

이제 블로그 게시물의 예를 들어 이러한 문서에 대해 좀 더 자세히 알아보겠습니다. MySQL과 같은 관계형 데이터베이스나 Excel 스프레드시트에서 동일한 데이터가 행처럼 보일 수 있는 방법입니다.

MongoDB는 BSON이라는 데이터 스토리지에 JSON과 유사한 데이터 형식을 사용합니다.IT는 기본적으로 JSON과 동일하게 보이지만 입력되어 있습니다. 즉, 모든 값이 String, Boolean, Date 및 Object(예: 교사 개체, Double Object) 등의 데이터 유형을 가집니다.이것은 모든 MongoDB 문서가 실제로 입력된다는 것을 의미합니다. 이것은 JSON과는 다릅니다.

JSON과 마찬가지로 이러한 BSON 문서에도 필드가 있으며 데이터는 키-값 쌍으로 저장됩니다.관계형 데이터베이스에서는 각 필드를 열이라고 하며 JSON 데이터가 훨씬 유연한 반면 데이터베이스는 테이블 구조의 데이터를 정렬합니다.

위 그림의 태그 필드를 예로 들어 보겠습니다. 여기에는 실제로 배열이 있으므로 기본적으로 한 필드에 대해 여러 값이 있지만 관계형 데이터베이스에서는 이 값이 허용되지 않습니다. 한 필드에 여러 값이 있을 수 없습니다.따라서 관계형 데이터베이스에서 이 문제에 대한 해결책을 찾아야 합니다. 그러면 더 많은 작업과 더 많은 전체적인 복잡성이 수반될 수 있습니다.

MongoDB의 또 다른 매우 중요한 기능은 임베디드 문서의 개념인데, 이는 관계형 데이터베이스에는 존재하지 않습니다.주석 필드에는 각 문서에 하나씩, 세 개의 개체가 포함된 배열이 있습니다.그래서 우리가 댓글 모음을 가지고 있다고 상상해 보세요. 각각의 댓글들은 실제로 이렇게 보일 수 있습니다. 그래서 저자와 댓글 텍스트로 말이죠. 하지만 그렇게 하는 대신에, 우리는 이 댓글들을 블로그 게시물 문서에 바로 포함시킵니다. 다시 말해서,우리는 댓글 문서를 게시 문서에 바로 포함합니다. 이것은 기본적으로 일부 관련 데이터를 하나의 문서에 모두 포함시키는 임베딩 또는 비정규화 과정입니다.

위의 예에서 주석은 게시물 및 운영 체제와 관련되어 있으며, 이는 일부 상황에서 데이터베이스의 성능을 향상시킵니다. 이렇게 하면 필요한 모든 데이터를 한 번에 더 쉽게 읽을 수 있기 때문입니다.

임베딩 또는 비정규화의 반대는 정규화이며, 이는 관계형 데이터베이스에서 데이터를 항상 모델링하는 방식입니다.위의 예제에서는 관계형 시스템에 데이터를 포함할 수 없습니다. 해결책은 주석에 대한 완전히 새로운 테이블을 만든 다음 주석 테이블의 ID 필드를 참조하여 테이블을 결합하는 것입니다.

BSON 문서에 대해 알아야 할 두 가지 사항:

첫째, 각 문서의 최대 크기는 현재 16MB입니다.

둘째, 각 문서에는 해당 문서의 기본 키 역할을 하는 고유 ID가 포함되어 있으며, 새 문서가 있을 때마다 개체 ID 데이터 유형으로 자동 생성되므로 걱정할 필요가 없습니다.

Mongodb는 스키마를 확인하고 외부 키를 확인하지 않기 때문에 삽입 및 업데이트가 훨씬 빠르지만, 속성으로 데이터를 읽고 검색할 때, 특히 인덱스 키가 없는 경우 항상 더 빠른 것은 아닙니다.

자세한 내용은 여기에서 확인하십시오. https://www.youtube.com/watch?v=K8xsuFgCRkU

언급URL : https://stackoverflow.com/questions/5186707/why-is-mongodb-so-fast