내 경우에는 MongoDB가 올바른 선택입니까? [닫은]

3 가지 주요 부분으로 구성된 웹 앱으로 구성된 Rails에서 첫 번째 실제 프로젝트를 빌드하려고합니다.

• 데이터베이스가 사용되지 않는 정적 부분
• 데이터베이스가 필요하고 각 사용자의 행이 동일한 필드를 가지므로 MySQL을 사용할 수있는 사용자 등록 부분
• 사용자가 컬렉션의 항목을 생성, 구성, 편집하고 다른 사용자와 공유 할 수있는 "앱"

몇 가지 항목 유형이 있으며 각 항목마다 다른 옵션이 있습니다. 예를 들어 다음 옵션이있는 "비디오"항목이있을 수 있습니다.

• 신분증
• user_id
• collection_id
• 표제
• 플랫폼 (포함 된 경우)
• url (포함 된 경우)
• 파일 이름 (내 앱에서 호스팅 된 경우)
• 파일 크기 (내 앱에서 호스팅 된 ID)

및 "지도"항목 :

• 신분증
• user_id
• collection_id
• 표제
• 플랫폼 (구글 맵, 빙 맵 ...)
• 위치
• url
• 지도 크기

사용자가 할 수있는 것처럼 항목에 MySQL을 사용할 수 있습니다 .MongoDB의 유연성은 각 항목마다 다른 옵션이 필요할 수 있으므로 유용 할 수 있습니다.

지금까지 나는 항상 PHP와 MySQL (작은 프로젝트를위한 공유 호스팅)을 사용해 왔으며 확장 성은 완전히 새로운 단어입니다.

배울 시간이 있지만 1 개월 정도의 구체적인 일을하고 싶습니다.

MongoDB 및 NoSQL vs RDMS 및 MySQL에 대해 많이 읽었으며 그것을 시도한 후 MongoDB의 작동 방식을 좋아한다고 말해야합니다. 테이블, 행 및 문서 JSON과 같이 :

• 내 상황에서 당신은 무엇을 raccomend 하시겠습니까? 왜?
• 확장성에 대해 MongoDB에 문제가 있습니까? 그렇다면 (DB 크기 측면에서) 언제 이러한 문제로 인해 앱 속도가 상당히 느려질 수 있습니까?

편집 : 앱 작동 방식

많은 사람들이 이것이 앱이 어떻게 작동하고 싶은지 물었습니다.

1. 사용자 가입
2. 그는 로그인했다
3. 그는 무한한 아이템을 만들 수있는 첫 번째 컬렉션 iside를 만듭니다.
4. 항목은 다양한 유형이며 각 유형은 데이터베이스에 저장하기 위해 서로 다른 데이터가 필요하며 항목 유형은 추가 또는 수정 될 수 있습니다

사용자는 그 안에 다른 컬렉션과 항목을 만들 수 있습니다.

그래서 우리는 컬렉션과 그 안의 아이템에 대한 CRUD를 가지고 있으며 각 컬렉션 / 아이템은 특정 사용자에게 추천됩니다.

MySQL의 주요 문제점은 유연한 스키마가 아니라는 것을 해결할 수있는 방법이 있다는 것입니다 (해결 방법?).

NoSQL에 대한 유일한 의심은 조인에 관한 것입니다.

편집 : MySQL을 계속 사용하는 아이디어

"설정"테이블에서 선택적 설정으로 필드를 작성하십시오. 각 설정은 | 또는 다른 상징.

그런 다음 각 항목의 선택적 설정 구조를 어딘가에 저장합니다. 예를 들어 "notes"항목 유형에는 두 가지 선택적 설정 "colour"및 "strange_setting"이 필요합니다. MySQL에서 데이터를 가져올 때 선택적 설정 필드를 배열의 첫 번째 항목이 "색상"등임을 알고있는 배열.

어떻게 생각해? 그 솔루션에 문제가 있습니까? 다른 아이디어가 있습니까?

앱으로 무엇을할지 알려줄 때까지 도와 드릴 수 없습니다. 관계형 데이터베이스는 특정 작업에 적합하고 NoSQL 데이터베이스는 다른 작업에 적합합니다.

누군가가 한 번 여기 저에게 이렇게 말했듯이 :

