主页 / user-195699

Majid's questions

Martin Hope
Majid
Asked: 2024-08-11 16:53:50 +0800 CST
  • 5

我计划为使用 Amazon S3 作为文件存储后端的多租户 SaaS 平台构建文件管理微服务。我打算使用 DynamoDB 作为数据库，因为它速度快且可扩展。该平台可能托管许多租户，每个租户有许多用户，每个用户的存储空间中有许多文件。

我需要在数据库中记录每个文件的元数据和用户目录结构（层次结构）。但是，我不确定 DynamoDB 是否是最佳选择。用户可能希望列出所有目录和文件，按名称搜索，或按字母顺序或按创建日期排序。这可能会导致“热分区”问题（至少对于全局二级索引而言）。当跟踪租户内所有用户上传的所有文件时，情况可能会变得更具挑战性。

因此，我正在考虑一种混合方法：使用 PostgreSQL 存储关系数据，使用 DynamoDB 存储文件信息和目录层次结构。

你对这个想法有什么看法？有人能给我指明正确的方向吗？

提前致谢。

aws
Martin Hope
Majid
Asked: 2020-08-29 08:43:04 +0800 CST
  • 2

假设我有一个agency用一些列命名的表：

  internal_id(integer, unique)
, external_id(bigint, unique)
, name, location, created_at, ...

internal_id并且external_id每个都是唯一的并且可以作为主键列。

还有一些其他表（说A, B, C, D, E）引用了这个表。假设这些表中的每一个都可能包含数百万或数十亿行。

通常我有external_id需要过滤表A, B, C, D, E数据的时候。

考虑到性能和存储空间，以下哪种方案是最好的选择：

  1. 在中用internal_id作主键agency，在其他表中用作外键。因为这个字段占用了 4 个字节的存储空间，我们可以节省数十亿字节。但是，正如我通常拥有的那样external_id，我必须为每个查询做一个额外JOIN的惩罚：
    SELECT A.* FROM A
         INNER JOIN agency ON A.internal_id=agency.internal_id
    WHERE agency.external_id=5;
  1. 在中用internal_id作主键agency，在其他表中用作外键。但是为了摆脱额外的JOIN，在我的应用程序中，我可以首先使用一个简单的查询 ( ) 映射external_id到，然后将获取的用于另一个简单的查询：internal_idSELECT internal_id FROM agency WHERE external_id=5internal_id
    SELECT * FROM A
    WHERE internal_id=59; -- 59 is the fetched internal_id from the other query

它是否比JOIN考虑应用程序和数据库之间的额外往返具有更好的性能？

  1. 忘记internal_id并将其用external_id作主键和外键，每个表中的每条记录都会增加 4 个额外字节A, B, C, D, E（
    SELECT * FROM A
    WHERE external_id=5

更新：

  • agency表可能包含成千上万或最多几百万行。
  • internal_id并且external_id不会随着时间的推移而改变，但其他非身份列可能很少改变。
  • 大约有 5 到 7 个相关表A, B, C, D, E, ...（
postgresql performance