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

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

  • Статья

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

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

При выборе следует помнить о следующих соображениях.

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

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

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

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

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

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

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

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

DevOps

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

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