Подходит ли DynamoDB для приложений с большим количеством транзакций?

Я пишу приложение для агрегации ставок на скачки, которое будет получать данные с веб-сайта букмекерской конторы. Для начала я буду получать данные с 3 веб-сайтов (позже их может быть больше 10) каждые 10 секунд. Таким образом, в случае с 3 веб-сайтами будет около 10 000 записей (бегунов) каждый день, и каждая запись может быть прочитана 3 раза каждые 10 секунд и обновлена, если есть изменения в шансах.

  1. Подходит ли DynamoDB для таких приложений или мне следует придерживаться СУБД?
  2. Будут ли какие-либо проблемы с согласованностью с DyanmoDB, когда я одновременно обновляю шансы (с разных веб-сайтов) для одного и того же бегуна (рекорда)?
  3. Приложение может перерасти в другие виды спорта и гонки и получать данные с большего количества веб-сайтов. Повлечет ли это огромные затраты с DyamoDB, поскольку оно будет больше читать и писать?

ОБНОВЛЕНИЕ — 07.02.2020, 9:30 Структура записи будет примерно такой, как показано ниже. Будет запущено несколько запланированных сервисов, каждый из которых будет заботиться о букмекере. Есть вероятность, что запись будет прочитана службами и одновременно обновлена. Расчетное значение столбца будет основано на значении столбца Bookies. Следовательно, я хочу иметь возможность последовательно читать самое последнее значение столбца Bookies.

  RUNNER       EVENTID  BOOKIE1     BOOKIE2     BOOKIE3     BOOKIE...    CALCULATED
  Runner 1     12345    Odds1       Odds2       Odds3       Odds...      Value
  Runner 2     67890    Odds1       Odds2       Odds3       Odds...      Value

ОБНОВЛЕНИЕ – 21 июля 2020 г., 12:20

После обновления моего поста у меня в голове всплывают некоторые цифры, и DynamoDB кажется очень дорогим. Вот мои номера, если что-то не так, дайте знать.

Предположения:

  1. 10000 бегунов
  2. Каждые 10 секунд в течение месяца примерно округляется до 270 000 звонков.
  3. 3 букмекера
  4. Предполагая, что каждая запись/элемент имеет размер менее 4 КБ.
  5. Один RCU может считывать 5,2 миллиона чтений в месяц (где-то нашел)
  6. Один WCU может считывать 2,5 миллиона операций чтения в месяц

Требуется RCU в месяц: (3 * 1 0000 * 270 000)/5,2 млн = 1558 RCU

WCU Требуется в месяц: (3 * 1 0000 * 270 000)/2,5 млн = 3240 WCU


amazon-web-services amazon-dynamodb cost-management rdbms consistency
person Riddle    schedule 20.07.2020    source источник
comment
Когда вы говорите, что я получу данные с 3 веб-сайтов, вы имеете в виду, что вы изучаете эти сайты? Если да, то я бы поискал лучший дизайн.   -  person jarmod    schedule 20.07.2020
comment
@jarmod некоторые API платные, а некоторые очищаются. У вас есть какие-либо предложения?   -  person Riddle    schedule 21.07.2020
comment
Только для того, чтобы по возможности избегать просмотра веб-страниц, например. заплатив небольшую плату за доступ через API к этому или другому эквивалентному сайту. Веб-скрапинг не очень надежен в долгосрочной перспективе, не говоря уже об условиях обслуживания.   -  person jarmod    schedule 21.07.2020
comment
Согласен с тобой. Я собираюсь заплатить за это, если есть платная услуга, так как это экономит мое время и усилия.   -  person Riddle    schedule 21.07.2020

Ответы (3)


arrow_upward
3
arrow_downward

DynamoDB создан для повышения производительности и масштабируемости (в частности, для чтения), он поддерживает транзакции.

На самом деле, в то время как реляционная база данных использует модель ACID, DynamoDB как ключ-значение NoSQL использует БАЗОВАЯ модель. Это меняет такие функции, как согласованность (которая гарантирует, что транзакция будет записана на диск до того, как ответ будет успешным) для возможности иметь передовую производительность.

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

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

Вы можете снизить некоторые затраты на согласованность чтения с помощью DAX встроенного уровня кэширования, который находится в перед DynamoDB.

Кроме того, при малом периоде использования DynamoDB обеспечивает автоматическое масштабирование. встроенный в него, что может уменьшить емкость, за которую вы платите (чтение и запись), когда вы тише.

Помимо этого, если вам нужна производительность при сохранении транзакционных записей, хранилище данных Redis в памяти поддерживает транзакции. Существует управляемая версия AWS с ElastiCache.

Конечно, есть и вариант реляционной БД, хотя он позволит выполнять транзакционную запись, вам нужно будет учитывать производительность чтения (будь то через кэш или через функциональность только для чтения).

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

person Chris Williams    schedule 20.07.2020
comment
Я бы не согласился с вашим утверждением о том, что, хотя он поддерживает транзакции, он не является основным направлением. Транзакции — это первоклассная функция, как и любая другая функция DynamoDB. Кроме того, изменение элемента каждые 10 секунд не имеет большого значения. Если бы вы делали это несколько раз в секунду, то, может быть. - person Kirk; 20.07.2020
comment
Хорошо, подправил ответ @Kirk. Я полагаю, я пытаюсь объяснить, что транзакции наносят ущерб (пусть и небольшой) производительности операций записи в DynamoDB :) - person Chris Williams; 20.07.2020

arrow_upward
2
arrow_downward

DynamoDB абсолютно способна справиться с такой нагрузкой и даже больше. В связи с этим не беспокойтесь о DynamoDB.

Для согласованности DynamoDB имеет возможность выполнять строго согласованное чтение< /а>. Кроме того, чтобы вы знали, как работает запись, DynamoDB подтверждает запись только после того, как она достигает по крайней мере двух из трех узлов хранения для этого раздела. Один из этих двух должен быть ведущим узлом для этого раздела. Строго согласованные чтения всегда исходят от ведущего узла.

Что касается стоимости, она зависит от многих факторов, и, не зная больше о вашей рабочей нагрузке и о том, как она будет расти, я не решаюсь предположить. Если вы хотите посмотреть его, вы можете оплатить по мере использования в режиме емкости по требованию на столе (столах), и вы платите только за то, что вы используете.

person Kirk    schedule 20.07.2020

arrow_upward
1
arrow_downward

Для такой ситуации с использованием DynamoDb рекомендуется использовать DAX (https://aws.amazon.com/en/dynamodb/dax/ ), что делает Dyanamo подходящим.

Что касается согласованности, это будет зависеть от вашей модели данных, и с ней все в порядке, но Dynamo с DAX справляется с этим хорошо, вот ссылка на рекомендации по согласованности для DAX + Dynamo: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.consistency.html

И, наконец, да, все услуги, которые вы используете в любом облачном провайдере, имеют квоту или скорость ввода-вывода, поэтому, когда приложение вырастет, цена сделает это.

person Chaotic Pechan    schedule 20.07.2020