Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Массовая заливка данных / 17 сообщений из 17, страница 1 из 1
13.03.2016, 13:24
    #39190824
Polesov
Polesov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Привет всем.

Имеются внешние данные (около 40 млн записей), которые надо залить в некую таблицу.
1. Создается талица без каких либо ограничений в виде ключей, индексов, not null.
2. Так же создается полный по структуре эквивалент в виде внешней таблицы.
3. Некой внешней программой создается файл в формате external table, содержащий внешние данные.
4. Запросом вида
Код: plsql
1.
insert into tbl select * from ext_tbl

данные переливаются в целевую талицу.
5. На целевую таблицу накладываюся все требуемые ограничения, создаются индексы:
Код: powershell
1.
2.
3.
   PK по полю типа CHAR(36)
   2 FK каждый по полю типа INTEGER
   2 простых индекса каждый по полю типа CHAR(36)



В данном конкретном случае процесс переноса данных и создания индексов занимает около 18 минут.

Если сначала создать индексы, а затем перенести данные запросом в целевую таблицу,
то процесс занимает существенно больше времени (я прождал около 3-х часов и снял процесс).

Чем обусловлено столь существенное увеличение времени при переносе данных в таблицу с созданными индексам
по сравнению с созданием индексов по таблице с залитыми данными?

С уважением, Polesov.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 13:38
    #39190827
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
PolesovЧем обусловлено столь существенное увеличение времени при переносе данных в
таблицу с созданными индексам по сравнению с созданием индексов по таблице с залитыми
данными?
Тем, что данные надо добавлять и в индексы, что есть нетривиальный процесс, затрагивающий
большое количество страниц.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 13:48
    #39190831
Polesov
Polesov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Dimitry Sibiryakov, но разница более, чем на порядок...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 13:54
    #39190833
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Polesov,

примитивные тесты показывают, что уникальный индекс по int/bigint замедляет вставку в ~3 раза, а индекс по строковому столбцу - в ~7 раз.
Увы, да, физика такая.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 13:55
    #39190835
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Polesovно разница более, чем на порядок...
рекомендую почитать алгоритм добавления ключа в страничный индекс. например, в b-tree filer этот код занимал где-то 3 страницы текста.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 13:58
    #39190837
dimitr
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Polesovразница более, чем на порядок...
между последовательным и случайным I/O - именно так
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:00
    #39190838
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Polesov,

потому что "PK по полю типа CHAR(36)" не есть хорошо для вставки. Если там какой нибудь GUID, то такие индексы практически не сжимаются префиксной компрессией, да и вставка каждой записи модифицирует разные страницы индекса. Был бы на этом месте монотонно возрастающий INTEGER возможно разница была бы не столь существенной.

Был тут как-то топик не совсем про то, но на 3 ей странице есть некоторые ответы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:01
    #39190839
Polesov
Polesov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
kdvпримитивные тесты показывают, что уникальный индекс по int/bigint замедляет вставку в ~3 раза, а индекс по строковому столбцу - в ~7 раз.
Можно ли сказать, что замедление суммируется по каждому из индексов?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:05
    #39190840
Polesov
Polesov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Симонов Дениспотому что "PK по полю типа CHAR(36)" не есть хорошо для вставки. Если там какой нибудь GUID, то такие индексы практически не сжимаются префиксной компрессией
Да, там PK имеет тип GUID, но ничего не поделаешь, т.к. данные внешние и структура уже предопределена.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:06
    #39190841
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
PolesovИмеются внешние данные (около 40 млн записей), которые надо залить в некую таблицу.

Это разовая операция или периодическая?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:11
    #39190843
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
PolesovМожно ли сказать, что замедление суммируется по каждому из индексов?
конечно! более того, для индексов по строковым столбцам замедление вставки нелинейно, т.е. вначале быстро, потом медленее, и после нескольких миллионов записей выравнивается. с индексами по числовым столбцам такого нет, там замедление вставки равномерно-постоянно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:11
    #39190845
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
PolesovМожно ли сказать, что замедление суммируется по каждому из индексов?

Грубо - можно. Но зависимость там далека от линейной.

Polesovтам PK имеет тип GUID
GUID это CHAR(16), не CHAR(36).
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:23
    #39190849
Polesov
Polesov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Симонов ДенисЭто разовая операция или периодическая?
Для конкретного экземпляра БД - разовая, т.к. при появлении обновлений внешних данных БД пересоздается заново.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:26
    #39190850
Polesov
Polesov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Dimitry SibiryakovGUID это CHAR(16), не CHAR(36).
Внешние данные в DBF-файлах - там GUID-ы представлены в текстовом виде.
Речь идет про ФИАС.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:36
    #39190852
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
PolesovВнешние данные в DBF-файлах - там GUID-ы представлены в текстовом виде.

Это как-то мешает использовать UUID_TO_CHAR при импорте?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.03.2016, 14:46
    #39190856
Polesov
Polesov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
Dimitry SibiryakovЭто как-то мешает использовать UUID_TO_CHAR при импорте?..
Такой вариант рассматривался, но никакого ощутимого выигрыша не наблюдалось.
Зато преобразование строковых гуидов ощутимо увеличивает время заливки данных.
БД носит справочный характер и используется в режиме read only.
Более того, при появлении обновлений данных БД пересоздается заново.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
14.03.2016, 16:05
    #39191525
Arioch
Arioch
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Массовая заливка данных
PolesovЕсли сначала создать индексы, а затем перенести данные запросом в целевую таблицу,
то процесс занимает существенно больше времени (я прождал около 3-х часов и снял процесс).

Чем обусловлено столь существенное увеличение времени при переносе данных в таблицу с созданными индексам

верно. временная деактивация индексов - это типовой FAQ при вставке больших данных.

тем, что индекс перестраивается или один раз, или много-много-много раз в процессе.
потому что движок не знаает заранее какая запись будет последней и обязан каждую из них воспринимать как последнюю и подстраивать индекс.

очень грубо говоря - просто для аналогии - попробуйте сравнить два действия

1) создать файл на 4*40МБ и заполнить его int32 числами от 1 до 40М
2) создать файл на 4 байта и записать в него int32 =1. Создать файл на 2*4 байтов, скопировать в него 1*4 байта из первого, удалить первый файл, в конец нового файла записать Int32 =2. Создать файл на 3*4 байтов, скопировать в него 2*4 байта из второго, удалить второй файл, в конец нового файла записать Int32 =3 - и так 40 млн раз
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Массовая заливка данных / 17 сообщений из 17, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 153ms
Закрыть
start [/forum/topic.php?fid=40&tablet=1&tid=1562294]:
 0ms
get settings:
 10ms
get forum list:
 16ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 39ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 2ms
others: 16ms
total:  153ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]