database MongoDB vs. Cassandra vs. MySQL 实时广告平台

MongoDB vs. Cassandra vs. MySQL for real-time advertising platform

提问by James Simpson

I'm working on a real-time advertising platform with a heavy emphasis on performance. I've always developed with MySQL, but I'm open to trying something new like MongoDB or Cassandra if significant speed gains can be achieved. I've been reading about both all day, but since both are being rapidly developed, a lot of the information appears somewhat dated.

我正在开发一个非常注重性能的实时广告平台。我一直使用 MySQL 进行开发，但如果可以实现显着的速度提升，我愿意尝试使用 MongoDB 或 Cassandra 之类的新东西。我一整天都在阅读有关这两个方面的信息，但由于两者都在迅速发展，因此很多信息似乎有些过时。

The main data stored would be entries for each click, incremented rows for views, and information for each campaign (just some basic settings, etc). The speed gains need to be found in inserting clicks, updating view totals, and generating real-time statistic reports. The platform is developed with PHP.

存储的主要数据将是每次点击的条目、视图的增量行以及每个活动的信息（只是一些基本设置等）。需要在插入点击次数、更新查看总数和生成实时统计报告中找到速度提升。该平台是用PHP开发的。

Or maybe none of these?

或者这些都没有？

采纳答案by Brian Lyttle

There are several ways to achieve this with all of the technologies listed. It is more a question of how you use them. Your ideal solution may use a combination of these, with some consideration for usage patterns. I don't feel that the information out there is that dated because the concepts at play are very fundamental. There may be new NoSQL databases and fixes to existing ones, but your question is primarily architectural.

有几种方法可以使用列出的所有技术来实现这一点。更多的是你如何使用它们的问题。您的理想解决方案可能会使用这些的组合，并考虑使用模式。我不认为那里的信息是过时的，因为在起作用的概念是非常基本的。可能会有新的 NoSQL 数据库和对现有数据库的修复，但您的问题主要是架构问题。

NoSQL solutions like MongoDB and Cassandra get a lot of attention for their insert performance. People tend to complain about the update/insert performance of relational databases but there are ways to mitigate these issues.

MongoDB 和 Cassandra 等 NoSQL 解决方案因其插入性能而备受关注。人们倾向于抱怨关系数据库的更新/插入性能，但有一些方法可以缓解这些问题。

Starting with MySQL you could review O'Reilly's High Performance MySQL, optimise the schema, add more memory perhaps run this on different hardware from the rest of your app (assuming you used MySQL for that), or partition/shard data. Another area to consider is your application. Can you queue inserts and updates at the application level before insertion into the database? This will give you some flexibility and is probably useful in all cases. Depending on how your final schema looks, MySQL will give you some help with extracting the data as long as you are comfortable with SQL. This is a benefit if you need to use 3rd party reporting tools etc.

从 MySQL 开始，您可以查看 O'Reilly 的High Performance MySQL，优化架构，添加更多内存，或者在与应用程序其余部分不同的硬件上运行它（假设您为此使用 MySQL），或分区/分片数据。另一个需要考虑的方面是您的应用程序。您可以在插入数据库之前在应用程序级别对插入和更新进行排队吗？这将为您提供一些灵活性，并且可能在所有情况下都有用。根据最终模式的外观，只要您对 SQL 感到满意，MySQL 就会为您提供一些提取数据的帮助。如果您需要使用 3rd 方报告工具等，这是一个好处。

MongoDB and Cassandra are different beasts. My understanding is that it was easier to add nodes to the latter but this has changed since MongoDB has replication etc built-in. Inserts for both of these platforms are not constrained in the same manner as a relational database. Pulling data out is pretty quick too, and you have a lot of flexibility with data format changes. The tradeoff is that you can't use SQL (a benefit for some) so getting reports out may be trickier. There is nothing to stop you from collecting data in one of these platforms and then importing it into a MySQL database for further analysis.

MongoDB 和 Cassandra 是不同的野兽。我的理解是向后者添加节点更容易，但自从 MongoDB 内置复制等功能以来，这种情况发生了变化。这两个平台的插入不受与关系数据库相同的限制。拉出数据也非常快，并且您可以灵活地更改数据格式。权衡是您不能使用 SQL（对某些人来说是一个好处），因此获取报告可能会更棘手。没有什么可以阻止您在这些平台之一中收集数据，然后将其导入 MySQL 数据库以进行进一步分析。

