如何使用partiql在DynamoDB中的查询订购?

发布于 2025-02-04 06:54:22 字数 1603 浏览 2 评论 0 原文

关于这个问题的一些论坛中有一些答案,人们通常在其中重复已经令人困惑的AWS文档有关DynamoDB的文档,但是我需要一个示例来查看其实际工作方式。 我有此查询:

SELECT id, message, created, FROM "messages"."sender_company_id-index" 
WHERE sender_company_id = 435634652 AND receiver_company_id = 69992528 
AND sender_user_id = 186 AND receiver_user_id = 201
ORDER BY id DESC

此错误消息失败:

执行命令期间发生了错误。 验证Exception:按子句顺序排序中的可变参考ID必须为 主要键的一部分

创建字段的一部分已经被索引,所以怎么了?为什么它要求它是“主要键的一部分”?在不同情况下,我想通过不同的字段订购,以便将它们全部设置为主要钥匙。我不明白!

编辑

我注意到下面的一些评论指出,使用partiql订单不可能。另外, So Link 声称。 但是,

更新:

我能够使它起作用。

SELECT id, created, sender_company_id, receiver_company_id
       sender_user_name, sender_user_id, sender_company_name, receiver_company_name
       FROM "messages"."sender_company_id-created-index" 
       WHERE (sender_company_id = 435634652 OR receiver_company_id= 435634652)
       AND (sender_user_id = 186 OR receiver_user_id = 186) 
       ORDER BY created ASC, sender_company_id ASC

错误:

验证exception:必须至少具有一个非访问的哈希密钥 使用订单时条件在Where子句中的条件。

如果我更改了此处的工作:

...WHERE sender_company_id = 435634652

这是我的索引:

”

我不了解这里发生了什么。我确实有索引,我在Where子句中使用了非选项(关键分区),但它失败了。

There are some answers in some forums about this question where people are generally repeating the already confusing AWS documentation about DynamoDB, but I need an example to see how it actually works.
I have this query :

SELECT id, message, created, FROM "messages"."sender_company_id-index" 
WHERE sender_company_id = 435634652 AND receiver_company_id = 69992528 
AND sender_user_id = 186 AND receiver_user_id = 201
ORDER BY id DESC

and it fails with this error message:

An error occurred during the execution of the command.
ValidationException: Variable reference id in ORDER BY clause must be
part of the primary key

created field is already indexed so what's wrong? Why does it require it to be "part of the primary key"? I would like to order by different fields in different cases so I cant have all of them set as primary key. I dont get it!

EDIT

I noticed some of the comments below state that ORDER BY is not a possibility using PartiQL. Also this SO link claims that.
However, AWS official documentation states the opposite.

UPDATE:

I was able to make it work though not completely.

SELECT id, created, sender_company_id, receiver_company_id
       sender_user_name, sender_user_id, sender_company_name, receiver_company_name
       FROM "messages"."sender_company_id-created-index" 
       WHERE (sender_company_id = 435634652 OR receiver_company_id= 435634652)
       AND (sender_user_id = 186 OR receiver_user_id = 186) 
       ORDER BY created ASC, sender_company_id ASC

Error:

ValidationException: Must have at least one non-optional hash key
condition in WHERE clause when using ORDER BY clause.

If I change the WHERE to this it works:

...WHERE sender_company_id = 435634652

Here is my indexes:

Screenshot of indexes in AWS

It is beyond my understanding what's going on here. I do have the indexes, I am using non-optional (key partitions) in the WHERE clause but it fails.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

错爱 2025-02-11 06:54:24
[EDIT:OP添加索引密钥详细信息和第二个PartiQL语句]

错误#1正在发生,因为您只能通过 order 一个是 sender_company_id-index index的分区( = hash)键或排序(= range)键*。请参阅第一个标记的不愉快示例的第一个块。发生错误#2是因为订购似乎仅用于查询操作(您的第二个语句是扫描)。这个约束是有道理的,但我找不到任何地方记录的。请参阅第二个不愉快的示例的第二块。但是首先,一些工作 示例订单:

我需要一个示例来查看它的实际工作方式。

my-table 具有分区密钥 pk ,然后对密钥 sk 进行排序。该表有一个辅助索引,名为 gsi1 。该索引使用 gsi1pk 字段作为其分区密钥,其排序密钥是 gsi1sk 。这是一个示例记录:

{
 "PK": "1x", "SK": "cc", "GSI1PK": "a", "GSI1SK": "b1", "Other": "foo", "Another": "bar"
}

这些是有效的partiql 通过语句订购:

