存储优化

这里有一些优化建议，你可以考虑用来提高性能并在开始扩展存储时降低成本。

🌐 Here are some optimizations that you can consider to improve performance and reduce costs as you start scaling Storage.

出口 #

🌐 Egress

如果你的项目有大量外发流量，这些优化可以帮助降低它。

🌐 If your project has high egress, these optimizations can help reducing it.

调整图片大小 #

🌐 Resize images

图片通常占你出口流量的大部分。通过尽量减小它们的大小，你可以减少出口流量并提升应用的性能。你可以利用我们的 图片转换 服务来即时优化任何图片。

🌐 Images typically make up most of your egress. By keeping them as small as possible, you can cut down on egress and boost your application's performance. You can take advantage of our Image Transformation service to optimize any image on the fly.

设置一个高的缓存控制值 #

🌐 Set a high cache-control value

使用浏览器缓存可以有效降低你的出口流量，因为资源在用户首次下载后会保存在用户的浏览器中。设置较高的 cache-control 值可以确保资源在用户的浏览器中存留较长时间，从而减少重复从服务器下载的需求。更多内容请点击 这里

🌐 Using the browser cache can effectively lower your egress since the asset remains stored in the user's browser after the initial download. Setting a high cache-control value ensures the asset stays in the user's browser for an extended period, decreasing the need to download it from the server repeatedly. Read more here

限制上传大小 #

🌐 Limit the upload size

你可以选择为你的存储桶设置最大上传大小。这样可以防止用户上传后再下载过大的文件。你可以通过在 存储桶级别 配置此选项来控制最大文件大小。

🌐 You have the option to set a maximum upload size for your bucket. Doing this can prevent users from uploading and then downloading excessively large files. You can control the maximum file size by configuring this option at the bucket level.

智能CDN #

🌐 Smart CDN

通过利用我们的智能CDN，你可以获得更高的缓存命中率，从而降低你的缓存出口费用，因为我们对缓存出口的收费更低（参见出口定价）。

🌐 By leveraging our Smart CDN, you can achieve a higher cache hit rate and therefore lower your egress cached, as we charge less for cached egress (see egress pricing).

优化列表对象 #

🌐 Optimize listing objects

一旦你有了大量的对象，你可能会注意到 supabase.storage.list() 方法开始变慢。这是因为这个端点比较通用，尝试在一次查询中同时获取文件夹和对象。虽然这种方法在构建像 Supabase 仪表盘上的存储查看器这样的功能时非常有用，但对象数量很多时会影响性能。

🌐 Once you have a substantial number of objects, you might observe that the supabase.storage.list() method starts to slow down. This occurs because the endpoint is quite generic and attempts to retrieve both folders and objects in a single query. While this approach is very useful for building features like the Storage viewer on the Supabase dashboard, it can impact performance with a large number of objects.

如果你的应用不需要计算整个层级，你可以通过创建如下的 Postgres 函数，大幅加快列出对象的查询执行速度：

🌐 If your application doesn't need the entire hierarchy computed you can speed up drastically the query execution for listing your objects by creating a Postgres function as following:

1
create or replace function list_objects(
2
    bucketid text,
3
    prefix text,
4
    limits int default 100,
5
    offsets int default 0
6
) returns table (
7
    name text,
8
    id uuid,
9
    updated_at timestamptz,
10
    created_at timestamptz,
11
    last_accessed_at timestamptz,
12
    metadata jsonb
13
) as $$
14
begin
15
    return query SELECT
16
        objects.name,
17
        objects.id,
18
        objects.updated_at,
19
        objects.created_at,
20
        objects.last_accessed_at,
21
        objects.metadata
22
    FROM storage.objects
23
    WHERE objects.name like prefix || '%'
24
    AND bucket_id = bucketid
25
    ORDER BY name ASC
26
    LIMIT limits
27
    OFFSET offsets;
28
end;
29
$$ language plpgsql stable;

然后你可以按如下方式使用你的 Postgres 函数：

🌐 You can then use the your Postgres function as following:

使用 SQL：

🌐 Using SQL:

1
select * from list_objects('bucket_id', '', 100, 0);

使用 SDK：

🌐 Using the SDK:

1
const { data, error } = await supabase.rpc('list_objects', {
2
  bucketid: 'yourbucket',
3
  prefix: '',
4
  limit: 100,
5
  offset: 0,
6
})

优化 RLS #

🌐 Optimizing RLS

在为存储表创建 RLS 策略时，你可以在感兴趣的列上添加索引来加快查找速度

🌐 When creating RLS policies against the storage tables you can add indexes to the interested columns to speed up the lookup