Есть ряд проблем, с которыми вы столкнетесь. Вероятно, самое большое, что все разные СУБД имеют разные предпочтительные форматы загрузки - поэтому любой отдельный формат данных потребует некоторой гимнастики для одной или нескольких СУБД - если вы не сгенерируете операторы INSERT напрямую.
Informix предпочитает формат, который можно свободно охарактеризовать как «поля с разделителями с обратной косой чертой, используемой в качестве escape и (неэкранированной) новой строки, указывающей конец записи». Разделителем по умолчанию является символ канала '|', но его можно изменить в соответствии с требованиями. Например:
100|Some string|2008-09-12|23.145|wc -l \| sort -n|76:34:45.219
К счастью, форматы даты достаточно гибкие. Если вам нужны ужасные подробности, загрузите исходный код SQLCMD (а не Microsoft usurper - оригинальный) из архива исходного кода IIUG и прочитайте файл unload.format. Загрузка данных CSV не является тривиальным упражнением в Informix - хотя у меня есть скрипт Perl с именем csv2unl, который в значительной степени автоматизирует преобразование из формата CSV в формат Informix UNLOAD (также должен быть доступен на веб-сайте IIUG).
Как предположил @ St3fan, для генерации данных можно использовать любой из основных языков сценариев. Я бы использовал Perl, но это в основном потому, что я выучил Perl очень давно, и поэтому чувствую себя наиболее комфортно с ним.
Другая проблема, на которую следует обратить внимание, заключается в том, генерируете ли вы данные для одной таблицы (или набора несвязанных таблиц) или для набора связанных таблиц. Например, сравнительно легко сгенерировать данные для одной таблицы; гораздо сложнее сгенерировать данные для двух таблиц, имеющих общее поле (например, таблица Orders и таблица OrderItems).
Несмотря на это, 2 ТБ - задача умеренно сложная. Даже если каждая строка составляет 1 КБ, вам потребуется сгенерировать около 2 миллиардов строк данных. Вам нужно будет загружать данные порциями - не все за одну транзакцию. Вы, вероятно, захотите создать индексы после загрузки, но это возлагает на вас ответственность за то, чтобы данные в таблицах были действительными (без ненужных дубликатов). Если вы используете столбец SERIAL (Informix-говорят для автоматически сгенерированного значения), вам, вероятно, потребуется использовать BIGSERIAL (или, возможно, SERIAL8 - это зависит от используемой версии Informix, но это должен быть IDS 11.50, в этом случае BIGSERIAL - лучший выбор).
@ dotIN спрашивает о времени ... как долго загружаться?
Давайте рассмотрим некоторые основные принципы ... какова приличная скорость записи для записи на диск? 100 МБ / с выдержали? Давайте использовать его в качестве отправной точки.
При 100 МБ / с записи данных потребуется:
2,000,000 MB / 100 MB/s = 20,000 s
что составляет примерно 6 часов.
Я думаю, что это очень высокий показатель; кроме того, вы должны передавать данные в СУБД (поэтому вы должны иметь операторы, выполняемые со скоростью, соответствующей 100 МБ / с), плюс вам нужно беспокоиться о регистрации действий в базе данных, и так далее, и так далее. Если нагрузка может быть эффективно распределена по нескольким дискам, вы сможете приблизиться к этому. Однако привязка к вводу / выводу очень проста, особенно если на вашей машине нет нескольких отдельно адресуемых дисков (например, один многотерабайтный RAID-накопитель с одним каналом ввода-вывода).
Если каждая строка загружается с помощью отдельного оператора INSERT, вам придется выполнять огромное количество операторов в секунду. Это еще один ингибитор производительности. Вы не указали точно, как вы выполняете загрузку, но при обработке больших объемов вы должны быть предельно осторожны, и для достижения максимальной производительности любой из СУБД требуются навыки и опыт - не говоря уже о всех из них. , И обратите внимание, что конфигурации, которые ускоряют производительность загрузки терабайтов данных, не обязательно приводят к хорошей производительности, когда вы больше не стремитесь к загрузке, а извлекаете информацию.
И есть упоминания о каплях; они имеют особые ограничения и требуют бережного отношения к каждой системе и обычно усложняют историю. (Например, в IDS вам понадобится отдельное Smart BlobSpace для интеллектуальных больших двоичных объектов - типов BLOB или CLOB - из DBSpace, где вы храните данные. Если вы используете устаревшие BLTE или TEXT большие двоичные объекты, вы, вероятно, захотите использовать Соответствующее BlobSpace - в отличие от Smart BlobSpace - с размером страницы, настроенным в соответствии с данными, которые вы храните. Возможно, вы не хотите хранить BLTE BYTE или TEXT BLOB-объектов в TABLE - это работает, но оно забивает систему ведения журнала Именно поэтому BlobSpaces доступны в качестве опции.)