Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Концептуальное.  [new]
ikonst
Member

Откуда:
Сообщений: 76
Добрый день, хочется совета. Концептуального.

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

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

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

Сейчас смотрю в сторону flashback archive. Что думаете? Может есть более интересные решения?
17 янв 08, 17:01    [5167333]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
ikonst
..

Сейчас смотрю в сторону flashback archive. Что думаете? ..

я бы начал с чего-нибудь более традиционного (секций, например)
17 янв 08, 17:13    [5167451]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
ikonst
Member

Откуда:
Сообщений: 76
Секционирование уже есть.
17 янв 08, 17:21    [5167532]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
ikonst

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

Менее 10 миллионов записей на месяц... Несерьезно

Данные не изменяемые задним числом, я так понимаю, соответственно, для отчетов имеет смысл строить агрегированные данные.
Короче, ручные агрегирования или матвьюхи + bitmap-индексы могут здорово облегчить жизнь.
Это все было про исторические отчеты.

Если отчет по последнему срезу, то вообще проблем нет, если разбито по дате выгрузки. Главное, чтобы запросы были правильно сделаны.
17 янв 08, 17:48    [5167782]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
насколько я понял ваш расклад, flashback archive тут уместен.
попробуйте - расскажете, какой он сладкий..
17 янв 08, 17:51    [5167813]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
orawish
Member

Откуда: Гадюкино-2 (City)
Сообщений: 15487
RA\/EN
ikonst

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

Менее 10 миллионов записей на месяц... Несерьезно
..имеет смысл строить агрегированные данные.
..

1) конечно..
2) дык (как я понял) это всё добро и есть агрегированные данные,
которые к тому же меняются в квартал по чайной ложке..
17 янв 08, 17:56    [5167863]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
ikonst
Member

Откуда:
Сообщений: 76
Нет, это не агрегированные данные - никакой статистики нет, это конфигурации оборудования. Да, меняется "по чайной ложке", поэтому хочется придумать как не хранить лишнего и анализировать данные без геммора.
18 янв 08, 11:02    [5170271]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
George A Eliseeff
Member

Откуда:
Сообщений: 59
[quote]Т.е. хотелось бы раз в неделю сливать полную конфигурацию, а раз в день - изменения.[/quote]

Ой не фааакт... Забываете о буферном кэше оракла.

Предположим, я хочу получить отчеты, отстоящие друг от друга на неделю.

В вашей схеме хранения:

Первый отчет загружает в буферный кэш большое количество данных из "полной конфигурации" №1 (например, 1000 блоков) и несколько блоков (например, 10) из ее истории изменений. Стоимость отчета по физическим чтениям - 1010.

Второй отчет загружает в буферный кэш большое количество данный из "полной конфигурации" №2 (1000 блоков), т.к. уже имеющиеся в оперативной памяти данные ему не нужны, и еще десяток других блоков истории изменений. Опять 1010 блоков.

Эффект от использования буфера - 0%.

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

Если хранить только самую первую "полную конфигурацию":

Первый отчет загрузит с диска в кэш 1000 блоков + N*10 блоков, где N - номер недели "от начала времен". Например, это составит 1300 блоков. Проигрыш - 290 блоков.

Второй отчет найдет какую-то часть блоков уже в кэше, например 500. т.е. догрузить с жесткого диска ему придется только 1301-500 = 800 блоков. Выигрыш - 210 блоков.

Третий отчет опять найдет что-то в кэше, и ему сново потребуется прочитать с диска на 100-300 блоков меньше по сравнению с вашей схемой хранения.


Соберите статистику по своим данным - сколько "весит" полный срез, сколько "весят" дневные данные, какой объем данных помещается в буферном кэше (не забывать про "вес" индексов!).

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



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

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


[quote]Секционирование уже есть.[/quote]

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

[quote]Конечно, можно воевать индексами, настройками СУБД, но хочется красивого масштабируемого решения. [quote]

Индексы и есть основной инструмент масштабирования. После головы, конечно. :)

[quote]Короче, ручные агрегирования или матвьюхи + bitmap-индексы могут здорово облегчить жизнь.[/quote]

