CassandraDB结构的扩展问题

时间:2018-09-11 16:47:53

标签: email cassandra bigdata scaling

我正在尝试创建基于数据库的邮件服务器。为此,我选择使用CassandraDB。主要问题是:表中的邮件越多,表的答案就越长(这是正常现象,但可以扩展到很多)。目前我只收到20000封邮件,而Cassandra则向我发送超时(显然,默认设置为5秒)。目的是使每个用户都能在我的表中找到包含500,000邮件的邮件,并可以过滤他们的邮件。

这是我的表结构:

CREATE TABLE mail__mail (
    accountid uuid,
    date timestamp,
    id uuid,
    attachment set<uuid>,
    categories set<uuid>,
    content text,
    dateadded timestamp,
    folderid uuid,
    hash text,
    isconfidential boolean,
    isdeleted boolean,
    isimportant boolean,
    isseen boolean,
    mailcc text,
    mailfrom text,
    mailid text,
    mailto text,
    size bigint,
    subject text,
    PRIMARY KEY (accountid, date, id)
) WITH CLUSTERING ORDER BY (date DESC,id ASC);

CREATE CUSTOM INDEX mailFromIndex ON mail__mail (mailfrom) USING 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'mode': 'CONTAINS','analyzed': 'true', 'analyzer_class': 'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer', 'case_sensitive': 'false'};
CREATE CUSTOM INDEX subjectIndex ON mail__mail (subject) USING 'org.apache.cassandra.index.sasi.SASIIndex' WITH OPTIONS = {'mode': 'CONTAINS','analyzed': 'true', 'analyzer_class': 'org.apache.cassandra.index.sasi.analyzer.NonTokenizingAnalyzer', 'case_sensitive': 'false'};

由于我在CassandraDB中的技能差,我很确定我的结构不好。

这是我要使用此表实现的操作:

  • UPDATE:isImportant,isConfidential,isDeleted,isSeen,mailId,folderId,类别
  • 删除:按ID,按文件夹ID,按帐户ID
  • SELECT:按ID,按文件夹ID,按帐户ID

我想使用此过滤器进行选择:

  • ORDER BY:日期,大小,mailFrom(ASC和DESC)
  • 内容:类别(我可以为邮件分配一些类别,并且我希望过滤一个或多个类别中的所有电子邮件)
  • 喜欢'% search %':mailFrom,以过滤包含我的搜索的邮件
  • 等于:isConfidential,isImportant,isDeleted,isSeen,以获取所有机密,重要,已删除或已看到的邮件。

我的表中几乎没有行(它可以在1000毫秒内处理7k电子邮件),但是我认为它可以通过良好的结构和良好的查询(无需允许过滤)来更快。

此外,我显然不能在同一查询中使用CONTAINS和LIKE'% text %',它给了我1300错误代码。因此,我在python中执行了此步骤,但我认为这是性能上的灾难,如果我可以使用cassandra进行所有操作,那就太好了。

要查询我的CassandraDB,我使用Python3.5 Cassandra驱动程序,但我认为此信息无关。

如果需要更多信息,请告诉我, 预先感谢!

编辑:作为一个解决方案,我按照你们告诉我的方法,我与Elassandra(ElasticSeach + Cassandra)一起部署了一个新服务器。我会尽力给你我尽快得到的结果。

1 个答案:

答案 0 :(得分:1)

我同意@Lohfink关于从查询本身开始对C *数据库建模的不同观点的建议。但是根据您的要求,C *可能不是完美的选择。您可以通过以下方式重新设计架构:

  • 像表扫描一样,没有使用ALLOW FILTERING的查询。
  • 相同的mail__mail模式,但将iddate合并到timeuuid中以简化操作。
  • 您可以使用外部ElasticSearch或将其as a plugin用于C *,而不是创建大量的二级索引(由于高基数数据的问题)和物化视图(由于数据复制)实际搜索。