Как организовать хранение списка данных в БД?

Question

[strangeletc]

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

База данных Postgres.

Структура 1 записи:
ID - идентификатор пользователя
number - номер записи
status - статус активности
IP - IP адрес
client - информация о клиенте: ОС, браузер и тд
country - местонахождение пользователя
timestamp - метка времени

1 вариант - хранить все одной таблице. Беспокоит то, что все данные перемешаны в куче. А если я хочу хранить историю вплоть от начала регистрации, то наберется огромное кол-во записей. А как быть с удалением записи из списка? Просто вешать пометку "удален" и оставлять в БД?
2 вариант - у каждого пользователя своя таблица и в ней список его активностей. Выглядит лучше, но, как я понял, создавать таблицы в процессе работы сервиса не есть хорошо.

Answer 1

[lega]

Главный вопрос - что вы хотите делать с этими данными? какие запросы? какие объемы?

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

Comments

[strangeletc]

Из примера с сессиями - записывать историю и выдавать последний активный. Скорость отдачи не критична, т.к. есть кэш.
А в общем интересует, как хранить список типовых данных (сессии/фото/видео тд) который относится к конкретному пользователю. Объемы , ну, например, 200.000 пользователей и у каждого может быть как одна так и 100.000 записей и более.

Как , например, вк или facebook хранят такие данные, кто-нибудь знает? Не в одну таблицу же пишут.

[lega]

strangeletc,

выдавать последний активный

Для этого история не нужна.

сессии/фото/видео тд

при больших объемах используется инстумент под задачу, максимально эффективный. Например фото, видео разливают по шардингу. Сессии, т.к. их триллионы, пакуют чанками в разрезе индексов, либо сразу формируют готовые отчеты без хранения истории.
Для мелкого проекта можно все а одной бд хранить.

Не в одну таблицу же пишут.

Таблицы вообще устарели* сами по себе. Сейчас главное эффективно "положить" данные в бд, и оптимально достать их оттуда.

[strangeletc]

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

Можно по подробнее , как это называется, чтобы нагуглить?

Таблицы вообще устарели* сами по себе. Сейчас главное эффективно "положить" данные в бд, и оптимально достать их оттуда.

NoSQL , что-то вроде Apache Cassandra/Google BigTable? Никак не могу понять в каких случаях подходят РСУБД , а в каких нет.

[strangeletc]

Каким способом хранят данные ассоциируемые с определённым ID?
20 - запись 1
------запись 2
------запись 3

75 - запись 1
------запись 2

[lega]

ЧТо-то типа партицирования, тут немного расписал:
https://toster.ru/answer?answer_id=890968#comments...

каких случаях подходят РСУБД

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

Каким способом хранят данные ассоциируемые с определённым ID?

Все зависит от деталей, например список комментариев к посту, можно хранить в самом посте.