Данные в Redis хранятся в виде хешей:
$ redis-cli "HGETALL" "pgbench_history:15" 1) "bid" 2) "2" 3) "aid" 4) "126329" 5) "delta" 6) "-4236" 7) "mtime" 8) "2014-07-11 14:59:38.5907" 9) "hid" 10) "4340"
Также можно проверить состояние репликации:
$ bucardo status PID of Bucardo MCP: 4655 Name State Last good Time Last I/D Last bad Time ==================+========+============+========+===========+===========+======== delta | Good | 14:59:39 | 8m 15s | 0/0 | none | pg_to_redis_sync | Good | 14:59:40 | 8m 14s | 646/2546 | 14:59:39 | 8m 15s
RubyRep
Введение
RubyRep представляет собой движок для организации асинхронной репликации, написанный на языке ruby. Основные принципы: простота использования и не зависит от БД. Поддерживает как master-master, так и master-slave репликацию, может работать с PostgreSQL и MySQL. Отличительными особенностями решения являются:
возможность двухстороннего сравнения и синхронизации баз данных;
простота установки.
К недостаткам можно отнести:
работа только с двумя базами данных для MySQL;
медленная работа синхронизации;
при больших объемах данных «ест» процессор и память;
проект не развивается.
Установка
и настройке, но за это ему приходится расплачиваться скоростью работы самый медленный из всех (синхронизация больших объемов данных между таблицами).
Шардинг
Введение
Шардинг разделение данных на уровне ресурсов. Концепция шардинга заключается в логическом разделении данных по различным ресурсам исходя из требований к нагрузке.
Рассмотрим пример. Пусть у нас есть приложение с регистрацией пользователей, которое позволяет писать друг другу личные сообщения. Допустим оно очень популярно и много людей им пользуются ежедневно. Естественно, что таблица с личными сообщениями будет намного больше всех остальных таблиц в базе (скажем, будет занимать 90% всех ресурсов). Зная это, мы можем подготовить для этой (только одной!) таблицы выделенный сервер помощнее, а остальные оставить на другом (послабее). Теперь мы можем идеально подстроить сервер для работы с одной специфической таблицей, постараться уместить ее в память, возможно, дополнительно партиционировать ее и т.д. Такое распределение называется вертикальным шардингом.
Что делать, если наша таблица с сообщениями стала настолько большой, что даже выделенный сервер под нее одну уже не спасает. Необходимо делать горизонтальный шардинг т.е. разделение одной таблицы по разным ресурсам. Как это выглядит на практике? Все просто. На разных серверах у нас будет таблица с одинаковой структурой, но разными данными. Для нашего случая с сообщениями, мы можем хранить первые 10 миллионов сообщений на одном сервере, вторые 10 - на втором и т.д. Т.е. необходимо иметь критерий шардинга какой-то параметр, который позволит определять, на каком именно сервере лежат те или иные данные.
Обычно, в качестве параметра шардинга выбирают ID пользователя (user_id) это позволяет делить данные по серверам равномерно и просто. Т.о. при получении личных сообщений пользователей алгоритм работы будет такой:
Определить, на каком сервере БД лежат сообщения пользователя исходя из user_id;
Инициализировать соединение с этим сервером;
Выбрать сообщения.
Задачу определения конкретного сервера можно решать двумя путями:
Хранить в одном месте хеш-таблицу с соответствиями «пользователь=сервер». Тогда, при определении сервера, нужно будет выбрать сервер из этой таблицы. В этом случае узкое место это большая таблица соответствия, которую нужно хранить в одном месте. Для таких целей очень хорошо подходят базы данных «ключ=значение»;
Определять имя сервера с помощью числового (буквенного) преобразования. Например, можно вычислять номер сервера, как остаток от деления на определенное число (количество серверов, между которыми Вы делите таблицу). В этом случае узкое место это проблема добавления новых серверов Вам придется делать перераспределение данных между новым количеством серверов.
Для шардинга не существует решения на уровне известных платформ, т.к. это весьма специфическая для отдельно взятого приложения задача.
Естественно, делая горизонтальный шардинг, Вы ограничиваете себя в возможности выборок, которые требуют пересмотра всей таблицы (например, последние посты в блогах людей будет достать невозможно, если таблица постов шардится). Такие задачи придется решать другими подходами. Например, для описанного примера, можно при появлении нового поста, заносить его ID в общий стек, размером в 100 элементом.
Горизонтальный шардинг имеет одно явное преимущество он бесконечно масштабируем. Для создания шардинга PostgreSQL существует несколько решений:
Postgres-XC
PL/Proxy
HadoopDB (Shared-nothing clustering)
Greenplum Database
PL/Proxy
PL/Proxy представляет собой прокси-язык для удаленного вызова процедур и партицирования данных между разными базами. Основная идея его использования заключается в том, что появляется возможность вызывать функции, расположенные в удаленных базах, а также свободно работать с кластером баз данных (например, вызвать функцию на всех узлах кластера, или на случайном узле, или на каком-то одном определенном).