MongoDB vs.카산드라 vs.실시간 광고 플랫폼용 MySQL

MongoDB vs.카산드라 vs.실시간 광고 플랫폼용 MySQL

저는 실적 위주의 실시간 광고 플랫폼에서 일하고 있습니다.저는 항상 MySQL로 개발해 왔지만, 상당한 속도 향상을 달성할 수 있다면 MongoDB나 Cassandra와 같은 새로운 것을 시도해 볼 의향이 있습니다.하루 종일 두 가지에 대해 읽었지만, 두 가지 모두 빠르게 발전하고 있기 때문에 많은 정보가 다소 오래된 것으로 보입니다.

저장된 기본 데이터는 클릭할 때마다 항목, 보기 행 증가 및 각 캠페인에 대한 정보(일부 기본 설정 등)입니다.클릭 삽입, 보기 합계 업데이트 및 실시간 통계 보고서 생성에서 속도 향상을 찾아야 합니다.그 플랫폼은 PHP로 개발되었습니다.

아니면 이것들 중 하나도 없나요?

나열된 모든 기술을 사용하여 이를 달성할 수 있는 몇 가지 방법이 있습니다.그것들을 어떻게 사용하느냐가 더 중요합니다.이상적인 솔루션은 사용 패턴을 고려하여 이러한 조합을 사용할 수 있습니다.저는 저 밖에 있는 정보들이 그렇게 오래된 것이라고 생각하지 않습니다. 왜냐하면 놀이에 있는 개념들은 매우 기본적이기 때문입니다.새로운 NoSQL 데이터베이스와 기존 데이터베이스에 대한 수정 사항이 있을 수 있지만 질문은 주로 아키텍처입니다.

MongoDB 및 Cassandra와 같은 NoSQL 솔루션은 삽입 성능으로 많은 주목을 받습니다.사람들은 관계형 데이터베이스의 업데이트/삽입 성능에 대해 불평하는 경향이 있지만 이러한 문제를 완화할 수 있는 방법이 있습니다.

MySQL을 시작으로 O'Reilly의 고성능 MySQL을 검토하고 스키마를 최적화하며 메모리를 추가할 수 있습니다. 이를 위해 MySQL을 사용했다고 가정할 때) 또는 파티션/하드 데이터를 다른 하드웨어에서 실행할 수 있습니다.고려해야 할 또 다른 영역은 애플리케이션입니다.데이터베이스에 삽입하기 전에 응용프로그램 수준에서 삽입 및 업데이트를 대기열에 넣을 수 있습니까?이를 통해 어느 정도 유연성을 얻을 수 있으며 모든 경우에 유용할 수 있습니다.최종 스키마가 어떻게 보이는지에 따라, MySQL은 당신이 SQL에 익숙하다면 데이터를 추출하는 데 도움을 참조하십시오.타사 보고 도구 등을 사용해야 하는 경우의 이점입니다.

MongoDB와 Cassandra는 다른 짐승입니다.후자에 노드를 추가하는 것이 더 쉬운 것으로 알고 있지만 MongoDB에 복제 등이 내장되어 있기 때문에 변경되었습니다.이러한 두 플랫폼 모두에 대한 삽입은 관계형 데이터베이스와 동일한 방식으로 제한되지 않습니다.데이터를 추출하는 작업도 매우 빠르며, 데이터 형식 변경에도 유연성이 높습니다.단점은 SQL(일부에게는 이점)을 사용할 수 없기 때문에 보고서를 작성하는 것이 더 까다로울 수 있다는 것입니다.이러한 플랫폼 중 하나에서 데이터를 수집한 다음 추가 분석을 위해 MySQL 데이터베이스로 가져오는 것을 막을 수 있는 것은 없습니다.

요구 사항에 따라 Flume과 같은 NoSQL 데이터베이스 이외의 도구가 있습니다.분석에 광범위하게 사용되는 Hadoop 플랫폼을 활용합니다.이러한 작업은 수행 중인 작업에 대해 데이터베이스보다 더 많은 유연성을 가질 수 있습니다.Hadoop World의 일부 콘텐츠에 관심이 있을 수 있습니다.

MySQL의 특징:

