Edge-home-orchestration-go: Как насчет объединения базы данных текущей конфигурации и базы данных serviceInfo в одну?

Созданный на 3 сент. 2020  ·  4Комментарии  ·  Источник: lf-edge/edge-home-orchestration-go

Как насчет объединения базы данных конфигурации и базы данных serviceInfo, как показано ниже, и использования базы данных serviceInfo для различных целей, таких как сбор данных о производительности (ЦП, память), версии и т. Д.?

Текущий

type Configuration struct {
    ID       string `json:"id"`
    Platform string `json:"platform"`
    ExecType string `json:"executionType"`
}
type ServiceInfo struct {
    ID       string   `json:"id"`
    Services []string `json:"services"`
}

Будущее

type Configuration struct {
    ID       string `json:"id"`
    Platform string `json:"platform"`
    ExecType string `json:"executionType"`
    Services []string `json:"services"`
}
enhancement

Самый полезный комментарий

@MoonkiHong @
Я тестировал работу Edge Orchestration в обычном режиме, когда конфигурационная база данных хранит списки сервисов.
Пожалуйста, рассмотрите этот вопрос и просмотрите предлагаемый PR, если с этим все в порядке.

Все 4 Комментарий

@ Karthikeyan-Samsung @ suresh-lc PTAL.

@MoonkiHong @
Я тестировал работу Edge Orchestration в обычном режиме, когда конфигурационная база данных хранит списки сервисов.
Пожалуйста, рассмотрите этот вопрос и просмотрите предлагаемый PR, если с этим все в порядке.

Объединение dbs в один выглядит лучше с точки зрения понимания. Но с точки зрения разработки и ремонтопригодности его хорошо поддерживать отдельно. Это упрощает правильное обновление информации и, таким образом, обеспечивает целостность данных. В будущем, если мы захотим ограничить услуги для конкретного запрашивающего, было бы лучше, если бы у нас было 2 разных dbs. Также, если мы хотим добавить другой параметр, например, на основе возможностей устройства (Sensor), если необходимо выполнить разгрузку, скажем, необходимо добавить возможность db. Следовательно, всегда лучше иметь отдельные базы данных, а не объединять их в одну. Если у слияния в одну базу есть сильная сторона, то мы должны подумать об этом.

Как описано в №132, давайте продолжим обсуждение этой темы, включая обратную совместимость структуры БД.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги