5

Muszę skalować naszą aplikację DB ze względu na ilość danych. Jest na PostgreSQL 9.3. Tak więc znalazłem PostgreSQL-XL i wygląda niesamowicie, ale ciężko jest mi próbować oprzeć się ograniczeniom dotyczącym tabel rozproszonych. Przesyłanie ich przez replikację (gdzie cała tabela jest replikowane w każdym datanode) jest całkiem OK, ale powiedzmy, że mam dwa duże powiązanych tabel, które muszą być „sharded” wzdłuż datanodes:Migracja z PostgreSQL do PostgreSQL: projekt tabel rozproszonych

CREATE TABLE foos 
(
    id bigserial NOT NULL, 
    project_id integer NOT NULL, 
    template_id integer NOT NULL, 
    batch_id integer, 
    dataset_id integer NOT NULL, 
    name text NOT NULL, 
    CONSTRAINT pk_foos PRIMARY KEY (id), 
    CONSTRAINT fk_foos_batch_id FOREIGN KEY (batch_id) 
     REFERENCES batches (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE CASCADE, 
    CONSTRAINT fk_foos_dataset_id FOREIGN KEY (dataset_id) 
     REFERENCES datasets (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE CASCADE, 
    CONSTRAINT fk_foos_project_id FOREIGN KEY (project_id) 
     REFERENCES projects (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE CASCADE, 
    CONSTRAINT fk_foos_template_id FOREIGN KEY (template_id) 
     REFERENCES templates (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE CASCADE, 
    CONSTRAINT uc_foos UNIQUE (project_id, name) 
); 

CREATE TABLE foo_childs 
(
    id bigserial NOT NULL, 
    foo_id bigint NOT NULL, 
    template_id integer NOT NULL, 
    batch_id integer, 
    ffdata hstore, 
    CONSTRAINT pk_ff_foos PRIMARY KEY (id), 
    CONSTRAINT fk_fffoos_batch_id FOREIGN KEY (batch_id) 
     REFERENCES batches (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE CASCADE, 
    CONSTRAINT fk_fffoos_foo_id FOREIGN KEY (foo_id) 
     REFERENCES foos (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE CASCADE, 
    CONSTRAINT fk_fffoos_template_id FOREIGN KEY (template_id) 
     REFERENCES templates (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE CASCADE 
); 

teraz dokumentacja PostgreSQL-XL stwierdza:

  • „(...) w rozproszonych tabel, UNIQUE musi zawierać kolumnę dystrybucji tabeli”
  • „(...) kolumna dystrybucyjnego musi być włączone w kluczu podstawowym "
  • "(...) kolumna z REFERENCES (FK) powinna być kolumną dystrybucyjną. (...) PRIMARY KEY musi być kolumna dystrybucji, jak również.”

Ich przykładami są nad uproszczeniem i scarse, więc może ktoś proszę mi DDL dwóch powyższych tabelach dla postgres-XL za pomocą rozsmarować HASH()?

a może zaproponować inne sposoby, aby skalować?

Odpowiedz

0
CREATE TABLE foos 
(...) DISTRIBUTE BY HASH(id); 

CREATE TABLE foos_child 
(...) DISTRIBUTE BY HASH(foo_id); 

teraz każdy przyłączyć na foos.id = foos_child.foo_id można wcisnąć w dół i zrobić lokalnie.

+0

Dziękuję za szybką odpowiedź, ale wcześniej próbowałem, to była pierwsza rzecz, którą zrobiłem, bez powodzenia. Otrzymuję ten błąd podczas próby utworzenia pierwszej tabeli: 'BŁĄD: Unikalny indeks tabeli podzielonej na partycje musi zawierać kolumnę z haszowaniem. Myślę, że jest to spowodowane unikalnym ograniczeniem, więc powiedzmy, że mogę się go pozbyć, wtedy otrzymam to inny błąd: 'ERROR: nie ma unikalnego ograniczenia pasującego do podanych kluczy dla tabeli referencyjnej" partie "', a ten jest spowodowany kolumną referencyjną batch_id, która jest kluczem obcym i powinna być kolumną dystrybucyjną w tabeli rozproszonej, prawda? – Joe