관계형 DB의 관계형 부분은 다른 부분보다 훨씬 최적화되어 있습니다.

관계형 데이터베이스가 사용 사례에 맞는 경우에도 사용할 수 있음을 의미합니다. 유연성 / 확장 성 때문에 MongoDB를 계속 사용하지 마십시오. 이것은 Wikipedia의 MongoDB에 관한 첫 번째 라인입니다.

MongoDB ( "humongous")는 오픈 소스 문서 지향 NoSQL 데이터베이스 시스템입니다.

실제로 문서 지향 DB를 사용 하시겠습니까? 사용 사례에 약간의 그래프가있는 경우 Neo4j와 같은 그래프 데이터베이스를 사용하는 것이 좋습니다. 또는 일부 사람들과 마찬가지로 SQL과 NoSQL을 모두 함께 사용할 수 있습니다.

BTW, 나는 또한 SQL과 NoSQL의 가장 좋은 부분을 사용하는 프로젝트를 수행하고 있습니다.

편집 : 다시 한 번 말합니다.

이 기사 에서 Neo4j vs Hadoop 섹션을 확인 하십시오. 그것은 말한다 :

원칙적으로 하둡 및 기타 키-값 저장소는 주로 비교적 평평한 데이터 구조와 관련이 있습니다. 즉, 값, 문서 또는 객체와 같은 간단한 객체 검색과 관련하여 매우 빠르고 확장 가능합니다.

같은 기사를 참조하면 실제로 MongoDB에 사용할 플랫 데이터 구조가 필요합니까? 이는 결국 자세한 사용 사례, 3 단계 및 4 단계 수행 방법에 따라 다릅니다.

또한 다음 질문을 참조 할 수도 있습니다.

/programming/2124274/mongodb-what-to-know-before-using

/programming/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

( 두 번째 질문의 상단 / 선택된 답변을 확인하십시오.이 문제가 해결 될 수 있다는 딜레마에 빠졌습니다. )

나는이 질문들에 당신이 알고 싶은 모든 정보가 있다고 생각합니다. 결국, 그것이 MongoDb인지 또는 다른 것을 결정 해야하는 것은 당신입니다. 우리는 단지 추천 할 수 있습니다. 자세한 사용 사례를 아는 유일한 사람은 귀하와 팀입니다.

다시 편집 (MySQL 부분의 경우) : 이해했듯이 db에 무언가를 저장하고 구분 기호를 통해 분리하려고 계획하고 있습니다. 이것은 두 가지 문제를 제시합니다 :

1. 구분 기호가있는 입력을 추가로 처리해야합니다.
2. 관계형 데이터베이스의 관계형 저장 부분은 문자열 일치 부분보다 훨씬 최적화되어 있습니다. 특정 결과를 얻기 위해 데이터베이스에서 문자열 일치를 수행 해야하는 구성표를 사용하지 않을 것입니다. 다시 강조하고 있습니다.

   관계형 DB의 관계형 부분은 다른 부분보다 훨씬 더 최적화되어 있습니다 (예 : 문자열 일치)

3. 다중 값 특성을 사용하지 마십시오. 사람들은 일반적으로 그들을 두려워합니다.

나는이 질문을 많이 본다. 그것은 항상 하나 또는 / 또는 것으로 생각되는 것 같습니다. MongoDB는 훌륭한 새 도구입니다. 또한 때로는 모든 것을위한 반짝이는 도구 인 것처럼 보이며 내 경험에 따라 선택하기가 어려울 수 있습니다.

가장 좋은 조합은 모두 BOTH라고 생각하며 사용자와 같은 일부 부분에 mylsql을 사용하는 방법에 대해 추천하고 싶지만 인증 및 권한 부여가 mySQL에서 가장 잘 수행된다고 생각되면 다른 부분에 MongoDB를 사용하십시오. 이 작업을 실제로 수행하는 수많은 예제와 모듈.

'더 많은 수의 항목'조각의 경우, 볼륨이 높거나 주로 읽거나 구조화되지 않은 데이터 인 경우 mongoDB를 사용하는 것이 좋습니다.