Based on your requirements there are tools other than NoSQL databases which you should look at such as Flume. These make use of the Hadoop platform which is used extensively for analytics. These may have more flexibility than a database for what you are doing. There is some content from Hadoop Worldthat you might be interested in.

根据您的要求，您应该查看除 NoSQL 数据库之外的其他工具，例如Flume。它们利用了广泛用于分析的 Hadoop 平台。对于您正在执行的操作，这些可能比数据库具有更大的灵活性。Hadoop World中有一些您可能感兴趣的内容。

回答by sirmak

Nosql solutions are better than Mysql, postgresql and other rdbms techs for this task. Don't waste your time with Hbase/Hadoop, you've to be an astronaut to use it. I recommend MongoDB and Cassandra. Mongo is better for small datasets (if your data is maximum 10 times bigger than your ram, otherwise you have to shard, need more machines and use replica sets). For big data; cassandra is the best. Mongodb has more query options and other functionalities than cassandra but you need 64 bit machines for mongo. There are some works around for analytics in both sides. There is atomic counters in both sides. Both can scale well but cassandra is much better in scaling and high availability. Both have php clients, both have good support and community (mongo community is bigger).

在这项任务中，Nosql 解决方案比 Mysql、postgresql 和其他 rdbms 技术更好。不要在 Hbase/Hadoop 上浪费时间，您必须成为一名宇航员才能使用它。我推荐 MongoDB 和 Cassandra。Mongo 更适合小型数据集（如果您的数据最多比您的 ram 大 10 倍，否则您必须分片，需要更多机器并使用副本集）。对于大数据；卡桑德拉是最好的。与 cassandra 相比，Mongodb 具有更多的查询选项和其他功能，但您需要 64 位机器才能使用 mongo。双方都有一些分析工作。两边都有原子计数器。两者都可以很好地扩展，但 cassandra 在扩展和高可用性方面要好得多。两者都有 php 客户端，都有很好的支持和社区（mongo 社区更大）。

Cassandra analytics project sample:Rainbird http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011

Cassandra 分析项目示例：Rainbird http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-twitter-strata-2011

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

mongo 示例：http: //www.slideshare.net/jrosoff/scalable-event-analytics-with-mongodb-ruby-on-rails

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

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

doubleclick developers developed mongo http://www.informationweek.com/news/software/info_management/224200878

doubleclick 开发者开发 mongo http://www.informationweek.com/news/software/info_management/224200878

回答by Ryan Taylor

Characteristics of MySQL:

MySQL的特点：

• Database locking (MUCH easier for financial transactions)
• Consistency/security (as above, you can guarantee that, for instance, no changes happen between the time you read a bank account balance and you update it).
• Data organization/refactoring (you can have disorganized data anywhere, but MySQL is better with tables that represent "types" or "components" and then combining them into queries -- this is called normalization).
• MySQL (and relational databases) are more well suited for arbitrary datasets and requirements common in AGILE software projects.

• 数据库锁定（金融交易更容易）
• 一致性/安全性（例如，您可以保证在您读取银行帐户余额和更新它之间不会发生任何变化）。
• 数据组织/重构（您可以在任何地方拥有杂乱无章的数据，但 MySQL 最好使用表示“类型”或“组件”的表，然后将它们组合成查询——这称为规范化）。
• MySQL（和关系数据库）更适合 AGILE 软件项目中常见的任意数据集和需求。

Characteristics of Cassandra:

卡桑德拉的特点：

• Speed: For simple retrieval of large documents. However, it will require multiple queries for highly relational data –?and "by default" these queries may not be consistent (and the dataset can change between these queries).
• Availability: The opposite of "consistency". Data is always available, regardless of being 100% "correct".^[1]
• Optional fields (wide columns): This CAN be done in MySQL with meta tables etc., but it's for-free and by-default in Cassandra.

• 速度：用于简单检索大型文档。但是，它需要对高度相关的数据进行多次查询——并且“默认情况下”这些查询可能不一致（并且这些查询之间的数据集可能会发生变化）。
• 可用性：与“一致性”相反。数据始终可用，无论是否 100%“正确”。^[1]
• 可选字段（宽列）：这可以在带有元表等的 MySQL 中完成，但它在 Cassandra 中是免费和默认的。

