PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Analisi comparativa delle soluzioni cloud PostgreSQL gestite - Parte prima:Amazon Aurora

Questo blog avvia una serie multipla che documenta il mio viaggio nel benchmarking di PostgreSQL nel cloud.

La prima parte include una panoramica degli strumenti di benchmarking e dà il via al divertimento con Amazon Aurora PostgreSQL.

Selezione dei provider di servizi cloud PostgreSQL

Qualche tempo fa mi sono imbattuto nella procedura di benchmark AWS per Aurora e ho pensato che sarebbe stato davvero interessante se avessi potuto fare quel test ed eseguirlo su altri provider di hosting cloud. A merito di Amazon, tra i tre fornitori di servizi di calcolo più noti — AWS, Google e Microsoft — AWS è l'unico contributore importante allo sviluppo di PostgreSQL e il primo a offrire un servizio PostgreSQL gestito (risalente a novembre 2013).

Sebbene i servizi PostgreSQL gestiti siano disponibili anche da una pletora di provider di hosting PostgreSQL, volevo concentrarmi sui suddetti tre provider di cloud computing poiché i loro ambienti sono i luoghi in cui molte organizzazioni che cercano i vantaggi del cloud computing scelgono di eseguire le loro applicazioni, a condizione che abbiano il know-how richiesto sulla gestione di PostgreSQL. Sono fermamente convinto che nel panorama IT odierno, le organizzazioni che lavorano con carichi di lavoro critici nel cloud trarrebbero grande beneficio dai servizi di un fornitore di servizi PostgreSQL specializzato, che può aiutarli a navigare nel complesso mondo dei GUCS e nelle miriadi di presentazioni SlideShare.

Selezione dello strumento di benchmark giusto

Il benchmarking di PostgreSQL compare abbastanza spesso nella mailing list delle prestazioni e, come sottolineato innumerevoli volte, i test non hanno lo scopo di convalidare una configurazione per un'applicazione reale. Tuttavia, la selezione dello strumento e dei parametri di riferimento giusti è importante per raccogliere risultati significativi. Mi aspetto che ogni provider cloud fornisca procedure per il benchmarking dei propri servizi, soprattutto quando la prima esperienza cloud potrebbe non iniziare con il piede giusto. La buona notizia è che due dei tre giocatori in questo test hanno incluso dei benchmark nella loro documentazione. La guida di AWS Benchmark Procedure per Aurora è facile da trovare, disponibile direttamente nella pagina delle risorse di Amazon Aurora. Google non fornisce una guida specifica per PostgreSQL, tuttavia la documentazione di Compute Engine contiene una guida ai test di carico per SQL Server basata su HammerDB.

Di seguito è riportato un riepilogo degli strumenti di benchmark basati sui loro riferimenti che vale la pena esaminare:

  • Il benchmark AWS menzionato sopra si basa su pgbench e sysbench.
  • HammerDB, menzionato anche in precedenza, è discusso in un recente post su pgsql-hacker list.
  • Test TPC-C basati su oltpbench come accennato in questa altra discussione sugli hacker di pgsql.
  • benchmarksql è un altro test TPC-C utilizzato per convalidare le modifiche alle divisioni di pagina B-Tree.
  • pg_ycsb è il nuovo arrivato in città, migliorato su pgbench e già utilizzato da alcuni hacker di PostgreSQL.
  • pgbench-tools, come suggerisce il nome, è basato su pgbench e, pur non avendo ricevuto alcun aggiornamento dal 2016, è il prodotto di Greg Smith, l'autore dei libri PostgreSQL High Performance.
  • join order benchmark è un benchmark che testerà Query Optimizer.
  • pgreplay che mi sono imbattuto durante la lettura del blog del prompt dei comandi è il più vicino possibile al benchmarking di uno scenario di vita reale.

Un altro punto da notare è che PostgreSQL non è ancora adatto per lo standard di benchmark TPC-H e, come notato in precedenza, tutti gli strumenti (tranne pgreplay) devono essere eseguiti in modalità TPC-C (pgbench è predefinito).

