Сейчас в базу на Oracle загрузка данных из csv файла, содержащего 106 млн записей с помощью утилиты sqlldr. Длительность загрузки составляет примерно 6-ть часов.

Вопрос - можно ли на С# написать код, который будет загружать данные если не быстрее, то хотя бы с такой же скоростью? Или, это фантастика?



Исправлено 1 раз(а). Последнее : S-type, 20.03.17 15:31

"С такой же скоростью" - наверное можно попробовать. Быстрее - сомнительно.
При том для начала неплохо было бы разобраться и с собственно начальным "импортом". У sqlldr куча разных опций и настроек, плюс к тому есть 2 основных режима загрузки - Conventional и Direct Path - различающихся кардинально. Вполне возможно что и загрузку при помощи этой утилиты можно ускорить в разы...

Для реализации последнего в C# клиенте придётся использовать ODP.NET unmanaged client (в "управляемом" клиенте это пока что не реализовано) и его класс OracleBulkCopy... Со всеми нюансами и особенностями "прямой загрузки" следует не спеша, вдумчиво ознакомится в мануале, а то можно будет наломать дров...

Есть такой общедоступный файл в РФ, "недействительные паспорта", как раза на 100млн записей, вот такой структуры:
PASSP_SERIES,PASSP_NUMBER
2602,075607
2406,286255
...
Фоксом принимается в DBF час-два примерно

Igor Korolyov
Для реализации последнего в C# клиенте придётся использовать ODP.NET unmanaged client (в "управляемом" клиенте это пока что не реализовано) и его класс OracleBulkCopy...

Полный список различий docs.oracle.com Действительно, не поддерживает.

of63
Есть такой общедоступный файл в РФ, "недействительные паспорта",

Дык, собственно, о нём, родимом, и речь. Сопровожденцы АБС решили загрузку этого файла в АБС "скинуть" на бизнес (мол, не царское дело). Бизнес то же не горит этим заниматься, и моментально задачу создал "автоматизируйте, мол, загрузку". А поскольку я периодически разные "скачай и загрузи" пишу, задачу на меня и переключили. Предложил сопровожденцам написать bat-файл, который с помощью wget скачает, 7-zip распакует, sqlldr загрузит, blat - логи админу отошлёт. А, этот bat-файл повесить в планировщике, что бы работал раз в неделю (в воскресенье вечером). Но, самому интересно стало. Как загрузить - это понятно (WebClient), распаковать (nuGet\SharpZipLib), а вот загрузить - тут вопрос и возник

of63
Фоксом принимается в DBF час-два примерно

Всего час-два? Наверное, очень прогрессивный это инструмент - Фокс



Исправлено 1 раз(а). Последнее : S-type, 20.03.17 21:13

Точно. Давай обратно, к нам на фокс

Исходный файл 1Г примерно. Я его в такой DBF принимаю:
серия - это 4 цифры N(4)... правда нескоько тыс записей в этом CSV испорчены, там вместо цифр символы нечитаемые, брак т.е....
номера - мемо-поле длиной 10^6 бит, для запоминания чисел длиной до 6 знаков, (это около 100 КБайт), ставлю бит в позиции недействительного паспорта. Получается ок. 350 МБайт. В 3 раза т.е. "ужалась" инфа, и в тоже время фоксом можно безболезненно пользоваться, всякими BITTEST() Доб. - "ужимание" происходит и из-за незаполненности (отсутствия) некоторых серий паспортов.



Исправлено 2 раз(а). Последнее : of63, 20.03.17 21:36

S-type
Наверное, очень прогрессивный это инструмент - Фокс

Сразу вспоминается концовка анекдота:

Цитата:

Негоже мне, купцу первой гильдии, в п.... стеснение иметь

of63
Точно. Давай обратно, к нам на фокс

Как это не прискорбно, но надо постепенно забывать о VFP и двигаться дальше. Вот только куда? Иногда грызёт червь сомнения, что надо было в сторону Java копать...

Simple777

S-type
Наверное, очень прогрессивный это инструмент - Фокс

Сразу вспоминается концовка анекдота:

Цитата:

Негоже мне, купцу первой гильдии, в п.... стеснение иметь

Анекдот про "узкую щёлочку" помню. Но, аналогии как то не улавливаю...

На яве ребеночек играет, в майнкрафт, игра вроде не видеонагруженная, но жрет процессорное время, все ядра, под 100 проц. Зверь вобщем эта ява. А делает на копейки...

S-type

Simple777

S-type
Наверное, очень прогрессивный это инструмент - Фокс

Сразу вспоминается концовка анекдота:

Цитата:

Негоже мне, купцу первой гильдии, в п.... стеснение иметь

Анекдот про "узкую щёлочку" помню. Но, аналогии как то не улавливаю...

Анекдот, кстати, хороший.

Аналогия тут вот какая. Ежели действительно, есть инструмент, который несмотря на свою устарелость отрабатывает массив в 3 быстрее, то какие могут быть "священные коровы"? Какая разница, если "щёлочка в 3 раза уже"?

Если про скорость на FoxPro правда, то можно даже автономный exe в FPD сделать - пусть себе качает 2 часа.

Топик не про фокс конечно. М.б. сетевые проблемы, одно дело 1Гб прокачать по 100 Мбитной сети (10МБайт/с, 2 мин перекачки), другое дело, если каждая строка из 100 млн записей - это INSERT в методике подгрузчика. Тут же куча мастеров, на форуме, по подгрузке XML-ей, может в нем - "скорость"

