Дедофорум Z
     
powered by simpleCommunicator - 2.0.18     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Просто Трёп [закрыт для гостей] / Миграция Оракл - PostgreSQL терабайт в час?
25 сообщений из 37, страница 1 из 2
  1  все
Миграция Оракл - PostgreSQL терабайт в час?
    #613824
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
А ведь пролучилось )

Мигрировали в итоге 2.4Тб за 11 часов. В пике был терабайт в час.

Прикол в том что в процессе миграции падал Оракл на 5 часов (Ораклисты решили во время миграции поменять память, это просто писец...), но долили) . Задача была мигрировать хотя бы за 60 часов. Вендор не мог мигрировать за 3 недели. Что за рукожопы пошли?...

Стоимость одной такой миграции - несколько десятков миллионов рублей.
IMG_20231111_171208_edit_200053663924160.jpg
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Изменено: 16.11.2023, 00:50 - Тень на плетень
Рейтинг: 1 / 0
Нравится: Гарыныч
16.11.2023, 00:49
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #613830
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
У меня этот уже третья миграция. В которой я все планировал.

Появился новый термин - виртуальные секции. Он нужен для очень быстрого извлечения батчей из оракла.

Переносили в 64 потока.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 0 / 0
16.11.2023, 00:54
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #613866
Кусь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кусь ✓
Участник
А чем мигрировали?
...
Рейтинг: 0 / 0
16.11.2023, 01:13
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #613876
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
Кусь  16.11.2023, 01:13
[игнорируется]
613866
А чем мигрировали?
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 2 / 0
Нравится: a.v.z, Гарыныч
16.11.2023, 01:20
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #614176
megabyte
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
megabyte
Участник
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
Кусь  16.11.2023, 01:13
[игнорируется]
613866
А чем мигрировали?
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
Популярное средство. В магните часто юзали для миграции с Оракла.
...
коротко о себе по версии дедофорумчан:
либераст, хохол, жыд, ЗОЖовец-наркоман на антидепрессантах, сталинист, протохохол, желающий поменять родных православных коррупционеров на иноземных..
Рейтинг: 0 / 0
16.11.2023, 09:22
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614180
Redd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Redd
Участник
А куда мигрируют ораклисты.. к хуям, в Германии, Америки?
...
Рейтинг: 1 / 0
Нравится: Мудило
16.11.2023, 09:25
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #614183
Мудило
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мудило
Участник
[не активирован]
Redd  16.11.2023, 09:25
[игнорируется]
614180
А куда мигрируют ораклисты.. к хуям, в Германии, Америки?
за 6О часов!
...
Рейтинг: 0 / 0
16.11.2023, 09:30
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614245
Кусь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кусь ✓
Участник
Ораклисты мигрируют в Казахстан
...
Рейтинг: 2 / 0
Нравится: eNose, Неуловимый Джо
16.11.2023, 10:27
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #614283
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
Redd  16.11.2023, 09:25
[игнорируется]
614180
А куда мигрируют ораклисты.. к хуям, в Германии, Америки?
Никуда. Пока еще много работы по поддержке Оракл. Не все можно мигрировать. Но обновлять точно не будут.

Оракл видимо будет такой вечный динозавр как Cobol ) И грохнуть нельзя, и что с ним делать непонятно.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Изменено: 16.11.2023, 10:55 - Тень на плетень
Рейтинг: 0 / 0
16.11.2023, 10:51
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614391
eNose
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eNose
Участник
[не активирован]
Кусь  16.11.2023, 10:27
[игнорируется]
614245
Ораклисты мигрируют в Казахстан
летять перелетные птицы!
...
Рейтинг: 0 / 0
16.11.2023, 11:52
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614421
anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anonymous
Участник
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
Кусь  16.11.2023, 01:13
[игнорируется]
613866
А чем мигрировали?
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
через подключаемые таблицы получается?
...
Рейтинг: 0 / 0
16.11.2023, 12:08
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #614777
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
pashesobaka  16.11.2023, 15:10
[игнорируется]
614634
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
Кусь  16.11.2023, 01:13
[игнорируется]
613866
А чем мигрировали?
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
Охуенно конечно.

А это не ты?
Screenshot_20231116-151004_YouTube.jpg
Нет. Фодка в моем топике по СПБ
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 1 / 0
Нравится: Гарыныч
16.11.2023, 17:00
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614782
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
anonymous  16.11.2023, 12:08
[игнорируется]
614421
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
Кусь  16.11.2023, 01:13
[игнорируется]
613866
А чем мигрировали?
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
через подключаемые таблицы получается?
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес.

И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно

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:15 - Тень на плетень
Рейтинг: 1 / 0
Нравится: Гарыныч
16.11.2023, 17:06
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #614800
Кусь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кусь ✓
Участник
Тень на плетень [игнорируется] 

