Как сохранить маршрутные данные в DynamoDB? - PullRequest
Новая
       103

Как сохранить маршрутные данные в DynamoDB?

0 голосов
/ 15 февраля 2020

Я пытаюсь найти лучший способ сохранить данные о маршруте поездки в DynamoDB. Просто для вашего сведения, мой код написан на Python3, и я использую Boto3 для взаимодействия с DynamoDB.

После исследования этого ресурса - https://schema.org/Trip, это то, что я думаю будут классы данных объектов. 

from marshmallow_dataclass import dataclass
from typing import List, Optional


@dataclass(frozen=True)
class Itinerary:
    id: str
    startTime: int
    endTime: int
    dayTripId: str
    placeName: str
    placeCategory: str
    estimatedCost: float


@dataclass(frozen=True)
class DayTrip:
    id: str
    day: str
    parentTripId: str
    date: Optional[str]
    itinerary: List[Itinerary]


@dataclass(frozen=True)
class UserTrip:
    tripId: str
    userId: str
    tripName: str
    subTrip: List[DayTrip]

По сути, структура выглядит следующим образом:

  • Человек может иметь много UserTrip s
  • UserTrip может состоять из одного или нескольких дней DayTrip, например, День 1, День 2, День 3
  • A DayTrip может иметь одно или несколько мест для посещения (Itinerary)
  • Itinerary - это самый низкий уровень, который описывает место для посещения

Не было бы хорошо хранить UserTrip как есть, с вложенной структурой JSON, состоящей из DayTrip, затем Itinerary, верно? Это будет означать, что атрибут subTrip определенного UserTrip будет огромным патчем JSON. Поэтому я думаю, что все здесь согласятся, что нет, нет. Это правильно?

Еще одна альтернатива, о которой я мог подумать, это хранить только id каждой сущности. Я имею в виду, например, что UserTrip будет иметь свой атрибут subTrip, содержащий список DayTrip id. Это означает, что будет еще одна таблица для хранения DayTrip элементов, и мы можем подключить ее к соответствующему UserTrip через атрибут parentTripId. И так далее для списка Itinerary.

Используя этот подход, у меня будет 3 x таблицы следующим образом:

  • user-trip-table для хранения UserTrip где subTrip будет содержать список DayTrip.id s
  • user-day-trip-table для хранения DayTrip, где itinerary будет содержать список Itinerary.id s. parentTripId включит сопоставление с исходной UserTrip
  • таблицей пользовательских маршрутов для хранения Itinerary, где оно может быть сопоставлено с исходным DayTrip через атрибут dayTripId.

Я не уверен, является ли это хорошей практикой, так как будет много поисков и асинхронные операции здесь невозможны. Это связано с тем, что для получения Itinerary мне нужно дождаться завершения операции GetItem, чтобы получить UserTrip, затем у меня будут идентификаторы DayTrip, а затем я сделаю еще один GetItem чтобы получить DayTrip, а затем, наконец, еще один GetItem для получения Itinerary.

Может ли сообщество предложить лучшее, более простое решение?

Спасибо!

1 Ответ

1 голос
/ 15 февраля 2020

Что касается структуры данных, я не вижу абсолютной необходимости в DayTrip, поскольку вы можете получить все эти данные из Itinerary. Поэтому в UserTrip я бы сохранял список маршрутов вместо списка DayTrips.

Не было бы хорошо хранить UserTrip как есть, с вложенной структурой JSON, состоящей из DayTrip тогда маршрут, верно? Это будет означать, что атрибут subTrip определенного UserTrip будет иметь огромный размер JSON. Поэтому я думаю, что все здесь согласятся, что нет, нет. Это правильно?

На самом деле этот рекомендуется в No SQL database , чтобы все данные были денормализованы / встроены в объект. Вы используете больше памяти, но избегаете соединений / обработки. Но имейте в виду ограничение размера элемента DynamoDB (в настоящее время 400 КБ).

В общем случае в No SQL вам необходимо создать свою схему на основе запросов, которые вам понадобятся. Например, в вашем случае вы хотите получить все маршруты UserTrip. Просто добавьте userTripId к таблице Itinerary. Создайте GSI на Itinerary с userTripId в качестве ключа ha sh, чтобы вы могли эффективно запросить его. Таким образом, вы получите все объекты маршрута поездки пользователя.

...