Postgresql Amazon RDS db.r4.16xlarge比m3.medium快不了多少

我有一个postgres数据库，有大约37K行、一些索引列和一个jsonb列。 使用m3实例类型并查询涉及json ops的特定查询需要93秒，而在db.r4.16xlarge上的相同查询需要83秒，重复进行。这种差异不应该更大吗？ 假设有488GB的Ram，一切都可以从内存中获得。。RDS是否未配置为以这种方式优化并使用可用内存

查询示例：

这是另一个具有相同“问题”的查询：

explain analyze
SELECT 
       u.id::text as id, 
       u.date_created, 
       u.email, 
       AVG((s.fields->'someFunctionPerTrip'->>'value')::numeric) as risk,
       ROUND(SUM((s.fields ->> 'totalDistanceCumulative')::real)) as distance,
       COUNT(s.id) as trips,
       ROUND(SUM((s.fields ->> 'totalTimeSec')::real)/3600) as duration,
       (MAX(s.start_timestamp) - MIN(s.start_timestamp))/(1000*3600*24),
       ROUND(AVG((s.fields ->> 'avgFuelConsumption')::numeric/2),3) as avg_fuel_consumption
FROM  user u, trip s
WHERE s.user_id = u.id 
GROUP BY u.id

结果:

"HashAggregate  (cost=5291.70..5308.76 rows=273 width=274) (actual time=20594.922..20595.460 rows=273 loops=1)"
"  Group Key: u.id"
"  ->  Hash Join  (cost=81.14..3209.34 rows=37861 width=128) (actual time=0.311..72.824 rows=37861 loops=1)"
"        Hash Cond: (s.user_id = u.id)"
"        ->  Seq Scan on trip s  (cost=0.00..2607.61 rows=37861 width=54) (actual time=0.005..19.026 rows=37861 loops=1)"
"        ->  Hash  (cost=77.73..77.73 rows=273 width=82) (actual time=0.297..0.297 rows=273 loops=1)"
"              Buckets: 1024  Batches: 1  Memory Usage: 39kB"
"              ->  Seq Scan on user u  (cost=0.00..77.73 rows=273 width=82) (actual time=0.002..0.186 rows=273 loops=1)"
"Planning time: 0.619 ms"
"Execution time: 20595.608 ms"

每个id列上都有一个索引。谢谢你帮我理解它

去掉所有json操作，它可以在80ms内运行。取出嵌套的op s.fields->'someFunctionPerTrip'->>'value'使其在10秒内运行

---

那么哪种RDS最适合解析嵌套json呢？提供了数据结构，我无法更改它。

两种实例类型的内存中都可以容纳37K行。这表明瓶颈不是存储

是否可能只是JSON操作花费了很长时间

---

可能会帮助您更深入地了解实际花费的时间。

您选择的实例类型功能非常强大，并且可能对成千上万的用户有良好的性能？每秒的事务数。但是，运行单个查询并不是衡量数据库吞吐量的合适方法

在测试数据库性能时，应该模拟应用程序典型的查询负载

---

如果你的用例纯粹在一小部分数据上，选择性能非常重要，你可以考虑使用内存数据库。这将比任何传统的关系数据库都要快。

我同意。考虑到我操作的数据库是postgresql，并且在RDS中存在填充的数据，我如何才能获得最大的SELECT性能？如何将其全部读取到内存中？trip s上的Seq扫描表明trip.user_id未编制索引。除此之外，可能是JSON解析导致查询速度减慢。作为测试，请尝试删除使用->>的每个SELECT条目并检查性能。如果它运行得更快，那么我建议将JSON数据转换为数据库表中的实际字段，以便直接针对字段优化查询，而无需解析JSON；我同意json解析可能是问题所在，但如何在RDS上获得最快的json解析。数据已经给出。我建议您首先测试它，以确认JSON解析导致了速度减慢。最好的方法是不要在查询中解析JSON。最好在加载数据时将JSON扩展到实际的数据库字段中。然后，只需对字段执行普通查询。您可以通过向现有表中添加列，然后执行更新以提取JSON数据并将其保存到列中来转换现有数据。这允许数据库以其全部潜力运行。您受到CPU的限制。列是json还是jsonb？如果json在准备时尝试jsonb，并且值存储为实际的二进制值，而不是文本。它的jsonb。我现在将尝试使用真正的服务器vs rds