Как выбрать базу данных?

Question

[tttttv]

Коллеги, добрый вечер. Есть необходимость писать в базу данных по 10к записей в секунду. Отсюда вопрос - обычный постгрес такое потянет? Просто через относительно небольшое время в базе появится такими темпами несколько миллиардов записей (хотя они и очень простые). Есть ощущение, что постгрес в таком случае будет медленно работать.

Чтение относительно редко из бд происходит, только запись очень частая

Comments

[Василий Банников]

А какие данные и как происходит чтение? По id? Списком по фильтру? Для аналитики?
Какие требования по доступности данных?
Будет ли ок, если данные после отправки не сразу будут доступны для чтения?
Что это вообще за данные?
Это какие-то события привязанные ко времени? Логи?
Сколько вообще байт одна запись занимает?

[AUser0]

Может проще писать такие поточные данные в простой файл?

[tttttv]

Василий Банников, GPS-маяки местоположение отправляют, несколько сот тысяч маяков. Чтение истории местоположений из админки с картой. Байт до 50 занимают наверное.

[Василий Банников]

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

Answer 1

[Василий Банников]

GPS-маяки местоположение отправляют, несколько сот тысяч маяков. Чтение истории местоположений из админки с картой. Байт до 50 занимают наверное.

В таком сценарии TimeScaleDB вполне должен справиться.
Чтобы чуть меньше нагружать инсертами - можно добавить несколько экземпляров базы с репликацией и загружать батчами

Comments

[tttttv]

Спасибо! Судя по описанию как раз то что нужно.

Answer 2

[rPman]

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

Потому что все зависит от того, как читаешь эти данные и как ищешь в них. И возможна ли модификация данных (наиважнейший вопрос, отрицательный ответ на который позволит через партиционирование убрать зависимость скорости от объемов данных)

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

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

Comments

[Алан Гибизов]

Ещё наверно unlogged

Answer 3

[mayton2019]

Есть такая старая поговорка из тайм-менеджмента - "что СРОЧНО - то не важно".

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

А есть вообще такой? Мне сложно себе представить. Если это биг-дата со стримингом - то там надо использовать не постгрес а другие системы. Kafka+Spark например. Но я не буду давать таких советов потому что люди обычно сидят на консервативных системах типа реляционок и хотят делать на них все. Просто им так удобнее.

Давайте немного арифметики. Если мы формируем 10к в секунду то за сутки у нас набегает 10000L * 60 * 60 * 24 = 864 000 000 или восемьсот миллионов строк. Это вот если загрузка будет постоянно такая.

Answer 4

[Станислав Бодро́в]

Есть необходимость писать в базу данных по 10к записей в секунду. .....Чтение относительно редко из бд происходит, только запись очень частая

Не проще писать в файл? Это не шутка. Если только писать и практически не читать. Логи nginx легко могут лететь с такой скоростью.

Answer 5

[Dimonchik]

обычный clickhouse такое потянет
а так задача big data решается ETLами , в которых, конечно, Постгресу есть достойное место, но не всегда в первичном звене

Comments

[Vitsliputsli]

Колоночные СУБД - это про аналитику, а здесь об этом ни слова. А запись в них всегда самое слабое место, которое требует особого внимания, и уж точно, нельзя ее брать просто для быстрой записи.