Хранилище данных: одна база данных или много?

Question

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

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

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

Это то, что делается в промышленности? Существуют ли существенные причины для этого или нет?

Платформа - Netezza. Размер в терабайтах, сотни миллионов строк.

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

Answer 1

Лучше поздно, чем никогда, но для Netezza:

При запросе кросс-базы данных производительность не снижается. Netezza допускает только операции SELECT между базами данных, операторы INSERT, UPDATE или DELETE не допускаются.

Это означает, что вы не можете сделать:

THISDB(ADMIN)=>INSERT INTO OTHERDB..TBL SELECT * FROM THISDBTABLE;

но вы можете сделать \c OTHERDB тогда

OTHERDB(ADMIN)=>INSERT INTO TBL SELECT * FROM THISDB..THISDBTABLE;

Вы также не можете создать материализованное представление для кросс-базы данных, например: OTHERDB(ADMIN)=>CREATE MATERIALIZED VIEW BLAH AS SELECT * FROM THISDB..THISDBTABLE;

Администрация может быть там, где вы решите (хотя, возможно, вы уже давно это сделали) о том, какие базы данных вы будете создавать. В зависимости от вашей инфраструктуры у вас может быть система TEST / QA и система PROD на одном и том же или на разных блоках.

Answer 2

Мы используем базы данных для каждого сегмента (ИНВЕНТАРЬ, CRM, БИЛЛИНГ ...).Там нет никаких недостатков производительности и технического обслуживания и обзор гораздо лучше.

Answer 3

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

Answer 4

Несколько моментов, на которые следует обратить внимание a) Если необходимо объединить данные в одной или нескольких таблицах подготовки, аудита, измерения и фактов, лучше хранить их в одной базе данных

b) Обычно высохранит таблицы измерений и таблицы фактов в одной и той же базе данных и распределит их по наиболее часто соединяемым столбцам, чтобы использовать функциональность Netezza

для совместного размещения * c) Вы должны иметь возможность использовать разрешение на предоставление SQL для управления доступом квсе объекты (БД, таблицы, представления и т. д.)

Answer 5

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

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

Там, где я нахожусь, у нас есть несколько баз данных TB в одном хранилище данных.Наше эмпирическое правило заключается в том, что один процесс загрузки или один запрос отчета НЕ должны охватывать базу данных.Это объединяет «похожие» таблицы, но дает некоторые допуски для наших резервных копий и непредвиденных процессов.Это также облегчает «поиск» данных.

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

Я не так хорошо знаком с Netezza, поэтому я не уверен на 100%, какие у вас варианты.

Answer 6

Редактировать

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

Если вы поместите ДВЕ экземпляра на одном физическом сервере, вы получите:

Отрицательные:

1. половина используемой памяти
2. В два раза больше процесса базы данных

Положительные:

1. Вы можете снять всю промежуточную базу данных, не затрагивая DW

Так что же для вас дороже, отключение окон или ЦП и памяти?

На одном и том же физическом сервере несколько экземпляров делают вопросы управления производительностью НАМНОГО более ручными для решения. Если вы посмотрите на работоспособность одного из экземпляров, он может выглядеть хорошо, но пользователи сообщают о низкой производительности, поэтому вам нужно посмотреть на следующий экземпляр, чтобы выяснить, может ли проблема возникать оттуда ... и так далее для каждого экземпляра. .

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

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

ОРИГИНАЛЬНАЯ ПОЧТА

Можем ли мы быть ясными по срокам. Когда вы говорите «в той же базе данных», вы имеете в виду тот же экземпляр или тот же физический сервер. Если бы вы переместили этап на новый экземпляр, он бы находился на том же физическом оборудовании?

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

Допустим, вы действительно имели в виду два отдельных физических блока ...

Допустим, вы покупаете 2 коробки с 12 путями (просто скажем). Когда вы готовите сервер БД на день, эти 12 процессоров тратятся впустую. Когда ваши пользователи соберутся и уйдут домой, ваши процессорные DW-процессоры тратятся впустую. Циклы процессора являются скоропортящимися, вы не можете получить их обратно. НО, если у вас был один блок с 24 путями ... тогда промежуточная БД МОЖЕТ использовать 20 ЦП в ночное время для превосходного параллельного выполнения для создания сводных таблиц, и ваши пользователи будут удваивать емкость для процессов в течение дня.

Допустим, вы имели в виду одно и то же оборудование.

«Похоже, что проблемы с безопасностью, резервным копированием / восстановлением и управлением производительностью становятся более интенсивными вручную».

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

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

Какую безопасность вы делаете на уровне экземпляра?

Резервное копирование

Какие DW вы резервируете на уровне экземпляра? Вы не копируете табличные пространства, а целые экземпляры? Похоже, что этот шаблон потерпит неудачу при определенном размере.

ПЛАТФОРМА: NETEZZA

Специально не знаком с инструментом. Таким образом, если это один экземпляр на одном блоке, то разделение будет казаться более логичным, чем физическим, и поэтому причины их существования - управление, а не производительность. Вы не увеличиваете свои процессоры или память, добавляя базу данных, верно? Так что не похоже, что в этом нет никакой производительности. Каждая БД может добавлять отдельные процессы (снижение производительности) или может быть полностью логичной, как схемы в Oracle. Если каждая база данных управляется новыми процессами, то переход данных между ними будет означать IPC.

Возможно, добавление тега Netezza получит некоторую тягу.