Как грамотнее переносить данные между БД в реалтайме?

Имеется такая схема:
Игровой сервак сливает в БД ( девятый постгресс разумеется ) все логи о действиях игроков. В данный момент это 2500-3000 запросов в секунду. Но ожидаем рост до 25-30 тысяч в секунду в течении года.

Среднее время выполнения одного запроса 2мс. Среднее кол-во записываемых в лог данных 128 байт.

Через сайт логи доступны для чтения. По условиям партнерской программы мы обязаны партнерам предоставлять логи по API. То есть они могут запросить сразу все логи одного игрока за 24 часа. Естественно это генерит нагрузку на БД и игровой сервак начинает лагать ( часть запросов там реализована асинхронно но большая часть - нет ) при этом среднее время запроса может вырасти до 25-50мс

Что хотелось бы - чтобы игровой сервак писал логи на сервер А а они с него силами самого сервера А переносились на сервер Б не замедляя при этом работу БД на А.
Если делать мастер-слейв то сервер А будет наполняться логами и скорость записи будет уменьшаться постепенно и через неделю среднее время запроса увеличится до неприемлемых 15-20мс.

Пробовали сделать триггер на А чтобы по триггеру данные переносились в Б и из А удалялись но или админы что то настроили через анус или еще что но среднее время запроса до 18мс выросло - то есть потеря восьмикратная почти.

Сейчас вот думаю может демона повесить который нотификации от сервера А получать будет и будет удалять данные из А и вставлять их в Б. Может нативное решение на сях быстрее будет работать чем триггер постгресовский.

Может быть кто то что то умнее предложить решение может?

Партнерам обязательно онлайн?? Может пойдут данные с задержкой?
Тогда их легко выгружать батчами раз в N часов

orfelin, поздравляю, Вы перешли на новый уровень.
На этом уровне нужно уметь программировать.
И/или нужно обращаться к профессиональным консультантам.

Если чуть серьезнее, то подумайте над
* созданием промежуточного уровня - пусть игровой сервер не сам пишет в базу, а отдает данные по чему-нибудь типа zeromq. А там уже можно, например, делить этот поток на части
* денормализацией данных и над тем чтобы убрать лишние индексы.
* шардингом (Вы храните данные всех пользователей в одной базе? поделите ее на части!)

Ivan Durak
Партнерам обязательно онлайн?? Может пойдут данные с задержкой? Тогда их легко выгружать батчами раз в N часов

максимум задержки которую они готовы терпеть это 5-10 минут
так что батчить не вариант

ilejn

orfelin, поздравляю, Вы перешли на новый уровень. На этом уровне нужно уметь программировать. И/или нужно обращаться к профессиональным консультантам. Если чуть серьезнее, то подумайте над * созданием промежуточного уровня - пусть игровой сервер не сам пишет в базу, а отдает данные по чему-нибудь типа zeromq. А там уже можно, например, делить этот поток на части * денормализацией данных и над тем чтобы убрать лишние индексы. * шардингом (Вы храните данные всех пользователей в одной базе? поделите ее на части!)

вариант 1 интересен и в принципе реализуем
вариант 2 - я слабо себе представляю. Даже самая мегаоптимальная организация БД будет томозить по мере роста количества данных
типа шардинг уже был - каждые 24 часа создавалась новая таблица с данными а текущая ( куда пищет сервак ) очищалась

Это помогало пока ресурсов сервера хватало. Сейчас у нас уже деловский сервак с 128 гигами на борту ( а начинали с 32 )
больше 192 гигов датацентр не дает
поэтому и важно разделить рабочую зону и хранение а это ваш вариант 1

Да, в силу специфики архиважно чтобы лог игрового действия был сохранен в бд. Потеря лога по какой либо причине является недопустимой

orfelin, я перечислил не то чтобы варианты, а скорее действия, дополняющие друг друга.

Про sharding можно почитать в википедии http://en.wikipedia.org/wiki/Shard_(database_architecture)
То, что Вы описали, обычно называют просто partition

Если у Вас есть в запасе много времени, то можно приобретать знания самостоятельно. Попробуйте погуглить хайлоад_плюс_плюс латинскими буквами и символами плюсиков. У них будет трансляция учебного дня.

Ну а если времени на ходьбу по граблям слишком мало, то лучше все-таки обратиться к консультантам.