MongoDB에서 시작하는 데이터베이스 지식에 대한 간략한 토론

이 기사는 MongoDB에서 시작하여 데이터베이스 지식에 대한 간략한 설명을 제공합니다. 이는 특정 참고 가치가 있으므로 도움이 될 수 있습니다.

오늘의 주제는 MongoDB의 데이터베이스에 대한 이야기입니다. 일상적인 프로젝트에서는 보통 mysql을 데이터베이스로 사용하는데, 문제가 생기면 "MongoDB로 바꾸는 게 어때요?"라는 소리를 자주 듣습니다. 데이터베이스 이야기

데이터베이스란 무엇입니까

가장 쉽게 말하면 데이터베이스는 데이터를 저장하는 창고입니다

데이터베이스의 기본 개념

• 데이터베이스는 정리하고, 저장하고, 저장하는 창고입니다. 특정 데이터 구조에 따라 데이터를 관리합니다

• 우리가 작성하는 프로그램은 모두 메모리에서 실행됩니다. 프로그램이 종료되거나 컴퓨터가 중단되면 프로그램의 모든 데이터가 손실됩니다. 데이터 보안을 보장하는 키보드.

• 데이터베이스는 대용량 데이터 지속성을 위한 일반적인 선택입니다. 1. 파일 2. 데이터베이스

데이터를 저장하기 위해 데이터베이스를 사용하는 이유

• 데이터베이스는 구조화되어 있습니다.

• 데이터베이스는 다양한 인터페이스를 제공할 수 있습니다. 빠르고 편리한 데이터 처리(추가, 삭제, 수정, 확인)

• 다양한 언어 ​​​​(PHP, jsp, .net..)으로 완벽한 인터페이스 제공

