СУБД против DynamoDB и без сервера и без сервера - PullRequest
0 голосов
/ 06 февраля 2019

У меня есть небольшая проблема, связанная с разработкой запланированного приложения, особенно с базой данных и без сервера / без сервера.Целью является веб-приложение, которое взаимодействует через API Rest с базой данных.Сам по себе Rest API - это всего лишь операции CRUD, поэтому, на мой взгляд, подход Serverless (AWS Lambda) вполне подойдет.Для этого наиболее вероятной эффективной базой данных будет DynamoDB (NoSQL).

Я знаком с RDBMS и плохо разбираюсь в базах данных NoSQL.

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

Выбор, например, базы данных Amazon RDS MySQL, будет намного дороже, и я не знаю, насколько хорошо они справляются с безсерверным подходом Rest API,

Так что я стою в точке, я действительно не знаю, какие услуги здесь использовать.Могу ли я по-прежнему использовать DynamoDB?Схема, вероятно, будет очень реляционной.

1 Ответ

0 голосов
/ 06 февраля 2019

DynamoDB не имеет никакой концепции схемы, так что все дело в редактировании не связано (с DynamoDB).Если под схемой вы подразумеваете объекты с определенными свойствами, то это зависит от варианта использования.Если вы согласны с наличием в таблице объектов, которые не используют одну и ту же «схему», то это очень просто, так как это разрешено по умолчанию.С другой стороны, если вам нужно, чтобы все объекты совместно использовали один и тот же набор атрибутов, и вы собираетесь их часто менять, то это действительно не так просто и просто по сравнению с RDS.

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

Учитывая цену.Ну, я бы не сказал, что DynamoDB такой дешевый.На первый взгляд кажется, что так, но если вы углубитесь в это, то обнаружите, что это на самом деле довольно дорого, в основном с точки зрения записи.Вам необходимо обеспечить емкость для чтения и записи, а также более высокую пропускную способность, которая вам требуется, чем дороже она становится (вы можете использовать автоматическое масштабирование для пакетного трафика, но в случае стабильного трафика это не сильно вам поможет).В более крупных масштабах RDS (не Aurora) будет стоить лишь часть того, что будет стоить DynamoDB (при условии, что мы говорим о сценарии использования, который может обрабатываться RDS).

Если вы беспокоитесь об интеграции RDS с Lambda, тогда сложность не так велика по сравнению с DynamoDB.Есть некоторые соображения, которые необходимо принять, такие как жесткое ограничение времени выполнения лямбды (которое в настоящее время составляет 15 минут) и RDS может реагировать медленнее (по сравнению с DynamoDB), но если ваш запрос занимает столько времени, то вы либо делаетечто-то не так или неправильно использует эти инструменты.

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

...