cassandradb结构的邮件伸缩问题

hts6caw3  于 2021-06-15  发布在  Cassandra
关注(0)|答案(2)|浏览(486)

我正在尝试创建一个基于数据库的邮件服务器。为此,我选择使用cassandradb。主要的问题是:我的表中的邮件越多,表中的答案就越长(这是正常的,但规模要大得多)。目前我只收到20000封邮件,Cassandra给我发送了一个超时(默认设置为5秒)。我们的目标是让每个用户在我的表中找到包含超过500k封邮件的邮件,并有可能过滤他们的邮件。
这是我的表格结构:

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'};

我很确定我的结构不好是因为我在Cassandra德布的技术很差。
下面是我想用这个表实现的操作:
更新:isimportant、isconfidential、isdeleted、isseen、mailid、folderid、categories
删除:按id、按文件夹id、按帐户id
选择:按id、按文件夹id、按帐户id
我想用这个过滤器选择:
订货人:日期、尺寸、邮寄地址(asc和desc)
包含:类别(我可以将某些类别分配给我的邮件,并且我希望在一个或多个类别中筛选所有电子邮件)
类似“%search%”:mailfrom,用于筛选包含我的搜索的邮件
等于:isconfidential、isimportant、isdeleted、isseen,以获取所有机密、重要、删除或看到的邮件。
我的表中只有很少的行(大约在1000毫秒内可以处理7k封电子邮件),但是我认为如果有好的结构和好的查询(没有允许过滤),它会更快。
而且,我显然不能在同一个查询中使用contains和类似“%text%”,它给了我一个错误代码。所以我用python做了这一步,但在我看来这是一个性能灾难,如果我能用cassandra做所有的事情,那就太好了。
为了查询我的cassandradb,我使用python3.5cassandra驱动程序,但我不认为这些信息是相关的。
如果您需要更多信息,请告诉我,提前谢谢!
编辑:作为一个解决方案,我按照你们告诉我的,我用elassandra(elasticseach+cassandra)部署了一个新服务器。我会尽快给你我得到的结果。

3zwjbxry

3zwjbxry1#

我同意@shutty的说法,你可以用cassandra作为你的数据存储,用es作为搜索工具。

iugsix8n

iugsix8n2#

我同意@lohfink关于从查询本身开始对c数据库建模的不同观点的建议。但根据你的要求,c可能不是最合适的。可以按以下方式重新设计架构:
没有带有“允许筛选”的查询,因为它执行表扫描。
相同的 mail__mail 架构,但带有 id 以及 date 合并到timeuuid以简化事情。
您可以使用外部elasticsearch或将其用作c*执行实际搜索的插件,而不是创建大量的二级索引(由于高基数数据的问题)和物化视图(由于数据复制)。

相关问题