Открыть список
Как стать автором
Обновить

Комментарии 17

… машина Exadata Х5 (один юнит) корпорации Оракл… примерно 17 тысячам записей исходных данных в секунду

это крайне медленно, должно быть на порядок быстрее, возможно код у Вас где-то не так написан
Сейчас попробовал на коленке загрузить. На моём стареньком компе на HDD, файл 0.3Гб, 7млн строк, залетают в MySQL за ~137сек, т.е. около 50к строк в секунду
При написании SQL ориентируюсь на скорость 100K в секунду для одного запроса вставки в таблицу. Эксперимент описывает интеграцию данных. Из исходных данных загружаются измерения и агрегаты.
Общее время, необходимое для интеграции делится на количество исходных записей.
Метод загрузки файла выбран не самый быстрый, его можно оптимировать, но в 2 раза, а не на порядок.
Но и метод с PHP не самый быстрый, поэтому этот шаг можно считать эквивалентным.
загрузку файла можно оптимизировать на порядок, а то и на 2, PHP вообще не должен трогать и читать файл, только отправлять SQL запросы. Далее второй пункт «Обработка и очистка данных — 2 SQL запроса и 130 минут.» тож больно долго, какие-то видимо сильно не оптимальные запросы, от этого пункта можно вообще избавиться и всё реализовать одной загрузкой. А какая БД у вас на Экзадате? Оракл?
Oracle Database 18c. Ваши замечания и вопросы верные и логичные.
Для описания причин нужно писать статью, но такие плохо читаются и сильно минусуются энтерпрайзом, пот. быстро уходят в сторону «эффективных менеджеров» (уже поробовал и удалил про конфликт интересов).

Один аспект. Все операции тем эффективные, чем ближе к железу.
Например, метод внешних таблиц в Оракле будет очень быстрым.
Но нужно иметь расширенные права к диску и окружению. Часто даже к ОС, тут сложно становится с гарантийным обслуживанием.
Администратор БД, чел. по безопасности и аналитик будут испытывать конфликт интересов (одни не занимаются содержимым, другие могут что-нибудь сломать).
Но есть другой способ — sqlloader, гибкий и не сильно быстрый. Можно быстро, но должно лежать рядом с базой и тут снова конфликт.

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

Поэтому во втором случае PHP для файла, чтобы сохранить баланс :)
уж простите, но похоже с компетентностью туго в вашей организации, за те 6 часов которые обрабатываются 10Гб, можно заново написать загрузчик, для любой БД, загрузить эти данные и отказаться от Экзадаты, и недальновидного Администратора этой Экзадаты.

Если у вас организационно-бюрократические проблемы в организации, то в технической статье глупо писать что Exadata Х5 обрабатывает информацию со скоростью 500кб/сек

