ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Параллельное создание большого количества PK и FK
25 сообщений из 44, страница 1 из 2
  1  все
Параллельное создание большого количества PK и FK
    #39761976
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
Добрый день,

Предстоит апгрейд больших бд, где не обойтись без пересоздания первичных и внешних ключей (переход с 32 битных ключей на 64 бита).

Хочу создать утилиту, которая скинет структуру бд в спец таблицы. Затем удалит констрэйнты, проведет операции с бд и восстановит PK и FK.

Вопрос, собственно, такой:

Я планирую восстановление делать в параллельных конектах, одновременно.

Даст ли это прирост производительности? ( уменьшение времени по сравнению с gbak)

Безопасно ли это с т.зр. внутренней работы сервера фб? Т.е. не приведет ли к повреждению бд.

На сервере 40 физических ядер и 512 гб озу. База 200 Гб. Кэш выставляется в размер базы. Страница 8192 байт.

Сервер: фб 3.0.4.

Я планирую использовать 20-30 параллельных конектов при восстановлении.
...
Рейтинг: 0 / 0
20.01.2019, 06:21
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39761993
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
sysdba22Безопасно ли это с т.зр. внутренней работы сервера фб?

да

sysdba22Даст ли это прирост производительности?

возможно.

sysdba22Я планирую использовать 20-30 параллельных конектов при восстановлении.

вот здесь надо аккуратней.
При создании индексов создаются файлы сортировки, которые могут быть очень большими, это надо учитывать при планировании свободного пространства.
Создавать 30 индексов параллельно ИХМО перебор. Можно уже упереться в IO а не ядра.
...
Рейтинг: 0 / 0
20.01.2019, 11:56
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762005
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
Я настраиваю файреберду под буфер сортировки 256 Гб памяти. Еще 200 Гб под кэш БД. Ну, и остаток под ОС, процессы и т.п.

Т.е. по идее даже 30 одновременных индексов это где-то по 8 Гб в буфере сортировки в оперативной памяти. Должно хватить, чтобы не валилось на диск.

Или я не прав?
...
Рейтинг: 0 / 0
20.01.2019, 12:37
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762009
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
т.е. идея такая, что все данные находятся в оперативной памяти и вся сортировка идет в оперативной памяти, да еще и параллельно. Только полученный итог скидывается на диск. Но там, для этого мощная SSD система от Intel га прямом подключении к PCI Express с бешенной производительностью.
...
Рейтинг: 0 / 0
20.01.2019, 12:45
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762027
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
sysdba22т.е. идея такая, что все данные находятся в оперативной памяти и вся сортировка идет в
оперативной памяти

то есть база у тебя игрушечная и на её быстродействие тебе наплевать. Делай что хочешь, о
результатах не забудь написать.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
20.01.2019, 13:50
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762032
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuRock
Участник
sysdba22База 200 ГбЭто небольшая база.
При эксклюзивном доступе (для обновления) можно выполнить все операции в последовательном порядке за несколько минут, мне кажется.
Изобретать велосипед для одноразового обновления, чтоб выиграть (возможно) пару минут как-то странно.
...
Рейтинг: 0 / 0
20.01.2019, 13:56
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762041
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
sysdba22Т.е. по идее даже 30 одновременных индексов это где-то по 8 Гб в буфере сортировки в оперативной памяти
во-первых, даже в InterBase параллельно рекомендуют создавать столько индексов, сколько на сервере ядер минус 1.
8 ядер - 7 потоков, и т.д.

во-вторых, если ты выделяешь N гиг под сортировку, то никакого "равенства" для 30ти сортировок там не будет. Памяти под сортировку (построение) конкретного индекса надо будет столько, сколько столбцов и записей индексируется. И если один индекс сожрет половину памяти под сортировки, то на остальные индексы останется ... вторая половина :-)

