【问题标题】:Most suitable data store for billions of indexes最适合数十亿索引的数据存储
【发布时间】:2012-02-03 08:23:56
【问题描述】:

所以我们希望存储两种索引。

  1. 第一种将是数十亿的数量级,每个都有 1 到 1000 个值,每个值是一个或两个 64 位整数。
  2. 第二种将是数百万,每个都有大约 200 个值,每个值的大小在 1KB 到 1MB 之间。

我们的使用模式将是这样的:

  • 这两种索引的值都会以每秒数千次的速度添加到顶部。
  • 索引将不常被读取,但当它们被读取时,它将是读取的整个索引
  • 应在将值写入索引或在某种批处理类型作业中修剪索引

现在我们已经考虑了很多数据库,目前我们最喜欢的是 Cassandra 和 PostreSQL。然而,我们的应用程序是在 Erlang 中的,它没有为 Cassandra 提供生产就绪的绑定。而一个主要的要求就是不能需要太多的人力来维护。我感觉 Cassandra 会引发意想不到的扩展问题,而 PostgreSQL 会很痛苦,但至少对我们来说这是一个已知数量。我们已经熟悉 PostgreSQL,但对 Cassandra 还不是很熟悉。

所以。关于哪种数据存储最适合我们的用例的任何建议或建议?我愿意接受任何和所有建议!

谢谢,

-亚历克

【问题讨论】:

  • 请澄清索引(例如第一个):单个键下有多少索引成员?如果可以,请发布一个数字示例。
  • “这将是读取的整个索引”——那么,这是一种非常奇怪的索引。通常,索引的目的是避免阅读全部内容。你能详细解释一下你想要达到的目标吗?

标签: mysql postgresql cassandra riak


【解决方案1】:

您没有提供足够的信息来支持大部分答案:您的索引设计。但是,Cassandra 通过扩展集群很容易扩展。

您可能想阅读这篇文章:http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

Cassandra 的一个更重要的问题是它是否支持您需要的那种查询 - 可伸缩性不是问题。从你给出的数字来看,听起来我们在谈论 TB 或数十 TB,这对 Cassandra 来说是非常安全的领域。

【讨论】:

    【解决方案2】:

    按照今天的标准,十亿并不是一个大数字,为什么不编写基准而不是猜测呢?这将为您提供更好的决策工具,而且非常容易做到。只需安装您的目标操作系统和每个数据库引擎,然后使用 Perl 运行查询(因为我喜欢它) 做这一切不会超过一天,我以前做过类似的事情。 一个很好的基准测试方法是编写一个随机的脚本,或者使用类似高斯钟形曲线的东西,执行查询,“模拟”实际使用。然后绘制数据或像老板一样做,然后阅读日志。

    【讨论】:

      猜你喜欢
      • 2010-11-15
      • 2019-01-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多