Разделение таблицы

Сколько у вас вобще ожидается клиентов? Если вобще ничего не известно, делайте как проще (одну таблицу), пусть потом (через 10 лет) другие переписывают.

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

Одна таблица скорее всего будет заметно медленнее для выборки только активных/неактивных еще и из-за разреженности данных на диске, если с этим специально не бороться(CLUSTER).

С другой стороны лично я бы выбрал одну таблицу, потому что рано или поздно наверняка появятся места где нужна будет выборка из всех клиентов. Вряд ли вы упрётесь в скорость выборки из базы, используя шардирование

Сотни миллионов уже страшновато. Наверное, имеет смыл потестировать.

Если у вас неактивный клиент не может стать активным, то в случае двух таблиц, та, которая большая, получается ″insert-only″, по ней VACUUM не нужен. С другой стороны, если у вас 100 млн. возникло за пять лет, это в среднем 55 тыс. в сутки переходов пользователя из активного в неактивный (перестроений индекса).

А чего-го бы partitioning не юзать?

для приложения будет одна таблица, по факту две.

https://wiki.postgresql.org/wiki/Table_partitioning

cluster,reindex,vacuum будем применять. Для выборки эти две таблицы сейчас могут выглядеть как одна через наследование.

для приложения будет одна таблица, по факту две.

Сейчас я уже так и сделал через наследование. Вообщем я подумал что редкий перенос данных из таблицы в таблицу и легкая деградация индекса предпочтительней линейного замедления обработки.

Если у вас неактивный клиент не может стать активным

Может. Снова оплатит подписку и станет, но это редкая операция. Клиент зарегистрировался - я его добавляю в таблицу не активных. Может он там так и останется. Если оплатит подписку на три месяца - я его перенешу в таблицу активных. Прошло три месяца - процесс меняющий данные понимает это и переносит клиента в таблицу не активных. Переносы эти и наследования таблиц вроде и лишнее нагромаждение, зато время обработки активных пользователей не будет линейно расти из за замусоривания не активными.

Попробуйте так: в одной таблице только активные пользователи, в другой - и активные и неактивные вместе.

очень хорошая мысль! спасибо!

А как воркеры будут выгребать ровно по тысяче активных клиентов, ведь их id будут сильно разрежены и простыми диапазонами id этого не добиться.

сначала берем начальный id в пакете равным нулю и примерно так получаем конечный id в пакете:

SELECT
        id
FROM
        (
            SELECT
                   id
            FROM
                   client
            WHERE
                   id >= ТУТ_НАЧАЛЬНЫЙ_ID
            ORDER BY id ASC
            LIMIT ТУТ_РАЗМЕР_ПАКЕТА
        ) AS client
ORDER BY id DESC
LIMIT 1;

потом берем начальный id равным конечный id + 1 и так пока ничего не прочитается

Тысяча последовательных запросов от потока-планировщика только лишь для того, чтоб раскидать задачи по воркерам. Подозрительное место. Я бы держал его в уме на предмет возможных проблем.

Если с ним будут проблемы, можно привязаться к размеру пула воркеров, и раскидывать клиентов по воркерам в момент добавления/удаления активного клиента.

то-же хорошая мысль, спасибо!

А уже потом каждый воркер будет дергать по тысяче клиентов из числа назначенных ему.

При такой схеме добавление воркеров в пул вообще не требует работы, удаление воркеров из пула потребует однократного перераспределения. Но это все равно не так трудоемко, как перераспределение перед каждым циклом обработки клиентов.

угу, потому что операция сделать клиента активным реже чем операция расчета данных для активных клиентов

Мэн, не из-за этого. Из-за того, что размер пула воркеров станет со временем более-менее постоянной величиной. Это самый большой плюс такой схемы, и самый же большой минус.

Когда клиент добавляется в активные, то мы просто выбираем самый незагруженный воркер, и назначаем клиента ему. Аналогично при переходе клиента в неактивные. Это почти бесплатно.

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

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

Можно держать таблицу: (номер_воркера, текущая_загруженность) и обновлять её при добавлении/удалении активного клиента. А каждого активного клиента нужно привязать к номеру его воркера.

А еще вопрос - postgresql умеет insert с merge, по аналогии с mssql, например?

В смысле insert с join, я хотел сказать.

работа будет линейно замедляться

Если индексы построишь, скорее всего логарифмически. При сотнях миллионов клиентов можно себе позволить добавить десяток серверов в ферму, «вернув» потерянное на «лишних» записях.

Не забывайте, это сотня миллионов клиентов не продливших подписку😊 клиенты не продляют подписку, не платят, денег мало, модернизировать оборудование не на что! 😊