SELECT * FROM "my-table"        WHERE PK = '1x'                              ORDER BY SK     ASC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK = 'a'                           ORDER BY GSI1SK ASC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK IN ['a', 'b']                   ORDER BY GSI1PK DESC, GSI1SK ASC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK IN ['a', 'b']                   ORDER BY GSI1SK DESC, GSI1PK DESC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK IN ['a', 'b'] AND Other = 'foo' ORDER BY GSI1SK DESC, GSI1PK DESC

但是,我在上查询索引的主键以外的字段订购将失败:

-- ValidationException: Variable reference Other in ORDER BY clause must be part of the primary key
❌ SELECT * FROM "my-table"."GSI1" WHERE GSI1PK = 'a' ORDER BY Other ASC
-- ValidationException: Variable reference GSI1PK in ORDER BY clause must be part of the primary key
❌ SELECT * FROM "my-table" WHERE PK = 'a' ORDER BY GSI1PK ASC

订购,显然还需要一个,其中子句带有 = 或在条件中的条件上的条件。也就是说,订购成功为查询操作。有序扫描操作失败:

-- ValidationException: Must have WHERE clause in the statement when using ORDER BY clause.
❌ SELECT * FROM "my-table" ORDER BY SK ASC

-- ValidationException: Must have at least one non-optional hash key condition in WHERE clause when using ORDER BY clause.
❌ SELECT * FROM "my-table" WHERE begins_with(PK, 'b') ORDER BY SK ASC

创建的字段已经被索引,所以怎么了?

dynamodb 辅助索引让您使用替代键

为什么它要求它成为“主要键的一部分”?我想订购不同的fieldds

DynamoDB订购,施加了设计约束,以保留其可扩展性超级能力。


*您只能按语句的 table [.index] 的主要密钥元素订购,如 docs select ... select ... select ... select ... by table [.index]按键[desc | asc] ,wery 密钥“哈希密钥或用于订购返回结果的排序键。”

[EDIT: OP added index key details and a second PartiQL statement]

Error #1 is happening because you can only ORDER BY a field that is the sender_company_id-index index's Partition (=Hash) Key or Sort (=Range) Key*. See the first block of unhappy examples marked ❌. Error #2 is happening because ORDER BY seems to be supported only for query operations (your second statement is a scan). This constraint makes sense, but I could not find it documented anywhere. See the second block of unhappy ❌ examples. But first, some working ORDER BY examples:

I need an example to see how it actually works.

my-table has a Partition Key PK and Sort Key SK. The table has one secondary index, named GSI1. The index uses the GSI1PK field as its Partition Key and its Sort Key is GSI1SK. Here's a sample record:

{
 "PK": "1x", "SK": "cc", "GSI1PK": "a", "GSI1SK": "b1", "Other": "foo", "Another": "bar"
}

These are valid PartiQL ORDER BY statements:

SELECT * FROM "my-table"        WHERE PK = '1x'                              ORDER BY SK     ASC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK = 'a'                           ORDER BY GSI1SK ASC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK IN ['a', 'b']                   ORDER BY GSI1PK DESC, GSI1SK ASC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK IN ['a', 'b']                   ORDER BY GSI1SK DESC, GSI1PK DESC
SELECT * FROM "my-table"."GSI1" WHERE GSI1PK IN ['a', 'b'] AND Other = 'foo' ORDER BY GSI1SK DESC, GSI1PK DESC

However, ordering by fields other than the Primary Keys of the index I'm querying on will fail:

-- ValidationException: Variable reference Other in ORDER BY clause must be part of the primary key
❌ SELECT * FROM "my-table"."GSI1" WHERE GSI1PK = 'a' ORDER BY Other ASC
-- ValidationException: Variable reference GSI1PK in ORDER BY clause must be part of the primary key
❌ SELECT * FROM "my-table" WHERE PK = 'a' ORDER BY GSI1PK ASC

ORDER BY apparently also requires a WHERE clause with a = or IN condition on the Partition Key. That is, ordering succeeds for query operations. Scan operations with ordering fail:

-- ValidationException: Must have WHERE clause in the statement when using ORDER BY clause.
❌ SELECT * FROM "my-table" ORDER BY SK ASC

-- ValidationException: Must have at least one non-optional hash key condition in WHERE clause when using ORDER BY clause.
❌ SELECT * FROM "my-table" WHERE begins_with(PK, 'b') ORDER BY SK ASC

the created field is already indexed so what's wrong?

DynamoDB secondary indexes are fundamentally different than their RDBMS cousins. A secondary index lets you query the data in the table using an alternate key.

Why does it require it to be "part of the primary key"? I would like to order by different fieldds

DynamoDB imposes design constraints to preserve its scalability superpowers.


* You can only order by the primary key elements of your statement's table[.index], as in the docs: SELECT ... FROM table[.index] ORDER BY key [DESC|ASC], where key is a "hash key or a sort key to use to order returned results."

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文