몽고의 스키마없는 유연성에 근거하여 결정을 내리지 말 것을 권합니다. SQL 및 sql- 스키마는 구조화 된 데이터가 있어야하고 이러한 구조에서만 가능한 계산 및 변환을 수행 할 수 있어야한다는 필요성에서 비롯되었습니다. 5 년 동안 데이터웨어 하우스 역할을 수행하면서 이것을 배웠습니다. 성능 문제에 대해서만 MongoBD를 찾습니다. 대량의 사용자 및 요청, 즉 100,000 명의 사용자와 20 개의 요청을 초당 요청하는 경우 mongoDB를 사용하고 그렇지 않으면 sql을 사용하려고 시도합니다. 많은 경우에 나는 저용량으로 mySQL을 사용한 다음, 수량, 수입 및 인프라가 지원할 때 mongoDB에서 혼합하기 전에 Oracle로 전환합니다. 볼륨 문제를 경험하기 전에 다루지 말아야한다는 데 동의하지만, 어디로 향하고 있는지에 대한 공정한 아이디어가 있다면 반쯤 다시 작성하고 싶지 않다면 처음 시작할 때 올바른 기술을 선택하는 것이 합리적입니다. 실제로 볼륨이 큰 경우 모든 수준의 스택에 사용할 옵션과 기술이 엄청나다는 것을 기억하십시오.

느슨하게 구조화 된 데이터에는 단점이 있습니다. 여기 주차장 비유를 사용합니다. 진입하는 최초의 3 대의 차량에는 분할 선이 좋지 않지만, 더 많은 차량이 진입함에 따라 많은 탈선이 일어나기 시작하고 주차하거나 쉽게 차를 세고 차선을 자유롭게 유지하려고 시도하는 것은 악몽이됩니다. 이것을 구성하면 선과 분배기 및 트래픽 흐름 등을 표시하는 것이 좋습니다. 때로는 상황이 바뀔 때 (자동차가 커짐) 선을 다시 칠해야합니다. 또한 연간 재 도장 및 유지 보수를위한 표준 다운 타임을 제공합니다.

스키마 디자인 측면은 아마도 전통적인 MySQL 사용자에게는 가장 큰 장애물이 될 것입니다. 스키마 디자인 의 MongoDb 페이지가 도움이된다고 생각합니다 . 마지막 요점은 믹스에 추가하는 모든 기술이 복잡성을 더한다는 것입니다. 당신이 그것을 사용하는 "있다"고 말할 특정 조각에 대한 거대한 옹호자들이 종종 있지만, 나는 정말로 큰 요소가 몇 조각인지 발견했습니다. 그것은 더 많은 실패 지점과 다른 누군가가 그 문제를 해결하기 위해 알아야하는 지식 기반의 대부분을 의미합니다.

fyi Rick Obsorne은 매우 독특한 비교 도표 를 가지고 있습니다!

NoSQL과 MySQL에 대한 많은 유효한 주장이 있습니다. 그러나 하나의 누락 된 링크는 확장에 관한 것입니다. 실제로 확장하고 사내 데이터베이스를 사용하여 확장하려는 경우 데이터베이스에 대한 많은 지식이 필요합니다. 사람들이 무한히 확장 할 수있는 시스템을 구현하려는 데 실패한 공포 이야기가 너무 많습니다.

실제로 NoSQL 라우트를 선택하고 (조인이없는 것처럼 그에 따른 비용을 지불 할 준비가 되었으면) AWS DynamoDB (http://aws.amazon.com/dynamodb/)를 고려하십시오. 여기서 전체 데이터베이스 스케일링 부분을 잊어 버리고 응용 프로그램에 집중할 수 있습니다. 행운을 빕니다.

면책 조항 : 저는 AWS DynamoDB 팀의 개발자이지만 제품을 진심으로 믿고 있습니다. 시도해보십시오 :)

따라서 디자인은 두 가지 종류의 객체를 데이터베이스에 저장하게됩니다.

• 사용자 필드 (항상 필드가 있음).
• Apps 객체 (다른 필드를 가질 수 있음). 앱은 한 명의 사용자에게만 속합니다.

컬렉션은 다른 앱을 그룹화하기위한 태그 일뿐 아니라 다른 개체로 만들 수 있거나 없습니다. 주장을 위해 컬렉션이 없으며 사용자에게 응용 프로그램 목록 만 있다고 가정 해 봅시다.