• 데이터베이스 잠금(금융 거래에 훨씬 용이함)
• 일관성/보안(예를 들어, 은행 계좌 잔액을 읽은 후 업데이트할 때 변경 사항이 발생하지 않음을 보장할 수 있습니다.)
• 데이터 구성/리팩터링(어디서나 데이터를 정리할 수 있지만 MySQL은 "유형" 또는 "구성요소"를 나타내는 테이블이 더 낫고 쿼리로 결합합니다. 이를 정규화라고 합니다.)
• MySQL(및 관계형 데이터베이스)은 Agile 소프트웨어 프로젝트에서 일반적으로 사용되는 임의의 데이터 세트 및 요구 사항에 더욱 적합합니다.

카산드라의 특징:

• 속도: 대용량 문서를 쉽게 검색할 수 있습니다.그러나 관계성이 높은 데이터에는 여러 쿼리가 필요합니다. 기본적으로 이러한 쿼리는 일관성이 없을 수 있습니다(또한 데이터 세트는 이러한 쿼리 간에 변경될 수 있습니다).
• 가용성:"일관성"의 반대말입니다.데이터는 100% "정확"^[1] 여부에 관계없이 항상 사용할 수 있습니다.
• 선택적 필드(넓은 열):이것은 MySQL에서 메타테이블 등으로 할 수 있지만, 카산드라에서는 기본적으로 무료입니다.

Cassandra는 키 값 또는 문서 기반 스토리지입니다.그게 무슨 뜻인지 생각해 보세요.일반적으로 저는 카산드라에게 하나의 키를 주고 하나의 데이터 세트를 돌려받습니다.그것은 거기서 갈라질 수 있지만, 기본적으로 그것이 진행되고 있습니다.정적 파일에 액세스하는 것과 비슷합니다.물론 여러 인덱스, 카운터 필드 등을 사용할 수 있지만 일반화하는 중입니다.카산드라가 여기서 온 거지

MySQL과 SQL은 그룹/세트 이론을 기반으로 합니다. 데이터 세트 간의 모든 관계를 결합할 수 있는 방법이 있습니다.MySQL 쿼리를 가져와 쿼리를 "키"로 만들고 응답을 "값"으로 만들어 카산드라에 저장하는 것은 매우 쉽습니다(예: 카산드라를 캐시로 만드는 것).이는 트레이드오프를 설명하는 데도 도움이 될 수 있습니다. MySQL을 사용하면 다른 쿼리를 작성하는 것만으로 데이터 테이블과 데이터 세트 간의 관계를 항상 재정렬할 수 있습니다.카산드라는 별로.그리고 카산드라가 이런 것들을 할 수 있는 기능들을 제공할 수도 있지만, 그것은 그것을 위해 만들어진 것이 아닙니다.

MongoDB와 CouchDB는 이 두 극단의 중간 어딘가에 들어맞습니다.MySQL은 특히 옵션 필드를 다룰 때, 그리고 좋은 모델이나 도구가 없을 때 마이그레이션을 다룰 때 다소^[2] 장황하고 성가실 수 있다고 생각합니다.확장성과 더불어 MySQL 데이터베이스를 확장하는 훌륭한 기술이 있을 것입니다. 그러나 Cassandra는 기능 세트의 제한으로 인해 항상 쉽게 확장할 수 있습니다.MySQL은 조금 더 제한이 없습니다.그러나 NoSQL과 Cassandra는 단일 쿼리에서 여러 테이블을 결합할 수 있는 SQL의 중요한 기능 중 하나인 조인을 수행하지 않습니다.따라서 복잡한 관계형 쿼리는 카산드라에서 확장되지 않습니다.

일관성 대 가용성은 대규모 분산 데이터 세트 내에서 절충됩니다.모든 노드가 새 데이터를 인식하도록 하는 데 시간이 걸립니다.Cassandra는 응답하기 전에 모든 노드를 확인하지 않고 빠르게 응답하는 것을 선택합니다.이로 인해 이전에 읽은 데이터를 지우고 데이터를 덮어쓸 때 이상한 에지 사례가 발생할 수 있습니다.자세한 내용은 CAP 정리, ACID 데이터베이스(특히 Atomicity) 및 Idempotent 데이터베이스 작업을 참조하십시오.MySQL에도 이러한 문제가 있지만 정확성보다 높은 가용성에 대한 아이디어는 카산드라에 매우 적합하며 확장성과 속도 이점을 많이 제공합니다.

