Как эффективно поддерживать количество тегов в Postgres?

Question

Я разрабатываю систему тегов, в которой у каждого пользователя есть список связанных с ним тегов, и я храню их в столбце text[]. Вот пример:

user_id: int4    tags: text[]
-------------    ------------
1                [ 'apple', 'banana', 'carrot', 'jelly' ]
2                [ 'jelly', 'zebra' ]

Мой сервер имеет маршрут с именем update-tags, который заменяет теги пользователя новым списком.

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

tag: text      count: int4
---------      -----------
'apple'        1
'banana'       1
'carrot'       1
'jelly'        2
'zebra'        1

Предполагая, что было 10 миллионов пользователей, и каждый пользователь имел около 100 тегов, связанных с ними, и было всего 10000 тегов (приблизительные числа), делая сканирование полной таблицы всех пользователей, и дедупликация всех их тегов непозволительна.

Теги для пользователей меняются очень редко, но их запрашивают очень часто. Я хотел бы оптимизировать скорость чтения, а не скорость записи.

Кроме того, счетчик тегов не обязательно должен быть точным на 100%, но в конечном итоге должен соответствовать.

Использование триггеров кажется, на правильном пути. Сначала у меня возникла мысль, что всякий раз, когда изменяется столбец tags пользователя, иметь триггер для увеличения / уменьшения счетчика, но что, если многие замены были одинаковыми? Разве это не исчезнет со временем? Есть ли лучший способ?

Answer 1

Кроме того, счетчик тегов не обязательно должен быть точным на 100%, но, в конечном счете, вместо этого должен быть согласован.

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

Я также думаю, что триггер вставки, обновления и удаления, который обновляет таблицу с полями (tag pk, count), правильный путь. Недостатком является то, что если два сеанса пытаются изменить количество одного и того же тега одновременно, один из них должен блокироваться, пока другой не будет зафиксирован. Но так как вы говорите, что такие изменения должны быть очень редкими, я не думаю, что это будет слишком большой проблемой. Вы также можете получить взаимоблокировки, если не обновите строки таблицы тегов в согласованном порядке.

но что, если многие замены были одинаковыми? Разве это не сместится со временем?

Я не вижу, откуда взялся бы какой-либо дрейф, если его правильно реализовать.