А что в Oracle не были секциониованы таблицы? Или там распределение данных хреновое - то густо, то пусто?
...
Рейтинг: 0 / 0
16.11.2023, 17:21
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #614803
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
Кусь  16.11.2023, 17:21
[игнорируется]
614800
Тень на плетень [игнорируется] 

А что в Oracle не были секциониованы таблицы? Или там распределение данных хреновое - то густо, то пусто?
Нам для миграции это не важно. Все равно берём данные относительно небольшими батчами.

То что распределение неравномерное - это наоборот хорошо. Получается самобалансировка потоков. Если все 55 потоков будут стартовать и завершаться одновременно - то и коммитится будут толпой. Это напрягает чекпоинтер. А вот неравномерность в итоге приводит к балансировке. Обычно на 2 - 3 итерации потоки вполне отлично самобалансируются.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 1 / 0
Нравится: Гарыныч
16.11.2023, 17:28
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614864
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
pashesobaka  16.11.2023, 18:04
[игнорируется]
614860
Тень на плетень  16.11.2023, 00:49
[игнорируется]
613824
А ведь пролучилось )

Мигрировали в итоге 2.4Тб за 11 часов. В пике был терабайт в час.

Прикол в том что в процессе миграции падал Оракл на 5 часов (Ораклисты решили во время миграции поменять память, это просто писец...), но долили) . Задача была мигрировать хотя бы за 60 часов. Вендор не мог мигрировать за 3 недели. Что за рукожопы пошли?...

Стоимость одной такой миграции - несколько десятков миллионов рублей.
IMG_20231111_171208_edit_200053663924160.jpg
А этот вот постгрес - один инстанс движка - сколько запросов/сек перерабатывает? Селектов.
Смотря какая архитектура. Как оптимизированы запросы. Время выполнения единичного Селекта - несколько единиц МИКРОсекунд - обычное дело. То есть до 1 млн в сек селект - это нормально.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 0 / 0
16.11.2023, 18:08
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614867
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
pashesobaka  16.11.2023, 18:05
[игнорируется]
614862
Тень на плетень  16.11.2023, 17:06
[игнорируется]
614782
anonymous  16.11.2023, 12:08
[игнорируется]
614421
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
Кусь  16.11.2023, 01:13
[игнорируется]
613866
...
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
через подключаемые таблицы получается?
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес.

И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно

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:12 - Тень на плетень
Рейтинг: 1 / 0
Нравится: Гарыныч
16.11.2023, 18:10
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614873
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
pashesobaka  16.11.2023, 18:11
[игнорируется]
614871
Тень на плетень  16.11.2023, 18:10
[игнорируется]
614867
pashesobaka  16.11.2023, 18:05
[игнорируется]
614862
Тень на плетень  16.11.2023, 17:06
[игнорируется]
614782
anonymous  16.11.2023, 12:08
[игнорируется]
614421
...
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес.

И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно

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 - Тень на плетень
Рейтинг: 0 / 0
16.11.2023, 18:13
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #614878
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
pashesobaka  16.11.2023, 18:12
[игнорируется]
614872
Тень на плетень  16.11.2023, 18:08
[игнорируется]
614864
pashesobaka  16.11.2023, 18:04
[игнорируется]
614860
Тень на плетень  16.11.2023, 00:49
[игнорируется]
613824
А ведь пролучилось )

Мигрировали в итоге 2.4Тб за 11 часов. В пике был терабайт в час.

Прикол в том что в процессе миграции падал Оракл на 5 часов (Ораклисты решили во время миграции поменять память, это просто писец...), но долили) . Задача была мигрировать хотя бы за 60 часов. Вендор не мог мигрировать за 3 недели. Что за рукожопы пошли?...

Стоимость одной такой миграции - несколько десятков миллионов рублей.
IMG_20231111_171208_edit_200053663924160.jpg
А этот вот постгрес - один инстанс движка - сколько запросов/сек перерабатывает? Селектов.
Смотря какая архитектура. Как оптимизированы запросы. Время выполнения единичного Селекта - несколько единиц МИКРОсекунд - обычное дело. То есть до 1 млн в сек селект - это нормально.
Вах. Это на постгресе?
А чё за железка на котором один постгрес работает?
Пришлю вечерком АВР с простейшей системы 4 ядра, 8Гб и т.д. Сам все увидишь.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 0 / 0
16.11.2023, 18:14
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #614889
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
pashesobaka  16.11.2023, 18:15
[игнорируется]
614880
Тень на плетень  16.11.2023, 18:13
[игнорируется]
614873
pashesobaka  16.11.2023, 18:11
[игнорируется]
614871
Тень на плетень  16.11.2023, 18:10
[игнорируется]
614867
pashesobaka  16.11.2023, 18:05
[игнорируется]
614862
...
Приклад останавливается. Поэтому все суперконстистентно. Прикол в том что даже падение Оракла и последующая доливка на консистентность не влияет.

