실시간 광고 플랫폼을위한 MongoDB vs. Cassandra vs. MySQL

실시간 광고 플랫폼을위한 MongoDB vs. Cassandra 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의 콘텐츠 가 있습니다.

---

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

Cassandra 분석 프로젝트 샘플 : Rainbird 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

doubleclick 개발자는 mongo를 개발했습니다. http://www.informationweek.com/news/software/info_management/224200878

---

MySQL의 특성 :

• 데이터베이스 잠금 (금융 거래에 훨씬 더 쉬움)
• 일관성 / 보안 (위와 같이 은행 계좌 잔액을 읽고 업데이트하는 시간 사이에 변경 사항이 발생하지 않도록 보장 할 수 있습니다.)
• 데이터 구성 / 리팩토링 (어디서나 데이터를 정리할 수 있지만 MySQL은 "유형"또는 "구성 요소"를 나타내는 테이블을 사용하여 쿼리로 결합하는 것이 더 좋습니다. 이것을 정규화라고합니다.)

카산드라의 특성 :

• 속도
• 가용성 (100 % "정확한"여부에 관계없이 데이터를 항상 사용할 수 있음)
• 선택적 필드 (메타 테이블 등을 사용하여 MySQL에서 수행 할 수 있지만 Cassandra에서는 무료입니다)

Cassandra는 키-값 또는 문서 기반 저장소 입니다. 그게 무슨 뜻인지 생각해보세요. 일반적으로 Cassandra ONE KEY를 제공하고 하나의 데이터 세트를 반환합니다. 거기에서 뻗어 나갈 수 있지만 기본적으로 그게 진행되고 있습니다. 정적 파일에 액세스하는 것과 비슷합니다. 물론 여러 인덱스, 카운터 필드 등을 가질 수 있지만 일반화하고 있습니다. 그것이 카산드라가 오는 곳입니다.

MySQL과 SQL은 그룹 / 집합 이론을 기반으로 하며 데이터 집합 간의 관계를 결합하는 방법이 있습니다. MySQL 쿼리를 가져 와서 쿼리를 "키"로, 응답을 "값"으로 만들어 Cassandra에 저장하는 것은 매우 쉽습니다 (예 : Cassandra를 캐시로 만들기). 이는 트레이드 오프도 설명하는 데 도움이 될 수 있습니다. MySQL을 사용하면 단순히 다른 쿼리를 작성하여 데이터 테이블과 데이터 세트 간의 관계를 항상 재정렬 할 수 있습니다. 카산드라는 그다지 많지 않습니다. 그리고 Cassandra가 이러한 작업 중 일부를 수행 할 수있는 기능을 제공 할 수는 있지만 그것이 구축 된 것이 아닙니다.

MongoDB와 CouchDB는이 두 극단의 중간에 적합합니다. MySQL은 특히 선택적 필드를 처리 할 때 처리하기가 다소 장황하고 성 가실 수 있으며 좋은 모델이나 도구가없는 경우 마이그레이션을 처리 할 수 ​​있습니다. 또한 확장 성으로 인해 MySQL 데이터베이스를 확장 할 수있는 훌륭한 기술이 있다고 확신하지만 Cassandra는 기능 집합의 제한으로 인해 항상 쉽게 확장 할 수 있습니다. MySQL은 조금 더 제한되지 않습니다. 그러나 NoSQL과 Cassandra는 하나의 쿼리에서 여러 테이블을 결합 할 수있는 SQL의 중요한 기능 중 하나 인 조인을 수행하지 않습니다 . 따라서 복잡한 관계형 쿼리는 Cassandra에서 확장되지 않습니다.

---

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

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

확실히 논쟁의 여지가 있지만 Membase가 다른 어떤 솔루션보다 더 나은 성능과 확장 성을 제공한다는 사실을 발견했습니다. 인덱싱 / 쿼리에서 부족한 점은 새로운 지속성 백엔드로서 CouchDB의 통합을 보완하는 것 이상을 계획하고 있습니다.

회사로서 Couchbase (Membase의 제작자)는 특히 광고 / 타겟팅 회사의 요구에 부응하는 많은 지식과 경험을 가지고 있습니다.

Membase가 적합한 지 알아보기 위해이 특정 사용 사례에 참여하고 싶습니다.

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

페리 크루그

---

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

1. Expressive Object Model MongoDB supports a rich and expressive object model. Objects can have properties and objects can be nested in one another (for multiple levels). This model is very “object-oriented” and can easily represent any object structure in your domain. You can also index the property of any object at any level of the hierarchy – this is strikingly powerful! Cassandra, on the other hand, offers a fairly traditional table structure with rows and columns. Data is more structured and each column has a specific type which can be specified during creation.

