DDL-Einschränkungen und andere Informationen für Aurora PostgreSQL Limitless Database

Einzelheiten darüber, was nicht unterstützt wird, finden Sie unter Beschränkungen.

Standardwerte werden unterstützt. Weitere Informationen finden Sie unter Standardwerte.

Nicht alle Indizes sind auf Routern sichtbar, wenn Sie \d table_name oder ähnliche Befehle verwenden. Verwenden Sie stattdessen die Ansicht pg_catalog.pg_indexes, um Indizes abzurufen, wie im folgenden Beispiel gezeigt.

SET rds_aurora.limitless_create_table_mode='sharded';
SET rds_aurora.limitless_create_table_shard_key='{"id"}';
CREATE TABLE items (id int PRIMARY KEY, val int);
CREATE INDEX items_my_index on items (id, val);

postgres_limitless=> SELECT * FROM pg_catalog.pg_indexes WHERE tablename='items';

 schemaname | tablename |   indexname    | tablespace |                                indexdef
------------+-----------+----------------+------------+------------------------------------------------------------------------
 public     | items     | items_my_index |            | CREATE INDEX items_my_index ON ONLY public.items USING btree (id, val)
 public     | items     | items_pkey     |            | CREATE UNIQUE INDEX items_pkey ON ONLY public.items USING btree (id)
(2 rows)

Einfache Beschränkungen, die Vergleichsoperatoren mit Literalen beinhalten, werden unterstützt. Komplexere Ausdrücke und Beschränkungen, die Funktionsvalidierungen erfordern, werden nicht unterstützt, wie in den folgenden Beispielen gezeigt.

CREATE TABLE my_table (
    id  INT CHECK (id > 0)                                     -- supported
  , val INT CHECK (val > 0 AND val < 1000)                     -- supported
  , tag TEXT CHECK (length(tag) > 0)                           -- not supported: throws "Expression inside CHECK constraint is not supported"
  , op_date TIMESTAMP WITH TIME ZONE CHECK (op_date <= now())  -- not supported: throws "Expression inside CHECK constraint is not supported"
);

Sie können Beschränkungen explizite Namen geben, wie im folgenden Beispiel gezeigt.

CREATE TABLE my_table (
    id  INT CONSTRAINT positive_id  CHECK (id > 0)
  , val INT CONSTRAINT val_in_range CHECK (val > 0 AND val < 1000)
);

Sie können die Beschränkungssyntax auf Tabellenebene mit der Beschränkung CHECK verwenden, wie im folgenden Beispiel gezeigt.

CREATE TABLE my_table (
    id INT CONSTRAINT positive_id  CHECK (id > 0)
  , min_val INT CONSTRAINT min_val_in_range CHECK (min_val > 0 AND min_val < 1000)
  , max_val INT
  , CONSTRAINT max_val_in_range CHECK (max_val > 0 AND max_val < 1000 AND max_val > min_val)
);

Ausschlussbeschränkungen werden in Aurora PostgreSQL Limitless Database nicht unterstützt.

Weitere Informationen finden Sie unter Fremdschlüssel.

NOT NULL-Beschränkungen werden uneingeschränkt unterstützt.

Der Primärschlüssel impliziert eindeutige Beschränkungen, weshalb die Einschränkungen für eindeutige Beschränkungen auch für den Primärschlüssel gelten. Das bedeutet Folgendes:

Die folgenden Beispiele veranschaulichen die Verwendung von Primärschlüsseln.

-- Create a standard table.
CREATE TABLE public.my_table (
    item_id INT
  , location_code INT
  , val INT
  , comment text
);

-- Change the table to a sharded table using the 'item_id' and 'location_code' columns as shard keys.
CALL rds_aurora.limitless_alter_table_type_sharded('public.my_table', ARRAY['item_id', 'location_code']);

Hier wird versucht, einen Primärschlüssel hinzuzufügen, der keinen Shard-Schlüssel enthält:

