Lord Britisharm, к чему этот боян, пиочитайте вверху. а заливку автору показал не чтобы он ораклю себе ставил, а нашел аналог у себе в мсскл, потому, что те пути что он использовал медленные. привел бы название способа со скоростью заливки ~ копирование файла, автору может полегчало бы.
1) я весь топик перечитал.
2) привел названия по ссылке. могу уточнить - Bulk insert.

Lord Britishреализация кривая
Это всего лишь мнение. Которое может быть как правильным, так и нет. Ведь некривой реализации так и не было приведено.


Lord Britishмы оптимальный пути на неск сотнях гб искали транспортной сети. и ниче никакой инмемори не понадобилось
Так не спорю. Говорю же, критерии скорости поиска не были указаны. Просто по факту обращение ко всем 50 Гб по любому приведет к неоднократному физическому чтению с диска, что само по себе тормоза. Вот если будет понятно, что несмотря на объемы сами запросы простые и юзаются правильные индексы, то этот минус нивелируется.

Lord Britishнагородят реализацию на каждый чих сохраняющую 50гб графа
Я не увидел в обсуждении топика того факта, что все 50 Гб каждый раз скидываются в БД. Это лишь ваши предположения. Или я невнимательный, и упустил констатацию этого факта.

А насчет математики - я по отрывочному текстовому описанию пока не понял, что именно делать в этом графе. Поэтому какая там математика - не представляю.

ViPRos,

Ну так смысл копировать, я ж не вам это отписал, а указал Lord British на аналогичные механизмы в MS SQL

А вам уже вопрос, чтобы понимать: 50 Гб - это постоянно приходящие данные? Ежедневные? Или объем меняющихся данных сильно меньше, а 50 Гб в основном - константные или нечасто обновляемые данные?
В общем, интересует объем изменяемых данных и периодичность этих изменений.


Lord British,
Я в курсе. Но решать, пригоден ли классический СУБД для данной задачи и какая ему нужна для этого структура БД, можно после более подробного описания проблемы и входных/выходных данных

Lord Britishа мне то зачем? я с мсскл не работаю
Именно поэтому :-) Вы сказали, что не работаете, я и привел аналог - для инфо, можно сказать.

Lord Britishближе к истине утилита bcp
Просто для загрузки - да. Но как понял, ему еще и из некой программы на .Net нужен доступ к этим данным. Тогда удобнее своя программная реализация этой загрузки. Например, SqlBulkCopy

Если же это частая загрузка данных просто на сервер, то Bulk Insert через джобы ИМХО интереснее.

ViPRosэти данные генерируются алгоритмом расчета расписания за один проход
За один проход сразу 50 Гб новых данных????????? Э... откуда столько?

ViPRos,

и? ведь 100 000 составных частей и 3 млн техпроцессов не каждый же раз новые?

Lord Britisharm, все массовые заливки, что оперируют предложениями типа 'INSERT....VALUES()' или используют хоть какую-то часть инфраструктуры БД, а не датафайлы напрямую не смогут работать быстрее того, что я привел в примере выше.

предложенные мной варианты не оперируют предложениями типа 'INSERT....VALUES()'


ViPRosну и? да ТП не каждый день меняется
Тогда я еще раз спрошу, какой именно объем МЕНЯЮЩИХСЯ данных за проход генерируется? Ведь можно эти 50 забить в БД, а потом поверх только апдейты накатывать

Lord BritishМожно в тело джоба поместить вызов sqlldr/bcp
Вызов через sqlcmd внешних утилит требует очень хороших прав

Lord Britishиспользовать внешний шедулер
при наличии встроенного - не айс

Lord Britishскорость заливки
Не мерил сам, но уверен, что вполне сопоставима.

Блин, пришел заказ, надо пересчитвывать, изменилиь условия (сломался станок, запил дяд вася, нет денег на оплату, задержался логистический оператор,........... мылен причин пересчета расписания)
а расписание новое = 50 гигов[/quote]

Я наверное чего то не понимаю. Как, как можно из факта слома станка выдать 50 Гб(!!!) изменений?
Скажите, а отложенные вычисления у вас допустимы? Например, нет необходимости высчитывать новое расписание, пока его не запросили? А по первому запросу посчитать и положить в БД.