Огромные таблицы с одновременным чтением и записью

Question

У меня есть пара миллионов строк в таблице postgresql.У меня есть до 20 процессов записи в эту таблицу (несколько сотен вставок / обновлений в секунду), и у меня есть несколько процессов, читающих из нее одновременно (время от времени большой выбор).Это приводит ко многим сбоям (поток закрыт, ошибка ввода / вывода) с обеих сторон, чтение и запись.

Теперь я думаю о разбиении этой таблицы на несколько таблиц.Я бы разделил на «тип» объекта, который в основном представляет собой поле, имеющее только 20 возможных значений, которые распределены одинаково.

Вопрос в том, должен ли я использовать несколько таблиц, несколько схем или несколько баз данных, чтобы гарантировать неблокирующий доступ к данным.Или, может быть, я должен использовать совершенно другую настройку.Может быть, другая база данных?Может быть, HTable?

Целостность данных не так важна.Это должно быть там, в конце концов, но мне действительно не нужен уровень изоляции или транзакции.Мне просто нужна быстрая система, которая может писать и читать из нескольких процессов без влияния на производительность и которая позволяет выполнять запросы на основе значений полей.

Сейчас я использую JDBC с уровнем изоляции TRANSACTION_READ_UNCOMMITTED и подключением к процессу.

ОБНОВЛЕНИЕ:

Схема выглядит следующим образом:

CREATE TABLE rev
(
  id integer NOT NULL,
  source text,
  date timestamp with time zone,
  title text,
  summary text,
  md5sum text,
  author text,
  content text,
  CONSTRAINT rev_id_pk PRIMARY KEY (id),
  CONSTRAINT md5sum_un UNIQUE (md5sum)
)

CREATE TABLE resp
(
  id integer NOT NULL,
  source text,
  date timestamp with time zone,
  title text,
  summary text,
  md5sum text,
  author text,
  content text,
  CONSTRAINT resp_id_pk PRIMARY KEY (id),
  CONSTRAINT md5sum_un UNIQUE (md5sum)
)

И у меня есть несколько индексов для некоторых полей.

Пример запроса выглядитнапример:

SELECT * FROM rev LEFT JOIN resp ON rev.id = resp.parent_id WHERE rev.date > ? LIMIT 1000 OFFSET ?

Таблица resp намного меньше, но она также получает обновления и запрашивается в объединениях.

Answer 1

Это приводит ко многим сбоям с обеих сторон при чтении и письме.

Что за сбои? Чтение и запись на одной и той же таблице вообще не должно быть проблемой в PostgreSQL, MVCC работает нормально.

Трудно сказать вам, как исправить ваши проблемы без какой-либо информации о системе и о том, что делают процессы. Не могли бы вы рассказать нам больше об этом? И показать схему базы данных?

Сейчас я использую JDBC с уровнем изоляции TRANSACTION_READ_UNCOMMITTED

READ UNCOMMITTED не существует в PostgreSQL, он рассматривается как Read Committed :

В PostgreSQL вы можете запросить любую из четырех стандартных транзакций уровни изоляции. Но внутренне есть только два уровни изоляции, соответствующие уровням Read Committed и Сериализуемый. Когда вы выбираете уровень Read Uncommitted, вы действительно получите Read Committed, и когда вы выберете Repeatable Read, вы действительно получите Serializable, поэтому фактический уровень изоляции может быть более строгим, чем что вы выбираете.

Answer 2

Я не уверен, насколько незначительна задержка для получения читаемых данных, но вы можете посмотреть Slony Replication . По сути, у вас есть основная база данных с ведомой базой данных. Все ваши вставки / записи будут помещены в основную базу данных, а затем Slony скопирует эти новые записи в подчиненную базу данных (это занимает немного времени, но ничего монументального. Возможно, несколько минут). Затем вы можете читать свои приложения исключительно из ведомой базы данных.

Если вам кажется, что Слони вам не подходит, вы можете посмотреть некоторые альтернативы с несколькими мастерами здесь . Это позволит вам иметь возможность записи на несколько машин, а все их содержимое будет скопировано на машину для чтения.