Общая идея - останавливаем все. Максимально быстро мигрируемся. Переключаемся на Постгрес.
Стоп зе ворлд, понимаем.
Любую. Даже супер критичную систему можно остановить ночью на несколько часов.)
Ну не, как же так. А прикинь банковские переводы ночью не будут переводиться через СБП.
Или лайки в фейсбуке не будут ставиться или комменты в ютуб не добавляться.
У них все будет все равно работать. Все векторы изменений пишет Кафка. Просто когда появляется БД вся толпа транзакций скидывается в БД. Как эффект - ну не совсем верно клиент будет видеть свой баланс. Но в минуса он все равно не уйдет. Через какое то время все равно прочихается. Все рассчитано.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 0 / 0
16.11.2023, 18:19
| Ответить | Цитировать | Написать  
Миграция Оракл - PostgreSQL терабайт в час?
    #615057
anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anonymous
Участник
Тень на плетень  16.11.2023, 17:06
[игнорируется]
614782
anonymous  16.11.2023, 12:08
[игнорируется]
614421
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
Кусь  16.11.2023, 01:13
[игнорируется]
613866
А чем мигрировали?
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
через подключаемые таблицы получается?
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес.

И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно

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 млн по первичному ключу.

Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее.
да я пробовал fdw для MSSQL
удалось выжать 300 гигов часа за 3 на дохлых тестовых серверах
...
Рейтинг: 0 / 0
16.11.2023, 21:29
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #615060
anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anonymous
Участник
Тень на плетень  16.11.2023, 18:14
[игнорируется]
614878
pashesobaka  16.11.2023, 18:12
[игнорируется]
614872
Тень на плетень  16.11.2023, 18:08
[игнорируется]
614864
pashesobaka  16.11.2023, 18:04
[игнорируется]
614860
Тень на плетень  16.11.2023, 00:49
[игнорируется]
613824
...
А этот вот постгрес - один инстанс движка - сколько запросов/сек перерабатывает? Селектов.
Смотря какая архитектура. Как оптимизированы запросы. Время выполнения единичного Селекта - несколько единиц МИКРОсекунд - обычное дело. То есть до 1 млн в сек селект - это нормально.
Вах. Это на постгресе?
А чё за железка на котором один постгрес работает?
Пришлю вечерком АВР с простейшей системы 4 ядра, 8Гб и т.д. Сам все увидишь.
лучше расскажи, чем мониторишь постгрю, чем тюнишь
есть пара мелких сервкаков, ставить забикс с графаной не торт, надо попроще как-то
...
Рейтинг: 0 / 0
16.11.2023, 21:31
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #615116
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
anonymous  16.11.2023, 21:31
[игнорируется]
615060
Тень на плетень  16.11.2023, 18:14
[игнорируется]
614878
pashesobaka  16.11.2023, 18:12
[игнорируется]
614872
Тень на плетень  16.11.2023, 18:08
[игнорируется]
614864
pashesobaka  16.11.2023, 18:04
[игнорируется]
614860
...
Смотря какая архитектура. Как оптимизированы запросы. Время выполнения единичного Селекта - несколько единиц МИКРОсекунд - обычное дело. То есть до 1 млн в сек селект - это нормально.
Вах. Это на постгресе?
А чё за железка на котором один постгрес работает?
Пришлю вечерком АВР с простейшей системы 4 ядра, 8Гб и т.д. Сам все увидишь.
лучше расскажи, чем мониторишь постгрю, чем тюнишь
есть пара мелких сервкаков, ставить забикс с графаной не торт, надо попроще как-то
Pg_awr. Это опять же моя разработка. (В интернетах ее нет.) Которая у нас стала корпоративным стандартом. Она размазана на десятки тысяч серверов. Ведет себя великолепно даже на очень высоконагруженных серверах. Вроде 8 ядер, 16 Гб, Load Average под 300. То есть фактически сервак стоит колом. Тем не менее работает. Собирает статистику.

Довольно забавно было наблюдать за pg_profile, который на таких нагрузках вообще ничего сделать не может. Висят сэмплы гирляндами которые сами себя блокируют. А pg_awr это все прекрасно видит.

