У меня есть приложение, которое я построил, и если все пойдет хорошо, может сгенерировать большой объем данных. В настоящее время я использую базу данных MySQL для хранения информации и использую соединения INNER и LEFT для запросов для фильтрации данных. Теперь я все равно собирался поиграть с динамодабом, но подумал, что спросить, считают ли люди, что это соответствует следующей структуре данных, или мне следует использовать реляционную базу данных.
Например, допустим, у меня была таблица проекта с идентификатором проекта в качестве первичного ключа. Теперь каждый «проект» может иметь несколько пользователей, связанных с ним. Теперь, когда менеджер A входит в систему, он может захотеть увидеть все проекты, которые есть у членов его команды. В модели RDS это может быть структурировано следующим образом:
**project** **project_to_user**
project_id PK project_id
project_title user_id
select p.project_id,p.project_title from project as p inner join project_to_user as pto on p.project_id = pto.user_id WHERE pto.user_id IN( 1,2,3,4);
Теперь я теоретически могу сохранить аналогичную структуру для DynamodB, однако сначала мне нужно будет выбрать все project_ids из project_to_user для каждого user_id (много чтений) или, возможно, для сканирования, если user_id был набором user_ids. Затем я мог бы выбрать все проекты на основе этих возвращенных идентификаторов (возможно, удалив дубликаты с помощью кода). В качестве альтернативы я подумал, что мог бы удалить таблицу project_to_user и иметь атрибут user_ids в проекте и выполнить сканирование этой таблицы. Я знаю, что сканирование - не лучший способ работы с динамодабом, но может ли это быть компенсировано тем, что первым способом сделать это может быть много чтений в любом случае?
В моем приложении не так много таблиц, что, как я понимаю, делает его хорошим кандидатом на amazon DynamodB, но стоит ли мне придерживаться реляционной модели?
Я знаю, что это может показаться довольно открытым, но я взволнован перспективой масштабных предложений DynamoDB, однако мне интересно, подходит ли он для такого рода вещей. Однако я могу видеть, что управление БД становится большой головной болью, если я буду придерживаться модели отношений. Я уже переделал БД, чтобы она соответствовала модели динамодаба, но именно эти «точки присоединения» заставляют меня не решаться делать прыжок и будут благодарны за любые идеи, которые могут быть у людей.
Я немного играю с MongoDB с точки зрения привыкания к NoSQL, но, как я понимаю, мне придется управлять этой настройкой больше, чем с Amazon DynamoDB (которая является профессионалом для Amazon)
Большое спасибо
* РЕДАКТИРОВАТЬ *
По запросу user_id может быть столько же поисков, сколько и для project_id, если не больше, но каждый проект также необходимо идентифицировать отдельно