-- Add column 'item_id' as the primary key.
-- Invalid because the primary key doesnt include all columns from the shard key:
-- 'location_code' is part of the shard key but not part of the primary key
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id); -- ERROR

-- add column "val" as primary key
-- Invalid because primary key does not include all columns from shard key:
--  item_id and location_code iare part of shard key but not part of the primary key
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id); -- ERROR

Hier wird versucht, einen Primärschlüssel hinzuzufügen, der einen Shard-Schlüssel enthält:

-- Add the 'item_id' and 'location_code' columns as the primary key.
-- Valid because the primary key contains the shard key.
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id, location_code); -- OK

-- Add the 'item_id', 'location_code', and 'val' columns as the primary key.
-- Valid because the primary key contains the shard key.
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id, location_code, val); -- OK

In diesem Beispiel wird eine Standardtabelle in eine Referenztabelle konvertiert:

-- Create a standard table.
CREATE TABLE zipcodes (zipcode INT PRIMARY KEY, details VARCHAR);

-- Convert the table to a reference table.
CALL rds_aurora.limitless_alter_table_type_reference('public.zipcode');

Weitere Informationen zum Erstellen von Sharded-Tabellen und Referenztabellen finden Sie unter Erstellen von Tabellen in Aurora PostgreSQL Limitless Database.

In Sharded-Tabellen muss der eindeutige Schlüssel den Shard-Schlüssel enthalten, das heißt, der Shard-Schlüssel muss eine Teilmenge des eindeutigen Schlüssels sein. Dies wird überprüft, wenn der Tabellentyp in „Sharded“ geändert wird. In Referenztabellen gibt es keine Einschränkung.

CREATE TABLE customer (
    customer_id INT NOT NULL
  , zipcode INT
  , email TEXT UNIQUE
);

UNIQUE-Beschränkungen auf Tabellenebene werden unterstützt, wie im folgenden Beispiel gezeigt.

CREATE TABLE customer (
    customer_id INT NOT NULL
  , zipcode INT
  , email TEXT
  , CONSTRAINT zipcode_and_email UNIQUE (zipcode, email)
);

Das folgende Beispiel zeigt die gemeinsame Verwendung eines Primärschlüssels und eines eindeutigen Schlüssels. Beide Schlüssel müssen den Shard-Schlüssel enthalten.

SET rds_aurora.limitless_create_table_mode='sharded';
SET rds_aurora.limitless_create_table_shard_key='{"p_id"}';
CREATE TABLE t1 (
p_id BIGINT NOT NULL,
c_id BIGINT NOT NULL,
PRIMARY KEY (p_id),
UNIQUE (p_id, c_id)
);

Sie können Erweiterungen wie in PostgreSQL erstellen.

CREATE EXTENSION [ IF NOT EXISTS ] extension_name
    [ WITH ] [ SCHEMA schema_name ]
             [ VERSION version ]
             [ CASCADE ]

Weitere Informationen finden Sie im Abschnitt CREATE EXTENSION der PostgreSQL-Dokumentation.

Die folgenden DDLs werden unterstützt:

ALTER EXTENSION name UPDATE [ TO new_version ]

ALTER EXTENSION name SET SCHEMA new_schema

Weitere Informationen finden Sie im Abschnitt ALTER EXTENSION der PostgreSQL-Dokumentation.

Sie können Erweiterungen wie in PostgreSQL löschen.