Cassandra is key-value or document-based storage. Think about what that means. TYPICALLY I give Cassandra ONE KEY and I get back ONE DATASET. It can branch out from there, but that's basically what's going on. It's more like accessing a static file. Sure, you can have multiple indexes, counter fields etc. but I'm making a generalization. That's where Cassandra is coming from.

Cassandra 是键值或基于文档的存储。想想这意味着什么。通常，我给 Cassandra 一把钥匙，然后我取回一个数据集。它可以从那里分支出来，但这基本上就是正在发生的事情。这更像是访问静态文件。当然，您可以有多个索引、计数器字段等，但我正在做一个概括。这就是卡桑德拉的来源。

MySQL and SQL is based on group/set theory-- it has a way to combine ANY relationship between data sets. It's pretty easy to take a MySQL query, make the query a "key" and the response a "value" and store it into Cassandra (e.g. make Cassandra a cache). That might help explain the trade-off too, MySQL allows you to always rearrange your data tables and the relationships between datasets simply by writing a different query. Cassandra not so much. And know that while Cassandra might PROVIDE features to do some of this stuff, it's not what it was built for.

MySQL 和 SQL 基于组/集合理论——它有一种方法可以组合数据集之间的任何关系。使用 MySQL 查询非常容易，将查询设为“键”，将响应设为“值”并将其存储到 Cassandra（例如，将 Cassandra 设为缓存）。这也可能有助于解释权衡，MySQL 允许您始终通过编写不同的查询来重新排列数据表和数据集之间的关系。卡桑德拉没有那么多。并且要知道，虽然 Cassandra 可能会提供一些功能来完成其中的一些事情，但这并不是它的初衷。

MongoDB and CouchDB fit somewhere in the middle of those two extremes. I think MySQL can be a bit verbose^[2]and annoying to deal with especially when dealing with optional fields, and migrations if you don't have a good model or tools. Also with scalability, I'm sure there are great technologies for scaling a MySQL database, but Cassandra will always scale, and easily, due to limitations on its feature set. MySQL is a bit more unbounded. However, NoSQL and Cassandra do notdo joins, one of the critical features of SQL that allows one to combine multiple tables in a single query. So, complex relational queries will not scale in Cassandra.

MongoDB 和 CouchDB 介于这两个极端的中间。我认为 MySQL 可能有点冗长^[2]并且处理起来很烦人，尤其是在处理可选字段和迁移时，如果您没有好的模型或工具。此外，在可扩展性方面，我确信有一些很棒的技术可以扩展 MySQL 数据库，但 Cassandra 将始终可以轻松扩展，因为其功能集的限制。MySQL 有点不受限制。但是，NoSQL 和 Cassandra不进行连接，这是 SQL 的关键特性之一，它允许在单个查询中组合多个表。因此，复杂的关系查询不会在 Cassandra 中扩展。

[1] Consistency vs. availability is a trade-off within large distributed dataset. It takes a while to make all nodes aware of new data, and eg. Cassandra opts to answer quickly and not to check with every single node before replying. This can causes weird edge cases when you base you writes off previously read data and overwriting data. For more information look into the CAP Theorem, ACIDdatabase (in particular Atomicity) as well as Idempotentdatabase operations. MySQL has this issue too, but the idea of high availability over correctness is very baked into Cassandra and gives it many of its scalability and speed advantages.

[1] 一致性与可用性是大型分布式数据集中的权衡。让所有节点都知道新数据需要一段时间，例如。Cassandra 选择快速答复，而不是在答复之前检查每个节点。当您注销以前读取的数据并覆盖数据时，这可能会导致奇怪的边缘情况。有关更多信息，请查看CAP 定理、ACID数据库（特别是原子性）以及幂等数据库操作。MySQL 也有这个问题，但是高可用性而不是正确性的想法非常融入 Cassandra，并赋予它许多可扩展性和速度优势。