Я напомню, для создания индекса в базе tpc-c, который в базе занимал 29 гиг, потребовался файл сортировки 182 гига.
В принципе, для индексов по int/bigint можно посчитать объем сортировки, зная размер таблицы.
sysdba22 База 200 Гб. Кэш выставляется в размер базы. Страница 8192 байт
по идее, для такой базы надо бы страницу 16к.
...
Рейтинг: 0 / 0
20.01.2019, 14:04
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762155
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
1) ядер там 48
2) с размером буфера под сортировку индекса учту.
3) в том то всё и дело, что проовернуть цикл бэкап рестор там проблема из за занимаемого времени. а из вашего опыта насколько может подрасти производительность?

если есть хотя бы приблизительная формула вычисления объёма буфера для создания индекса, если известно количество записей и тип данных, то буду признателен.

как я понимаю, размер будет отличаться в зависимости от того идет сортировка в озу или на диске.
...
Рейтинг: 0 / 0
20.01.2019, 22:06
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762179
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
sysdba22а из вашего опыта насколько может подрасти производительность?
производительность рестора? Рестор состоит из наливки данных и создания индексов. Про это было тут:
http://www.ibase.ru/restorespeed/
создание индексов может занимать половину времени рестора. при параллельном создании индексов можно ускориться ... допустим впополам. А значит итогово где-то на четверть. Но такого опыта нет.
sysdba22если есть хотя бы приблизительная формула вычисления объёма буфера для создания индекса
да блин, отсортируй таблицу по какому-нибудь столбцу, получишь конкретный результат.
select field from table order by 1
так, чтобы индекс не использовался (если он есть по столбцу). И будет файл сортировки в temp и его размер.
sysdba22как я понимаю, размер будет отличаться в зависимости от того идет сортировка в озу или на диске.
в смысле? размер сортировки равен размеру сортировки в памяти плюс размер файла сортировки. Ни по каким другим причинам "размер" отличаться не будет.
...
Рейтинг: 0 / 0
21.01.2019, 01:11
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762193
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
я где то читал, что механизм сортировки в фб работает по разному для файла и для сортировки в памяти. я имею ввиду внутренний буфер фб под сортировку, а не кэш файловой системы, который дает операционная система. поэтому и спрашиваю про размер.
...
Рейтинг: 0 / 0
21.01.2019, 05:28
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762210
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vlad F
Участник
sysdba22,

Думаю, было бы крайне полезно для сообщества выполнить означенные манипуляции сравнительно, в последовательном и параллельном режимах. Но это при наличии такой технической возможности (ну и интереса), естественно.
...
Рейтинг: 0 / 0
21.01.2019, 08:21
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762227
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
sysdba22я где то читал, что механизм сортировки в фб работает по разному для файла и для сортировки в памяти. я имею ввиду внутренний буфер фб под сортировку, а не кэш файловой системы, который дает операционная система. поэтому и спрашиваю про размер.

Там примерно так, сначала сортируются маленькие порции QuickSort это в памяти, потом эти отсортированные порции сливаются многопроходным алгоритмом сортировки слиянием, если данные помещаются в память, то в памяти, если нет то образуется файлы сортировок. Их суммарный объём довольно сложно посчитать. Очень приближённо размер распакованных полей + RDB$KEY для всех таблиц, но наверное есть какой-то ещё оверхед.
Файлы сортировок которые образуются на диски помечены как временные, поэтому сама ОСь, по факту тоже может держать их в памяти без сброса на диск.

Подробнее об это может Влад рассказать.
Ещё кое что есть тут https://www.ibase.ru/news/materialy-vebinara-effektivnoe-ispol-zovanie-pamati-subd-firebird/
...
Рейтинг: 0 / 0
21.01.2019, 09:38
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762233
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
а вот размер этих "маленьких порций" нельзя увеличить? а то памяти хватает, чтобы весь индекс в озу за раз отсортировать. очень бы мне кажется это помогло.
...
Рейтинг: 0 / 0
21.01.2019, 09:55
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762289
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
sysdba22,

ничего там не надо увеличивать. Если сортировка влазит в память, то она остается в памяти. Если нет - идет в файл сортировки, причем, к примеру, если SortMemSize 2 гига, а сортируется 4 гига, то 2 гига сортировки будут в памяти, остальное пойдет во временный файл сортировки.
Сам файл сортировки временный, поэтому его операционная система старается разместить в памяти, на винде это видно как файл нулевого размера, реальный размер видно только если свойства файла посмотреть.
И, если у ОС не хватает памяти, то тогда временный файл выгружается на диск.

