|
Миграция Оракл - PostgreSQL терабайт в час?
#613824
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
|
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
А ведь пролучилось ) Мигрировали в итоге 2.4Тб за 11 часов. В пике был терабайт в час. Прикол в том что в процессе миграции падал Оракл на 5 часов (Ораклисты решили во время миграции поменять память, это просто писец...), но долили) . Задача была мигрировать хотя бы за 60 часов. Вендор не мог мигрировать за 3 недели. Что за рукожопы пошли?... Стоимость одной такой миграции - несколько десятков миллионов рублей. ... |
||||||||||||||||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
|
||||||||||||||||
16.11.2023, 00:49 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
У меня этот уже третья миграция. В которой я все планировал. Появился новый термин - виртуальные секции. Он нужен для очень быстрого извлечения батчей из оракла. Переносили в 64 потока. ... |
|||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
Нравится:
Не нравится:
|
|||
16.11.2023, 00:54 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
А чем мигрировали? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2023, 01:13 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
А чем мигрировали? Об этом у меня как раз был доклад на pg conf 2023 spb Но там было мало времени. Обо всех нюансах не расскажешь. ... |
|
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
|
|
16.11.2023, 01:20 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
Популярное средство. В магните часто юзали для миграции с Оракла. ... |
|||
коротко о себе по версии дедофорумчан:
либераст, хохол, жыд, ЗОЖовец-наркоман на антидепрессантах, сталинист, протохохол, желающий поменять родных православных коррупционеров на иноземных.. :
Нравится:
Не нравится:
|
|||
16.11.2023, 09:22 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
А куда мигрируют ораклисты.. к хуям, в Германии, Америки? ... |
|
:
|
|
16.11.2023, 09:25 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
А куда мигрируют ораклисты.. к хуям, в Германии, Америки? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2023, 09:30 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
Ораклисты мигрируют в Казахстан ... |
|
:
|
|
16.11.2023, 10:27 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
А куда мигрируют ораклисты.. к хуям, в Германии, Америки? Оракл видимо будет такой вечный динозавр как Cobol ) И грохнуть нельзя, и что с ним делать непонятно. ... |
|||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
Изменено: 16.11.2023, 10:55 - Тень на плетень
Нравится:
Не нравится:
|
|||
16.11.2023, 10:51 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
Ораклисты мигрируют в Казахстан ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2023, 11:52 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
через подключаемые таблицы получается? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2023, 12:08 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
Нет. Фодка в моем топике по СПБ ... |
|
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
|
|
16.11.2023, 17:00 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес. И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно 1. Отключить индексы и триггеры 2. Заливать так: insert into pg.table_1 select * ora.table on conflict do nothing; Концовка очень важна, иначе будут возникать блокировки. И так хреначим в 55 потоков. Большие таблицы дробятся на виртуальные секции по 10 млн записей. Но не по тупому через limit offset(так в итоге все станет колом из за full scan на стороне Оракла), а через диапазоны по первичным ключам. Так используются индексы первичного ключа и выборка конкретной секции происходит гораздо быстрее. То есть нулевая секция от 0 до 10 млн, первая от 10 млн до 20 млн и далее. Для 4.5 миллиардов записей получается 450 виртуальных секций в диапазонах по 10 млн по первичному ключу. Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее. ... |
|
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
|
|
16.11.2023, 17:06 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
Нам для миграции это не важно. Все равно берём данные относительно небольшими батчами. То что распределение неравномерное - это наоборот хорошо. Получается самобалансировка потоков. Если все 55 потоков будут стартовать и завершаться одновременно - то и коммитится будут толпой. Это напрягает чекпоинтер. А вот неравномерность в итоге приводит к балансировке. Обычно на 2 - 3 итерации потоки вполне отлично самобалансируются. ... |
|
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
|
|
16.11.2023, 17:28 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
А ведь пролучилось ) Мигрировали в итоге 2.4Тб за 11 часов. В пике был терабайт в час. Прикол в том что в процессе миграции падал Оракл на 5 часов (Ораклисты решили во время миграции поменять память, это просто писец...), но долили) . Задача была мигрировать хотя бы за 60 часов. Вендор не мог мигрировать за 3 недели. Что за рукожопы пошли?... Стоимость одной такой миграции - несколько десятков миллионов рублей. ... |
|||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
Нравится:
Не нравится:
|
|||
16.11.2023, 18:08 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес. И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно 1. Отключить индексы и триггеры 2. Заливать так: insert into pg.table_1 select * ora.table on conflict do nothing; Концовка очень важна, иначе будут возникать блокировки. И так хреначим в 55 потоков. Большие таблицы дробятся на виртуальные секции по 10 млн записей. Но не по тупому через limit offset(так в итоге все станет колом из за full scan на стороне Оракла), а через диапазоны по первичным ключам. Так используются индексы первичного ключа и выборка конкретной секции происходит гораздо быстрее. То есть нулевая секция от 0 до 10 млн, первая от 10 млн до 20 млн и далее. Для 4.5 миллиардов записей получается 450 виртуальных секций в диапазонах по 10 млн по первичному ключу. Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее. Он конфликт ду нафинг - это же опасненько. Типа не консистентно как-то. Общая идея - останавливаем все. Максимально быстро мигрируемся. Переключаемся на Постгрес... PROFIT. ... |
|
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
|
|
16.11.2023, 18:10 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
... И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно 1. Отключить индексы и триггеры 2. Заливать так: insert into pg.table_1 select * ora.table on conflict do nothing; Концовка очень важна, иначе будут возникать блокировки. И так хреначим в 55 потоков. Большие таблицы дробятся на виртуальные секции по 10 млн записей. Но не по тупому через limit offset(так в итоге все станет колом из за full scan на стороне Оракла), а через диапазоны по первичным ключам. Так используются индексы первичного ключа и выборка конкретной секции происходит гораздо быстрее. То есть нулевая секция от 0 до 10 млн, первая от 10 млн до 20 млн и далее. Для 4.5 миллиардов записей получается 450 виртуальных секций в диапазонах по 10 млн по первичному ключу. Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее. Он конфликт ду нафинг - это же опасненько. Типа не консистентно как-то. Общая идея - останавливаем все. Максимально быстро мигрируемся. Переключаемся на Постгрес. ... |
|||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
Изменено: 16.11.2023, 18:15 - Тень на плетень
Нравится:
Не нравится:
|
|||
16.11.2023, 18:13 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
А ведь пролучилось ) Мигрировали в итоге 2.4Тб за 11 часов. В пике был терабайт в час. Прикол в том что в процессе миграции падал Оракл на 5 часов (Ораклисты решили во время миграции поменять память, это просто писец...), но долили) . Задача была мигрировать хотя бы за 60 часов. Вендор не мог мигрировать за 3 недели. Что за рукожопы пошли?... Стоимость одной такой миграции - несколько десятков миллионов рублей. А чё за железка на котором один постгрес работает? ... |
|||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
Нравится:
Не нравится:
|
|||
16.11.2023, 18:14 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
... Общая идея - останавливаем все. Максимально быстро мигрируемся. Переключаемся на Постгрес. Или лайки в фейсбуке не будут ставиться или комменты в ютуб не добавляться. ... |
|||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
Нравится:
Не нравится:
|
|||
16.11.2023, 18:19 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес. И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно 1. Отключить индексы и триггеры 2. Заливать так: insert into pg.table_1 select * ora.table on conflict do nothing; Концовка очень важна, иначе будут возникать блокировки. И так хреначим в 55 потоков. Большие таблицы дробятся на виртуальные секции по 10 млн записей. Но не по тупому через limit offset(так в итоге все станет колом из за full scan на стороне Оракла), а через диапазоны по первичным ключам. Так используются индексы первичного ключа и выборка конкретной секции происходит гораздо быстрее. То есть нулевая секция от 0 до 10 млн, первая от 10 млн до 20 млн и далее. Для 4.5 миллиардов записей получается 450 виртуальных секций в диапазонах по 10 млн по первичному ключу. Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее. удалось выжать 300 гигов часа за 3 на дохлых тестовых серверах ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2023, 21:29 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
Смотря какая архитектура. Как оптимизированы запросы. Время выполнения единичного Селекта - несколько единиц МИКРОсекунд - обычное дело. То есть до 1 млн в сек селект - это нормально. А чё за железка на котором один постгрес работает? есть пара мелких сервкаков, ставить забикс с графаной не торт, надо попроще как-то ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2023, 21:31 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|
---|---|
#18+
... А чё за железка на котором один постгрес работает? есть пара мелких сервкаков, ставить забикс с графаной не торт, надо попроще как-то Довольно забавно было наблюдать за pg_profile, который на таких нагрузках вообще ничего сделать не может. Висят сэмплы гирляндами которые сами себя блокируют. А pg_awr это все прекрасно видит. Конечно есть и другие мониторинги на zabbix и Grafana. Но это очень общие метрики. Детально, то что происходить внутри БД мы смотрим при помощи pg_awr. ... |
|
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
|
|
16.11.2023, 22:37 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес. И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно 1. Отключить индексы и триггеры 2. Заливать так: insert into pg.table_1 select * ora.table on conflict do nothing; Концовка очень важна, иначе будут возникать блокировки. И так хреначим в 55 потоков. Большие таблицы дробятся на виртуальные секции по 10 млн записей. Но не по тупому через limit offset(так в итоге все станет колом из за full scan на стороне Оракла), а через диапазоны по первичным ключам. Так используются индексы первичного ключа и выборка конкретной секции происходит гораздо быстрее. То есть нулевая секция от 0 до 10 млн, первая от 10 млн до 20 млн и далее. Для 4.5 миллиардов записей получается 450 виртуальных секций в диапазонах по 10 млн по первичному ключу. Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее. удалось выжать 300 гигов часа за 3 на дохлых тестовых серверах ... |
|||
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
:
Нравится:
Не нравится:
|
|||
16.11.2023, 22:42 |
|
Миграция Оракл - PostgreSQL терабайт в час?
|
|||
---|---|---|---|
#18+
... И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно 1. Отключить индексы и триггеры 2. Заливать так: insert into pg.table_1 select * ora.table on conflict do nothing; Концовка очень важна, иначе будут возникать блокировки. И так хреначим в 55 потоков. Большие таблицы дробятся на виртуальные секции по 10 млн записей. Но не по тупому через limit offset(так в итоге все станет колом из за full scan на стороне Оракла), а через диапазоны по первичным ключам. Так используются индексы первичного ключа и выборка конкретной секции происходит гораздо быстрее. То есть нулевая секция от 0 до 10 млн, первая от 10 млн до 20 млн и далее. Для 4.5 миллиардов записей получается 450 виртуальных секций в диапазонах по 10 млн по первичному ключу. Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее. удалось выжать 300 гигов часа за 3 на дохлых тестовых серверах в целом неплохо, надо лишь план составить и баланс подобрать, тот замер то я получил тупым insert into table_pg select * from table_mssql ну а потом индексы накатил думаю можно было бы и получше разогнать, но потом решили, что пока не надо ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2023, 23:55 |
|
|
Start [/forum/topic.php?fid=8&tid=13868&msg=614878]: |
0ms |
get settings: |
0ms |
get forum list: |
5ms |
check forum access: |
0ms |
check topic access: |
0ms |
track hit: |
19ms |
get topic data: |
2ms |
get forum data: |
0ms |
get page messages: |
71ms |
update_topic_read_status (13868): 16.11.2023 23:55:14: |
0ms |
get tp. blocked users: |
1ms |
get online users: |
22ms |
check new: |
312ms |
others: | 143ms |
total: | 575ms |
0 / 0 |