Вставки blob'ов длиной до 32К: ужасный кошмар по сравнению с такими же varchar'ами

Таблоид
Дата: 14.08.2012 14:39:26
hi all (по мотивам топика-сравнения вставок FB vs PG)

Дано: база с чарсетом win1251 и двумя табличками
recreate table tc(id int, s varchar(32760));
recreate table tb(id int, b blob);

Измеряется статистика вставки в каждую таблицу 20 тыс строк, причем поле 's' заполняется "по максимуму", т.е. строками длиной 32760 символов.
Результаты превзошли все ожидания (привожу данные из трейса):
Кеш коннектаТип поля 'S'Операцияtimereadswritesfetchesmarks
75varcharinserts3324928368288037154
75varcharcommit117511
1024varcharinserts3325618498288034154
1024varcharcommit1481102211
75blobinserts984182183514686070404257
75blobcommit38716511
1024blobinserts1467932180820686070404257
1024blobcommit7231101411

Разница времени для insert'ов:
Кеш коннектаtime ratiowrites ratiofetches ratiomarks ratio
7529,664,78,310,9
102444,197,88,311,8

Это с блобами всегда такое было или что-то сломалось в последнее время ?

PS-1. show version; show database:
+
SQL> show version;
ISQL Version: WI-V2.5.2.26520 Firebird 2.5
Server version:
Firebird/x86/Windows NT (access method), version "WI-V2.5.2.26520 Firebird 2.5"
Firebird/x86/Windows NT (remote server), version "WI-V2.5.2.26520 Firebird 2.5/XNet (TLPRG)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.2.26472 Firebird 2.5/XNet (TLPRG)/P12"

SQL> show database;
Database: T1251.FDB
Owner: SYSDBA
PAGE_SIZE 4096
Number of DB pages allocated = 191936
Sweep interval = 20000
Forced Writes are OFF
Transaction - oldest = 9
Transaction - oldest active = 10
Transaction - oldest snapshot = 10
Transaction - Next = 14
ODS = 11.2
Default Character set: WIN1251
PS-2. Test:
+
set stat on;
set term ^;
execute block as
declare n int = 20000;
declare x varchar(32760);
begin
x = rpad('',32760, 'x');
while (n>0) do
insert into tc(id,s) values(:n-1, :x)
returning :n-1 into n;
end^
set term ;^
commit;
---------------------------------------------------------------
set term ^;
execute block as
declare n int = 20000;
declare x blob;
begin
x = rpad('',32760, 'x');
while (n>0) do
insert into tb(id,b) values(:n-1, :x)
returning :n-1 into n;
end^
set term ;^
commit;
set stat off;
Микросекунда
Дата: 14.08.2012 15:07:51
Таблоид пишет:

> Результаты превзошли все ожидания

Давно и все знают, что блобы == тормоза :)

ИМХО: просто тупо инсертить туеву хучу блобов - это не интересно. Интересно проверить рестор базы с туевой хучей блобов. Я не замерял, но на глаз, когда рестор доходит до таблиц с большим числом записей с блобами - замедляется в разы.

Posted via ActualForum NNTP Server 1.5

hvlad
Дата: 14.08.2012 15:49:23
А ничего, что varchar'ы сжимаются, в отличие от блобов ?
Таблоид
Дата: 14.08.2012 15:49:23
Микросекунда
на глаз, когда рестор доходит до таблиц с большим числом записей с блобами - замедляется в разы.
ради интереса я проверил этот вариант, но на серьёзной linux-машине. Заменил, ес-сно, лимит числа вставляемых строк с 20 на 200 тыс:
+
set stat on;
set term ^;
execute block as
declare n int = 200000;
declare x varchar(32760);
begin
x = rpad('',32760, 'x');
while (n>0) do
insert into tc(id,s) values(:n-1, :x)
returning :n-1 into n;
end^
set term ;^
commit;
---------------------------------------------------------------
set term ^;
execute block as
declare n int = 200000;
declare x blob;
begin
x = rpad('',32760, 'x');
while (n>0) do
insert into tb(id,b) values(:n-1, :x)
returning :n-1 into n;
end^
set term ;^
commit;
Соотношение времени insert'ов на этой машине уже не такое ошеломляющее, различие "всего" в три раза:
cache field typeoperationtimereadswritesfetchesmarks
768varcharinserts80309027955828762371552
768varcharcommit10176811
768blobinserts2307020181755668607994042561
768blobcommit0175811


