Моделирование реляционных данных в DynamoDB (вложенные отношения) - PullRequest
3 голосов
/ 17 апреля 2019

Модель сущности:

enter image description here

Я прочитал Руководство AWS по созданию моделирования реляционных данных в DynamoDB.Это так запутанно в моем шаблоне доступа.

Шаблон доступа

+-------------------------------------------+------------+------------+
| Access Pattern                            | Params     | Conditions |
+-------------------------------------------+------------+------------+
| Get TEST SUITE detail and check that      |TestSuiteID |            |
| USER_ID belongs to project has test suite |   &UserId  |            |
+-------------------------------------------+------------+------------+
| Get TEST CASE detail and check that       | TestCaseID |            |
| USER_ID belongs to project has test case  |   &UserId  |            |
+-------------------------------------------+------------+------------+
| Remove PROJECT ID, all TEST SUITE         | ProjectID  |            |
| AND TEST CASE also removed                |   &UserId  |            |
+-------------------------------------------+------------+------------+

Итак, я моделирую данные реляционной сущности как руководство.

+-------------------------+---------------------------------+
|       Primary Key       |            Attributes           |
+-------------------------+                                 +
|     PK     |     SK     |                                 |
+------------+------------+---------------------------------+
|   user_1   |    USER    |    FullName    |                |
+            +            +----------------+----------------+
|            |            | John Doe       |                |
+            +------------+----------------+----------------+
|            |   prj_01   |   JoinedDate   |                |
+            +            +----------------+----------------+
|            |            | 2019-04-22     |                |
+            +------------+----------------+----------------+
|            |   prj_02   |   JoinedDate   |                |
+            +            +----------------+----------------+
|            |            | 2019-05-26     |                |
+------------+------------+----------------+----------------+
|   user_2   |    USER    |    FullName    |                |
+            +            +----------------+----------------+
|            |            | Harry Potter   |                |
+            +------------+----------------+----------------+
|            | prj_01     |   JoinedDate   |                |
+            +            +----------------+----------------+
|            |            | 2019-04-25     |                |
+------------+------------+----------------+----------------+
| prj_01     | PROJECT    |      Name      |   Description  |
+            +            +----------------+----------------+
|            |            | Facebook Test  | Do some stuffs |
+            +------------+----------------+----------------+
|            | t_suite_01 |                |                |
+            +            +----------------+----------------+
|            |            |                |                |
+------------+------------+----------------+----------------+
| prj_02     | PROJECT    |      Name      |   Description  |
+            +            +----------------+----------------+
|            |            | Instagram Test | ...            |
+------------+------------+----------------+----------------+
| t_suite_01 | TEST_SUITE |      Name      |                |
+            +            +----------------+----------------+
|            |            | Test Suite 1   |                |
+            +------------+----------------+----------------+
|            | t_case_1   |                |                |
+            +            +----------------+----------------+
|            |            |                |                |
+------------+------------+----------------+----------------+
| t_case_1   | TEST_CASE  |      Name      |                |
+            +            +----------------+----------------+
|            |            | Test Case 1    |                |
+------------+------------+----------------+----------------+

Если у меня просто UserIDи TestCaseId в качестве параметра, как я могу получить TestCase Detail и убедиться, что у UserId есть разрешение.

Я думал о хранении сложных иерархических данных в одном элементе.Что-то нравится это

+------------+-------------------------+
| t_suite_01 | user_1#prj_1            |
+------------+-------------------------+
| t_suite_02 | user_1#prj_2            |
+------------+-------------------------+
| t_case_01  | user_1#prj_1#t_suite_01 |
+------------+-------------------------+
| t_case_02  | user_2#prj_1#t_suite_01 |
+------------+-------------------------+

Вопрос: Каков наилучший способ для этого случая?Я признателен, если бы вы могли дать мне несколько советов для этого подхода (поклон)

Ответы [ 2 ]

4 голосов
/ 19 апреля 2019

Я думаю, что схема ниже делает то, что вы хотите.Создайте GSI только для ключа раздела на атрибуте «GSIPK» и выполните запрос следующим образом:

  1. Получить сведения о наборе тестов и проверить пользователя: запрос GSI - PK == ProjectId, FilterCondition [SK ==TestSuiteId ||PK == UserId]

  2. Получение сведений о тестовом примере и проверка пользователя: запрос GSI - PK == TestCaseId, FilterCondition [SK = TestSuiteId: TestCaseId ||PK = UserId]

  3. Удалить проект: Запрос GSI - PK == ProjectId, удалить все возвращенные элементы.

Запросы 1 и 2 возвращаютсяс 1 или 2 предметами.Одним из них является подробный элемент, а другим - права пользователя для набора тестов или тестового примера.Если возвращается только один элемент, он является подробным элементом, и у пользователя нет доступа.

enter image description here

enter image description here

1 голос
/ 18 апреля 2019

Первый вопрос, который вы должны задать: почему я хочу использовать БД документа ключа-значения над реляционной БД, когда у меня явно сильные отношения в моих данных?

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

Допустим, вы должны пойти на DynamodB.Если это так, большинство шаблонов, применимых для реляционных БД, являются анти-шаблонами, когда речь идет о NoSQL.В последнем переиздании есть полезный доклад о шаблонах проектирования для DynamodB и советы по его просмотру https://youtu.be/HaEPXoXVf2k.

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

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

Это должно удовлетворить ваши шаблоны доступа.

...