SQL이 "자세한" 것은 SQL을 사용하지 않는 좋은 이유가 아닙니다. 게다가 대부분의 사람들은 일반 텍스트 SQL 문을 작성하지 않을 것이며 작성해서는 안 됩니다.

이 작업에는 Mysql, postgresql 및 기타 rdbms 기술보다 나은 솔루션이 없습니다.Hbase/Hadoop과 함께 시간을 낭비하지 마십시오. 그것을 사용하려면 우주비행사가 되어야 합니다.저는 몽고DB와 카산드라를 추천합니다.Mongo는 소규모 데이터 세트에 적합합니다(데이터가 RAM보다 최대 10배 큰 경우, 그렇지 않으면 샤딩해야 하고 더 많은 시스템이 필요하며 복제 세트를 사용해야 합니다).빅 데이터의 경우, 카산드라가 가장 좋습니다.Mongodb는 cassandra보다 쿼리 옵션 및 기타 기능이 더 많지만 Mongo를 사용하려면 64비트 시스템이 필요합니다.양쪽 모두에서 분석을 위한 몇 가지 작업이 있습니다.양쪽에 원자력 계수기가 있습니다.둘 다 잘 확장할 수 있지만, 카산드라는 확장성과 고가용성 면에서 훨씬 뛰어납니다.둘 다 php 클라이언트를 가지고 있고, 둘 다 좋은 지원과 커뮤니티를 가지고 있습니다(몽고 커뮤니티가 더 큽니다).

Cassandra 분석 프로젝트 샘플:레인버드 http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011

mongo 샘플: http://www.slideshare.net/jrosoff/scalable-event-analytics-with-mongodb-ruby-on-rails

http://axonflux.com/how-superfeedr-built-analytics-using-mongodb

더블 클릭 개발자 mongo http://www.informationweek.com/news/software/info_management/224200878

카산드라 vs.MongoDB 다음 프로젝트의 데이터 저장소로 Cassandra 또는 MongoDB를 고려하고 있습니까?두 데이터베이스를 비교하시겠습니까?Cassandra와 MongoDB는 둘 다 "NoSQL" 데이터베이스이지만 현실은 매우 다릅니다.그들은 매우 다른 강점과 가치 제안을 가지고 있기 때문에, 어떤 비교도 미묘한 차이가 있어야 합니다.먼저 초기 요구사항부터 살펴보겠습니다.이러한 데이터베이스는 RDBMS를 대체하지 않으며 "ACID" 데이터베이스도 아닙니다.따라서 정규화 및 일관성이 주요 요구사항인 트랜잭션 워크로드가 있는 경우 이러한 데이터베이스는 모두 사용할 수 없습니다.MySQL, PostGres, Oracle 등과 같은 기존 관계형 데이터베이스를 사용하는 것이 좋습니다.이제 관계형 데이터베이스가 사라졌으니, 의사 결정에 도움이 되는 Cassandra와 MongoDB의 주요 차이점을 고려해 보겠습니다.이 게시물에서는 구체적인 기능에 대해 설명하지는 않지만, 선택에 도움이 되는 몇 가지 높은 수준의 전략적 차이를 지적할 것입니다.

1. 표현형 객체 모델 MongoDB는 풍부하고 표현형 객체 모델을 지원합니다.객체는 속성을 가질 수 있으며 객체는 여러 수준에 대해 서로 중첩될 수 있습니다.이 모델은 매우 "객체 지향적"이며 도메인의 모든 개체 구조를 쉽게 나타낼 수 있습니다.계층의 모든 수준에서 개체의 속성을 인덱싱할 수도 있습니다. 이는 매우 강력합니다!반면에 카산드라는 행과 열이 있는 꽤 전통적인 테이블 구조를 제공합니다.데이터가 더 구조화되고 각 열에는 생성 중에 지정할 수 있는 특정 유형이 있습니다.

평결:문제 도메인에 풍부한 데이터 모델이 필요한 경우 MongoDB가 더 적합합니다.

