Поделиться через

Критерии выбора хранилища данных

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

Общие рекомендации

При выборе следует учитывать следующие рекомендации.

Функциональные требования

  • Формат данных: какой тип данных планируется хранить? Распространенные типы включают транзакционные данные, объекты JSON, телеметрию, индексы поиска или неструктурированные файлы.
  • Размер данных: насколько большими являются сущности, которые необходимо хранить? Должны ли эти сущности поддерживаться как один документ или могут ли они быть разделены по нескольким документам, таблицам и коллекциям?
  • Масштабирование и структура. Какова общая емкость хранилища? Предполагается ли секционирование данных?
  • Связи данных: должны ли ваши данные поддерживать связи "один ко многим" или "многие ко многим"? Являются ли отношения важной частью данных? Придется ли объединить данные внутри одного и того же набора данных или из внешних наборов данных?
  • Модель согласованности. Насколько важно, чтобы обновления, внесенные в один узел, отображались в других узлах перед дальнейшими изменениями? Можно ли принять итоговую согласованность? Требуются ли гарантии ACID для транзакций?
  • Гибкость схемы: какие схемы будут применяться к данным? Будете ли вы использовать фиксированную схему, схему при записи или схему при чтении?
  • Параллелизм. Какой механизм параллелизма вы хотите использовать при обновлении и синхронизации данных? Будет ли приложение выполнять множество обновлений, которые могут потенциально конфликтуть? В этом случае может потребоваться блокировка записей и пессимистичное управление параллелизмом. Или можете ли вы поддерживать оптимистические механизмы контроля параллелизма? Если да, достаточно простого элемента управления параллелизмом на основе меток времени или требуется добавленная функциональность элемента управления параллелизмом с несколькими версиями?
  • Перемещение данных. Потребуется ли решение выполнять задачи ETL для перемещения данных в другие хранилища или хранилища данных?
  • Жизненный цикл данных: запись один раз, чтение много раз? Можно ли переместить его в прохладное или холодное хранилище?
  • Другие поддерживаемые функции: требуются ли другие специальные функции, такие как проверка схемы, агрегирование, индексирование, полнотекстовый поиск, MapReduce или другие возможности запросов?

Нефункциональные требования

  • Производительность и масштабируемость. Каковы требования к производительности данных? У вас есть конкретные требования к скоростям приема данных и скоростям обработки данных? Каково допустимое время отклика для запроса и агрегирования данных после загрузки? Насколько большой объем хранилища данных потребуется для увеличения масштаба? Является ли ваша рабочая нагрузка ориентирована больше на чтение или на запись?
  • Надежность. Какое общее соглашение об уровне обслуживания требуется для поддержки? Какой уровень отказоустойчивости необходим для потребителей данных? Какие возможности резервного копирования и восстановления требуются?
  • Репликация. Необходимо ли распределять данные между несколькими репликами или регионами? Какие возможности репликации данных требуются?
  • Ограничения. Будут ли ограничения определенного хранилища данных поддерживать ваши требования к масштабу, количеству подключений и пропускной способности?

Управление и затраты

  • Управляемая служба. Если это возможно, используйте управляемую службу данных, если не требуется определенных возможностей, которые можно найти только в инфраструктуре как услуга (IaaS) размещенного хранилища данных.
  • Доступность региона: для управляемых служб служба доступна во всех регионах Azure? Нужно ли размещать решение в определенных регионах Azure?
  • Переносимость: необходимо ли перенести данные в локальные, внешние центры обработки данных или другие облачные среды размещения?
  • Лицензирование: у вас есть предпочтение между проприетарной и лицензией СКПО? Существуют ли другие внешние ограничения на то, какой тип лицензии вы можете использовать?
  • Общая стоимость: какова общая стоимость использования службы в решении? Сколько экземпляров потребуется запустить для поддержки требований к доступности и пропускной способности? Рассмотрим затраты на операции в этом расчете. Одной из причин, по которым следует предпочесть управляемые службы, является снижение операционных затрат.
  • Эффективность затрат: можно ли секционировать данные для более эффективного хранения данных? Например, можно переместить большие объекты из дорогой реляционной базы данных в хранилище объектов?

Безопасность

  • Безопасность: какой тип шифрования требуется? Требуется ли шифрование неактивных данных? Какой механизм проверки подлинности вы хотите использовать для подключения к данным?
  • Аудит: какой журнал аудита необходимо создать?
  • Требования к сети. Необходимо ли ограничить или иным образом управлять доступом к данным из других сетевых ресурсов? Должны ли данные быть доступны только из среды Azure? Должны ли данные быть доступны из определенных IP-адресов или подсетей? Требуется ли доступ к приложениям или службам, размещенным локально или в других внешних центрах обработки данных?

DevOps

  • Набор навыков: существуют ли языки программирования, операционные системы или другие технологии, которые ваша команда использует? Есть ли другие, с которыми будет трудно работать ваша команда?
  • Клиенты: есть ли хорошая поддержка клиентов для ваших языков разработки?

Дальнейшие действия