|
Форум: Firebird, HQbird, InterBase
|
|
Тема: Предел кол-ва транзакций для БД
|
| Re: Предел кол-ва транзакций для БД [сообщение #4934 является ответом на сообщение #4931] |
Fri, 19 April 2024 00:42 |
SD
Сообщений: 342
Зарегистрирован: August 2022
|
Senior Member |
|
|
shavluk писал(а) Thu, 18 April 2024 15:44
Но при 1.5М транзакций в сутки, репликация тоже не самый простой путь.
Вангую, что там 99% транзакций - read-only по факту. Довольно трудно найти вменяемый источник такого потока данных. Разве что все чеки перетёрочки собирают или ММВБ, но такие люди по форумам не ходят...
|
|
|
|
| Re: Предел кол-ва транзакций для БД [сообщение #4935 является ответом на сообщение #4925] |
Fri, 19 April 2024 09:57 |
basid
Сообщений: 99
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Member |
|
|
H.e.l.p писал(а) Thu, 18 April 2024 16:18Два вопроса Вопросов, на самом деле, три, поэтому отвечаю не по порядку.
Многопоточный бэкап параллельно вычитывает данные из разных мест одной таблицы. Потоки, естественно, ничего не пропускают по общему итогу и не конкурируют друг с другом "внутри" базы.
Многопоточный рестор ускоряет только восстановление индексов, точно также вычитывая данные для сортировки в несколько потоков.
Данные, которые читаются из бэкапа, вставляются в (очередную) таблицу в один поток. На этом этапе просто нечего параллелить.
"Потоковый бэкап-рестор" это вполне себе общеизвестная концепция "труба-конвейер" (pipe) и организовывается он как и любой другой конвейер: процесс1 | процесс2
Или даже: процесс1 | ... | процессN
Следует чётко разграничивать регулярные и разовые задачи.
Ежедневный бэкап (с восстановлением, как минимум, метаданных) - задача регулярная. Время бэкап важно, но не критично.
"Перебэкап" базы для сброса значений счётчиков транзакции, в обозримой перспективе - задача разовая.
Для разовой задачи критичным является общее время. Не просто важно, а именно, что критично - есть всего одна попытка и минимум времени: amat victoria curam.
В данном случае, теоретический возможный минимум - время восстановления "новой" базы, поэтому doc/README.services_extension.txt и ("сложено"):"bin/gbak" -se service_mgr ... -b -g база stdout 2>full.bkp.err |
"bin/gbak" -se service_mgr ... -c -use_ stdin новая-база 2>full.rst.err
При восстановлении обязательно указываются -v, -y и -st, чтобы в протоколе было видно сколько времени заняли этапы восстановления.
Процесс всегда начинается с бэкапа-восстановления только метаданных:gbak -se ... -m -b -g база stdout | gbak -se ... -m -c stdin мета-база
Для 32-разрядного - до гигабайта-гигабайта с четвертью. Может быть и до полутора гигабайт, но это уже надо смотреть отдельно и будет зависеть от разрядности операционки.
Большой TCL, в любом случае, несколько (или даже существенно) ускорит построение индексов при восстановлении базы.
Разрядность посмотреть "в сведениях о реализации":"bin/fbsvcmgr" service_mgr ... info_implementation -z Firebird services manager version WI-V2.5.9.27152 Firebird 2.5
Server implementation: Firebird/x86-64/Windows NT
Firebird services manager version WI-V2.5.9.27139 Firebird 2.5
Server implementation: Firebird/x86/Windows NT
Диск, на который будет восстанавливаться новая база, должен быть быстрым. Если быстрый диск только один и он занят "старой" базой, то будет чуть сложнее и займёт больше времени.
|
|
|
|
| Re: Предел кол-ва транзакций для БД [сообщение #4936 является ответом на сообщение #4935] |
Fri, 19 April 2024 14:41 |
SD
Сообщений: 342
Зарегистрирован: August 2022
|
Senior Member |
|
|
Цитата:Ещё полезно восстанавливать базу "без резерва" (опция -use_), что "подпакует" записи и уменьшит размер "новой" базы. После успешного восстановления в таком режиме обязательно делается gfix -use reserve для новой базы (doc/README.DiskSpaceAllocation).
Твоя фамилия Остер? Первый же update фрагментирует "упакованные" таким образом записи и уронит производительность вдвое.
Прямо сейчас я просто копирую 1,6 террабайта с винта. Процесс обещает идти более трёх часов. Это в любом случае неприемлемо для сколь-либо важной и нагруженной базы.
|
|
|
|
| Re: Предел кол-ва транзакций для БД [сообщение #4937 является ответом на сообщение #4936] |
Fri, 19 April 2024 15:06 |
basid
Сообщений: 99
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Member |
|
|
SD писал(а) Fri, 19 April 2024 19:41Первый же update фрагментирует "упакованные" таким образом записи и уронит производительность вдвое. Меня опять терзают смутные сомнения, что процент "активных" данных в не-OLTP базе не просто меньше ста, но ещё и уменьшается с каждым годом.
P.S.
Вас послушать, так каждый update удвоит время выполнения запроса.
|
|
|
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