Затем сделал backup, а на рестор натравил supertee с логированием времени:
supertee -t -n t1_restore.log gbak -c t1.fbk t1.tmp -v > /dev/null 2>&1

И вот какие данные вижу в логе t1_restore.log:
bash-3.2$ cat -n t1_restore.log
1 Tue Aug 14 15:35:32 2012: gbak:opened file t1.fbk
2 Tue Aug 14 15:35:32 2012: gbak:transportable backup -- data in XDR format
3 Tue Aug 14 15:35:32 2012: gbak: backup file is compressed
4 Tue Aug 14 15:35:32 2012: gbak:created database t1.tmp, page_size 4096 bytes
5 Tue Aug 14 15:35:32 2012: gbak:started transaction
<...>
16 Tue Aug 14 15:35:32 2012: gbak: committing metadata
17 Tue Aug 14 15:35:32 2012: gbak:restoring data for table TB
18 Tue Aug 14 15:35:33 2012: gbak: 10000 records restored
19 Tue Aug 14 15:35:37 2012: gbak: 20000 records restored
20 Tue Aug 14 15:35:38 2012: gbak: 30000 records restored
21 Tue Aug 14 15:35:42 2012: gbak: 40000 records restored
22 Tue Aug 14 15:35:44 2012: gbak: 50000 records restored
23 Tue Aug 14 15:35:48 2012: gbak: 60000 records restored
24 Tue Aug 14 15:35:52 2012: gbak: 70000 records restored
25 Tue Aug 14 15:35:53 2012: gbak: 80000 records restored
26 Tue Aug 14 15:35:57 2012: gbak: 90000 records restored
27 Tue Aug 14 15:35:59 2012: gbak: 100000 records restored
28 Tue Aug 14 15:36:02 2012: gbak: 110000 records restored
29 Tue Aug 14 15:36:03 2012: gbak: 120000 records restored
30 Tue Aug 14 15:36:08 2012: gbak: 130000 records restored
31 Tue Aug 14 15:36:11 2012: gbak: 140000 records restored
32 Tue Aug 14 15:36:13 2012: gbak: 150000 records restored
33 Tue Aug 14 15:36:14 2012: gbak: 160000 records restored
34 Tue Aug 14 15:36:19 2012: gbak: 170000 records restored
35 Tue Aug 14 15:36:22 2012: gbak: 180000 records restored
36 Tue Aug 14 15:36:23 2012: gbak: 190000 records restored
37 Tue Aug 14 15:36:28 2012: gbak: 200000 records restored
38 Tue Aug 14 15:36:29 2012: gbak: 200000 records restored
39 Tue Aug 14 15:36:29 2012: gbak:restoring data for table TC
40 Tue Aug 14 15:36:30 2012: gbak: 10000 records restored
41 Tue Aug 14 15:36:30 2012: gbak: 20000 records restored
42 Tue Aug 14 15:36:31 2012: gbak: 30000 records restored
43 Tue Aug 14 15:36:32 2012: gbak: 40000 records restored
44 Tue Aug 14 15:36:33 2012: gbak: 50000 records restored
45 Tue Aug 14 15:36:34 2012: gbak: 60000 records restored
46 Tue Aug 14 15:36:35 2012: gbak: 70000 records restored
47 Tue Aug 14 15:36:36 2012: gbak: 80000 records restored
48 Tue Aug 14 15:36:37 2012: gbak: 90000 records restored
49 Tue Aug 14 15:36:38 2012: gbak: 100000 records restored
50 Tue Aug 14 15:36:39 2012: gbak: 110000 records restored
51 Tue Aug 14 15:36:40 2012: gbak: 120000 records restored
52 Tue Aug 14 15:36:41 2012: gbak: 130000 records restored
53 Tue Aug 14 15:36:41 2012: gbak: 140000 records restored
54 Tue Aug 14 15:36:42 2012: gbak: 150000 records restored
55 Tue Aug 14 15:36:43 2012: gbak: 160000 records restored
56 Tue Aug 14 15:36:44 2012: gbak: 170000 records restored
57 Tue Aug 14 15:36:45 2012: gbak: 180000 records restored
58 Tue Aug 14 15:36:46 2012: gbak: 190000 records restored
59 Tue Aug 14 15:36:47 2012: gbak: 200000 records restored
60 Tue Aug 14 15:36:47 2012: gbak: 200000 records restored
<...>
90 Tue Aug 14 15:36:47 2012: gbak: committing metadata
91 Tue Aug 14 15:36:47 2012: gbak:finishing, closing, and going home
Таким обр., 200 тыс строк с блобами (все по 32 К длиной) ресторились 57 сек, с варчарами (такой же длины каждый) - 18 сек. То есть, соотношение времени на этой машине такое же, как при инсертах: в три раза.
Таблоид
Дата: 14.08.2012 15:51:07
hvlad
А ничего, что varchar'ы сжимаются, в отличие от блобов ?
значит, если вставлять guid-строку длиной 32 К, то такого ужоса не должно было быть ?
Таблоид
Дата: 14.08.2012 17:42:14
Таблоид
значит, если вставлять guid-строку длиной 32 К, то такого ужоса не должно было быть ?
Тихо сам с собою я веду беседу: да, ужос потускнел.
При вставке в varchar-поле несжимаемых строк соотв-щее время отличается от вставки блобов "всего" в 2 раза. За счет чего именно - всё равно непонятно, т.к. соотношения по writes и marks - всего 1.1.
Кеш коннектаТип поля 'S'Операцияtimereadswritesfetchesmarks
75varcharinserts5454011165586413379363358
75varcharcommit7717511
75blobinserts11597710183094466091404257
75blobcommit24717511
1024varcharinserts1311349162499413379363358
1024varcharcommit4021102311
1024blobinserts22630210180815466091404257
1024blobcommit12261102411