MySQL에서 달성 할 수 있다고 생각하지만 MongoDB에서는 앱 객체의 구조 측면에서 유연성이 높으며 아마도 자연스럽게 표현을 데이터베이스에 매핑하여 코드를 간단하게 만들 수 있습니다.

MySQL에서는 앱마다 다른 형식을 처리하는 데 문제가 있지만 가능합니다. 몇 가지 아이디어 :

• 모든 객체 (id, user_id, title 등) 사이에 모든 공통 정보가 포함 된 중간 테이블을 만든 다음 유형을 사용하여 해당 형식에 대해 공통이 아닌 필드 만 사용하여 다른 테이블에서 검색 할 수 있습니다 (예 : 파일의 경우 file_name 및 file_size). 각 형식마다 다른 테이블을 만들어야합니다. app_id (기본 키)로 두 테이블을 모두 색인화하면 색인화 된 값으로 테이블에 액세스하는 것이 빠르기 때문에 충분히 빠릅니다.
• 일부 형식으로 데이터를 인코딩하고 표준화 된 상태로 저장할 수 있습니다. 예를 들어, JSON에서 일반적이지 않은 데이터를 문자열로 인코딩하여 VARCHAR 필드에 저장하십시오. 공간이 부족하지 않도록 해당 필드의 크기에주의하십시오. 형식은 복잡하거나 (JSON) 단순 할 수 있습니다 (값은 쉼표로 구분됨)
• int1, int2, str1, str2와 같은 다른 "일반"필드를 생성하고 앱 유형에 대한 str1은 "file_name"이고 다른 유형에 대해서는 "location"이되도록 정의 할 수 있습니다.

MongoDB에서 두 개의 MongoDB 컬렉션을 사용하는 것만 큼 간단합니다. 하나는 사용자 용이고 다른 하나는 앱용입니다. 어떤 종류의 제한을 가정하면 (이것은 설명하지 않았지만 단지 말을 위해) 앱을 사용자 객체 내부에 목록으로 저장할 수도 있습니다. 필드에 관계없이 모든 종류의 객체를 저장할 수 있으므로 데이터를 저장하고 검색하는 것이 더 자연 스럽습니다. user_id로 검색하여 사용자에게 속한 모든 앱을 얻을 수 있습니다. MongoDB에서는 어쨌든 조인 쿼리를 수행 할 가능성을 잃어 버렸지 만이 경우 기본 쿼리가 사용자를 검색하고 사용자와 관련된 앱을 검색한다고 생각합니다. "각 응용 프로그램이 3 개 이하인 컬렉션이 2 개 이상인 사용자에게 제공"과 같은 많은 작업을 수행하려는 경우 조인 쿼리가 아닌 생성해야합니다. 그러나 코드의 프로세스로서 관계형 데이터베이스보다 자연스럽지 않고 처리하는 데 더 많은 시간이 걸릴 수 있습니다. 매개 변수를 검색하려면 (예를 들어 특정 사용자에게 속한 모든 응용 프로그램을 제공하십시오. X 유형의 모든 응용 프로그램을 제공하십시오) MongoDB에서는 매우 쉽고 조인을 사용할 필요가 없습니다.

MongoDB on Rails의 지원에 대해 잘 모르겠습니다. 파이썬과 JavaScript에서 사용했습니다.

편집 : 두 테이블에 액세스 할 때 시간과 다른 MySQL 옵션에 대한 의견 추가

특히 실제 프로젝트이고 빠르게 추진하고 싶다면 가장 잘 알고있는 기술을 사용하십시오. MySQL과 Mongo를 사용하면 고유의 이점과 두통이 함께 제공됩니다. 두 가지 모두를 다루면서 훌륭한 디자인 원칙을 따르는 경우 MySQL에서 Mongo로 마이그레이션하는 것이 그리 어렵지 않다고 덧붙입니다.

당신의 경우에 MongoDB와 함께 갈 좋은 이유 중 하나는 데이터입니다. 언급했듯이지도, 비디오 등 여러 가지 컬렉션 유형의 항목이 있습니다. RDBMS를 사용하여이를 구현하는 경우 3 가지 접근 방식이 있습니다.

