Какое решение для базы данных подходит для высокопроизводительных обновлений?

Question

Предположим, я являюсь службой подписки, и у меня есть таблица, в каждой строке которой представлены данные клиента.

Я хочу создать систему, которая будет ежедневно обрабатывать данные о клиентах.Этот ежедневный снимок содержит данные всех существующих в настоящее время клиентов (т. Е. Будут строки для новых клиентов и клиентов, которые отписались от подписки, не будут отображаться в этих данных).Мне также необходимо отслеживать продолжительность подписки каждого клиента, используя время начала и окончания.Если клиент повторно подписывается, другая запись этого времени начала и окончания обновляется для этого клиента.Пример записи / схемы показан ниже.

{
    "CustomerId": "12345",
    "CustomerName": "Bob",
    "MagazineName": "DatabaseBoys",
    "Gender": "Male",
    "Address": "{streetName: \"Sesame Street\", ...}",
    "SubscriptionTimeRanges": [{start:12345678, end: 23456789}, {start:34567890, end: 45678901},...]
}

• Я буду обрабатывать> 250 000 строк данных один раз в день , каждый день
• Мне нужночтобы узнать, существует ли какая-либо запись в снимке * в настоящее время в базе данных
• Общий размер таблицы будет> 250 000
• Есть долгосрочные преимуществаэто связано с наличием реляционной базы данных (например, присоединение к другой таблице, содержащей информацию из журнала)
• Я хотел бы получить записи либо по CustomerId, либо по MagazineName
• Запись не должначтение блока
• Для этого я предполагаю, что мне потребуется отсканировать всю таблицу, выполнить итерацию по каждой записи и индивидуально обновить SubscriptionTimeRanges массив / JSON-блоб каждой записи
• Задержка записи составляетне сложное требование, но в то же время я не должен ожидать, что потребуется более часа, чтобы обновить все эти записи (можно ли это сделать за одну транзакцию, если это обновление ...?)
• читает шоуld также быть быстрым
• Параллельная обработка всегда хороша, но что может привести к блокировке для ACID-совместимых БД?

Я знаю, что DynamoDB быстро справится с этим вариантом использования,и схема записи находится прямо на аллее NoSQL.Я могу использовать глобальные вторичные индексы / локальные вторичные индексы, чтобы решить некоторые из моих проблем.У меня есть некоторый опыт работы с PostgreSQL при использовании Redshift, но я в основном имел дело с массовыми вставками без необходимости изменения данных.Теперь мне нужен аспект модификации данных.Я думаю, что RDS Postgres был бы хорош для этого, но хотел бы услышать ваши мысли или мнения.

PS Не принимайте проект системы "подписки" слишком серьезно, это лучший параллельный пример, который я мог бы подуматьпри настройке примера для аналогичных требований ..:)

Answer 1

250 000 строк данных, обрабатываемых ежедневно, вероятно, не оправдывает использование Amazon Redshift .Он состоит из миллионов или миллиардов строк и обычно используется, когда вы хотите выполнять запросы в течение дня.

Если база данных RDS удовлетворяет вашим потребностям, тогда сделайте это!Если вы хотите сэкономить, вы можете накапливать записи в Amazon S3 в течение дня, а затем просто загружать и обрабатывать данные один раз в день, отключая базу данных, когда она не требуется.(Или даже отмените его и запустите новый на следующий день, поскольку кажется, что вам не нужен доступ к историческим данным.)

Amazon Athena может даже удовлетворить ваши потребности, читаяежедневные данные с S3 и даже не нуждающиеся в постоянной базе данных.

Answer 2

Это субъективный вопрос, но, объективно говоря, DynamoDB не предназначен для сканирования.Он может их выполнять, но требует повторных запросов в цикле, начиная каждый запрос с того места, где остановился последний.Это не быстро для больших наборов данных, так что есть также параллельное сканирование , но вы должны манипулировать потоками и использовать большую пропускную способность таблиц с этим.

С другой стороны,Прототипирование и тестирование на DynamoDB с использованием SDK легко и недорого.

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