Разумно ли разделять таблицы, которые растут с разной скоростью, в свои собственные базы данных? - PullRequest
2 голосов
/ 09 декабря 2011

В моей базе данных есть таблицы, которые будут расти с разной скоростью:

  • довольно статичные, которые я совсем не ожидаю,
  • средние, которые будутнесколько линейно растут в зависимости от количества пользователей и их активности
  • быстрорастущих, которые будут быстро расти, поскольку они содержат зарегистрированные точки данных

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

  • С одной базой данных проще работать, но в будущем это может привести к более высоким затратам на обслуживание
  • Поддерживать несколько баз данных проще, если приложение будетразвернут, но потребует больше времени на исследования и разработки

Можете ли вы порекомендовать одно или другое решение на основе вашего прошлого опыта?

Спасибо,

1 Ответ

3 голосов
/ 09 декабря 2011

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

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

Но у нас есть одна общая база данных, которая содержит информацию, которая используется в нескольких приложениях. (Например, корпоративная информация, местоположение и т. Д.), Чтобы избежать дублирования данных. (Зачем вести список мест в каждой базе данных).

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

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

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

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

...