Лучшая практика - варианты хранения внешних справочных данных, которые запрашиваются различными способами - PullRequest
0 голосов
/ 11 января 2019

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

Различные приложения будут запрашивать справочные данные, чтобы представить их своим целевым клиентам (которые могут быть врачами, медсестрами, техниками, отделом закупок и т. Д.). Будет разработан общий глобальный API для возврата запрошенных данных.

Требуется историческая информация (например, FDB в 2017 году имел NDC1, который затем был удален из канала FDB в 2019 году. Таким образом, врач, который прописал NDC1, должен иметь возможность запрашивать информацию об этом препарате, проходящем через историю).

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

В Azure у нас есть следующие варианты хранения: Хранение блобов Космос ДБ База данных Azure SQL с системой контроля версий Azure Datawarehouse Озеро Лазурных Данных

Как лучше хранить внешние справочные данные? Мы склоняемся к базе данных Azure SQL с системой контроля версий. Кто-нибудь из вас работал с внешними справочными данными? Если да, каково ваше решение о хранении и хорошо ли это сработало для вас? Я хотел бы услышать ваши комментарии и мнения. Спасибо!

1 Ответ

0 голосов
/ 11 января 2019

Вы должны основывать свой выбор на типе данных, которые вы пытаетесь сохранить, и на том, как вам нужно ссылаться на них. Похоже, вам здесь могут понадобиться несколько разных технологий.

Например, Azure SQL отлично подходит для хранения реляционных данных. Так что, если ваши данные имеют табличную форму и должны иметь отношения между ними, то это хороший выбор. Однако, если вы собираетесь хранить миллионы и миллионы строк, производительность может снизиться в реляционной базе данных. В таком сценарии или в случае, когда у вас много транзакционных данных, вы можете посмотреть на Cosmos DB.

Вы упомянули изображения в какой-то момент, помещать их в базу данных не очень хорошая идея, в таком сценарии вы захотите посмотреть, используя хранилище BLOB-объектов.

«Справочные данные» на самом деле ничего не значат, посмотрите на отдельные типы данных, которые вы хотите хранить, и как эти данные используются, и принимайте решения на основе этого. Для большого количества различных типов данных вряд ли найдется подходящее решение для одного размера.

...