В целом для Оракла тут вообще изи и сверх быстро всё должно работать:
— CREATE TABLE access_log… ORGANIZATION EXTERNAL (… LOCATION ('access.log')) PARALLEL 12…
— MERGE INTO agregate_data SELECT… FROM access_log
притом если ещё лог файл подточить напильником для фикс формата и создать внешнюю таблицу как ORGANIZATION EXTERNAL (… RECORDS FIXED… ), то можно получить мгновенный доступ к любой записи используя
ORGANIZATION EXTERNAL (… ACCESS PARAMETERS (… RECORDS FIXED… SKIP N
даже если файл будет хоть 10Тб
Хотел бы спросить.
Почему все хотят видеть техническую статью, не привязанную к реальности?

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

Есть ли информация о том, сколько у Вас в среднем времени проходит от external table до готового отчёта?
Почему все хотят видеть техническую статью, не привязанную к реальности?

Странная у Вас реальность…

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

Всем желающим не надо, надо дать только разработчикам. Можно хоть докер развернуть, пусть контейнер как надо соберут и установят какие надо для работы параметры и ПО, я не понимаю какие тут вообще могут быть проблемы…
Типа как в анекдоте:
Товарищ прапорщик, а можно телевизор посмотреть?
— Можно, только не включайте.


Есть ли информация о том, сколько у Вас в среднем времени проходит от external table до готового отчёта?

Какой отчёт? Из каких данных? Вопрос не совсем корректный. Я в своё время (~год назад) через EXTERNAL TABLE + INSERT APPEND делал загрузку телеметрических данных с GPS датчиков, около 15к в онлайне, данные обновлялись каждую секунду со сложной бизнес логикой с
денормализованными данными о скоростных режимах, расходах топлива, превышений и т.д.

Ваша задача:
— access.log загрузка 350млн записей 10Гб данных
— ELT преобразование
— агрегированный отчёт
мои предварительные оценки:
— пара-тройка дней на разработку (чисто SQL запросы)
— день на простенький вывод отчёта html
— ориентировочная финальная производительность на более менее нормальном железе ~ 15-60 мин на генерацию
Ваша оценка времени оказалась достаточно точной. Показал заметку ответственному за Экзадату специалисту.
EXTERNAL TABLE неожиданно реализовалось и время первого этапа составило 10 минут вместо 90. Полный цикл обработки — 70 минут.
очень рад, что заметки оказались полезными
Не буду спорить, но я бы сделал так:
1. sqlloader с опцией direct в оракловскую таблицу без всяких индексов, всё в одну транзакцию — это будет очень быстро, мы максимально быстро загнали данные из файла в БД с огромными кэшами и улучшенной возможностью применения бизнес логики.
2. insert /*+ APPEND */ select * из временной оракловской таблицы в другую оракловскую таблицу (пустую или не очень), в которой уже есть индексы и всё прочее. Можно даже в таблицу с партициями, тогда можно будет доступ к данным еще подтюнить.
3. Если фильтрация не очень сложная — то на правильно индексированной таблице вы довольно быстро почистите данные от шелухи.
Везде должно быть быстро. У меня в одном проекте еще был шаг 0 — perl'овый скрипт делал первоначальную очистку файлов от шелухи. Вот уж кого нельзя обвинить в медленности дисковых операций.
Извините меня, но похоже, что вы забыли включить Exadata. Даже не самая новая модель X5 всё равно является довольно шустрой машиной, как в плане CPU, так и в плане скорости ее локальных дисков (я правильно понял, что вы не использовали Exadata storage cells, подключенные через спаренную оптику 2х32Gbit?).
Про скорость Exadata согласен: в случае ошибок проще сделать резервную копию и перегрузить таблицы целиком, чем исправлять, так быстрее.
В Exadata всё включено, диски SSD, всё параллельно, нагрузка равномерно распределена, таблицы с партициями, с большой компрессией, статистика собрана, пакеты скомпилированы для выполнения нативно и параллельно.

Но это ведь не один SQL Select Insert и не измерение скорости Exadata. Она действительно быстра, спору нет.

Идея была описать время всего цикла интеграции относительно количества исходных данных.
На это время влияют факторы:
— дедубликация, очистка данных, форматы (используются условия, строковые функции, преобразования)
— вызов функций из другого пакета
— подключение других таблиц для формирования ссылки
— загрузка исторических таблиц

Было бы интересно узнать примеры из других проектов. Сколько времени требуется до готовности отчётов.

Если у вас такая обработка что легко параллелится то для неё не нужен SQL и производительность обоих машин будет гораздо выше при рациональном программировании задачи. Однако если обработка выполняется средствами SQL то никакой sqlite или oracle вам не поможет равномерно разнести нагрузку на 1000 машин, и все теоретические выкладки о производительности идут ко дну.

> Чтение из файла 10,3 ГБ — 350 миллионов записей за 180 минут.
Не знаю что за хранилище в этой экзадате, но кажется базу записали на флоппи диски, иначе как объяснить скорость чтения 1мб/с? :)
Благодаря комментариям обнаружил, что какой-то жук задеплоил очень старый файл конфигурации для загрузки файла и уже давно. Поправлю и измерю ещё раз время.
Зайдем с другой стороны. Поправьте если я не прав. Вы подняли sql сервер на RPi на SD карте, хотя вполне можно было бы использовать SSD, что должно в разы увеличить скорость. Насколько я знаю, наконец-то прикрутили и нормальную загрузку с SSD так что вообще никаких проблем не должно быть. Более того, за 60 у.е. уже вполне можно взять RPi 4 c 4Гб памяти, который легко гонится почти до 2 Ггц. Также возможно скорость поднимется с переходом на новую 64 битную Raspberry OS, хотя тут не очень ясно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.