2. 보조 인덱스 보조 인덱스는 MongoDB의 1차 클래스 구성입니다.이렇게 하면 MongoDB에 저장된 개체의 속성을 쉽게 인덱싱할 수 있습니다.이렇게 하면 이러한 보조 인덱스를 기반으로 쿼리를 수행하기가 매우 쉽습니다.카산드라는 2차 인덱스에 대한 필기체 지원만 가지고 있습니다.보조 인덱스도 단일 열 및 동일성 비교로 제한됩니다.만약 당신이 주로 기본 키로 쿼리를 할 것이라면, 카산드라는 당신을 위해 잘 작동할 것입니다.

평결:응용프로그램에 보조 인덱스가 필요하고 쿼리 모델의 유연성이 필요한 경우 MongoDB가 적합합니다.

3. 고가용성 MongoDB는 "단일 마스터" 모델을 지원합니다.즉, 마스터 노드와 여러 슬레이브 노드가 있습니다.마스터가 다운되면 노예 중 한 명이 마스터로 선출됩니다.이 프로세스는 자동으로 수행되지만 일반적으로 10-40초의 시간이 소요됩니다.새 지도자가 선출되는 동안 복제본 집합이 중단되어 쓰기를 수행할 수 없습니다.이는 대부분의 응용프로그램에 적용되지만 궁극적으로 필요에 따라 달라집니다.카산드라는 "다중 마스터" 모델을 지원합니다.단일 노드의 손실은 클러스터의 쓰기 작업 능력에 영향을 미치지 않으므로 쓰기 작업 시 100% 가동 시간을 달성할 수 있습니다.

평결:100% 가동 시간이 필요한 경우 Cassandra가 더 적합합니다.

4. "단일 마스터" 모델을 사용하는 쓰기 확장성 MongoDB는 Primary에서만 쓰기를 수행할 수 있습니다.보조 서버는 읽기에만 사용할 수 있습니다.따라서 기본적으로 3개의 노드 복제본 세트가 있는 경우 마스터만 쓰기를 수행하고 나머지 2개의 노드는 읽기에만 사용됩니다.따라서 쓰기 확장성이 크게 제한됩니다.여러 개의 샤드를 구축할 수 있지만 기본적으로 데이터 노드의 1/3만 쓰기를 수행할 수 있습니다."다중 마스터" 모델을 사용하는 Cassandra는 모든 서버에서 쓰기를 수행할 수 있습니다.기본적으로 쓰기 확장성은 클러스터에 있는 서버 수에 따라 제한됩니다.클러스터에 서버가 많을수록 확장성이 향상됩니다.

평결:쓰기 확장성이 중요하다면 카산드라가 더 적합합니다.

5. 쿼리 언어 지원 Cassandra는 SQL과 매우 유사한 CQL 쿼리 언어를 지원합니다.이미 데이터 분석가 팀이 있는 경우 대규모 조직에 매우 중요한 SQL 기술의 대부분을 이식할 수 있습니다.그러나 CQL은 완전한 ANSI SQL이 아닙니다. 몇 가지 제한 사항이 있습니다(가입 지원 없음, OR 조항 없음).현재 MongoDB는 쿼리 언어를 지원하지 않습니다.쿼리는 JSON fragment로 구성됩니다.

평결:쿼리 언어 지원이 필요한 경우 카산드라가 더 적합합니다.

6. 성능 벤치마크 성능에 대해 살펴보겠습니다.이 시점에서 데이터베이스의 성능 벤치마크 비교를 예상할 수 있습니다.저는 의도적으로 성능 벤치마크를 비교 대상에 포함시키지 않았습니다.어떤 비교에서도, 우리는 우리가 사과 대 사과를 비교하고 있는지 확인해야 합니다.

7. 데이터베이스 모델 - 테스트 중인 응용 프로그램의 데이터베이스 모델/구성표가 큰 차이를 만듭니다.일부 스키마는 MongoDB에 적합하고 일부 스키마는 Cassandra에 적합합니다.따라서 데이터베이스를 비교할 때 두 데이터베이스에 모두 적합한 모델을 사용하는 것이 중요합니다.

8. 부하 특성 – 벤치마크 부하의 특성은 매우 중요합니다.예: 쓰기 집약적인 벤치마크에서 Cassandra가 MongoDB를 흡연할 것으로 예상합니다.그러나 읽기 집약적인 벤치마크에서 MongoDB와 Cassandra는 성능이 비슷해야 합니다.
9. 일관성 요구사항 - 이것은 까다로운 요구사항입니다.지정된 읽기/쓰기 일관성 요구사항이 두 데이터베이스에서 동일하고 한 참가자에게 치우치지 않도록 해야 합니다.많은 '마케팅' 벤치마크에서 노브는 상대방에게 불리하도록 조정되는 경우가 많습니다.따라서 일관성 설정에 주의해야 합니다.

