如何正确公开Cassandra实体的RESTAPI

虽然我知道不建议公开依赖于数据库的ID，而且使用经典关系数据库似乎很容易避免，但我想知道，在使用nosql数据库时，如何避免性能影响，因为在nosql数据库中，要避免搜索索引，并且不应在端点上公开复杂（长）组合键

例如，在Cassandra中，可用的查询链接到数据库模式，因此，在不添加索引的情况下，如何实现在这些实体上运行的API以及相应的（很长的复合）ID

例如，如何实现REST API来检查表中是否存在如下所示的条目：

TABLE A (
  ...,
  PRIMARY KEY ((pk1, pk2), ck1, ck2, ck3, ck4, ck5)
)

相应的端点看起来像这样（或者至少在某个地方包含URL中的所有主键组件）

这看起来很复杂，如果查询项目列表会很快导致很长的URL

---

这个问题通常是如何处理的？

在cassandra中，您的查询必须包含分区键。对于您的示例，分区键是pk1和pk2，带有=运算符。聚类列（ck1、ck2、…、ck5）用于对数据进行排序，并使用=、运算符添加一些其他筛选。分区键用于确定数据所属的节点，聚类列用于控制数据在分区中的排序方式。如果“索引”指的是分区键，那么您的查询必须包括它。我的意思是我必须在查询中包括所有（或至少包括分区键），这意味着我必须通过REST公开它们。我想知道，如果不使用额外的索引（如SASI），是否可以避免这种情况。您能再描述一下您对使用额外索引的想法吗？我不太明白你的意思。另外，我对SASI还有一点意见：据我所知，它被标记为实验性的，不建议用于生产

GET/v1/A/1/

看起来是查询ID为1的ressource的好方法，但由于实体的ID更复杂，所以它需要这样的

GET/v1/A/pk1/pk2/ck1/ck2/ck3/ck4/ck5

或ID的某个串联版本。我想问一下在不创建额外索引的情况下通常是如何处理的（实现线性ID）。您不必在定义主键的列上手动创建额外的索引。CQL中的所有数据访问（插入、更新、删除）都是按行操作的，因此它们都需要主键。

   GET /v1/A/pk1/pk2/ck1/ck2/ck3/ck4/ck5