Ai fini di questo blog, ho pensato che la procedura di benchmark AWS per Aurora sia un buon inizio semplicemente perché stabilisce uno standard per i provider di servizi cloud e si basa su strumenti ampiamente utilizzati.

Inoltre, ho usato l'ultima versione di PostgreSQL disponibile in quel momento. Quando si seleziona un provider cloud, è importante considerare la frequenza degli aggiornamenti, soprattutto quando importanti funzionalità introdotte dalle nuove versioni possono influire sulle prestazioni (come nel caso delle versioni 10 e 11 rispetto alla 9). Al momento della stesura di questo documento abbiamo:

  • Amazon Aurora PostgreSQL 10.6
  • Amazon RDS per PostgreSQL 10.6
  • Google Cloud SQL per PostgreSQL 9.6
  • Microsoft Azure PostgreSQL 10.5

...e il vincitore qui è AWS offrendo la versione più recente (sebbene non sia l'ultima, che al momento della stesura di questo articolo è la 11.2).

Impostazione dell'ambiente di benchmarking

Ho deciso di limitare i miei test ai carichi di lavoro medi per un paio di motivi:in primo luogo, le risorse cloud disponibili non sono identiche tra i provider. Nella guida, le specifiche AWS per l'istanza database sono 64 vCPU / 488 GiB RAM / 25 Gigabit Network, mentre la RAM massima di Google per qualsiasi dimensione di istanza (la scelta deve essere impostata su "custom" in Google Calculator) è 208 GiB, e Business Critical Gen5 di Microsoft a 32 vCPU viene fornito con solo 163 GiB). In secondo luogo, l'inizializzazione di pgbench porta la dimensione del database a 160 GiB che, nel caso di un'istanza con 488 GiB di RAM, è probabile che venga archiviata in memoria.

Inoltre, ho lasciato intatta la configurazione di PostgreSQL. Il motivo per attenersi alle impostazioni predefinite del provider di servizi cloud è che, immediatamente, quando è sollecitato da un benchmark standard, ci si aspetta che un servizio gestito funzioni ragionevolmente bene. Ricorda che la comunità di PostgreSQL esegue i test di pgbench come parte del processo di gestione dei rilasci. Inoltre, la guida AWS non menziona alcuna modifica alla configurazione PostgreSQL predefinita.

Come spiegato nella guida, AWS ha applicato due patch a pgbench. Poiché la patch per il numero di client non si applicava in modo pulito alla versione 10.6 di PostgreSQL e non volevo investire tempo per risolverla, il numero di client era limitato a un massimo di 1.000.

La guida specifica un requisito per l'istanza client per avere abilitato il networking avanzato, per questo tipo di istanza è l'impostazione predefinita:

[[email protected] ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 0a:cd:ee:40:2b:e6 brd ff:ff:ff:ff:ff:ff
    inet 172.31.19.190/20 brd 172.31.31.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8cd:eeff:fe40:2be6/64 scope link
       valid_lft forever preferred_lft forever
[[email protected] ~]$ ethtool -i eth0
driver: ena
version: 2.0.2g
firmware-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
>>> aws (master *%) ~ $ aws ec2 describe-instances --instance-ids i-0ee51642334c1ec57 --query "Reservations[].Instances[].EnaSupport"
[
    true
]

Esecuzione del benchmark su Amazon Aurora PostgreSQL

Durante la corsa vera e propria ho deciso di fare un'altra deviazione dalla guida:invece di eseguire il test per 1 ora impostare il limite di tempo a 10 minuti, che è generalmente accettato come un buon valore.

Corri #1

Specifiche

  • Questo test utilizza le specifiche AWS per le dimensioni dell'istanza del database e del client.
    • Macchina client:istanza EC2 ottimizzata per la memoria su richiesta:
      • vCPU:32 (16 core x 2 thread/core)
      • RAM:244 GiB
      • Stoccaggio:EBS ottimizzato
      • Rete:10 Gigabit
    • Cluster DB:db.r4.16xlarge
      • vCPU:64
      • ECU (capacità CPU):195 x [1,0-1,2 GHz] Opteron / Xeon 2007
      • RAM:488 GiB
      • Storage:EBS Optimized (capacità dedicata per I/O)
      • Rete:larghezza di banda massima di 14.000 Mbps su una rete da 25 Gps
  • La configurazione del database includeva una replica.
  • L'archiviazione del database non è stata crittografata.

Esecuzione dei test e dei risultati

  1. Segui le istruzioni nella guida per installare pgbench e sysbench.
  2. Modifica ~/.bashrc per impostare le variabili di ambiente per la connessione al database e i percorsi richiesti per le librerie PostgreSQL:
    export PGHOST=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGUSER=postgres
export PGPASSWORD=postgres
export PGDATABASE=postgres
export PATH=$PATH:/usr/local/pgsql/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
  3. Inizializza il database:
    [[email protected] ~]# pgbench -i --fillfactor=90 --scale=10000
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables...
100000 of 1000000000 tuples (0%) done (elapsed 0.05 s, remaining 457.23 s)
200000 of 1000000000 tuples (0%) done (elapsed 0.13 s, remaining 631.70 s)
300000 of 1000000000 tuples (0%) done (elapsed 0.21 s, remaining 688.29 s)

...

999500000 of 1000000000 tuples (99%) done (elapsed 811.41 s, remaining 0.41 s)
999600000 of 1000000000 tuples (99%) done (elapsed 811.50 s, remaining 0.32 s)
999700000 of 1000000000 tuples (99%) done (elapsed 811.58 s, remaining 0.24 s)
999800000 of 1000000000 tuples (99%) done (elapsed 811.65 s, remaining 0.16 s)
999900000 of 1000000000 tuples (99%) done (elapsed 811.73 s, remaining 0.08 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 811.80 s, remaining 0.00 s)
vacuum...
set primary keys...
done.
  4. Verifica la dimensione del database:
    postgres=> \l+ postgres
                                                                 List of databases
   Name   |  Owner   | Encoding |   Collate   |    Ctype    | Access privileges |  Size  | Tablespace |                Description
----------+----------+----------+-------------+-------------+-------------------+--------+------------+--------------------------------------------
 postgres | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                   | 160 GB | pg_default | default administrative connection database
(1 row)
  5. Utilizzare la query seguente per verificare che l'intervallo di tempo tra i checkpoint sia impostato in modo che i checkpoint vengano forzati durante l'esecuzione di 10 minuti:
    SELECT
   total_checkpoints,
   seconds_since_start / total_checkpoints / 60 AS minutes_between_checkpoints FROM (
      SELECT EXTRACT(
      EPOCH FROM (
         now() - pg_postmaster_start_time()
      )
      ) AS seconds_since_start,
   (checkpoints_timed+checkpoints_req) AS total_checkpoints
FROM pg_stat_bgwriter) AS sub;
    Risultato:
    postgres=> \e
   total_checkpoints | minutes_between_checkpoints
-------------------+-----------------------------
                  50 |           0.977392292333333
(1 row)
  6. Esegui il carico di lavoro di lettura/scrittura:
    [[email protected] ~]# pgbench --protocol=prepared -P 60 --time=600 --client=1000 --jobs=2048
    Output 
    starting vacuum...end.
progress: 60.0 s, 35670.3 tps, lat 27.243 ms stddev 10.915
progress: 120.0 s, 36569.5 tps, lat 27.352 ms stddev 11.859
progress: 180.0 s, 35845.2 tps, lat 27.896 ms stddev 12.785
progress: 240.0 s, 36613.7 tps, lat 27.310 ms stddev 11.804
progress: 300.0 s, 37323.4 tps, lat 26.793 ms stddev 11.376
progress: 360.0 s, 36828.8 tps, lat 27.155 ms stddev 11.318
progress: 420.0 s, 36670.7 tps, lat 27.268 ms stddev 12.083
progress: 480.0 s, 37176.1 tps, lat 26.899 ms stddev 10.981
progress: 540.0 s, 37210.8 tps, lat 26.875 ms stddev 11.341
progress: 600.0 s, 37415.4 tps, lat 26.727 ms stddev 11.521
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: prepared
number of clients: 1000
number of threads: 1000
duration: 600 s
number of transactions actually processed: 22040445
latency average = 27.149 ms
latency stddev = 11.617 ms
tps = 36710.828624 (including connections establishing)
tps = 36811.054851 (excluding connections establishing)
  7. Prepara il test di sysbench:
    sysbench --test=/usr/local/share/sysbench/oltp.lua \
    --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \
    --pgsql-db=postgres \
    --pgsql-user=postgres \
    --pgsql-password=postgres \
    --pgsql-port=5432 \
    --oltp-tables-count=250\
    --oltp-table-size=450000 \
    prepare
    Output:
    sysbench 0.5:  multi-threaded system evaluation benchmark

Creating table 'sbtest1'...
Inserting 450000 records into 'sbtest1'
Creating secondary indexes on 'sbtest1'...
Creating table 'sbtest2'...
...
Creating table 'sbtest250'...
Inserting 450000 records into 'sbtest250'
Creating secondary indexes on 'sbtest250'...
  8. Esegui il test sysbench:
    sysbench --test=/usr/local/share/sysbench/oltp.lua \
    --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \
    --pgsql-db=postgres \
    --pgsql-user=postgres \
    --pgsql-password=postgres \
    --pgsql-port=5432 \
    --oltp-tables-count=250 \
    --oltp-table-size=450000 \
    --max-requests=0 \
    --forced-shutdown \
    --report-interval=60 \
    --oltp_simple_ranges=0 \
    --oltp-distinct-ranges=0 \
    --oltp-sum-ranges=0 \
    --oltp-order-ranges=0 \
    --oltp-point-selects=0 \
    --rand-type=uniform \
    --max-time=600 \
    --num-threads=1000 \
    run
    Output:
    sysbench 0.5:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1000
Report intermediate results every 60 second(s)
Random number generator seed is 0 and will be ignored

Forcing shutdown in 630 seconds

Initializing worker threads...

Threads started!

[  60s] threads: 1000, tps: 20443.09, reads: 0.00, writes: 81834.16, response time: 68.24ms (95%), errors: 0.62, reconnects:  0.00
[ 120s] threads: 1000, tps: 20580.68, reads: 0.00, writes: 82324.33, response time: 70.75ms (95%), errors: 0.73, reconnects:  0.00
[ 180s] threads: 1000, tps: 20531.85, reads: 0.00, writes: 82127.21, response time: 70.63ms (95%), errors: 0.73, reconnects:  0.00
[ 240s] threads: 1000, tps: 20212.67, reads: 0.00, writes: 80861.67, response time: 71.99ms (95%), errors: 0.43, reconnects:  0.00
[ 300s] threads: 1000, tps: 19383.90, reads: 0.00, writes: 77537.87, response time: 75.64ms (95%), errors: 0.75, reconnects:  0.00
[ 360s] threads: 1000, tps: 19797.20, reads: 0.00, writes: 79190.78, response time: 75.27ms (95%), errors: 0.68, reconnects:  0.00
[ 420s] threads: 1000, tps: 20304.43, reads: 0.00, writes: 81212.87, response time: 73.82ms (95%), errors: 0.70, reconnects:  0.00
[ 480s] threads: 1000, tps: 20933.80, reads: 0.00, writes: 83737.16, response time: 74.71ms (95%), errors: 0.68, reconnects:  0.00
[ 540s] threads: 1000, tps: 20663.05, reads: 0.00, writes: 82626.42, response time: 73.56ms (95%), errors: 0.75, reconnects:  0.00
[ 600s] threads: 1000, tps: 20746.02, reads: 0.00, writes: 83015.81, response time: 73.58ms (95%), errors: 0.78, reconnects:  0.00
OLTP test statistics:
   queries performed:
      read:                            0
      write:                           48868458
      other:                           24434022
      total:                           73302480
   transactions:                        12216804 (20359.59 per sec.)
   read/write requests:                 48868458 (81440.43 per sec.)
   other operations:                    24434022 (40719.87 per sec.)
   ignored errors:                      414    (0.69 per sec.)
   reconnects:                          0      (0.00 per sec.)

General statistics:
   total time:                          600.0516s
   total number of events:              12216804
   total time taken by event execution: 599964.4735s
   response time:
         min:                                  6.27ms
         avg:                                 49.11ms
         max:                                350.24ms
         approx.  95 percentile:              72.90ms

Threads fairness:
   events (avg/stddev):           12216.8040/31.27
   execution time (avg/stddev):   599.9645/0.01

Metriche raccolte

Metriche di Cloudwatch Performance Insights MetricsScarica il whitepaper oggi PostgreSQL Management &Automation con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestisci e ridimensiona PostgreSQLScarica il whitepaper

Corsa #2

Specifiche

  • Questo test utilizza le specifiche AWS per il client e una dimensione dell'istanza inferiore per il database:
    • Macchina client:istanza EC2 ottimizzata per la memoria su richiesta:
      • vCPU:32 (16 core x 2 thread/core)
      • RAM:244 GiB
      • Stoccaggio:EBS ottimizzato
      • Rete:10 Gigabit
    • Cluster DB:db.r4.2xlarge:
      • vCPU:8
      • RAM:61GiB
      • Stoccaggio:EBS ottimizzato
      • Rete:larghezza di banda massima di 1.750 Mbps su una connessione fino a 10 Gbps
  • Il database non includeva una replica.
  • L'archiviazione del database non è stata crittografata.

Esecuzione dei test e dei risultati

I passaggi sono identici a Run #1, quindi sto mostrando solo l'output:

  • pgbench Carico di lavoro in lettura/scrittura:

    ...

745700000 of 1000000000 tuples (74%) done (elapsed 794.93 s, remaining 271.09 s)
745800000 of 1000000000 tuples (74%) done (elapsed 795.00 s, remaining 270.97 s)
745900000 of 1000000000 tuples (74%) done (elapsed 795.09 s, remaining 270.86 s)
746000000 of 1000000000 tuples (74%) done (elapsed 795.17 s, remaining 270.74 s)
746100000 of 1000000000 tuples (74%) done (elapsed 795.24 s, remaining 270.62 s)
746200000 of 1000000000 tuples (74%) done (elapsed 795.33 s, remaining 270.51 s)

...

999800000 of 1000000000 tuples (99%) done (elapsed 1067.11 s, remaining 0.21 s)
999900000 of 1000000000 tuples (99%) done (elapsed 1067.19 s, remaining 0.11 s)
1000000000 of 1000000000 tuples (100%) done (elapsed 1067.28 s, remaining 0.00 s)
vacuum...
set primary keys...
total time: 4386.44 s (insert 1067.33 s, commit 0.46 s, vacuum 2088.25 s, index 1230.41 s)
done.
    starting vacuum...end.

progress: 60.0 s, 3361.3 tps, lat 286.143 ms stddev 80.417
progress: 120.0 s, 3466.8 tps, lat 288.386 ms stddev 76.373
progress: 180.0 s, 3683.1 tps, lat 271.840 ms stddev 75.712
progress: 240.0 s, 3444.3 tps, lat 289.909 ms stddev 69.564
progress: 300.0 s, 3475.8 tps, lat 287.736 ms stddev 73.712
progress: 360.0 s, 3449.5 tps, lat 289.832 ms stddev 71.878
progress: 420.0 s, 3518.1 tps, lat 284.432 ms stddev 74.276
progress: 480.0 s, 3430.7 tps, lat 291.359 ms stddev 73.264
progress: 540.0 s, 3515.7 tps, lat 284.522 ms stddev 73.206
progress: 600.0 s, 3482.9 tps, lat 287.037 ms stddev 71.649
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 10000
query mode: prepared
number of clients: 1000
number of threads: 1000
duration: 600 s
number of transactions actually processed: 2090702
latency average = 286.030 ms
latency stddev = 74.245 ms
tps = 3481.731730 (including connections establishing)
tps = 3494.157830 (excluding connections establishing)

  • sysbench test:

    sysbench 0.5:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1000
Report intermediate results every 60 second(s)
Random number generator seed is 0 and will be ignored

Forcing shutdown in 630 seconds

Initializing worker threads...

Threads started!

[  60s] threads: 1000, tps: 4809.05, reads: 0.00, writes: 19301.02, response time: 288.03ms (95%), errors: 0.05, reconnects:  0.00
[ 120s] threads: 1000, tps: 5264.15, reads: 0.00, writes: 21005.40, response time: 255.23ms (95%), errors: 0.08, reconnects:  0.00
[ 180s] threads: 1000, tps: 5178.27, reads: 0.00, writes: 20713.07, response time: 260.40ms (95%), errors: 0.03, reconnects:  0.00
[ 240s] threads: 1000, tps: 5145.95, reads: 0.00, writes: 20610.08, response time: 255.76ms (95%), errors: 0.05, reconnects:  0.00
[ 300s] threads: 1000, tps: 5127.92, reads: 0.00, writes: 20507.98, response time: 264.24ms (95%), errors: 0.05, reconnects:  0.00
[ 360s] threads: 1000, tps: 5063.83, reads: 0.00, writes: 20278.10, response time: 268.55ms (95%), errors: 0.05, reconnects:  0.00
[ 420s] threads: 1000, tps: 5057.51, reads: 0.00, writes: 20237.28, response time: 269.19ms (95%), errors: 0.10, reconnects:  0.00
[ 480s] threads: 1000, tps: 5036.32, reads: 0.00, writes: 20139.29, response time: 279.62ms (95%), errors: 0.10, reconnects:  0.00
[ 540s] threads: 1000, tps: 5115.25, reads: 0.00, writes: 20459.05, response time: 264.64ms (95%), errors: 0.08, reconnects:  0.00
[ 600s] threads: 1000, tps: 5124.89, reads: 0.00, writes: 20510.07, response time: 265.43ms (95%), errors: 0.10, reconnects:  0.00
OLTP test statistics:
    queries performed:
        read:                            0
        write:                           12225686
        other:                           6112822
        total:                           18338508
    transactions:                        3056390 (5093.75 per sec.)
    read/write requests:                 12225686 (20375.20 per sec.)
    other operations:                    6112822 (10187.57 per sec.)
    ignored errors:                      42     (0.07 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          600.0277s
    total number of events:              3056390
    total time taken by event execution: 600005.2104s
    response time:
         min:                                  9.57ms
         avg:                                196.31ms
         max:                                608.70ms
         approx.  95 percentile:             268.71ms

Threads fairness:
    events (avg/stddev):           3056.3900/67.44
    execution time (avg/stddev):   600.0052/0.01

Metriche raccolte

Metriche di Cloudwatch Informazioni sulle prestazioni - Metriche dei contatori Informazioni sulle prestazioni - Caricamento del database in base alle attese

Pensieri finali

  • Gli utenti possono utilizzare dimensioni di istanza predefinite. Come svantaggio, se il benchmark mostra che l'istanza può beneficiare di memoria aggiuntiva, non è possibile "aggiungere più RAM". L'aggiunta di più memoria si traduce in un aumento della dimensione dell'istanza che comporta un costo maggiore (il costo raddoppia per ogni dimensione dell'istanza).
  • Il motore di archiviazione Amazon Aurora è molto diverso da RDS ed è basato sull'hardware SAN. Le metriche di throughput I/O per istanza mostrano che il test non si è nemmeno avvicinato al massimo per i volumi EBS SSD IOPS forniti di 1.750 MiB/s.
  • Ulteriore ottimizzazione può essere eseguita esaminando gli eventi AWS PostgreSQL inclusi nei grafici di Performance Insights.

Il prossimo della serie

Resta sintonizzato per la parte successiva:Amazon RDS per PostgreSQL 10.6.