Комментарии 17
… машина Exadata Х5 (один юнит) корпорации Оракл… примерно 17 тысячам записей исходных данных в секунду
это крайне медленно, должно быть на порядок быстрее, возможно код у Вас где-то не так написан
Сейчас попробовал на коленке загрузить. На моём стареньком компе на HDD, файл 0.3Гб, 7млн строк, залетают в MySQL за ~137сек, т.е. около 50к строк в секунду
При написании SQL ориентируюсь на скорость 100K в секунду для одного запроса вставки в таблицу. Эксперимент описывает интеграцию данных. Из исходных данных загружаются измерения и агрегаты.
Общее время, необходимое для интеграции делится на количество исходных записей.
Метод загрузки файла выбран не самый быстрый, его можно оптимировать, но в 2 раза, а не на порядок.
Но и метод с PHP не самый быстрый, поэтому этот шаг можно считать эквивалентным.
Общее время, необходимое для интеграции делится на количество исходных записей.
Метод загрузки файла выбран не самый быстрый, его можно оптимировать, но в 2 раза, а не на порядок.
Но и метод с PHP не самый быстрый, поэтому этот шаг можно считать эквивалентным.
загрузку файла можно оптимизировать на порядок, а то и на 2, PHP вообще не должен трогать и читать файл, только отправлять SQL запросы. Далее второй пункт «Обработка и очистка данных — 2 SQL запроса и 130 минут.» тож больно долго, какие-то видимо сильно не оптимальные запросы, от этого пункта можно вообще избавиться и всё реализовать одной загрузкой. А какая БД у вас на Экзадате? Оракл?
Oracle Database 18c. Ваши замечания и вопросы верные и логичные.
Для описания причин нужно писать статью, но такие плохо читаются и сильно минусуются энтерпрайзом, пот. быстро уходят в сторону «эффективных менеджеров» (уже поробовал и удалил про конфликт интересов).
Один аспект. Все операции тем эффективные, чем ближе к железу.
Например, метод внешних таблиц в Оракле будет очень быстрым.
Но нужно иметь расширенные права к диску и окружению. Часто даже к ОС, тут сложно становится с гарантийным обслуживанием.
Администратор БД, чел. по безопасности и аналитик будут испытывать конфликт интересов (одни не занимаются содержимым, другие могут что-нибудь сломать).
Но есть другой способ — sqlloader, гибкий и не сильно быстрый. Можно быстро, но должно лежать рядом с базой и тут снова конфликт.
Оптимизация и распределение знаний в проекте тоже являются причиной конфликта интересов. Тот, кто с паролем и всё может, будет концентрировать знания вокруг себя, что приведёт к проблеме в случае его отсутствия.
Быстро загрузить — не всегда эффективно.
Поэтому во втором случае PHP для файла, чтобы сохранить баланс :)
Для описания причин нужно писать статью, но такие плохо читаются и сильно минусуются энтерпрайзом, пот. быстро уходят в сторону «эффективных менеджеров» (уже поробовал и удалил про конфликт интересов).
Один аспект. Все операции тем эффективные, чем ближе к железу.
Например, метод внешних таблиц в Оракле будет очень быстрым.
Но нужно иметь расширенные права к диску и окружению. Часто даже к ОС, тут сложно становится с гарантийным обслуживанием.
Администратор БД, чел. по безопасности и аналитик будут испытывать конфликт интересов (одни не занимаются содержимым, другие могут что-нибудь сломать).
Но есть другой способ — 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Тб
Если у вас организационно-бюрократические проблемы в организации, то в технической статье глупо писать что 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 до готового отчёта?
Какой отчёт? Из каких данных? Вопрос не совсем корректный. Я в своё время (~год назад) через EXTERNAL TABLE + INSERT APPEND делал загрузку телеметрических данных с GPS датчиков, около 15к в онлайне, данные обновлялись каждую секунду со сложной бизнес логикой с
денормализованными данными о скоростных режимах, расходах топлива, превышений и т.д.
Ваша задача:
— access.log загрузка 350млн записей 10Гб данных
— ELT преобразование
— агрегированный отчёт
мои предварительные оценки:
— пара-тройка дней на разработку (чисто SQL запросы)
— день на простенький вывод отчёта html
— ориентировочная финальная производительность на более менее нормальном железе ~ 15-60 мин на генерацию
Не буду спорить, но я бы сделал так:
1. sqlloader с опцией direct в оракловскую таблицу без всяких индексов, всё в одну транзакцию — это будет очень быстро, мы максимально быстро загнали данные из файла в БД с огромными кэшами и улучшенной возможностью применения бизнес логики.
2. insert /*+ APPEND */ select * из временной оракловской таблицы в другую оракловскую таблицу (пустую или не очень), в которой уже есть индексы и всё прочее. Можно даже в таблицу с партициями, тогда можно будет доступ к данным еще подтюнить.
3. Если фильтрация не очень сложная — то на правильно индексированной таблице вы довольно быстро почистите данные от шелухи.
Везде должно быть быстро. У меня в одном проекте еще был шаг 0 — perl'овый скрипт делал первоначальную очистку файлов от шелухи. Вот уж кого нельзя обвинить в медленности дисковых операций.
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. Она действительно быстра, спору нет.
Идея была описать время всего цикла интеграции относительно количества исходных данных.
На это время влияют факторы:
— дедубликация, очистка данных, форматы (используются условия, строковые функции, преобразования)
— вызов функций из другого пакета
— подключение других таблиц для формирования ссылки
— загрузка исторических таблиц
Было бы интересно узнать примеры из других проектов. Сколько времени требуется до готовности отчётов.
В Exadata всё включено, диски SSD, всё параллельно, нагрузка равномерно распределена, таблицы с партициями, с большой компрессией, статистика собрана, пакеты скомпилированы для выполнения нативно и параллельно.
Но это ведь не один SQL Select Insert и не измерение скорости Exadata. Она действительно быстра, спору нет.
Идея была описать время всего цикла интеграции относительно количества исходных данных.
На это время влияют факторы:
— дедубликация, очистка данных, форматы (используются условия, строковые функции, преобразования)
— вызов функций из другого пакета
— подключение других таблиц для формирования ссылки
— загрузка исторических таблиц
Было бы интересно узнать примеры из других проектов. Сколько времени требуется до готовности отчётов.
Если у вас такая обработка что легко параллелится то для неё не нужен SQL и производительность обоих машин будет гораздо выше при рациональном программировании задачи. Однако если обработка выполняется средствами SQL то никакой sqlite или oracle вам не поможет равномерно разнести нагрузку на 1000 машин, и все теоретические выкладки о производительности идут ко дну.
НЛО прилетело и опубликовало эту надпись здесь
Благодаря комментариям обнаружил, что какой-то жук задеплоил очень старый файл конфигурации для загрузки файла и уже давно. Поправлю и измерю ещё раз время.
Зайдем с другой стороны. Поправьте если я не прав. Вы подняли sql сервер на RPi на SD карте, хотя вполне можно было бы использовать SSD, что должно в разы увеличить скорость. Насколько я знаю, наконец-то прикрутили и нормальную загрузку с SSD так что вообще никаких проблем не должно быть. Более того, за 60 у.е. уже вполне можно взять RPi 4 c 4Гб памяти, который легко гонится почти до 2 Ггц. Также возможно скорость поднимется с переходом на новую 64 битную Raspberry OS, хотя тут не очень ясно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сколько данных может обработать Raspberry Pi быстро