用于一对多查找的Cassandra数据建模 [英] Cassandra data modeling for one-to-many lookup

查看:135
本文介绍了用于一对多查找的Cassandra数据建模的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

请考虑存储用户及其联系人的问题。有大约1亿用户,每个有几百个联系人,平均联系人是1kb的大小。可能有一些用户具有过多的联系人(> 5000),并且可能有一些联系人比1kb的平均值大得多(比如10x)。用户主动添加联系人,较少也会删除它们。联系人不是指向其他用户的指针,而只是一组信息。

Consider the problem of storing users and their contacts. There are about a 100 million users, each has a few hundred contacts and on an average contacts are 1kb in size. There may be some users with too many contacts (>5000) and there may be some contacts that are much (say 10x) bigger than the average of 1kb. Users actively add contacts and less often also delete them. Contacts are not pointers to other users but just a bundle of information.

有两种查询 -


  1. 给定用户和联系人姓名,查找联系人详细信息

  2. 给定用户,查找所有关联的联系人姓名

我在想像这样的联系人表格 -

I was thinking of a contacts table like this -

CREATE TABLE contacts {
    user_name text,
    contact_name text,
    contact_details map<text, text>,
    PRIMARY KEY ( (user_name, contact_name) )
    //            ^ Notice the composite primary key
}

复合主键的选择是由于数量和大小的每个用户的联系人。我需要每行一个联系人。

The choice of composite primary key is due to the number and size of contacts per user. I wanted one contact per row.

此表格可以轻松地解决查询联系人的详细信息,查询用户和联系人姓名。

This table easily addresses the query of looking up a contact's details given a user and a contact name.

我在寻找第二个查询的建议。

I'm looking for suggestions to address the second query.

我心中有两个选项b
$ b

Two options (with related concerns) on my mind -


  1. 创建名为contact_names_by_user的第二个表,其中user_name作为分区键,contact_name作为集群键。问题:如果某个用户的联系人过多(例如20k),那么是否会导致非最佳宽行?

  2. 在user_name上创建索引。关注:然而考虑到用户总数(100M)与每个用户的平均联系人(例如200)的比率,该值是否被认为具有高基数,因此不适合建立索引?



    一般来说,有没有指南来查找一个项目(例如这里的用户)引用的许多项目(例如联系人),而不在宽行或非最佳索引中运行? / p>

In general, are there guideline around looking up many items (like contacts here) referred by one item (like user here) without running in wide rows or non-optimal indexes?

推荐答案

创建索引本身不应该是问题IMHO。平均基数200听起来不错。

Creating index itself should not be a problem IMHO. Average cardinality of 200 sounds good.

其他选项是维护自己的索引,如:
CREATE TABLE contacts_by_user(
user_name text PRIMARY KEY,
联系人集

Other option is you maintaining your own index like: CREATE TABLE contacts_by_user ( user_name text PRIMARY KEY, contacts set )

,但您的索引和联系人可能会不同步。

though your index and contacts can go out of sync.

这篇关于用于一对多查找的Cassandra数据建模的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