마지막으로 기억해야 할 것은 벤치마크 로드가 애플리케이션의 성능을 반영하거나 반영하지 않을 수 있다는 점입니다.따라서 벤치마크가 유용하려면 애플리케이션의 성능 특성을 반영하는 벤치마크 로드를 찾는 것이 매우 중요합니다.다음은 몇 가지 벤치마크입니다. - NoSQL 성능 벤치마크 - Cassandra vs.MongoDB vs.카우치베이스 vs.H 베이스

7. 사용의 용이성 2년 전에 이 질문을 했다면 MongoDB가 실제 승자가 되었을 것입니다.MongoDB를 시작하고 실행하는 것은 꽤 간단한 작업입니다.그러나 지난 몇 년 동안 카산드라는 제품의 이러한 측면에서 큰 발전을 이루었습니다.CQL을 Cassandra의 기본 인터페이스로 채택함으로써 한 단계 더 발전했습니다. 수많은 SQL 프로그래머들이 Cassandra를 매우 쉽게 사용할 수 있게 되었습니다.

평결: 둘 다 사용하기 쉽고 향상되었습니다.

8. Native Aggregation MongoDB에는 ETL 파이프라인을 실행하여 데이터베이스에 저장된 데이터를 변환하는 Aggregation 프레임워크가 내장되어 있습니다.이는 중소규모 작업에 적합하지만 데이터 처리 요구가 복잡해짐에 따라 집계 프레임워크를 디버깅하기가 어려워집니다.Cassandra에는 통합 프레임워크가 내장되어 있지 않습니다.이를 위해 Hadoop, Spark와 같은 외부 도구가 사용됩니다.

9. 스키마가 없는 모델 MongoDB에서 문서에 스키마를 적용하지 않도록 선택할 수 있습니다.새 버전의 이전 버전에서는 이것이 기본값이었지만 문서에 대한 스키마를 시행할 수 있는 옵션이 있습니다.MongoDB의 각 문서는 서로 다른 구조일 수 있으며 데이터를 해석하는 것은 응용 프로그램에 달려 있습니다.이는 대부분의 애플리케이션과 관련이 없지만 경우에 따라 추가적인 유연성이 중요합니다.CQL을 기본 언어로 사용하는 최신 버전의 Cassandra는 정적 타이핑을 제공합니다.열의 유형을 미리 정의해야 합니다.

Membase(www.couchbase.com )도 이 목록에 추가하고 싶습니다.

제품으로서 Membase는 다수의 광고 대행사(AOL Advertising, Chango, Delta Projects 등)에 배치되었습니다.이러한 기업들이 Membase를 성공적으로 사용한 방법에 대한 여러 공개 사례 연구와 사례가 있습니다.

Membase는 다른 솔루션보다 더 나은 성능과 확장성을 제공한다는 것을 알게 되었습니다.인덱싱/쿼리에서 부족한 점은 CouchDB를 새로운 지속성 백엔드로 통합하는 것 이상의 것을 계획하고 있습니다.

Couchbase(Membase 제조업체)는 기업으로서 광고/타겟팅 기업의 요구를 구체적으로 충족시키는 많은 지식과 경험을 보유하고 있습니다.

Membase가 적합한지 확인하기 위해 이 특정 사용 사례에 대해 귀하와 협력하고 싶습니다.

이메일(couchbase-dot-com)을 보내주시거나 포럼에 방문해 주십시오. http://www.couchbase.org/forums/

페리 크루그

유사한 작업량의 예로 New Relic을 살펴보겠습니다.하루에 2,000억 개 이상의 데이터 포인트를 디스크에 캡처하고 MySQL 5.6(Percona)을 백엔드로 사용하고 있습니다.

블로그 게시물은 http://blog.newrelic.com/2014/06/13/store-200-billion-data-points-day-disk/ 에서 확인할 수 있습니다.

언급URL : https://stackoverflow.com/questions/6162789/mongodb-vs-cassandra-vs-mysql-for-real-time-advertising-platform