Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Оптимизация загрузки данных в Oracle Express
|
|||
|---|---|---|---|
|
#18+
Уважаемые коллеги! Помогите пожалуйста оптимизировать закачку данных из плоских файлов. Ситуация следующая: В кубе 7 измерений, два из них достаточно объемные по 3-5 тыс. записей со сложными иерархиями. Все измерения в показателях сделаны как SPARSE. За каждый месяц приходится закачивать в среднем по 10 млн. записей. Вопрос: Почему загрузка данных происходит неравномерно? Например, первые 2-4 млн. записей загружаются за 10-15 мин., а дальше время начинает сильно расти. Так, что загрузка данных за месяц может доходить до 12 часов! Количество памяти на сервере пока ограничено. Увеличение памяти планируется, но хочется решить этот вопрос другими средствами. Пробовал следующие ухищрения: - изменял последовательность индексации измерений в показателях куба; - изменял количество записей, после которых производил update куба; - пробовал делать пустой вспомогательный куб, и загружал в него данные частями по 2 млн. записей, после чего экспортировал в eif-файл, очищал куб и далее загружал; - изменял настройки сервера (MS Server 2003); - временно добавлял памяти (слегка скорость увеличивается и достаточно стабильно, но пока нет возможности ее добавить сколько необходимо); Ни один из использованных методов не принес стабильного результата. Хотя были моменты, когда данные за месяц загружались в течение 30 мин. Это был рекорд! Но повторение в точности тех же установок не помогло воспроизвести такую же скорость загрузки. Отчего же зависит скорость загрузки данных в Oracle Express? Буду благодарен за все высказанные гипотезы и советы. -=- С уважением, Илья Салов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 10:33 |
|
||
|
Оптимизация загрузки данных в Oracle Express
|
|||
|---|---|---|---|
|
#18+
2 Илья Салов Приведенный пример к сожалению довольно типичен для количества измерений больше 6. Все приведенные ухищрения тоже пробовал и гарантированно ничего не помогало. Приходилось изменять структуру базы, для чего использовал три направления в зависимости от задачи: 1. Разделить базу на две с количеством измерений меньше (например 6 вместо 7). Для измерений, не входящих в другую базу следует выбирать такую пару, в которой переменная гарантировано не кореллирована (т.е. ее значения относительно одного измерения не зависят от значений относительно другого). Часто две базы с 6 измерениями загружаются намного быстрее чем одна с семью. 2. Удалять старые данные на нижних уровнях временнОго измерения (часто данные за конкретный день в позапрошлом году не важны). 3. Разделить переменную (и соответственно, измерение, обычно временнОе) на несколько частей (напр. по годам, кварталам,т.д.). Размер памяти переменной важен для скорости загрузки, т.о. данные будут всегда загружаться в одну "подпеременную" и быстрее. Для клиентов создается формула, которая формирует из подпеременных значение соответствующее старой переменной. Время запросов при этом незначительно увеличивается, время загрузки существенно уменьшается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 11:26 |
|
||
|
Оптимизация загрузки данных в Oracle Express
|
|||
|---|---|---|---|
|
#18+
Спасибо, Bill. Советы очень полезные. Попробую реализовать по порядку. Значит никак нельзя стабилизировать скорость загрузки не используя сегменитрование куба? По поводу некоррелированных измерений не совсем понял, как можно выделить такую пару? На первый взгляд нужны все измерения, и так их количество сократили до минимума. Что значит пары не коррелируют? Или этот алгоритм можно реализовать на любых измерениях? Тогда как это отразится на конечных пользователях? -=- С уважением, Илья Салов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 11:53 |
|
||
|
Оптимизация загрузки данных в Oracle Express
|
|||
|---|---|---|---|
|
#18+
Я бы еще добавил, что не стоит все измерения в кубе ставить в SPARSE. По моему опыту очень большого преимущества можно достигуть играя сочетаниями измерений DENSE и SPARSE. Еще момент, как вы проводите агрегацию по иерархиям после загрузки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 12:16 |
|
||
|
Оптимизация загрузки данных в Oracle Express
|
|||
|---|---|---|---|
|
#18+
2 Илья Салов Значит никак нельзя стабилизировать скорость загрузки не используя сегменитрование куба? Мне такие способы не известы, хотя ето не значит что их точно нет. Однако сомневаюсь что есть чудодейственный способ, позволяющий критически снезить время выгрузки и слелать ее технологичной. Я имею в виду чтобы не приходилось ежедневно следить чтобы время выгрузки снова не превысило допустимый предел. Разве только очень много памяти. Попробую реализовать по порядку Как правило в каждом случае достаточно одного, наиболее подходящего. По поводу некоррелированных измерений не совсем понял, как можно выделить такую пару? Либо экспериментально либо на основании здравого смысла. Например, есть измерение с кодами торговых точек города, и есть измерение "время суток". В большинстве случаев если ассортимент одинаков зависимость продаж от времени суток можно считать примерно одинаковой для всех точек и разнести эти измерения по разным кубам. Конечно, можно привести немало примеров, когда это не так. Для конечного пользователя принципиально важно чтобы в один куб попадали измерения, зависимости переменной от которых взаимосвязаны, чтобы можно было смотреть их вместе. В приведенном ранее случае например может быть и резон, аналитик скажем может увидеть что в одной точке продажи монотонно снижаются к вечеру, а в другой есть еще вечерний всплеск и понять, что это в промышленном районе рабочие двинулись за водкой и соответственно скорректировать время работы и ассортимент. В общем, нужен внимательный предварительный анализ. Пользователю тоже не всегда удобнее чтобы все было в одном кубе- часто бывает что начинают разбегаться глаза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 12:33 |
|
||
|
Оптимизация загрузки данных в Oracle Express
|
|||
|---|---|---|---|
|
#18+
2 Birkhoff Совершенно справедливо, но не всегда помогает. В некоторых случаях уменьшение времени загрузки в результате уменьшения количества SPARSE- измерений компенсируется увеличением времени аггрегации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2003, 12:46 |
|
||
|
Оптимизация загрузки данных в Oracle Express
|
|||
|---|---|---|---|
|
#18+
Выражаю глубокую благодарность всем принявшим участие в решении вопроса и, в особенности, давшим добрые и полезные советы!:-) Из предложенных вариантов опробовал: - уменьшение кол-ва измерений и дробление на несколько кубов; - вынос индексации некоторых измерений в DENSE область; Все использованные варианты не дали значительного результата, так как проблема была в другом. Оказалось, что в части импортируемых данных содержатся записи с неопределенными значениями NULL или просто пустые строчки. Вот на них и происходили заметные снижения скорости загрузки. Теперь все в порядке. А предложенные советы я приму к сведению в дальнейших проектах. Еще раз СПАСИБО ВСЕМ! -=- С уважением, Илья Салов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2003, 14:30 |
|
||
|
|

start [/forum/search_topic.php?author=McClain&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
88ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 665ms |
| total: | 884ms |

| 0 / 0 |