Доб. А в SQL-технологии нельзя сначала файл CSV положить на SQL-сервер, а уж там дать команду "вот из этого CSV-файла положить в таблицу" ?



Исправлено 1 раз(а). Последнее : of63, 20.03.17 21:34

Simple777
Аналогия тут вот какая. Ежели действительно, есть инструмент, который несмотря на свою устарелость отрабатывает массив в 3 быстрее, то какие могут быть "священные коровы"? Какая разница, если "щёлочка в 3 раза уже"?

Как сказал Igor Korolyov - возможно, Sqlldr настроен неоптимально, и его можно "подвинуть". Опять таки, VFP наверняка всё делал локально. Конечно, можно 1,2 ГБ сначала на сервер перенести - но, это ведь то же время Хотя, по сравнению со временем "заливки" в базу - это копейки.



Исправлено 1 раз(а). Последнее : S-type, 20.03.17 21:40

Перенести 1.2 Гб на сервер - это уже другая задача. Вероятно, эти задачи как раз лучше и разделить. мтк (C) (Оффа)

of63
Доб. А в SQL-технологии нельзя сначала файл CSV положить на SQL-сервер, а уж там дать команду "вот из этого CSV-файла положить в таблицу" ?

На самом деле, у меня не стоит задачи настроить Sqlldr на оптимальную работу - есть отдел, сопровождающий АБС, есть отдел, сопровождающий СУБД - пусть у них головы по этому и болят, а я из другого отдела А вот как заставить программу на C# работать максимально быстро - это очень интересует.

> VFP наверняка всё делал локально
Конечно, причем, чтобы быстро получалось ставить битики в полях, использована ф-ия SYS(2600) - прямой доступ к памяти, через API лочил память, и в ее биты писал, иначе BITSET-ами тоже было полсуток.

>А вот как заставить программу на C# работать максимально быстро - это очень интересует.
это же Си, он сделает это также быстро, за час и быстрее. Проблема в записи полученного в SQL-таблицу, вероятно. Надо писать не каждую запись из 100млн, а пачками. Вот у меня пишется "сериями", серий всего - 3 тыс. по 100кбайт ((т.е. по 10^6 битов)... И то, после того, как я собрал эти биты в памяти локальной машины (т.е. по окончании перебора всех 100 млн записей нарисовались 3 тыс. 100кБайтных строк)



Исправлено 3 раз(а). Последнее : of63, 20.03.17 21:50

Не, ну если вопрос "чиста в скорости", то надо просто выкинуть СУБД как таковую Естественно фокс (exclusive открытая локальная таблица) быстрее обработает кучу вставок, чем оракл - сеть (хотя её можно откинуть если пускать прогу прямо на сервере), 10 слоёв вызовов всяких "внутренних функций" для обеспечения согласованности и непротиворечивости, изоляции транзакций, восстановления в случае сбоя и т.д. и т.п. Кое что позволяет "обойти" тот самый режим direct-path write. Если таблица всегда переписывается целиком "с нуля", это вполне подойдёт...

На C# же можно сделать бинарный файл - например по тому же самому принципу 100К битового поля + 4 байта на "номер серии" и всё - он то с памятью пошустрее будет работать нежели фокс даже через SYS(2600) - опять же если ПОНИМАТЬ что и как делаешь
(забавно, фокс примерно такие "битовые карты" и строит из b-tree индексов для работы рашмор-оптимизации - ну он то сам на си писан - там "накладных расходов" на операции с памятью практически нет).

Вообще можно и в оракле такую же структуру сварганить - запись с "серией" и блобом для хранения битовой карты. Только вот работать с сим чудом придётся скорее всего на клиенте, либо же использовать мозговыворачивающие ХП писанные к тому же на java ("напрямую" проверить n-й бит blob поля оракл не сможет) - т.к. постоянное чтение этих 100Кб кусков для bittest-инга очень уж неспецифичная для СУБД задача...

Кстати, если уж тащить на клиента, то можно подумать и над вариантом с "упаковкой" подобного блоба - чтобы хранить не фиксированные 100К на запись, а в упакованном виде - выйдет где 50К а где и всего 1-2К на запись Надо только поискать наиболее оптимальный алгоритм для упаковки "битовой карты" фиксированного размера.
Всё ж "физика" чтения (плюс ещё и передачи по сети) на сегодня немного тяжелее чем "логика" разворачивания в памяти...

Игорь, истины ради
>забавно, фокс примерно такие "битовые карты" и строит из b-tree индексов для работы рашмор-оптимизации - ну он то сам на си писан
битовую карту я строил сам, как массив Q-строк, ПОСЛЕ приема всех 100 млн строк (бит), записал это в DBF, собственно как серия и мемо поле при нем... Все происходило в памяти. Я поэтому и посоветовал ТС перекачать файл на сервер. Ну уж на сервере (как на локальной машине, вы на T-SQL/Си всех перебьете, шутка)

(Доб, 1Г размер большой, может физика процесса ОС не сработать)



Исправлено 1 раз(а). Последнее : of63, 21.03.17 00:24

S-type
Сейчас в базу на Oracle загрузка данных из csv файла, содержащего 106 млн записей с помощью утилиты sqlldr. Длительность загрузки составляет примерно 6-ть часов.
Вопрос - можно ли на С# написать код, который будет загружать данные если не быстрее, то хотя бы с такой же скоростью? Или, это фантастика?

Просто ради интереса, загрузка sqlldr с машины клиента идет или все перекинуто на сервер оракла и там запускается sqlldr ?