@tttttv

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

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

Чтение относительно редко из бд происходит, только запись очень частая
  • Вопрос задан
  • 272 просмотра
Решения вопроса 1
vabka
@vabka
Токсичный шарпист

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

В таком сценарии TimeScaleDB вполне должен справиться.
Чтобы чуть меньше нагружать инсертами - можно добавить несколько экземпляров базы с репликацией и загружать батчами
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
@rPman
Ни один адекватный разработчик не будет не разобравшись с задачей писать 10k событий как отдельные события, в подавляющем большинстве случаев данные собираются в пакеты и только тогда пишутся, причем зачастую можно так и хранить.

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

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

Отделяй модуль/место сбора оперативных данных от их анализа, например делай две базы, отличающиеся как по месту размещения так и по типу (например оперативные данные можно просто собирать в ram, с космическими скоростями, без sql отдельным приложением-демоном), а аналитику собирать паралельно и периодически, под задачу.
Ответ написан
@bacon
Чтение относительно редко из бд происходит, только запись очень частая
зачем тогда это? Запись ради записи? Короче, больше похоже что тут надо сразу как-то обрабатывать поток, а в базу уже класть агрегированные данные. Ну и у посгреса есть нашлепка TimescaleDB.

Собирай стенд, да тестируй различные способы, на основании тестов уже и выбирай.
PS а так смешно конечно, собираемся писать типа "highload", но бежим на тостера за советом. Правильно - сначала найти человека, которые имеет опыт в подробном, и возложить эти проблемы на него.
Ответ написан
Комментировать
@mayton2019
Bigdata Engineer
Есть такая старая поговорка из тайм-менеджмента - "что СРОЧНО - то не важно".

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

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

Давайте немного арифметики. Если мы формируем 10к в секунду то за сутки у нас набегает 10000L * 60 * 60 * 24 = 864 000 000 или восемьсот миллионов строк. Это вот если загрузка будет постоянно такая.
Ответ написан
Комментировать
Есть необходимость писать в базу данных по 10к записей в секунду. .....Чтение относительно редко из бд происходит, только запись очень частая
Не проще писать в файл? Это не шутка. Если только писать и практически не читать. Логи nginx легко могут лететь с такой скоростью.
Ответ написан
Комментировать
dimonchik2013
@dimonchik2013
non progredi est regredi
обычный clickhouse такое потянет
а так задача big data решается ETLами , в которых, конечно, Постгресу есть достойное место, но не всегда в первичном звене
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы