Где и как хранить таблицу на 1 миллиард записей?

Question

[Xaip]

На данный момент есть таблица на 500 миллионов записей в postgresql. Она увеличивается примерно на 100к записей в день. Таблица содержит 3 колонки id, factor_id, parcel_id, первичный ключ, и две ссылки на другие таблицы соответственно. Данную таблицу не надо анализировать или агрегировать. Нужно только иметь возможность быстро вставить и прочитать запись. Собираюсь партицианировать таблицу по ключу factor_id, но таких таблиц может быть более 10к, боюсь будет просто каша, особенно когда будут удаляться связанные записи factor_id и таблица будет всегда отсаваться пустой. Посоветуйте ваш вариант. Заранее, спасибо.

Answer 1

[Melkij]

Определитесь с тем как вы будете удалять эти данные.

3 колонки id, factor_id, parcel_id

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

Очень большое сомнение что вам здесь нужен id вместо составного pk.

увеличивается примерно на 100к записей в день

Т.е. сейчас у вас данные за 15 лет работы и вас беспокоит что будет ещё через 15 лет? Ну просто пересчитав указанные объёмы вставки.

В полновесном MVCC транзакционнике PostgreSQL очень маленькие строки держать несколько дорого именно по месту, заголовок строки большой.

3 колонки id, factor_id, parcel_id

24 да 3*8 байт если эти поля считать bigint'ами, да на лярд записей... порядка 25гб плюс-минус. Фигня вопрос вообще-то. У вас проблема-то есть? Или просто руки чешутся?

Comments

[Дмитрий]

Очень большое сомнение что вам здесь нужен id вместо составного pk.

А можно, пожалуйста, чуть подробнее об этом?

[Melkij]

Дмитрий, ммм, а куда подробнее? Этот id здесь действительно нужен? Ответ "ну ведь это primary key" не принимается. primary key вовсе не обязан быть суррогатным автоинкрементом

[Дмитрий]

Melkij, а почему он суррогатный, если ID может быть не только абстрактным автоинкрементом, но ещё и вполне себе рабочей сущностью, выполняющей функцию идентификатора при работе с БД?

[Melkij]

Дмитрий, потому что на вид очень похоже на распространённую ошибку, когда зачем-то делают бессмысленный суррогатный ключ вместо родного составного ключа предметной области. У меня очень большое подозрение что здесь нужен первичный ключ (factor_id, parcel_id) и вовсе не нужное ни для чего поле id.

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

Answer 2

[index0h]

не юзайте внешние ключи, не удаляйте данные (только маркируйте как удаленные)

Comments

[Xaip]

Внешние ключи тормозят insert? Какой профит?

[index0h]

Xaip, конечно, у вас индексы перестраиваются для текущей таблицы, еще и проверяются для остальной. А без внешних ключей только для текущей. Удаление же - в принципе очень длительная операция.

[Melkij]

не удаляйте данные (только маркируйте как удаленные)

Давайте без вредных советов, ладно?
Поинтересуйтесь на досуге как происходит update в MVCC.

Насчёт fk tradeoff так же весьма спорный.

Answer 3

[thyratr0n]

• Количество партицированных таблиц в 10к - это мелочи, так что смело разделяйте.
  
• Избавьте от id - он тут не нужен.
  

Если есть возможность использовать другие СУБД, то тот же Redis, как было сказано, отлично решит вашу проблему.

Answer 4

[Кирилл Горелов]

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