Это отличный вопрос, хотя и немного широкий. Это полностью зависит от того, что именно вы используете, и как вы планируете свои рабочие нагрузки.
В отношении контейнеров следует помнить, что здесь действительно нет магии. Контейнеры в конечном итоге сводятся к ограничениям уровня ядра (cgroup), наложенным на процесс, и уровень оркестровки (например, Kubernetes или CloudFoundry Diego) отвечает за реакцию, когда контейнер уничтожается за превышение этих ограничений (например, нехватка памяти).
В целом, существует ряд факторов высокого уровня, о которых следует помнить
- Каковы требования к долговечности данных для этого проекта
- Каковы рабочие нагрузки (например, почасовые всплески, непредсказуемая нагрузка и т. Д.)
- Каков срок действия вашего соглашения об уровне обслуживания, и можете ли вы, клиенты, с легкостью справиться с ним при переходе к новым мастерам на вашем уровне данных
- Самое главное, является ли контейнеризация правильным шаблоном для достижения уровня данных вашего проекта.
Помимо этого, вам нужно взглянуть на характеристики вашей оркестровой среды. Если вам необходимо сохранить содержимое диска, убедитесь, что вы выбрали контейнерный оркестратор, способный удовлетворить это требование.
У вас может быть что-то вроде сегментированного кластера MongoDB, использующего механизм In-Memory для уровня кэширования, который требует немного больше возможностей, чем типичное хранилище значений ключей, такое как memcache (например, возможность запрашивать / фильтровать сам кэш). В зависимости от требований вашего проекта, вполне возможно потерять этот слой «кеша» и перестроить его по требованию.
В других рабочих нагрузках. Вы можете запустить что-то вроде EnterpriseDB ARK, чтобы обеспечить кластеризованные, высокодоступные, контейнерные развертывания PostgreSQL поверх Kubernetes. Это сопряжено со своими проблемами, но позволяет вам внедрить модель брокера услуг в архитектуру ваших микро сервисов, чтобы развернуть и сохранить уровень данных для каждого из ваших микро сервисов таким образом, чтобы смягчить уровень монолитных данных, который склонен к болтливому соседу. проблемы в этом типе архитектуры.