DROP EXTENSION [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

Weitere Informationen finden Sie im Abschnitt DROP EXTENSION der PostgreSQL-Dokumentation.

Sie können keine Mitgliedsobjekte zu Erweiterungen hinzufügen oder daraus löschen.

ALTER EXTENSION name ADD member_object

ALTER EXTENSION name DROP member_object

rds_aurora.limitless_pgstattuple(relation_name)

rds_aurora.limitless_pgstattuple(relation_name, subcluster_id)

rds_aurora.limitless_pgstatindex(relation_name)

rds_aurora.limitless_pgstatindex(relation_name, subcluster_id)

rds_aurora.limitless_pgstatginindex(relation_name)

rds_aurora.limitless_pgstatginindex(relation_name, subcluster_id)

rds_aurora.limitless_pgstathashindex(relation_name)

rds_aurora.limitless_pgstathashindex(relation_name, subcluster_id)

rds_aurora.limitless_pg_relpages(relation_name)

rds_aurora.limitless_pg_relpages(relation_name, subcluster_id)

rds_aurora.limitless_pgstattuple_approx(relation_name)

rds_aurora.limitless_pgstattuple_approx(relation_name, subcluster_id)

Mit diesem Befehl können Sie Funktionen wie in Aurora PostgreSQL erstellen. Sie können damit nur nicht ihre Volatilität ändern, während Sie sie ersetzen.

Weitere Informationen finden Sie im Abschnitt CREATE FUNCTION der PostgreSQL-Dokumentation.

Mit diesem Befehl können Sie Funktionen wie in Aurora PostgreSQL ändern, nur nicht ihre Volatilität.

Weitere Informationen finden Sie im Abschnitt ALTER FUNCTION der PostgreSQL-Dokumentation.

Sie können Funktionen wie in Aurora PostgreSQL löschen.

DROP FUNCTION [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

Weitere Informationen finden Sie im Abschnitt DROP FUNCTION der PostgreSQL-Dokumentation.

Wenn Sie eine Funktion oder ein Verfahren verteilen, befasst sie oder es sich nur mit Daten, die durch den Shard-Schlüsselbereich in diesem Shard begrenzt sind. In Fällen, in denen Funktionen oder Verfahren versuchen, auf Daten von einem anderen Shard zuzugreifen, unterscheiden sich die von den verteilten Funktionen oder Verfahren zurückgegeben Ergebnisse von denen der nicht verteilten Funktionen oder Verfahren.

Sie erstellen beispielsweise eine Funktion, die Abfragen enthält, die mehrere Shards betreffen werden, rufen dann aber das Verfahren rds_aurora.limitless_distribute_function auf, um sie zu verteilen. Wenn Sie diese Funktion aufrufen, indem Sie Argumente für einen Shard-Schlüssel angeben, werden die Ergebnisse ihrer Ausführung wahrscheinlich durch die in diesem Shard vorhandenen Werte begrenzt. Die Ergebnisse unterscheiden sich von denen, die ohne Verteilung der Funktion generiert wurden.

Nehmen wir an, wir haben die Funktion func, die Sharded-Tabelle customers und den Shard-Schlüssel customer_id.

postgres_limitless=> CREATE OR REPLACE FUNCTION func(c_id integer, sc integer) RETURNS int
    language SQL
    volatile
    AS $$
    UPDATE customers SET score = sc WHERE customer_id = c_id RETURNING score;
    $$;

Jetzt verteilen wir diese Funktion:

SELECT rds_aurora.limitless_distribute_function('func(integer, integer)', ARRAY['c_id'], 'customers');

Im Folgenden sehen Sie Beispiel-Abfragepläne.

EXPLAIN(costs false, verbose true) SELECT func(27+1,10);

                    QUERY PLAN
 --------------------------------------------------
  Foreign Scan
    Output: (func((27 + 1), 10))
    Remote SQL:  SELECT func((27 + 1), 10) AS func
  Single Shard Optimized
 (4 rows)

EXPLAIN(costs false, verbose true)
 SELECT * FROM customers,func(customer_id, score) WHERE customer_id=10 AND score=27;

                          QUERY PLAN
 ---------------------------------------------------------------------
  Foreign Scan
    Output: customer_id, name, score, func
    Remote SQL:  SELECT customers.customer_id,
      customers.name,
      customers.score,
      func.func
     FROM public.customers,
      LATERAL func(customers.customer_id, customers.score) func(func)
    WHERE ((customers.customer_id = 10) AND (customers.score = 27))
  Single Shard Optimized
 (10 rows)

Das folgende Beispiel zeigt ein Verfahren mit IN- und OUT-Parametern als Argumente.

CREATE OR REPLACE FUNCTION get_data(OUT id INTEGER, IN arg_id INT)
    AS $$
    BEGIN
        SELECT customer_id,
        INTO id
        FROM customer
        WHERE customer_id = arg_id;
    END;
    $$ LANGUAGE plpgsql;

Das folgende Beispiel verteilt das Verfahren nur unter Verwendung von IN-Parametern.

EXPLAIN(costs false, verbose true) SELECT * FROM get_data(1);

             QUERY PLAN
 -----------------------------------
  Foreign Scan
    Output: id
    Remote SQL:  SELECT customer_id
     FROM get_data(1) get_data(id)
  Single Shard Optimized
 (6 rows)

Die Funktion setval wird nicht unterstützt. Weitere Informationen finden Sie im Abschnitt Sequenz-Bearbeitungsfunktionen in der PostgreSQL-Dokumentation.

Die folgenden Optionen werden nicht unterstützt.

CREATE [{ TEMPORARY | TEMP} | UNLOGGED] SEQUENCE
    [[ NO ] CYCLE]

Weitere Informationen finden Sie im Abschnitt CREATE SEQUENCE der PostgreSQL-Dokumentation.

Die folgenden Optionen werden nicht unterstützt.

ALTER SEQUENCE
    [[ NO ] CYCLE]

Weitere Informationen finden Sie im Abschnitt ALTER SEQUENCE der PostgreSQL-Dokumentation.

Der Befehl ALTER TABLE wird für Sequenzen nicht unterstützt.

postgres_limitless=> CREATE SEQUENCE s;
CREATE SEQUENCE

postgres_limitless=> SELECT nextval('s');

 nextval
---------
       1
(1 row)

postgres_limitless=> SELECT * FROM pg_sequence WHERE seqrelid='s'::regclass;

 seqrelid | seqtypid | seqstart | seqincrement | seqmax | seqmin | seqcache | seqcycle 
----------+----------+----------+--------------+--------+--------+----------+----------
    16960 |       20 |        1 |            1 |  10000 |      1 |        1 | f
(1 row)

% connect to another router
postgres_limitless=> SELECT nextval('s');

 nextval 
---------
   10001
(1 row)

postgres_limitless=> SELECT * FROM pg_sequence WHERE seqrelid='s'::regclass;

 seqrelid | seqtypid | seqstart | seqincrement | seqmax | seqmin | seqcache | seqcycle 
----------+----------+----------+--------------+--------+--------+----------+----------
    16959 |       20 |    10001 |            1 |  20000 |  10001 |        1 | f
(1 row)

postgres_limitless=> DROP SEQUENCE s;
DROP SEQUENCE

postgres_limitless=> CREATE SEQUENCE s;
CREATE SEQUENCE

postgres_limitless=> ALTER SEQUENCE s RESTART 500;
ALTER SEQUENCE

postgres_limitless=> SELECT nextval('s');

 nextval
---------
     500
(1 row)

postgres_limitless=> SELECT currval('s');

 currval
---------
     500
(1 row)

postgres=# CREATE TABLE t(a bigint primary key, b bigint);
CREATE TABLE

postgres=# CREATE SEQUENCE s minvalue 0 START 0;
CREATE SEQUENCE

postgres=# INSERT INTO t VALUES (nextval('s'), currval('s'));                                                                                             
INSERT 0 1

postgres=# INSERT INTO t VALUES (nextval('s'), currval('s'));
INSERT 0 1

postgres=# SELECT * FROM t;

 a | b
---+---
 0 | 0
 1 | 1
(2 rows)

postgres=# ALTER SEQUENCE s RESTART 10000;
ALTER SEQUENCE

postgres=# INSERT INTO t VALUES (nextval('s'), currval('s'));                                                                                             
INSERT 0 1

postgres=# SELECT * FROM t;

   a   |   b
-------+-------
     0 |     0
     1 |     1
 10000 | 10000
(3 rows)

Diese Ansicht zeigt den Status und die Konfiguration einer verteilten Sequenz. Die Spalten minvalue, maxvalue, start, inc und cache haben dieselbe Bedeutung wie in der Ansicht pg_sequences und zeigen die Optionen, mit denen die Sequenz erstellt wurde. Die Spalte lastval zeigt den letzten zugewiesenen oder reservierten Wert in einem verteilten Sequenzobjekt. Dies bedeutet nicht, dass der Wert bereits verwendet wurde, da Router Sequenzblöcke lokal speichern.

postgres_limitless=> SELECT * FROM rds_aurora.limitless_distributed_sequence WHERE sequence_name='test_serial_b_seq';

 schema_name |   sequence_name   | lastval | minvalue |  maxvalue  | start | inc | cache
-------------+-------------------+---------+----------+------------+-------+-----+-------
 public      | test_serial_b_seq | 1250000 |        1 | 2147483647 |     1 |   1 |     1
(1 row)

Diese Ansicht zeigt verteilte Sequenzmetadaten und aggregiert Sequenzmetadaten von Cluster-Knoten. Sie verwendet die folgenden Spalten:

postgres_limitless=> SELECT * FROM rds_aurora.limitless_sequence_metadata WHERE sequence_name='test_serial_b_seq' order by subcluster_id;

 subcluster_id |   sequence_name   | schema_name | active_minvalue | active_maxvalue | reserved_minvalue | reserved_maxvalue | chunk_size | chunk_state | local_last_value 
---------------+-------------------+-------------+-----------------+-----------------+-------------------+-------------------+------------+-------------+------------------
 1             | test_serial_b_seq | public      |          500001 |          750000 |           1000001 |           1250000 |     250000 |           1 |           550010
 2             | test_serial_b_seq | public      |          250001 |          500000 |            750001 |           1000000 |     250000 |           1 |                 
(2 rows)

Wenn für die Blockgröße ein zu geringer Wert festgelegt wurde und die Transaktionsrate hoch ist, haben die Hintergrund-Worker möglicherweise nicht genug Zeit, um neue Blöcke anzufordern, bevor die aktiven Blöcke verbraucht sind. Dies kann zu Konflikten und Warteereignissen wie LIMITLESS:AuroraLimitlessSequenceReplace, LWLock:LockManager, Lockrelation und LWlock:bufferscontent führen.

Erhöhen Sie den Wert des Parameters rds_aurora.limitless_sequence_chunk_size.

In PostgreSQL erfolgt das Sequenz-Caching auf Sitzungsebene. Jede Sitzung weist während eines Zugriffs auf das Sequenzobjekt aufeinanderfolgende Sequenzwerte zu und erhöht den last_value des Sequenzobjekts entsprechend. Sobald nextval innerhalb dieser Sitzung erneut verwendet wird, werden dann einfach die vorab zugewiesenen Werte zurückgegeben, ohne dass auf das Sequenzobjekt zugegriffen wird.

Alle Nummern, die innerhalb einer Sitzung zugewiesen, aber nicht verwendet wurden, gehen verloren, wenn die Sitzung endet, was zu „Lücken“ in der Sequenz führt. Dies kann zu einem raschen Verbrauch des sequence_chunk und somit zu Konflikten und Warteereignissen wie LIMITLESS:AuroraLimitlessSequenceReplace, LWLock:LockManager, Lockrelation und LWlock:bufferscontent führen.

Verringern Sie den festgelegten Wert für den Sequenz-Cache.