Соотношение по статистикам:
Кеш коннектаtime ratiowrites ratiofetches ratiomarks ratio
752,131,111,131,11
10241,731,111,131,11

Test:
+
recreate table tc(id int, s varchar(32760) character set octets);
recreate table tb(id int, b blob);
-- GTT'шка для хранения "длинной несжимаемой строки":
recreate global temporary table gtt(s varchar(32760) character set octets) on commit preserve rows;
commit;
set term ^;
execute block as
declare i int = 0;
declare x varchar(32760) = '';
begin
while (i<32730) do begin
x = x || gen_uuid();
i = i + 16;
end
insert into gtt(s) values(:x);
end^
set term ;^
commit;

--.....................................
set stat on;
set term ^;
execute block as
declare n int = 20000;
declare x varchar(32760);
begin
select first 1 s from gtt into x;
while (n>0) do
insert into tc(id,s) values(:n-1, :x)
returning :n-1 into n;
end^
set term ;^
commit;
--.....................................
set term ^;
execute block as
declare n int = 20000;
declare x varchar(32760);
begin
select first 1 s from gtt into x;
while (n>0) do
insert into tb(id,b) values(:n-1, :x)
returning :n-1 into n;
end^
set term ;^
commit;
set stat off;
Таблоид
Дата: 14.08.2012 20:24:44
hvlad
А ничего, что varchar'ы сжимаются, в отличие от блобов ?
BTW: а почему для блобов сжатие не делается ? там ведь не всегда музыка да "джипеги" хранятся - тексты большие тоже ведь туда пишут.
dimitr
Дата: 14.08.2012 20:32:09
Таблоид
а почему для блобов сжатие не делается ?

оно отдано на откуп конечному юзеру, RTFM блоб-фильтры. Ибо ХЗ что там у тебя за формат блоба и как его эффективнее жать.
Док
Дата: 19.08.2012 07:28:42
dimitr
оно отдано на откуп конечному юзеру, RTFM блоб-фильтры. Ибо ХЗ что там у тебя за формат блоба и как его эффективнее жать.

Жаль, что их использование ограничено функционалом клиента, ибо инструменты администрирования про фильтры ни сном ни духом.
Di_LIne
Дата: 19.08.2012 09:49:23
Таблоид
а почему для блобов сжатие не делается ?

Типа сёрверу нех больше делать, как распаковывать и упаковывать их.

Таблоид
там ведь не всегда музыка да "джипеги" хранятся - тексты большие тоже ведь туда пишут.

Вот ток не поднимай опять этот холивар: Документы в БД - в блоб vs фтопку.
Последнее и без вариантов.

Док
Жаль, что их использование ограничено функционалом клиента...

... которого тошь, полтора раза для апчелся.
Док, но имхо: блобы - пережиток и тяжкое наследие от доэфбишных времен.


Таблоид & Док - не надо превращать сервер БД в файл-менеджер.
FAR все равно уделает любую СУБДю...
Любы рассуждения наткнуца и обломаютца на ситуации: 400 ползателей разом ломанулись и каждый за своей Ёксельмоксель-бумашкой.