Это анти-шаблон, чтобы хранить базу данных в контейнере? - PullRequest
0 голосов
/ 03 июля 2019

У меня есть вопрос, касающийся лучших практик с контейнерами. Это анти-паттерн - иметь базу данных в контейнере?

Я уже несколько раз видел реализации БД в контейнерах, и я хотел бы услышать ваши мыслив теме.Насколько я понимаю, контейнеры должны быть легкими и эффективно не сохраняющими состояния.Они также должны работать как крупный рогатый скот, а не как домашние животные (как, например, легко уничтожаемые, и вы не полагаетесь на один контейнер, останавливающийся для выполнения бизнес-функций).

Из того, что я знаю о БД, они обычно не крупный рогатый скоти в зависимости от приложения они не легкие.Они также в значительной степени по своему состоянию.

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

1 Ответ

1 голос
/ 04 июля 2019

Это отличный вопрос, хотя и немного широкий. Это полностью зависит от того, что именно вы используете, и как вы планируете свои рабочие нагрузки.

В отношении контейнеров следует помнить, что здесь действительно нет магии. Контейнеры в конечном итоге сводятся к ограничениям уровня ядра (cgroup), наложенным на процесс, и уровень оркестровки (например, Kubernetes или CloudFoundry Diego) отвечает за реакцию, когда контейнер уничтожается за превышение этих ограничений (например, нехватка памяти).

В целом, существует ряд факторов высокого уровня, о которых следует помнить

  • Каковы требования к долговечности данных для этого проекта
  • Каковы рабочие нагрузки (например, почасовые всплески, непредсказуемая нагрузка и т. Д.)
  • Каков срок действия вашего соглашения об уровне обслуживания, и можете ли вы, клиенты, с легкостью справиться с ним при переходе к новым мастерам на вашем уровне данных
  • Самое главное, является ли контейнеризация правильным шаблоном для достижения уровня данных вашего проекта.

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

У вас может быть что-то вроде сегментированного кластера MongoDB, использующего механизм In-Memory для уровня кэширования, который требует немного больше возможностей, чем типичное хранилище значений ключей, такое как memcache (например, возможность запрашивать / фильтровать сам кэш). В зависимости от требований вашего проекта, вполне возможно потерять этот слой «кеша» и перестроить его по требованию.

В других рабочих нагрузках. Вы можете запустить что-то вроде EnterpriseDB ARK, чтобы обеспечить кластеризованные, высокодоступные, контейнерные развертывания PostgreSQL поверх Kubernetes. Это сопряжено со своими проблемами, но позволяет вам внедрить модель брокера услуг в архитектуру ваших микро сервисов, чтобы развернуть и сохранить уровень данных для каждого из ваших микро сервисов таким образом, чтобы смягчить уровень монолитных данных, который склонен к болтливому соседу. проблемы в этом типе архитектуры.

...