[2] SQL being "verbose" isn't a great reason to not use it –?plus most of us aren't going to (and shouldn't) write plain-text SQL statements.

[2] SQL“冗长”并不是不使用它的重要理由——而且我们大多数人不会（也不应该）编写纯文本 SQL 语句。

回答by sanjusci

Cassandra vs. MongoDB Are you considering Cassandra or MongoDB as the data store for your next project? Would you like to compare the two databases? Cassandra and MongoDB are both “NoSQL” databases, but the reality is that they are very different. They have very different strengths and value propositions – so any comparison has to be a nuanced one. Let's start with initial requirements… Neither of these databases replaces RDBMS, nor are they “ACID” databases. So If you have a transactional workload where normalization and consistency are the primary requirements, neither of these databases will work for you. You are better off sticking with traditional relational databases like MySQL, PostGres, Oracle etc. Now that we have relational databases out of the way, let's consider the major differences between Cassandra and MongoDB that will help you make the decision. In this post, I am not going to discuss specific features but will point out some high-level strategic differences to help you make your choice.

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.

1. 富有表现力的对象模型 MongoDB 支持丰富且富有表现力的对象模型。对象可以具有属性，并且对象可以相互嵌套（对于多个级别）。该模型非常“面向对象”，可以轻松表示领域中的任何对象结构。您还可以在层次结构的任何级别为任何对象的属性建立索引——这非常强大！另一方面，Cassandra 提供了具有行和列的相当传统的表结构。数据更加结构化，每列都有一个特定的类型，可以在创建过程中指定。

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

结论：如果您的问题域需要丰富的数据模型，那么 MongoDB 更适合您。

1. 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.

2. 二级索引二级索引是 MongoDB 中的一流结构。这使得索引存储在 MongoDB 中的对象的任何属性变得容易，即使它是嵌套的。这使得基于这些二级索引进行查询变得非常容易。Cassandra 仅粗略地支持二级索引。二级索引也仅限于单列和相等比较。如果您主要通过主键进行查询，那么 Cassandra 将非常适合您。

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

结论：如果您的应用程序需要二级索引并且需要查询模型的灵活性，那么 MongoDB 更适合您。

1. 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.

3. 高可用性 MongoDB 支持“单主”模型。这意味着您有一个主节点和许多从节点。如果 master 宕机，其中一个 slave 会被选为 master。此过程会自动发生，但需要时间，通常为 10-40 秒。在新的领导者选举期间，您的副本集已关闭且无法进行写入。这适用于大多数应用程序，但最终取决于您的需求。Cassandra 支持“多主”模型。单个节点的丢失不会影响集群进行写入的能力——因此您可以实现 100% 的写入正常运行时间。

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

结论：如果您需要 100% 的正常运行时间，Cassandra 更适合您。

1. 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.

4. 写入可扩展性 MongoDB 及其“单主”模型只能在主节点上进行写入。辅助服务器只能用于读取。因此，基本上如果您有三个节点副本集，则只有主节点进行写入，而其他两个节点仅用于读取。这极大地限制了写入可扩展性。您可以部署多个分片，但基本上只有 1/3 的数据节点可以进行写入。Cassandra 及其“多主”模型可以在任何服务器上进行写入。本质上，您的写入可扩展性受到集群中服务器数量的限制。集群中的服务器越多，它的扩展性就越好。

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

结论：如果写可扩展性是你的事，Cassandra 更适合你。

1. 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.

5. 查询语言支持 Cassandra 支持与 SQL 非常相似的 CQL 查询语言。如果您已经拥有一个数据分析师团队，他们将能够移植他们的大部分 SQL 技能，这对大型组织非常重要。然而，CQL 并不是完全成熟的 ANSI SQL——它有几个限制（没有连接支持，没有 OR 子句）等。 MongoDB 在这一点上不支持查询语言。查询被构造为 JSON 片段。

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

结论：如果您需要查询语言支持，Cassandra 更适合您。

1. 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.

2. 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.

3. 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.
4. 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.

6. 性能基准 让我们谈谈性能。此时，您可能希望对数据库进行性能基准比较。我故意不在比较中包含性能基准。在任何比较中，我们都必须确保我们进行的是苹果对苹果的比较。

7. 数据库模型 - 被测试应用程序的数据库模型/架构有很大的不同。有些模式非常适合 MongoDB，有些模式非常适合 Cassandra。因此，在比较数据库时，重要的是使用对两个数据库都运行良好的模型。

8. 负载特性——基准负载的特性非常重要。例如，在大量写入的基准测试中，我希望 Cassandra 使用 MongoDB。但是，在大量读取的基准测试中，MongoDB 和 Cassandra 的性能应该相似。
9. 一致性要求 - 这是一个棘手的问题。您需要确保指定的读/写一致性要求在两个数据库中是相同的，并且不偏向于一个参与者。通常在许多“营销”基准中，旋钮被调整到对另一方不利。因此，请密切注意一致性设置。

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

要记住的最后一件事是基准测试负载可能会也可能不会反映您的应用程序的性能。因此，为了使基准测试有用，找到反映应用程序性能特征的基准测试负载非常重要。以下是您可能想要查看的一些基准： - NoSQL 性能基准 - Cassandra 与 MongoDB 与 Couchbase 与 HBase

1. 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.

7. 易用性 如果您在几年前问过这个问题，那么 MongoDB 将是不折不扣的赢家。启动和运行 MongoDB 是一项相当简单的任务。然而，在过去的几年里，Cassandra 在产品的这方面取得了长足的进步。随着采用 CQL 作为 Cassandra 的主要接口，它更进了一步——它们使大量 SQL 程序员非常容易地使用 Cassandra。

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

结论：两者都相当容易使用和升级。

1. 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.

2. 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.

8. 本地聚合 MongoDB 有一个内置的聚合框架来运行 ETL 管道来转换存储在数据库中的数据。这对于中小型作业非常有用，但随着您的数据处理需求变得更加复杂，聚合框架变得难以调试。Cassandra 没有内置的聚合框架。为此使用了 Hadoop、Spark 等外部工具。

9. 无模式模型 在 MongoDB 中，您可以选择不对文档强制实施任何模式。虽然这是较新版本中先前版本的默认设置，但您可以选择为文档强制实施架构。MongoDB 中的每个文档都可以是不同的结构，由您的应用程序来解释数据。虽然这与大多数应用程序无关，但在某些情况下，额外的灵活性很重要。较新版本中的 Cassandra（使用 CQL 作为默认语言）提供静态类型。您需要预先定义非常列的类型。

回答by Perry krug

I'd also like to add Membase (www.couchbase.com) to this list.

我还想将 Membase (www.couchbase.com) 添加到此列表中。

As a product, Membase has been deployed at a number of Ad Agencies (AOL Advertising, Chango, Delta Projects, etc). There are a number of public case studies and examples of how these companies have used Membase successfully.

作为一种产品，Membase 已部署在许多广告代理商（AOL Advertising、Chango、Delta Projects 等）中。有许多公共案例研究和示例说明这些公司如何成功使用 Membase。

While it's certainly up for debate, we've found that Membase provides better performance and scalability than any other solution. What we lack in indexing/querying, we are planning on more than making up for with the integration of CouchDB as our new persistence backend.

虽然这肯定有待讨论，但我们发现 Membase 提供了比任何其他解决方案更好的性能和可扩展性。我们在索引/查询方面的不足，我们计划做的不仅仅是将 CouchDB 集成作为我们新的持久性后端来弥补。

As a company, Couchbase (the makers of Membase) has a large amount of knowledge and experience specifically serving the needs of Ad/targeting companies.

作为一家公司，Couchbase（Membase 的制造商）拥有大量专门满足广告/定位公司需求的知识和经验。

Would certainly love to engage with you on this particular use case to see if Membase is the right fit.

当然很乐意与您讨论这个特定的用例，看看 Membase 是否合适。

Please shoot me an email (perry -at- couchbase -dot- com) or visit us on the forums: http://www.couchbase.org/forums/

请给我发电子邮件 (perry -at-couchbase -dot-com) 或访问我们的论坛：http: //www.couchbase.org/forums/

Perry Krug

佩里·克鲁格

回答by Morgan Tocker

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

我会将 New Relic 视为类似工作负载的示例。他们每天将超过 2000 亿个数据点捕获到磁盘，并使用 MySQL 5.6 (Percona) 作为后端。

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

可在此处获取博客文章：http: //blog.newrelic.com/2014/06/13/store-200-billion-data-points-day-disk/