Матвьхи "по датам" опять только увеличат объем хранения и нагрузку на диски, принимать решение о их целесообразности можно на основе анализа запросов, а не сруктуры хранимых данных.
18 янв 08, 20:09    [5174598]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8131
ikonst
Нет, это не агрегированные данные - никакой статистики нет, это конфигурации оборудования. Да, меняется "по чайной ложке", поэтому хочется придумать как не хранить лишнего и анализировать данные без геммора.
Стандартное решение - хранить конфигурации в виде
ИД_оборудования
датавремя_начала 
датавремя_конца 
параметры конфигурации
Каждая строка в таблице - это версия конфигурации единицы оборудования.
Версия живет с "датавремя_начала" по "датавремя_конца"
(текущая версия имеет "датавремя_конца" = 31,12,9999, например).
"параметры конфигурации" описывают эту самую конфигурацию.
При изменении хотя бы одного параметра конфигурации создается новая версия,
жизнь которой начинается, например, через секунду после завершения предыдущей.
(Вполне возможно, что вам хватит точности в 1 сутки, а не 1 секунда)

Запросы на любой момент времени будут включать доп. условие
AND момент_времени BETWEEN датавремя_начала AND датавремя_конца

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

Поскольку изменения происходят "по чайной ложке", то и версий конфигурации будет немного.

При этом можно нарезать секции по "датавремя_конца" (при ENABLE ROW MOVEMENT)
Так старые версии будут постепенно уходить в архивные секции (partitions)
18 янв 08, 21:34    [5174781]     Ответить | Цитировать Сообщить модератору
 Re: Концептуальное.  [new]
RA\/EN
Member

Откуда:
Сообщений: 3658
George A Eliseeff
[quote]Т.е. хотелось бы раз в неделю сливать полную конфигурацию, а раз в день - изменения.[/quote]

Ой не фааакт... Забываете о буферном кэше оракла.


Но есть ньюанс (с). Запихать все в память (раздув ее до необходимого размера) и подохнуть на buffer busy waits. Дополнительно - все запросы строить с учетом историзации и навсегда забыть про использование простых и удобных вещей для работы с хранилищами: star transformation, Discoverer.
Мое мнение - излишнее усложнение логики работы системы, не следующее из текущих задач и существующих проблем, приведет к:
  • необоснованным трудозатратам
  • снижению поддерживаемости системы
  • небольшому росту скиллов разрботчика + сформированному извращенному представлению о действительности

    Согласитесь, концепция хранилища данных как In-Memory DataBase - экзотика(извращение). В основном за счет хреновой масштабируемости.
  • 18 янв 08, 22:41    [5174953]     Ответить | Цитировать Сообщить модератору
     Re: Концептуальное.  [new]
    RA\/EN
    Member

    Откуда:
    Сообщений: 3658
    SQL*Plus
    [quot ikonst]Запросы на любой момент времени будут включать доп. условие
    AND момент_времени BETWEEN датавремя_начала AND датавремя_конца

    Плавали, знаем.
    Необходимо хорошо представлять, к чему может превести тотальный перекос данных в колонке "датавремя_конца", а при запросах к акуальным данным не забывать лепить предикат "датавремя_конца"=to_date(...) литералом.
    18 янв 08, 22:52    [5174982]     Ответить | Цитировать Сообщить модератору
     Re: Концептуальное.  [new]
    SQL*Plus
    Member

    Откуда: Россия, Москва
    Сообщений: 8131
    RA\/EN
    SQL*Plus
    [quot ikonst]Запросы на любой момент времени будут включать доп. условие
    AND момент_времени BETWEEN датавремя_начала AND датавремя_конца

    Плавали, знаем.
    Необходимо хорошо представлять, к чему может превести тотальный перекос данных в колонке "датавремя_конца", а при запросах к акуальным данным не забывать лепить предикат "датавремя_конца"=to_date(...) литералом.
    Любой перекос данных радости никому не принесет.
    Поэтому всяких перекосов нужно избегать.
    В данном же случае упомянутый перекос будет исправлен при следующей суточной загрузке.

    При запросе к актуальным данным нужно будет "лепить предикат "
    датавремя_конца"=to_date('31.12.9999', 'fxDD.MM.YYYY')
    или же вынести to_date('31.12.9999', 'fxDD.MM.YYYY') в DETERMINISTIC функцию

    Или же "лепить" условия вида
    AND SYSDATE BETWEEN датавремя_начала AND датавремя_конца
    или
    AND SYSDATE < датавремя_конца
    21 янв 08, 18:27    [5182356]     Ответить | Цитировать Сообщить модератору
    Все форумы / Oracle Ответить