데이터베이스 인기 (출처: https: //db-engines.com/ko/ranking)

통계 데이터를 보면 가장 많이 사용되는 DBMS는 "관계형"으로 상위 5개 중 4개를 차지하고 데이터가 상위까지 확장되는 것을 알 수 있습니다. 10개, 관계형 데이터베이스도 7개를 차지합니다.

대부분의 프로그래머가 MySQL 사용을 선호하는 이유는 무엇입니까?

• 오픈 소스, 기업만 라이선스 구매 필요

• 널리 사용됨: Linux, Windows, Ubuntu, Mac OS X 등과 같은 대부분의 플랫폼에서 널리 사용할 수 있습니다.

• 사용하기 쉽습니다

• 신뢰성: 수년간 시도 및 테스트됨

• PHP와 작동하며(PHP는 세계 최고임) JAVA, PERL, C, C++ 등과 같은 다른 프로그래밍 언어와도 사용할 수 있습니다.

• 소규모 및 대규모 애플리케이션에 적용됩니다

관계형 데이터베이스가 그렇게 좋다면 MongoDB가 여전히 상위 5위에 포함되는 이유는 무엇일까요? 살펴보겠습니다

관계형 데이터베이스와 MySQL의 단점은 무엇인가요?

• 확장성: 특정 레코드에 더 많은 데이터를 추가하려면 여러 테이블, 열 및 행으로 확장해야 할 수 있으며, 데이터가 행별로 저장되므로 관계형 데이터베이스는 저장 장치에서 전체 데이터 행을 읽습니다.

• 첫 번째 항목에서 발생한 단점은 데이터 구조를 저장할 수 없다는 점입니다

• 속도: 데이터 구조의 문제로 인해 데이터 분석이 필요합니다. 일정 시간이 걸리며, 테이블 데이터가 점차 커지면 인덱스가 있어도 유사 쿼리의 매칭이 매우 느려집니다.

• 사용하기 전에 테이블을 정의하려면 먼저 스키마를 작성해야 하며 동시에 테이블 구조 스키마를 확장해야 하는 경우에는 DDL(데이터 정의 언어) 및 명령문 수정을 수행해야 합니다. 수정하면 테이블이 잠깁니다.

MongoDB가 이렇게 매력적인 이유는 무엇일까요?

• 유연성: 문서 구조는 개발자가 언제든지 데이터/문서를 쉽게 추가하고 편집할 수 있도록 명확하고 키-값 쌍으로 구조화된 각 프로그래밍 언어로 코딩하는 방식과 더 일치합니다

• 다양한 쿼리 지원: 필드, 표현식, 범위 쿼리, JavaScript 함수 등

• 더 빠른 처리 시간: MySQL 데이터베이스의 여러 테이블에 저장된 관련 데이터가 MongoDB의 동일한 문서에 저장되므로

• 아니요 엄격한 스키마: 문서 구조를 정의하기 전에 문서를 생성할 수 있습니다

• MongoDB의 기능은 대용량 데이터 처리에 더 적합합니다

자세히 설명하기 전에 먼저 둘을 비교해 보겠습니다

	MySQL	MongoDB
Version	1995-2018(mysql 8.0)	2009
구조	관계형	비관계형
유연성	약함, 사용하기 전에 데이터베이스 스키마 정의 필요	MySQL에 비해 상당한 유연성 - 불필요한 스키마 정의
확장성	예, 하지만 더 어려운 점은 MySQL 데이터베이스를 수직으로 확장할 수 있으며, 더 많은 리소스를 단일 서버에 추가할 수 있다는 것입니다.	MySQL보다 확장성이 뛰어납니다. MongoDB는 수평 확장이 가능하므로 더 많은 서버를 추가하여 데이터베이스를 확장할 수 있습니다.
DB 관리자 필요	예	아니요 - 개발자와 관리자 모두 사용 가능
적용 가능한 시나리오	회계 회사, 은행 및 기타 회사 명확한 스키마를 갖춘 구조화된 데이터가 필요한 경우 다소 고정된 요구 사항(트위터 제외)이 있는 비즈니스에 이상적입니다.	실시간 데이터, IoT, 콘텐츠 관리, 모바일 앱, 소셜 네트워크, 빅 데이터/네트워크 분석 지향 시스템 및 명확한 요구 사항이 없는 시스템을 갖추고 있습니다. 아키텍처 또는 아키텍처 구조화된 데이터 비즈니스를 위한 이상적인 선택은 계속 변합니다

유연성

먼저 유연성에 대해 이야기해 보겠습니다. 예를 들어 쇼핑몰에는 많은 제품이 있으며 이러한 제품에는 고유한 속성이 있습니다. 예를 들어 TV에는 화면 크기와 화면 해상도가 있고 에어컨에는 냉장 기능이 있습니다. 유형 및 외부 머신 노이즈와 같은 속성을 제품 테이블에 넣는 것은 매우 어려우므로 프로그래머가 데이터 테이블을 설계하는 데 추가 작업이 추가됩니다. 그러나 MongoDB는 스키마(스키마, 데이터 모델)가 없으면 매우 간단합니다.

MongoDB의 유연성은 비정형 및 반정형 데이터에도 반영됩니다. MongoDB는 전체 텍스트 인덱싱을 제공하고 지리적 위치 쿼리 및 인덱싱도 지원합니다. 예를 들어, 사용자가 반경 5km 내에 공중화장실이 어디에 있는지 알고 싶어합니다. 이는 "지리적 범위 쿼리"입니다. 그런 다음 그는 가장 가까운 자전거를 검색합니다. Mobike는 MongoDB를 사용하여 이러한 "거리 정렬 쿼리"를 완료합니다.

확장성

데이터를 한 머신에 담을 수 없다면, 여러 머신에 담기 위해서는 샤딩(sharding)이 필요합니다. 샤딩은 수년 동안 MongoDB의 기본 기능이었으며 다른 MongoDB 기능과 효율적으로 통합되었습니다.

예를 들어, 샤딩된 클러스터의 복잡한 집계 쿼리는 샤드 키(샤드 키)를 기반으로 여러 노드에서 실행되도록 자동으로 할당되고, 컴퓨팅 작업은 최대한 데이터 노드로 푸시됩니다. 마지막으로 노드에서 모든 노드의 결과를 집계합니다. 샤딩은 노드 간에 데이터를 자동으로 마이그레이션하여 데이터 볼륨의 균형을 맞출 수도 있습니다. 동시에 MongoDB의 복제(복제본 세트) 기술과 결합하면 데이터 손실을 효과적으로 방지할 수 있습니다. (테스트 중에 mongo가 자동으로 복제본 세트의 모든 머신 주소를 검색하는 것으로 나타났습니다. Mongo가 중지되면 연결된 서버가 오류 보고 안 함)

MongoDB에서 샤딩된 클러스터 구조 배포 사용:

MongoDB의 단점

• 우리 모두 알고 있듯이 MongoDB는 서버 메모리를 많이 차지합니다

• MongoDB는 약간 적습니다. secure

• 너무 자유롭고 유연한 파일 저장 형식으로 인해 발생하는 데이터 오류(...)

• 단일 문서의 크기는 16M로 제한됩니다.

• 배열형 데이터 작업에는 충분하지 않습니다

MongoDB를 선택하는 경우

시시콜콜한 요약을 많이 했지만 가장 중요한 것은 MongoDB를 선택했을 때입니다

• 시스템 운영 중에 생성되는 로그 정보는 일반적으로 다양한 종류가 있습니다. 범위가 넓고 내용도 비교적 지저분합니다. 이러한 지저분한 로그는 MongoDB

• 지리적 위치 저장을 통해 수집 및 관리할 수 있습니다. MongoDB는 지리적 위치, 2차원 공간 인덱스를 지원하고 경도와 위도를 저장할 수 있으므로 두 지점 사이의 거리 및 기타 위치 정보를 빠르게 계산할 수 있습니다.

• 데이터 규모가 빠르게 증가하고 있음(주의 정보 공급 등)

• 고가용성 환경 보장 필요

• 파일 저장 요구 사항

• 기타 시나리오, 예: 게임 개발, 사용자 정보는 물류 시스템, 소셜 시스템, 심지어 사물 인터넷 시스템 외에도 MongoDB, 장비, 포인트 등을 통해 저장될 수 있습니다

데이터베이스의 종류

그렇게 말하지만 우리는 mysql과 MongoDB를 왜 넣나요? 서로 비교하고 선택하기 위해서죠? 데이터베이스의 개발부터 현재까지 크게 세 가지 유형으로 나뉘거든요

RDBMS(관계형 데이터베이스)

먼저 언급해야 할 것은 관계형입니다. 우리에게 가장 친숙한 mysql 데이터베이스가 속한 데이터베이스입니다.

관계형 데이터베이스의 특징:

• MySql, SQL Server Oracle 등

• 특징은 테이블을 통해 관계를 구축하는 것입니다.

• 기본적으로 SQL 언어를 사용하여 데이터베이스를 관리합니다.

Nosql( 비관계형 데이터베이스)

NoSql은 MongoDB의 데이터베이스 유형으로 2009년 샌프란시스코에서 열린 Meetup에서 유래되었습니다. Meetup에 등장한 NoSql 기술에 대한 설명은 오픈 소스, 분산, 비관계형 데이터베이스

비관계형 데이터베이스의 특징:

• 행과 열의 개념이 없으며 json 클래스를 사용하여 데이터를 저장합니다.

• 컬렉션은 "테이블"과 동일하고 문서는 "행"과 동일합니다

• 마찰의 표준화 및 비표준화.

• 표준화는 혁신을 제한하고, 비표준 단어는 통합할 수 없습니다

NoSql은 처음 제안되었을 때 Non-Relational로 해석되었으며, 또한 No-SQL을 의미하기도 했습니다. 그러나 최근 몇 년간 급속한 발전으로 인해 SQL은 점차 다양한 분야에서 사용되기 시작했으며, 따라서 SQL은 더 이상 RDBMS의 전유물이 아니며, NoSql 기술 시스템에도 SQL 기능이 도입되면서 Not-Only-SQL이라는 개념이 발전했습니다.

대부분의 NoSql 기술은 ACID 의미 체계 및 복잡한 관련 쿼리에 대한 지원을 약화시키고, 더 단순하거나 더 전문적인 데이터 모델을 채택하고, 더 높은 읽기 및 쓰기 성능을 위해 교환할 수 있는 읽기 및 쓰기 경로를 최적화합니다.

NewSql

위키의 정의에 따르면

NewSQL은 온라인 트랜잭션 처리를 위해 NoSQL 시스템과 동일한 확장 가능한 성능을 제공하려는 최신 관계형 데이터베이스 관리 시스템의 한 클래스입니다. (OLTP) 읽기-쓰기 워크로드를 처리하는 동시에 기존 데이터베이스 시스템의 ACID 보장을 유지합니다. 분산 관계형 데이터베이스로 이해하면 분산 트랜잭션을 지원할 수 있는 기본 전제 조건입니다. NoSQL과 NewSQL은 기술 스택에서 중복되는 부분이 많지만 관계형 모델을 지원하는지 여부와 복잡한 트랜잭션을 얼마나 잘 지원하는지에 있어서는 분명한 차이가 있습니다. 나는 그것에 대해 많이 알지 못하기 때문에 여기서는 많은 말을 하지 않겠습니다.

여기에서는 데이터베이스의 종류를 간단히 소개합니다. NoSql, NewSql, RDBMS에 속하는 스토리지 기술은 결국 MySQL과 같이 끊임없이 발전하고 있습니다. nosql 기능과도 호환됩니다:

또는 일부 사람들은 왜 MongoDB의 단점에 대한 소개가 없는지 궁금해할 수도 있습니다. 이는 2018년 여름 MongoDB 4.0 버전에서 MongoDB가 트랜잭션 기능을 도입하고 트랜잭션 작업에 mongo 쉘을 사용하는 등 다중 문서 ACID 기능을 지원했기 때문입니다

#🎜 🎜#

구체적인 스트레스 테스트 데이터는 추후 추가됩니다

위 내용은 MongoDB에서 시작하는 데이터베이스 지식에 대한 간략한 토론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!