Выбор базы данных для вставки миллионов строк каждый день для построения графика для каждого пользователя

Question

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

В основном мне нужно хранить большое количество данных через cron для сети каждого пользователя.-worth.

Существует 20K взаимных фондов, в которые пользователь может инвестировать.В настоящее время насчитывается 80 миллионов пользователей, из которых 20 миллионов вложили средства в несколько взаимных фондов.Эти цифры быстро растут.

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

Теперь моя задача - создать масштабируемый дизайн для хранения (user_id, networth, date) каждый день для построения графика с момента, когда пользователь сделал свои первые инвестиции.

У меня следующие вопросы:

1. Какую базу данных мне следует использовать?

2. Как только база данных выбрана, каковы способы достижения масштабируемости для добавления ~ 100 миллионов записей в день.

ОБНОВЛЕНИЕ : данные должныхраниться с момента первого вложения, сделанного пользователем.Для простоты вы можете рассчитывать на 5 лет для каждого пользователя.

Открыт для любой базы данных.Предпочел бы Graph Database.

Спасибо.

Answer 1

Насколько я понимаю, новые данные генерируются ежедневно для каждого пользователя, и, как указано в вопросе, необходимая емкость состоит в том, чтобы ежедневно вставлять 100 миллионов строк.Тем не менее, важно знать, как далеко в прошлом записи должны быть сохранены в базе данных?Нужно ли хранить данные в течение месяца, года или пяти лет?Если предположить, что на графике трендов используются данные за последний полный год, то общее количество необходимых строк будет 100 миллионов * 365 (дней), что составляет 36500 миллионов, то есть 36 миллиардов строк.Предполагая, что одна строка занимает 24 байта, общая требуемая емкость составляет ~ 1 ТБ (округлено).Это было бы хорошо для хранения данных за 1 год для всех пользователей.В конце года данные могут быть заархивированы, а полная емкость может быть восстановлена ​​в начале следующего года.

Учитывая, что данные не нуждаются в поддержке ACID, поскольку они не являются транзакционнымиданные и данные не имеют каких-либо связей между различными объектами, база данных NoSQL, кажется, здесь хорошо подходит.Предполагая, что пакетное задание будет запущено и вставит обновленную чистую стоимость сразу для всех 100 миллионов пользователей, представляется необходимым сократить время вставки.База данных пар «ключ-значение» с поддержкой быстрой записи, например Cassandra, кажется здесь хорошим выбором.Ключ раздела будет идентификатором пользователя.Кроме того, природа данных такова, что она неизменна, поэтому базовая структура хранения данных Cassandra только добавляется, что делает ее еще более удобной.

Поскольку данные являются неизменяемыми, это делает их очень подходящими для кэширования.В зависимости от емкости кэша все или некоторые данные ежедневных активных пользователей могут храниться в кэше для обслуживания запросов, необходимых для построения графиков.Кэш-память LRU может быть хорошим выбором.

Примечание: Если база данных NoSQL не является опцией, реляционная база данных с разделением на основе идентификатора пользователя также сделает эту работу.

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