5

Мне нужно масштабировать нашу прикладную БД из-за количества данных. Это на PostgreSQL 9.3. Итак, я нашел PostgreSQL-XL, и это выглядит потрясающе, но мне сложно сдерживать ограничения для распределенных таблиц. Для того, чтобы распределить их по репликации (где вся таблица тиражируется в каждом DataNode) вполне нормально, но, скажем, у меня есть два больших связанных таблиц, которые должны быть «sharded» по DataNodes:Миграция из Postgresql в Postgres-XL: разработка распределенных таблиц

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 
); 

сейчас Postgres-XL документации говорится, что:

  • "(...) в распределенных таблиц, UNIQUE ограничения должны включать в себя столбец распределения таблицы"
  • «(...) столбец распределения должны быть включены в ПЕРВИЧНОМ КЛЮЧЕ "
  • "(...) столбец с ССЫЛКАМИ (FK) должен быть столбцом распределения. (...) PRIMARY KEY должен быть столбец распределения, а также.»

Их примеры более упрощенным и скудны, так что может кто-то пожалуйста, DDL мне два выше таблицы для Postgres-XL с помощью DISTRIBUTE BY HASH()?

Или, может предложить другие способы масштабирования?

ответ

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

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

Теперь любой присоединиться на foos.id = foos_child.foo_id можно сдвинуть вниз и сделать на местном уровне.

+0

Спасибо за быстрый ответ, но я уже пробовал это раньше, это было первое, что я сделал на самом деле, без везения. Я получаю эту ошибку, пытаясь создать первую таблицу: «ОШИБКА: уникальный индекс секционированной таблицы должен содержать столбец хеш-распределения». Я предполагаю, что это связано с уникальным ограничением, поэтому, допустим, я мог бы избавиться от него, тогда я получаю это другая ошибка: «ОШИБКА: нет уникального ограничения, связанного с заданными ключами для табличных« партий », и это связано с ссылочным столбцом batch_id, который является внешним ключом и должен быть столбцом распределения в распределенной таблице, правильно? – Joe

Смежные вопросы