Агрегатное представление в реальном времени для нескольких схем Oracle

Question

All

В поисках руководства по проектированию решения Oracle, которое я сейчас пытаюсь оценить:

Проблема

У меня есть данные в трех отдельных схемах на одном и том же сервере oracle db. Я собираюсь создать приложение, которое будет отображать данные из всех трех схем, однако показанные данные будут основаны на правилах сортировки и определения приоритетов в реальном времени, которые применяются к данным в глобальном масштабе (т. Е. На основе примененных весов приоритетов, которые я могу извлекать данные из любой из трех схем).

Предварительное решение

Создайте VIEW в БД, которая поддерживает логические ссылки на соответствующие столбцы в трех схемах, напишите хранимую процедуру, которая принимает параметризованные веса приоритетов. Затем приложение вызывает хранимую процедуру, чтобы выбрать «приоритетную» строку из представления, а затем напрямую запрашивает в связанной схеме дополнительные данные на основе возвращенной строки.

У меня есть опасения по поводу производительности, когда данные сортируются / расставляются по приоритетам при каждом выполняемом запросе, но я не вижу выхода из этого, поскольку правила расстановки приоритетов часто меняются. Мы говорим о наборах данных в области 2-3 миллионов строк на схему.

У кого-нибудь есть альтернативные предложения о том, как обеспечить агрегированный и отсортированный просмотр данных?

Answer 1

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

SELECT SOMETHING
FROM
  SCHEMA1.SOME_TABLE ST1, SCHEMA2.SOME_TABLE ST2
WHERE ST1.PK_FIELD = ST2.PK_FIELD

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

Просто установите обновления снимков с интервалом, соответствующим вашим потребностям.

Answer 2

Как уже говорили другие, запрос нескольких миллионов строк в Oracle на самом деле не проблема, но это зависит от того, как часто вы это делаете - каждая десятая доли секунды может вызвать некоторую нагрузку на сервер БД!

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

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

У Тома Кайта (знаменитости Ask Tom) всегда есть некоторые интересные идеи (и реальные факты) в этих областях. В этой статье описывается генерация правильного динамического поискового запроса, но Том отмечает, что когда вы запрашиваете Google, он никогда не пытается получить точное число обращений к запросу - он дает вам предположение . Если вы можете применить хорошую оценку, тогда вы действительно сможете улучшить время выполнения запросов

Answer 3

Неважно, что данные взяты из 3 схем, на самом деле. Важно знать, как часто будут меняться данные, как часто будут меняться критерии и как часто они будут запрашиваться.

Если существует ограниченный набор критериев (то есть данные будут просматриваться ограниченным числом способов), которые меняются только раз в несколько дней и будут запрашиваться как сумасшедшие, вам, вероятно, следует взглянуть на материализованные представления.

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

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

Честно говоря, 2-3 миллиона записей - это уже немного для Oracle, учитывая достаточное количество оборудования. Вероятно, я бы сначала проверил простые динамические запросы, прежде чем пытаться представить (материализованное) представление.