Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
uaggster Member Откуда: Сообщений: 954 |
... и какие при этом есть подводные камни? По некоторым прикидкам, на некоторых базах, которые сейчас используются в нашей организации, выгружаемые для загрузки в хранилище данные перевалят за 2 Гб в виде хмл. Есть ли какие то подводные камни в выгрузке таких данных? Беглое гугление показало, что все озабочены либо загрузкой таких данных (с этим нет никаких проблем, т.к. всё грузится через xml bulk load), либо сохранением таких файлов в blob полях (чего тоже не предполагается). Речь о выгрузки данных, сформированных запросами типа: select * from vReport for xml raw и экспортом их через bcp: bcp "EXEC [dbo].[GET_FIN_PLAN]" queryout "C:\tmp\plan.xml" -S SERVERNAME -U USERNAME -P PASSWORD -w -r (соответственно, в хранимке запрос, типа того, который показан выше, возможно более сложный, но бывает и такой, с учетом того, что vReport - сильнонавороченная view). Либо экспорт производится через самодельное c# приложение, но которое тоже вызывает EXEC [dbo].[GET_что-то-там], возвращающее единственное поле с хмлем. Мне кажется, что всё должно посыпаться. Пожалуйста, кто с таким сталкивался, подскажите, какие затыки ждут? |
9 янв 18, 16:28 [21090717] Ответить | Цитировать Сообщить модератору |
WarAnt Member Откуда: Питер Сообщений: 2423 |
uaggster, а что мешает попробовать? есть сомнения что через xml raw можно вытащить больше 2 гигов, как альтернативный вариант можно попробовать старый добрый EXPLICIT |
9 янв 18, 16:36 [21090759] Ответить | Цитировать Сообщить модератору |
Amiri Member Откуда: Pakistan Сообщений: 721 |
можно, но не более. |
9 янв 18, 16:43 [21090797] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
|
||
9 янв 18, 17:08 [21090963] Ответить | Цитировать Сообщить модератору |
Сон Веры Павловны Member Откуда: Сообщений: 6118 |
Я сталкивался. Ждут вот такие затыки:
И тут не помогут ни самописные скрипты, ни SSIS-пакеты, ни внешние программы, т.к. все они будут пытаться получить xml одним куском. Выход - только bcp, т.к. он выгружает порциями. |
||
9 янв 18, 17:10 [21090974] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
Т.е. собственно "bulk"-операции определены как класс только для вставки данных. |
||
9 янв 18, 17:56 [21091171] Ответить | Цитировать Сообщить модератору |
Руслан Дамирович Member Откуда: Резиновая нерезиновая Сообщений: 940 |
Я такое через SSIS делаю Создаем подключение к SQL Создаем подключение к XML - plain-file добавляем колонку xml типа поток текста в юникоде DT_NTEXT 1. Задача потока данных Head Источник - SQL: SELECT [xml] = CONVERT( XML, NULL ) Назначение - XML: метка перезаписать данные заголовок: <root> 2. Задача потока данных Body Источник - SQL: SELECT [xml] = ... FROM ... Назначение - XML: привязать xml <-> xml 3. Задача потока данных Tail Источник - SQL: SELECT [xml] = CONVERT( XML, NULL ) Назначение - XML: заголовок: </root> Запускаем, радуемся жизни, если сможем открыть файл размером более 2Гб. |
9 янв 18, 18:07 [21091200] Ответить | Цитировать Сообщить модератору |
WarAnt Member Откуда: Питер Сообщений: 2423 |
вот потому и сомнения что это возможно, а как раз explicit такой проблемой не обладает, так как выгружает поток в виде строк по 2 кб длиной |
||||
9 янв 18, 19:57 [21091397] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
Но тогда такое поле > 2ГБ можно и из клиента получить? Обычный клиент ведь использует (может использовать) те же методы, что и bcp или SSIS?
|
||||||
9 янв 18, 20:23 [21091436] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9634 |
|
||
9 янв 18, 21:46 [21091648] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 954 |
Коллеги, спасибо. Сейчас попробую на тесте, отпишусь. Кстати, попутный вопрос: в filetable тоже не получится сохранить файл, размером более 2 Гб? |
10 янв 18, 09:19 [21092205] Ответить | Цитировать Сообщить модератору |
LSV Member [заблокирован] Откуда: Киев Сообщений: 30817 |
А чем не подошел CSV ??? Он намного быстрее и компактнее. Зачем эти монстры, состоящие на 50-70% из тегов ? |
10 янв 18, 10:32 [21092511] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 954 |
Там одним xml-ем выгружается весь набор данных, который, для некоторых систем включает по десятку таблиц, а то и больше. С производительностью именно загрузки там особых проблем нет. Через SQLXMLBulkLoad всё вполне себе резво грузится. Схема, в общем, такая: Рабочие системы выгружают данные в хмли, или целиком, или инкрементально, потом их, соответствующий каждому виду данных модуль - грузит в промежуточную базу, а оттуда - апдейтится хранилище. Разработчики уверяют, что так удобнее поддерживать и вносить изменения. |
||
10 янв 18, 10:51 [21092566] Ответить | Цитировать Сообщить модератору |
Руслан Дамирович Member Откуда: Резиновая нерезиновая Сообщений: 940 |
XML и прочие обертки толерантны к содержимому за счет сочетаний <tag></tag>. Хотя спорное утверждение. Но я согласен с вами - XML при таких объемах информации не самый лучший вариант. |
||
10 янв 18, 11:30 [21092762] Ответить | Цитировать Сообщить модератору |
LSV Member [заблокирован] Откуда: Киев Сообщений: 30817 |
|
||
10 янв 18, 12:01 [21092900] Ответить | Цитировать Сообщить модератору |
Руслан Дамирович Member Откуда: Резиновая нерезиновая Сообщений: 940 |
Возникает вопрос, а зачем нужно промежуточное звено в виде XML? - грузите сразу в промежуточную базу. Хотя, если
То вас уже ничто не спасет... выражаю вам свое искреннее сочувствие. |
||||
10 янв 18, 12:05 [21092914] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 954 |
Потому что часть систем - унаследованно, и разработчиков у них нет. Как сговнякано, так и живет. Временами некие привлеченные специалисты меняют набор выгружаемых данных, просто правя запрос, который формирует данные в хмл, и всё. |
||||
10 янв 18, 13:03 [21093098] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 954 |
Я, возможно, неправильно выразился. Исходные системы - они разнородные, от разных разработчиков, вплоть до того, что в разных филиалах софт, выполняющий разные задачи - разный, причем в части филиалов - даже разработчики умерли (и, к сожалению - это не фигура речи). Планово со скрипом заменяется и т.д. А вот целевая система, где, с некоторыми потерями агрегируются данные - она одна. У них разработчики - совершенно конкретные, и у них проблем нету. Они любые файлы могут загрузить, лишь бы ФЛК проходило. Хоть 100 Гб, хоть 200. Совсем никаких проблем. |
||||||
10 янв 18, 13:08 [21093112] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31782 |
XML - вполне нормальный стандарт, всеми понимаемый, можно определить формат данных, документов, транзакций и т.п. Чем лучше, если бы сказали - вот вам "промежуточная база" в постгрессе, лейте туда. А для ещё одной системы нужно выгружать то же самое в промежуточную базу на оракле. И структуры там меняются. А с XML каждый выгружает в стабильно определённый XML, и пусть делают с ним всё что хотят. Понятно, что рецепт не универсальный, но вполне рабочий. Мы вот раньше получали данные из Oracle, Sybase и CSV нескольких форматов, из систем разных вендоров. А потом постепенно перешли на импорт из формата XML, в определённом отраслевом формате, который, само собой, все эти вендоры поддерживают, и стало намного легче. И да, файлы бывают большие, но нам всё равно, мы загружаем, а не выгружаем :-) |
||||||
10 янв 18, 13:45 [21093258] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |