【问题标题】:Cassandra database design - 1000 columns or dynamically created tablesCassandra 数据库设计 - 1000 列或动态创建的表
【发布时间】:2015-06-24 08:39:12
【问题描述】:

我想听听您对广告代理数据库潜在解决方案的建议。

我们希望构建一个能够以我们知道的方式跟踪用户的系统 他们在广告上做了什么,在哪里。

广告的类型很多,其中一些还可以使用FORMS,用户可以填写数据。 每个表单都不同,但我们不想为每个表单创建表格。

我们想创建一个非常宽的表,其中包含 1k 列,每种类型有几十列,并存储数据。

简而言之:

  1. 使用 Cassandra;
  2. 创建每日表,以便将数据存储在每日表中;
  3. 每个表将有 1000 个列(日期时间为 100,int 为 100,等等)。

应用程序逻辑会将数据映射到相关的列,以便我们稍后能够搜索和更新这些数据。

你觉得这个怎么样?

【问题讨论】:

  • 一个直接的想法是,您需要考虑如何查询数据,而不是如何存储数据。
  • 根据表单字段查询数据。认为它是一个表单生成器,每个表单不同,所以查询不同..

标签: cassandra


【解决方案1】:

小心在 Cassandra 中动态生成表。当您有太多表时,您将开始遇到问题,因为每个表都有内存开销。每Jonathan Ellis

Cassandra 将为每个 CF 的 memtable 保留至少 1MB 的空间:http://www.datastax.com/dev/blog/whats-new-in-cassandra-1-0-performance

在 Cassandra 中,即使是每日表格也不是一个好主意(每个表格的表格更糟)。我建议您构建一个可以保存所有数据的表,并且您知道它可以很好地扩展 - 使用 cassandra-stress 验证这一点。

此时,听从 mikea 的建议并开始考虑您的访问模式(请参阅 Patrick 的 video series),您可能需要构建额外的表来满足您的查询需求。

注意:对于希望在 c* 中使用无模式选项的任何人: https://blog.compose.io/schema-less-is-usually-a-lie/ http://rustyrazorblade.com/2014/07/the-myth-of-schema-less/

【讨论】:

  • 我明白了,但我的形式多种多样,没有共同点,所以不存在正常的结构。
  • 至少,你应该可以这样做:create table(form_id uuid, field_name text, field_value text, primary key (form_id, field_name))
  • 换句话说,de-normailze
  • 这只是您可以进入的方向的一个示例。您可以为您的特定用例找到一个快乐的媒介。如果有帮助,请考虑使用集合或用户定义的类型。但要准备好为此付出代价。
  • 你觉得我上面提到的选项怎么样?
猜你喜欢
  • 2012-08-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-22
  • 1970-01-01
  • 1970-01-01
  • 2018-10-04
  • 2019-02-23
相关资源
最近更新 更多