Каков современный способ разделения PostgreSQL на машины, когда данные «естественно разбиваются»


22

После нескольких лет пребывания в пространстве «NoSQL» у меня появилась проблема, которая по своей природе является «реляционной». Сегодня я вижу хранилища данных совершенно другими глазами, чем раньше. Такие вещи, как Riak, испортили меня таким образом, что я больше не могу терпеть отдельные точки отказа, «отказ в обслуживании» и т. Д. Конечно, (или я надеюсь) я не «полностью потерял рассудок». Это личный проект, который не совсем (или еще) предъявляет чрезвычайно высокие требования.

Большинство решений шардинга не дают мне того, что я хочу (по крайней мере, мельком), вероятно, потому, что моя проблема довольно «проста» для решения. По крайней мере, на концептуальном уровне (игнорируя ограничения, которые сами RDBM вносят в таблицу).

  1. У меня есть небольшое количество «общих» данных, которые можно свободно копировать. У него нет требований жесткой согласованности. Это может быть сохранено в подобной динамо базе данных и будет масштабироваться бесконечно. Но я все еще хотел бы использовать одну базу данных, если это возможно.

  2. У меня много данных для каждого пользователя. То есть - множество пользователей, каждый из которых имеет данные абсолютно разумного размера, действительно подходит для хранения на одном узле PostgreSQL. Мы говорим о десятках тысяч записей максимум.

  3. Мне никогда не нужно запрашивать межпользовательские и мне не нужно межпользовательское атомарность.

Это звучит очень легко достичь. По крайней мере, когда я смотрю на это своими «глазами NoSQL».

Вот мои наивные идеи для начинающих:

  1. В крайнем случае, я мог бы просто сериализовать всего пользователя как единый ключ / значение в Riak. Конечно, постоянная де-сериализация нескольких мегабайт данных будет медленной, и поэтому я рассматриваю возможность использования PostgreSQL. Многие Riak K / V не нужны, так как мне нужны атомарность / транзакции в данных каждого пользователя.

  2. Я мог бы использовать базу данных SQLite для каждого пользователя и использовать что-то вроде GlusterFS для избыточности / доступности. Это, вероятно, решение, которое я выберу, если не смогу найти что-то такое же хорошее, используя PostgreSQL. Плюсы: действительно хорошо масштабировать; Минусы: я бы предпочел иметь типы PostgreSQL и строгость по сравнению с SQLite

Итак, что я бы в идеале запросил у решения шардинга PostgreSQL:

  1. Автоматически хранить несколько копий данных каждого пользователя (на разных машинах). Уметь динамически переключать мастер-узел для каждого пользователя / шарда (если предыдущий мастер вышел из строя).
  2. Уметь динамически увеличивать / уменьшать масштаб, добавляя / удаляя узлы сервера. Главным образом, как это умеет Риак.
  3. Не требуйте, чтобы мое приложение знало, с какими узлами разговаривать и когда.

Привет локсы, как ты в конце концов решил эту проблему?
Дикла

Разделение на уровне приложений с несколькими хранилищами данных. На самом деле совсем беспорядок :(. Действительно печально, что чего-то подобного не существует ...
loxs

Ответы:



4

Я думаю, лучший вариант - это pgpool-II . Вы можете иметь до 128 узлов и

  1. Можно настроить сложные правила разбиения и распределения данных.
  2. Поддержка "Online Provisioning". Не масштабирует записи, но читает масштабируемые
  3. Не уверен, если это возможно из коробки. Может быть, вам нужно использовать LVS

Другой вариант может быть Stado

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.