我正在努力寻找一种解决方案（最好是 DBaaS），我可以依靠它来存储和查询大约 3 亿行数据（大约 100GB）。
有问题的数据几乎是数字。还有一个“描述”列，我想对其执行全文搜索。还有几个用于过滤的“类别”列。我还想以多种方式（10 多个不同的索引）过滤/排序搜索结果。
不需要进行复杂的连接，因为数据几乎是非规范化的。数据更新频繁：每天约有 5000 万条记录被替换。
我首先尝试使用 DynamoDB，但它最多只能支持 5 个索引，并且无法以合理的速度进行全文搜索。我也考虑过谷歌的 BigQuery，但它是为“仅附加”数据而设计的。我现在正在考虑 Redshift，但我不确定它如何能够处理如此大量的每日更新。
任何意见，将不胜感激！
我有巨大的 postgres 表（10GB 数据 - 160M 记录）。表是静态的，没有对其执行的写操作。我想复制它，执行写入，重新索引它，然后使用单个快速事务删除旧事务并将新事务重命名为原始名称。
复制这么大的表的最快方法是什么？
我有两个数据库表。一个包含数亿条记录。让我们称之为那个history。另一个是每天计算的，我想将它的所有记录复制到history一个中。
我所做的是运行：
INSERT INTO history SELECT * FROM daily
它确实奏效了一段时间，但随着记录数量的不断增长，它开始变得越来越慢。现在我有大约 200 万条记录需要在一次操作中从复制到复制，daily并且history完成时间太长。
是否有另一种更有效的方式将数据从一个表复制到另一个表？
我有两个索引表：
我想要的是能够按整体和特定网络内的 view_count 进行排序。Postgres 对这两种情况都使用正确的索引。但是，如果我想查找 network_id 为 NULL 的大多数视图的记录，它会使用第一个索引，并过滤掉 ，因此执行速度非常慢：
explain analyze SELECT *
FROM latest_channel_snapshots
WHERE network_id IS NULL
ORDER BY view_count DESC NULLS LAST
LIMIT 5 OFFSET 500000;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=39599.04..39599.44 rows=5 width=74) (actual time=1926.271..1926.287 rows=5 loops=1)
-> Index Scan using latest_channel_snapshots_views_idx on latest_channel_snapshots (cost=0.00..42001.59 rows=530336 width=74) (actual time=0.060..1899.224 rows=500005 loops=1)
Filter: (network_id IS NULL)
Rows Removed by Filter: 305022
Total runtime: 1926.309 ms
(5 rows)
我有 18M 行的视频表。当我按 ID 搜索特定视频时，最多需要 6 秒才能完成。有时需要几毫秒，有时长达 6 秒，但平均约为 2 秒。
应用程序托管在 heroku 上，我正在使用带有 410MB RAM 的Crane 数据库 ( https://addons.heroku.com/heroku-postgresql )。
有什么办法可以加快这个速度吗？我平均每秒查询 50 次视频，新视频以每秒 50 次的速度插入/更新。
explain analyze SELECT * FROM videos WHERE id = 17841464 LIMIT 1;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..6.43 rows=1 width=119) (actual time=2337.892..2337.894 rows=1 loops=1)
-> Index Scan using videos_pkey on videos (cost=0.00..6.43 rows=1 width=119) (actual time=2337.888..2337.888 rows=1 loops=1)
Index Cond: (id = 17841464)
Total runtime: 2337.943 ms
表格如下所示：
\d+ videos;
Table "public.videos"
Column | Type | Modifiers | Storage | Stats target | Description
----------------+-----------------------------+-----------------------------------------------------+----------+--------------+-------------
id | integer | not null default nextval('videos_id_seq'::regclass) | plain | |
uuid | character(11) | not null | extended | |
channel_id | integer | not null | plain | |
category_id | integer | | plain | |
title | character varying(255) | | extended | |
published_at | timestamp without time zone | | plain | |
view_count | bigint | | plain | |
like_count | integer | | plain | |
dislike_count | integer | | plain | |
favorite_count | integer | | plain | |
comment_count | integer | | plain | |
disabled | boolean | default false | plain | |
created_at | timestamp without time zone | | plain | |
updated_at | timestamp without time zone | | plain | |
Indexes:
"videos_pkey" PRIMARY KEY, btree (id)
"videos_uuid_idx" UNIQUE, btree (uuid)
"videos_latest_by_channel_idx" btree (channel_id, published_at DESC)
"videos_top_by_channel_idx" btree (channel_id, view_count DESC)
Has OIDs: no
我正在尝试使用这样的简单查询对 800 万个浮点 ( REAL) 值求和：
SELECT SUM(metric) FROM metrics;
但是，它返回的结果非常不准确。它应该返回 137,586.77，但它返回 137,303（差 283.77）
有没有办法强制查询更精确？
我的一些plpgsql触发器中运行了几条 sql 语句。我已经启用了日志记录log_statement = 'all'。它记录“触发语句”，但不记录查询本身中的语句。
有没有办法在标准 postgres 日志中显示在触发器中执行的语句？
我已经使用 postgresql 规则实施了数据非规范化策略。出于性能原因，我选择了规则而不是触发器。
Schema 的结构如下：
hits系统的一部分是为表中的每个用户存储stats。Hit 是一个虚构的指标，它并不真正相关。系统可以收集许多这些指标。统计表中有很多记录（每天超过 1,000,000 条）。
我想知道给定日期每个用户、每个项目、每个客户和每个应用程序有多少次点击。
为了使其快速运行，我按天对统计数据进行分组并将输出存储到 user_hits 表中。在此过程中，还添加了 application_id、client_id 和 project_id（作为列），并创建了适当的索引。
我想通过按 project_id、client_id 和最后的 application_id 分组来进一步优化流程。数据管道是这样的：
stats -> user_hits -> project_hits -> client_hits -> application_hits
我想确保当我删除user_hits给定日期的数据时project_hits，同一日期的数据也会被删除。这个过程应该传播到链中的最后一个表。
我定义了这些简单的规则：
CREATE RULE delete_children AS ON DELETE TO user_hits
DO ALSO
DELETE FROM project_hits WHERE day = OLD.day;
CREATE RULE delete_children AS ON DELETE TO project_hits
DO ALSO
DELETE FROM client_hits WHERE day = OLD.day;
CREATE RULE delete_children AS ON DELETE TO client_hits
DO ALSO
DELETE FROM application_hits WHERE day = OLD.day;
但是，当我发表这样的声明时：
DELETE FROM user_hits WHERE day = current_date;
我希望它运行这 3 个查询作为回报：
DELETE FROM project_hits WHERE day = current_date;
DELETE FROM client_hits WHERE day = current_date;
DELETE FROM application_hits WHERE day = current_date;
然而，事实并非如此。
它完成了操作，但需要几分钟才能完成（使用测试数据）。使用真实数据需要数小时，而手动运行这 3 个查询需要几毫秒。它花费的时间似乎与组合的数量成正比（用户 x 项目 x 客户 x 应用程序）。
这里有什么问题？我错过了什么吗？这可以用触发器以优化的方式实现吗？
包括重现问题的示例脚本：
https://gist.github.com/assembler/5151102
user_hits更新：从到project_hits（等等）的过渡由工作进程在后台完成（因为它涉及联系第 3 方服务以获取更多信息）。它足够聪明，可以重新计算缺失日期的所有内容。所以我唯一需要的是一种以优化方式级联删除记录的方法。
更新：stats每天都会填写表格。唯一可能的情况是无条件删除一整天的数据，然后用新值替换它。
更新：我注意到受影响的行数（从explain语句中提取）正好等于user_hits、project_hits、client_hits和application_hits表（数亿行）中受影响行的乘积。
事实证明它是这样工作的：
DELETE FROM user_hits WHERE day = current_date;user_hits表中的每一行，触发规则，从中删除每一行project_hitsproject_hits，都会触发规则，从中删除每一行client_hitsclient_hits，都会触发规则，从中删除每一行application_hits因此，操作数等于这些表中受影响行数的乘积。