Verdict: If your problem domain needs a rich data model then MongoDB is a better fit for you.

2. Secondary Indexes Secondary indexes are a first-class construct in MongoDB. This makes it easy to index any property of an object stored in MongoDB even if it is nested. This makes it really easy to query based on these secondary indexes. Cassandra has only cursory support for secondary indexes. Secondary indexes are also limited to single columns and equality comparisons. If you are mostly going to be querying by the primary key then Cassandra will work well for you.

Verdict: If your application needs secondary indexes and needs flexibility in the query model then MongoDB is a better fit for you.

3. High Availability MongoDB supports a “single master” model. This means you have a master node and a number of slave nodes. In case the master goes down, one of the slaves is elected as master. This process happens automatically but it takes time, usually 10-40 seconds. During this time of new leader election, your replica set is down and cannot take writes. This works for most applications but ultimately depends on your needs. Cassandra supports a “multiple master” model. The loss of a single node does not affect the ability of the cluster to take writes – so you can achieve 100% uptime for writes.

Verdict: If you need 100% uptime Cassandra is a better fit for you.

4. Write Scalability MongoDB with its “single master” model can take writes only on the primary. The secondary servers can only be used for reads. So essentially if you have three node replica set, only the master is taking writes and the other two nodes are only used for reads. This greatly limits write scalability. You can deploy multiple shards but essentially only 1/3 of your data nodes can take writes. Cassandra with its “multiple master” model can take writes on any server. Essentially your write scalability is limited by the number of servers you have in the cluster. The more servers you have in the cluster, the better it will scale.

Verdict: If write scalability is your thing, Cassandra is a better fit for you.

5. Query Language Support Cassandra supports the CQL query language which is very similar to SQL. If you already have a team of data analysts they will be able to port over a majority of their SQL skills which is very important to large organizations. However CQL is not full blown ANSI SQL – It has several limitations (No join support, no OR clauses) etc. MongoDB at this point has no support for a query language. The queries are structured as JSON fragments.

Verdict: If you need query language support, Cassandra is the better fit for you.

6. Performance Benchmarks Let’s talk performance. At this point, you are probably expecting a performance benchmark comparison of the databases. I have deliberately not included performance benchmarks in the comparison. In any comparison, we have to make sure we are making an apples-to-apples comparison.

7. Database model - The database model/schema of the application being tested makes a big difference. Some schemas are well suited for MongoDB and some are well suited for Cassandra. So when comparing databases it is important to use a model that works reasonably well for both databases.

8. Load characteristics – The characteristics of the benchmark load are very important. E.g. In write-heavy benchmarks, I would expect Cassandra to smoke MongoDB. However, in read-heavy benchmarks, MongoDB and Cassandra should be similar in performance.
9. Consistency requirements - This is a tricky one. You need to make sure that the read/write consistency requirements specified are identical in both databases and not biased towards one participant. Very often in a number of the ‘Marketing’ benchmarks, the knobs are tuned to disadvantage the other side. So, pay close attention to the consistency settings.

One last thing to keep in mind is that the benchmark load may or may not reflect the performance of your application. So in order for benchmarks to be useful, it is very important to find a benchmark load that reflects the performance characteristics of your application. Here are some benchmarks you might want to look at: - NoSQL Performance Benchmarks - Cassandra vs. MongoDB vs. Couchbase vs. HBase

7. Ease of Use If you had asked this question a couple of years ago MongoDB would be the hands-down winner. It’s a fairly simple task to get MongoDB up and running. In the last couple of years, however, Cassandra has made great strides in this aspect of the product. With the adoption of CQL as the primary interface for Cassandra, it has taken this a step further – they have made it very simple for legions of SQL programmers to use Cassandra very easily.

Verdict: Both are fairly easy to use and ramp up.

8. Native Aggregation MongoDB has a built-in Aggregation framework to run an ETL pipeline to transform the data stored in the database. This is great for small to medium jobs but as your data processing needs become more complicated the aggregation framework becomes difficult to debug. Cassandra does not have a built-in aggregation framework. External tools like Hadoop, Spark are used for this.

9. Schema-less Models In MongoDB, you can choose to not enforce any schema on your documents. While this was the default in prior versions in the newer version you have the option to enforce a schema for your documents. Each document in MongoDB can be a different structure and it is up to your application to interpret the data. While this is not relevant to most applications, in some cases the extra flexibility is important. Cassandra in the newer versions (with CQL as the default language) provides static typing. You need to define the type of very column upfront.

---

I would look at New Relic as an example of a similar workload. They capture over 200 Billion data points a day to disk and are using MySQL 5.6 (Percona) as a backend.

A blog post is available here: http://blog.newrelic.com/2014/06/13/store-200-billion-data-points-day-disk/

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