По моим тестам, если у ОС хватает памяти для временного файла, нет никакой разницы по времени между сортировкой в памяти ФБ и во временном файле.
http://www.ibase.ru/files/articles/performance/Firebird Optimizer - ORDER vs SORT.pdf
страница 9.
...
Рейтинг: 0 / 0
21.01.2019, 12:08
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762294
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
sysdba22,

я же вроде написал, что слияния тоже в памяти могут происходить. Кроме того как и сказал Дмитрий временные файлы зачастую тоже в памяти находятся.

Реально там есть проблема только с совсем гигантскими индексами, которая вылезла на террабайтной базе, когда памяти не хватало, и которая решалась только спецбилдом. Там вроде надо было размер и количество групп менять. Насколько я знаю она до сих пор не решена. Там вроде предлагалась их динамически менять от объёма сортировки. Кстати насколько я помню из обсуждения в ряде случаев можно было ускорить совсем маленькие сортировки.
...
Рейтинг: 0 / 0
21.01.2019, 12:17
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762306
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
а эта проблема планируется к устранению?

потому что мы тоже будем идти к террабайтной бд.

не хотелось бы с ней столкнуться.

она есть в багтреккере, чтобы посмотреть на ее описание?
...
Рейтинг: 0 / 0
21.01.2019, 12:33
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762307
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
sysdba22,

всё есть тут и ссылки на трекер тоже https://www.ibase.ru/fb1tbtech/
...
Рейтинг: 0 / 0
21.01.2019, 12:39
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762308
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
sysdba22она есть в багтреккере, чтобы посмотреть на ее описание?
Конечно есть
http://www.ibase.ru/fb1tbtech/

http://tracker.firebirdsql.org/browse/CORE-2525
...
Рейтинг: 0 / 0
21.01.2019, 12:40
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762330
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
насколько я вижу в описании, там проблема в выделении памяти и она проявилась на 32 бит файреберде и на 32 бит винде. можно ли сделать предположение, что ее не будет на 64 бит ос и фб?
...
Рейтинг: 0 / 0
21.01.2019, 13:20
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762337
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
sysdba22,

нет, там проблема гораздо глубже. Читай комменты в тикете внимательней
...
Рейтинг: 0 / 0
21.01.2019, 13:31
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762341
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
sysdba22,

при чем тут 32 бита....
...
Рейтинг: 0 / 0
21.01.2019, 13:38
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762343
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
sysdba22а вот размер этих "маленьких порций" нельзя увеличить?

Можно. Читай firebird.conf на предмет Temp* параметров.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.01.2019, 13:38
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762532
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Dimitry SibiryakovМожно. Читай firebird.conf на предмет Temp* параметров.
он хочет, чтобы ранов совсем не было. Один единственный буфер в ОЗУ на 100500МБ и квиксорт в нем.
...
Рейтинг: 0 / 0
21.01.2019, 20:04
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762637
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vlad F
Участник
dimitr,

А это можно, технически, сделать?
...
Рейтинг: 0 / 0
22.01.2019, 08:22
| Ответить | Цитировать | Написать  
Параллельное создание большого количества PK и FK
    #39762815
sysdba22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysdba22
Гость
dimitrон хочет, чтобы ранов совсем не было. Один единственный буфер в ОЗУ на 100500МБ и квиксорт в нем.

только не на 100500, а на 256 Гб пока ))

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

скажем так, в чем проблема. у нас тут 20 лет системе нашей и мы сейчас думаем, как так сделать, чтобы она спокойно проработала следующие 20.

одну проблему мы решаем переходом на 64 бит ИД.

остается проблема скорости и роста базы. резать данные категорически не хочется...
...
Рейтинг: 0 / 0
22.01.2019, 13:54
| Ответить | Цитировать | Написать  
25 сообщений из 44, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Параллельное создание большого количества PK и FK
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39761993&tid=1560830]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 149ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 57ms
get tp. blocked users:
 1ms
others: 293ms
total:  538ms
созд. / загр.: 538ms
x
x
Закрыть


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