ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Массовая заливка данных
17 сообщений из 17, страница 1 из 1
Массовая заливка данных
    #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:24
| Ответить | Цитировать | Написать  
Массовая заливка данных
    #39190827
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
PolesovЧем обусловлено столь существенное увеличение времени при переносе данных в
таблицу с созданными индексам по сравнению с созданием индексов по таблице с залитыми
данными?
Тем, что данные надо добавлять и в индексы, что есть нетривиальный процесс, затрагивающий
большое количество страниц.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
13.03.2016, 13:38
| Ответить | Цитировать | Написать  
Массовая заливка данных
    #39190831
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Polesov
Участник
Dimitry Sibiryakov, но разница более, чем на порядок...
...
Рейтинг: 0 / 0
13.03.2016, 13:48
| Ответить | Цитировать | Написать  
Массовая заливка данных
    #39190833
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Polesov,

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

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

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

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

Это как-то мешает использовать UUID_TO_CHAR при импорте?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
13.03.2016, 14:36
| Ответить | Цитировать | Написать  
Массовая заливка данных
    #39190856
Polesov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Polesov
Участник
Dimitry SibiryakovЭто как-то мешает использовать UUID_TO_CHAR при импорте?..
Такой вариант рассматривался, но никакого ощутимого выигрыша не наблюдалось.
Зато преобразование строковых гуидов ощутимо увеличивает время заливки данных.
БД носит справочный характер и используется в режиме read only.
Более того, при появлении обновлений данных БД пересоздается заново.
...
Рейтинг: 0 / 0
13.03.2016, 14:46
| Ответить | Цитировать | Написать  
Массовая заливка данных
    #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
14.03.2016, 16:05
| Ответить | Цитировать | Написать  
17 сообщений из 17, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Массовая заливка данных
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39190827&tid=1562294]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 61ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 59ms
get tp. blocked users:
 2ms
others: 10ms
total:  177ms
созд. / загр.: 177ms
x
x
Закрыть


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