Конечно есть и другие мониторинги на zabbix и Grafana. Но это очень общие метрики. Детально, то что происходить внутри БД мы смотрим при помощи pg_awr.
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 1 / 0
Нравится: Гарыныч
16.11.2023, 22:37
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #615122
Тень на плетень
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Тень на плетень
Участник
anonymous  16.11.2023, 21:29
[игнорируется]
615057
Тень на плетень  16.11.2023, 17:06
[игнорируется]
614782
anonymous  16.11.2023, 12:08
[игнорируется]
614421
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
Кусь  16.11.2023, 01:13
[игнорируется]
613866
...
oracle_fdw

Об этом у меня как раз был доклад на pg conf 2023 spb

Но там было мало времени. Обо всех нюансах не расскажешь.
через подключаемые таблицы получается?
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес.

И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно

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 млн по первичному ключу.

Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее.
да я пробовал fdw для MSSQL
удалось выжать 300 гигов часа за 3 на дохлых тестовых серверах
Это очень хороший результат. Круто 👍 Для MS SQL это скорее всего tds_fdw. Но концепция та же - мы качаем данные напрямую из базы в базу минуя дампы. Быстрее этого не может быть ничего. Хотя многие пытаются делать это через дампы. Типа ora2pg , Pentaho kettle. И т.д. мы над ними посмеваемся )
...
Кто в предыдущие годы набил карманы за счет всяких "процессов" в экономике 90-х годов, они точно не элита, а кусок говна.
Рейтинг: 0 / 0
16.11.2023, 22:42
| Ответить | Цитировать | Написать | Ответы  
Миграция Оракл - PostgreSQL терабайт в час?
    #615274
anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
anonymous
Участник
Тень на плетень  16.11.2023, 22:42
[игнорируется]
615122
anonymous  16.11.2023, 21:29
[игнорируется]
615057
Тень на плетень  16.11.2023, 17:06
[игнорируется]
614782
anonymous  16.11.2023, 12:08
[игнорируется]
614421
Тень на плетень  16.11.2023, 01:20
[игнорируется]
613876
...
через подключаемые таблицы получается?
Да. Таблицы которые смотрят в Оракл. Хотя определения также находятся в Посгрес.

И да, качать нужно не в один поток. Чтобы не было конфликтов и блокировок нужно

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 млн по первичному ключу.

Все определения индексов и ограничений в новых таблицах в ПГ нужно дропнуть, а создавать их снова многопоточно уже после заливки данных. Так получается гораздо быстрее.
да я пробовал fdw для MSSQL
удалось выжать 300 гигов часа за 3 на дохлых тестовых серверах
Это очень хороший результат. Круто 👍 Для MS SQL это скорее всего tds_fdw. Но концепция та же - мы качаем данные напрямую из базы в базу минуя дампы. Быстрее этого не может быть ничего. Хотя многие пытаются делать это через дампы. Типа ora2pg , Pentaho kettle. И т.д. мы над ними посмеваемся )
да tds_fdw, юзал совместно с sqlserver2pgsql
в целом неплохо, надо лишь план составить и баланс подобрать, тот замер то я получил тупым insert into table_pg select * from table_mssql
ну а потом индексы накатил
думаю можно было бы и получше разогнать, но потом решили, что пока не надо
...
Рейтинг: 0 / 0
16.11.2023, 23:55
| Ответить | Цитировать | Написать  
25 сообщений из 37, страница 1 из 2
  1  все
Форумы / Просто Трёп [закрыт для гостей] / Миграция Оракл - PostgreSQL терабайт в час?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (2): Анонимы (2)
Читали форум (109): Анонимы (100), Сталкер, Ифрит, XEugene 1 мин., Разум вселенной 3 мин., Кусь 4 мин., паразит 5 мин., NSFuimus 6 мин., Гарыныч 7 мин., Брюквенные годы 8 мин.
Пользователи онлайн (124): Анонимы (111), Просто Трёп, Сталкер, Ифрит, Yandex Bot 1 мин., XEugene 1 мин., Vaska Balboa 2 мин., Разум вселенной 3 мин., паразит 3 мин., Bing Bot 4 мин., Кусь 4 мин., NSFuimus 6 мин., Гарыныч 6 мин., Брюквенные годы 6 мин.
Польз. соглашение
ReSQL.ru, Чоткий форум, Чат Кролика       Пашэ: Рисунки, Чат       Деда: Фотоальбом, Встречи
Закрыть
Start [/forum/topic.php?fid=8&tid=13868]:
 0ms
get settings:
 0ms
get forum list:
 4ms
check forum access:
 0ms
check topic access:
 0ms
track hit:
 18ms
get topic data:
 2ms
get forum data:
 0ms
get page messages:
 40ms
update_topic_read_status (13868): 16.11.2023 23:55:14:
 0ms
get tp. blocked users:
 0ms
get online users:
 24ms
check new:
 309ms
others: 139ms
total:  536ms
созд. / загр.: 536ms (нв.: 309ms)
x
x
Закрыть


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