• 유형별 테이블 : 각 테이블에는 각 유형의 객체에 특정한 열이 포함됩니다.

  단점 : 모든 데이터 유형을 검색하는 N 쿼리.

  장점 : 좋은 OO 디자인, 쉽게 유지 관리

• 단일 테이블 : 모든 유형에 대해 가능한 모든 속성을 포함하는 하나의 거대한 테이블

  단점 : 개체를 변경하면 테이블이 커지면 변경 테이블이 필요합니다. 유지하기 어렵다.

  장점 : 구현하기 쉽습니다.

• 메타 데이터가 포함 된 핵심 테이블 : 핵심 속성 (예 : 제목, 날짜) 및 추가 속성에 대한 키-값 쌍이있는 메타 데이터 테이블이있는 단일 테이블이 있습니다.

  단점 : 단일 객체에 대한 모든 데이터를 가져 오는 두 개의 쿼리.

  장점 : 매우 유연하고 구현하기가 어렵지 않습니다.

나는 이전에 이러한 각 접근 방식을 사용했으며 몽고와 자연스럽게 일하는 것은 없다고 말할 수 있습니다. 데이터는 아마도 다음과 같습니다.

{_id:"collection1",
 name:"My first Collection",
 owner: "user123243342",
 entries: [
    {type:"video",
     url: "http://www.youtube.com/234324",
     tags: ["roadtrip", "fun", "camera"]
     },
    {type:"map",
     coordinates: [LOC: [38, –102], LOC: [43, –33], LOC: [228, –102]],
     description: "Road trip to nowhere",
 ]
}

그러나 도메인 개체를 그대로 유지할 수 있으므로 스키마 디자인에 대해 걱정할 필요가 없습니다. MongoDB는 본질적으로 쿼리 할 수있는 객체 저장소입니다.

MySql과 Mongodb의 성능 비교에 대한 토론은 생략했습니다. 항상 성능을 염두에 두어야하지만 데이터 액세스 패턴을 모르면 효과적으로 의사 결정을 내릴 수 없습니다. 좋은 프로젝트는 성장하고 새로운 과제가 발생함에 따라 리팩토링을 몇 차례 반복해야 할 것입니다. 조기 성능에 대해 걱정하지 말고 가장 잘 알고있는 도구를 선택하고 코딩을 시작하십시오.

편집하다

"|"를 사용하여 MySQL을 사용하고 동일한 필드에 속성을 유지하는 것에 대한 특정 질문에 응답합니다. 이러지 마 이 접근법은 해결하는 것보다 더 많은 문제를 줄 것입니다. 우선, MySql을 사용하여 개별 속성에 대해 쿼리 할 수 ​​없습니다. 둘째, 데이터 액세스 계층에 너무 많은 복잡성을 추가합니다. 대신 테이블 당 유형 또는 메타 데이터 접근 방식을 사용하십시오. 이전에 WordPress로 작업 한 경우 메타 데이터 접근 방식을 사용합니다.

• 사용자 테이블 + 사용자를위한 usemeta
• 포스트 테이블 + postmeta 테이블 포스트

따라서 데이터 구조가 매우 유연하고 합리적인 속도로 쿼리 할 수 ​​있습니다.

아래 기사는 데이터베이스의 데이터 양과 검색된 데이터 양을 고려하여 선택, 페치 및 삽입 측면에서 MySQL과 MongoDB를 비교 한 좋은 결과를 제공합니다. 결과는 "삽입"과 관련하여 MongoDB에 대한 뛰어난 성능을 보여 주지만 다른 경우에는 MySQL이 승리합니다. 아래를보십시오 :

http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

MongoDB를 사용한 경험이있어서 좋은 해결책이라고 생각합니다. 매일 수천 개의 컬렉션을 삽입하는 데 사용했습니다. Solr 솔루션 (캐시 솔루션, 하루에 한 번 업데이트 됨)과 결합하여 필요할 때 컬렉션 ID로 MongoDB 데이터를 검색 할 수 있으므로 즉시 선택할 필요가 없습니다. 따라서 많은 인서트를 처리해야하고 선택하고 가져올 필요가 없다는 것을 고려할 때 MongoDB는 좋은 아이디어 일 수 있습니다. 각 사례에 따라 다르며 우수한 분석을 수행해야합니다.