powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Умолчательное направление при построении индекса по PK
25 сообщений из 69, страница 2 из 3
Умолчательное направление при построении индекса по PK
    #39163908
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arioch> тебе ссылку зачем дали? прочитай в ней ВТОРОЕ сообщение, а ?

Прочитал. И?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163910
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposhЯ не прошу так сделать, я предложил рассмотреть целесообразность этогоМеханизм есть. Нужен он в 1% частных случаев. Доп. затраты (см. ответ ДЕ) будут платить все.
Накуа ?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163914
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Влад, ну я как то уже с этим согласился
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163915
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposh> данный вопрос должен решаться архитектором БД при создании PK-ключа

Как и большинство вопросов.
Собсно, если по дефолту делать DESC -
найдутся те, кому будет нужен ASC.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163917
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposhВлад, ну я как то уже с этим согласилсяЭто я позже прочитал :)
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163920
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамИ?
И он, типа, думает, что я кретин, который в цитату ставит случайный кусок сообщения, а не
точно выпиленную посылку, на которую и даётся ответ.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163925
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Hvlad > Доп. затраты (см. ответ ДЕ) будут платить все.

А вот по какой методике их бы изменить? Есть идеи?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163937
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposhА вот по какой методике их бы измерить? Есть идеи?
Стандартный тест на время вставки 100 миллионов записей тебе чем-то не нравится?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163949
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladshaposhактуальность получения максимального значения по полю PKВ где она ? Зачем это нужно ?Не по PK, а по "просто" индексу - нужна. Темпоральные атрибуты (названия изделий или группы, к которым они относятся; госномер автомобиля, ID его собственника, номер двигателя или даже VIN (да! иногда бывает замена всего кузова, но тачка остается после этого в эксплуатации); названия клиентов, в т.ч. введённые неправильно - их тоже надо хранить для 100% воспроизводимости старых документов при их перепечатке; некоторые реквизиты организаций, которые могут меняться, но должна сохраняться вся "история соответствий времени": ФИО руководителя или главбуха, и прочая).
Обычному усеру нужна последняя версия названия (актуальная сейчас); тому, кто лезет в архив за старыми док-тами - версия атрибута, ID-которой записан в этом документе.
Если ID версии получается дёрганием генератора вперёд, то надо ставить убывающий индекс. А если дёргать генератор взад, то сразу неудобно при разработке / отладке: либо пялимся на отрицательные значения либо на положительные числа типа 99999999, чтобы "не так быстро ушли в минус".
Но в любом случае в индексе новые значения в индексе будут появляться "против натуральной шерсти".
Например, для asc-индекса это будут 1) 999999, 2) 999998, 3) 999997 - и скорее всего при выполнении запроса с plan order'ом потребуется "прыгать назад", т.е. cluster factor там будет хреновый.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163995
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Быстренький тест набросанный на коленке, основанный на импорте данных ФИАС показал, что
время вставки 1 000 000 записей в таблицу с PK DESC составила 103,5%
от времени вставки в аналогичную таблицу с PK ASC. Тип PK - Int32
1 000 000 не показатель, но все-таки похоже DESC-сортировка дорогое удовольствие.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164002
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposh,

сравни еще время выборки из заполненной таблицы
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164021
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не понял, 3,5% - дорогое удовольствие.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164059
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
3,5%. Я посчитал что это "дорого" за возможность индексированного поиска MAX(ID)
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164092
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrshaposh,

сравни еще время выборки из заполненной таблицыИ размеры индексов тоже стоит сравнить
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164137
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>> Dimitr, Vlad
Обязательно сравню, не сейчас
Сорри, дела
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164141
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что-то не очень сильно бросается в глаза разница между:
1) скоростью заливки данных (50 млн строк, тип id = bigint) при юзании asc vs desc индексов:
DDL + add initial data
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
recreate sequence g_asc;
recreate sequence g_desc;
recreate table test_asc(id bigint primary key using ascending index test_asc_id);
recreate table test_dec(id bigint primary key using descending index test_dec_id);

set term ^; execute block as declare n int = 50000000; begin while(n>0) do insert into test_asc values(gen_id(g_asc,1)) returning :n-1 into n; end^ set term ;^
commit;

set term ^; execute block as declare n int = 50000000; begin while(n>0) do insert into test_dec values(gen_id(g_desc, -1)) returning :n-1 into n; end^ set term ;^
commit;
trace
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
2016-02-05T15:15:39.4020 (2608:0x7fae326ef040) EXECUTE_STATEMENT_FINISH
        e30 (ATT_7, SYSDBA:NONE, NONE, TCPv4:192.168.0.220/36061)
        /opt/fb30ss/bin/isql:2631
                (TRA_11, CONCURRENCY | WAIT | READ_WRITE)

Statement 27:
-------------------------------------------------------------------------------
execute block as declare n int = 50000000; begin while(n>0) do insert into test_asc values(gen_id(g_asc,1)) returning :n-1 into n; end
0 records fetched
 795093 ms, 568 read(s), 530075 write(s), 401730629 fetch(es), 151488906 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$PAGES                                                           187
TEST_ASC                                                       50000000



2016-02-05T15:32:38.0340 (2608:0x7fae326ef040) EXECUTE_STATEMENT_FINISH
        e30 (ATT_7, SYSDBA:NONE, NONE, TCPv4:192.168.0.220/36061)
        /opt/fb30ss/bin/isql:2631
                (TRA_20, CONCURRENCY | WAIT | READ_WRITE)

Statement 96:
-------------------------------------------------------------------------------
execute block as declare n int = 50000000; begin while(n>0) do insert into test_dec values(gen_id(g_desc, -1)) returning :n-1 into n; end
0 records fetched
 796282 ms, 563 read(s), 530098 write(s), 401750452 fetch(es), 151488927 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$PAGES                                                           187
TEST_DEC                                                       50000000

2) выборкой по asc vs desc индексу (делал по три запуска в каждом случае; дифферент порогов = 1 млн, значения из середины листового уровня):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SQL> select * from test_asc where id between 25000000 and 26000000 order by id;

Select Expression
    -> Filter
        -> Table "TEST_ASC" Access By ID
            -> Index "TEST_ASC_ID" Range Scan (lower bound: 1/1, upper bound: 1/1)

 vs 

SQL> select * from test_dec where id between -26000000 and -25000000 order by id desc;

Select Expression
    -> Filter
        -> Table "TEST_DEC" Access By ID
            -> Index "TEST_DEC_ID" Range Scan (lower bound: 1/1, upper bound: 1/1)
trace
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
2016-02-05T15:35:11.6000 (2608:0x7fae326ef040) EXECUTE_STATEMENT_FINISH
        e30 (ATT_7, SYSDBA:NONE, NONE, TCPv4:192.168.0.220/36061)
        /opt/fb30ss/bin/isql:2631
                (TRA_27, CONCURRENCY | WAIT | READ_WRITE)

Statement 97:
-------------------------------------------------------------------------------
select * from test_asc where id between 25000000 and 26000000 order by id
1000001 records fetched
   3050 ms, 7640 read(s), 3001503 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TEST_ASC                                    1000001

 == vs  == 

Statement 403:
-------------------------------------------------------------------------------
select * from test_dec where id between -26000000 and -25000000 order by id desc
1000001 records fetched
   3088 ms, 7640 read(s), 3001503 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TEST_DEC                                    1000001

3) статистикой индексов (практически близнецы):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
Database "/var/db/fb30/e30.fdb"
Database header page information:
	Flags			0
	Generation		46
	System Change Number	0
	Page size		8192
	ODS version		12.0
	Oldest transaction	32
	Oldest active		33
	Oldest snapshot		33
	Next transaction	34
	Sequence number		0
	Next attachment ID	11
	Implementation		HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
	Shadow count		0
	Page buffers		0
	Next header page	0
	Database dialect	3
	Creation date		Feb 2, 2016 18:57:15
	Attributes		

    Variable header data:
	*END*


Database file sequence:
File /var/db/fb30/e30.fdb is the only file

Analyzing database pages ...
TEST_ASC (128)
    Primary pointer page: 181, Index root page: 182
    Total formats: 1, used formats: 1
    Average record length: 10.66, total records: 50000000
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 16.00, compression ratio: 1.50
    Pointer pages: 188, data page slots: 306752
    Data pages: 306752, average fill: 55%
    Primary pages: 306752, secondary pages: 0, swept pages: 0
    Empty pages: 3, full pages: 306748
    Fill distribution:
	 0 - 19% = 3
	20 - 39% = 1
	40 - 59% = 306748
	60 - 79% = 0
	80 - 99% = 0

    Index TEST_ASC_ID (0)
	Root page: 3026, depth: 3, leaf buckets: 73987, nodes: 50000000
	Average node length: 11.68, total dup: 0, max dup: 0
	Average key length: 8.14, compression ratio: 1.11
	Average prefix length: 3.86, average data length: 5.14
	Clustering factor: 306749, ratio: 0.01
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 0
	    40 - 59% = 3120
	    60 - 79% = 0
	    80 - 99% = 70867

TEST_DEC (129)
    Primary pointer page: 381495, Index root page: 381520
    Total formats: 1, used formats: 1
    Average record length: 10.66, total records: 50000000
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 16.00, compression ratio: 1.50
    Pointer pages: 188, data page slots: 306752
    Data pages: 306752, average fill: 55%
    Primary pages: 306752, secondary pages: 0, swept pages: 0
    Empty pages: 3, full pages: 306748
    Fill distribution:
	 0 - 19% = 3
	20 - 39% = 1
	40 - 59% = 306748
	60 - 79% = 0
	80 - 99% = 0

    Index TEST_DEC_ID (0)
	Root page: 384209, depth: 3, leaf buckets: 73987, nodes: 50000000
	Average node length: 11.68, total dup: 0, max dup: 0
	Average key length: 8.14, compression ratio: 1.11
	Average prefix length: 3.86, average data length: 5.14
	Clustering factor: 306749, ratio: 0.01
	Fill distribution:
	     0 - 19% = 0
	    20 - 39% = 0
	    40 - 59% = 3120
	    60 - 79% = 0
	    80 - 99% = 70867


PS. LI-V3.0.0.32323
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164167
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид) скоростью заливки данных (50 млн строк

потому что нужен диск со скоростью примерно равное скорости RAM :D
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164175
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ariochнужен диск со скоростью примерно равное скорости RAM :DНа этой машине хотя и хорошая дисковая, но таки до скорости RAM ей далёко.
ЗЫ. А что должно было вылезти на диске, который "со скоростью ram" ?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164189
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

ну так ты в своём тесте генераторы перевернул для PK по DESC индексу, так конечно большой разницы быть не должно.

Сомневаюсь что ТСа это устроит.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164198
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

а зачем же ты разные данные заливаешь в таблицы ?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164210
Фотография DirksDR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposhАктуальность получения MAX(ID) для поля PK выше чем MIN(ID), поэтому представляется целесообразным по умолчанию строить DESС-индекс для поля PK.
Конец недели, может поэтому не врубаюсь, из-за чего сыр-бор?
Что, есть подозрение, что max(id) вызывает полный скан индекса?

Проверяем на Оракле:
Код: sql
1.
select max(TM_PROPERTY1_ID) from TM_PROPERTY1


В таблице больше 100млн записей. План выполнения:
Код: sql
1.
2.
3.
|   1 |  SORT AGGREGATE            |                 |     1 |     9 |           |         |                                                                  
                                                                                
|   2 |   INDEX FULL SCAN (MIN/MAX)| PK_TM_PROPERTY1 |     1 |     9 |     4   (0)| 00:00:01 |                                                                  


Может, FULL SCAN (MIN/MAX) отличается чем-то от простого FULL SCAN, но время выполнения
варьируется от 16 до 31 мсек.
Не верю, что весь индекс сканировался.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164223
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladа зачем же ты разные данные заливаешь в таблицы ?не "зачем", а "от чего": тумблер многостаночника был включён, отвлекался на всякое разное... лок-таблицы там всякие с бак-трассами какими-то... ;-)
Сейчас повторю по-новой с test-dec.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164232
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DirksDR,

не надо тут Ораклом трясти. Во первых у него есть index only scan, а в FB нету. Во вторых в оракле индексы по умолчанию двунаправленные.

DirksDRМожет, FULL SCAN (MIN/MAX) отличается чем-то от простого FULL SCAN

должен отличаться.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164252
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидСейчас повторю по-новой с test-dec.Заливка в пустую базу тех же 50 млн:
trace: 869686 ms, 1129 read(s), 887981 write(s), 408344253 fetch(es), 151846887 mark(s)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
2016-02-05T16:47:40.1080 (2608:0x7fae326ef040) EXECUTE_STATEMENT_FINISH
        /var/db/fb30/e30.fdb (ATT_5, SYSDBA:NONE, NONE, TCPv4:192.168.0.220/36065)
        /opt/fb30ss/bin/isql:2934
                (TRA_4, CONCURRENCY | WAIT | READ_WRITE)

Statement 95:
-------------------------------------------------------------------------------
execute block as declare n int = 50000000; begin while(n>0) do insert into test_dec values(gen_id( g_asc, 1 )) returning :n-1 into n; end
0 records fetched
 869686 ms, 1129 read(s), 887981 write(s), 408344253 fetch(es), 151846887 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$PAGES                                                           187
TEST_DEC                                                       50000000
Выборка 1 млн из 50-ти:
3124 ms, 9130 read(s), 3002993 fetch(es)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
SQL> set explain on; select * from test_dec where id between 25000000 and 26000000 order by id desc;

Select Expression
    -> Filter
        -> Table "TEST_DEC" Access By ID
            -> Index "TEST_DEC_ID" Range Scan (lower bound: 1/1, upper bound: 1/1)

Statement 31:
-------------------------------------------------------------------------------
select * from test_dec where id between 25000000 and 26000000 order by id desc
1000001 records fetched
   3124 ms, 9130 read(s), 3002993 fetch(es)

Table                             Natural     Index    Update    Insert    Delete
*********************************************************************************
TEST_DEC                                    1000001
gstat -r:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
TEST_DEC (128)
    Primary pointer page: 181, Index root page: 182
    Total formats: 1, used formats: 1
    Average record length: 10.66, total records: 50000000
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 16.00, compression ratio: 1.50
    Pointer pages: 188, data page slots: 306752
    Data pages: 306752, average fill: 55%
    Primary pages: 306752, secondary pages: 0, swept pages: 0
    Empty pages: 3, full pages: 306748
    Fill distribution:
         0 - 19% = 3
        20 - 39% = 1
        40 - 59% = 306748
        60 - 79% = 0
        80 - 99% = 0

    Index TEST_DEC_ID (0)
        Root page: 396870,  depth: 4, leaf buckets: 144575 , nodes: 50000000
        Average node length: 11.69, total dup: 0, max dup: 0
        Average key length: 8.14, compression ratio: 1.11
        Average prefix length: 3.85, average data length: 5.15
        Clustering factor: 306749,  ratio: 0.01 
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 144574
            60 - 79% = 0
            80 - 99% = 1

Код: plaintext
1.
2.
3.
SQL> show table test_dec;
ID                               BIGINT  Not Null
CONSTRAINT INTEG_2:
  Primary key (ID) uses explicit descending index TEST_DEC_ID

Сжимаемость в два раза хуже почему-то... листовых блоков стало 144575 против прежних 73987.
А вот clustering ratio по-прежнему ОК - всего 0.01 (т.е. это означает, что при навигации для перехода к след. ключу в 99% случаев движку не придётся прыгать на другую страницу, как это было бы с длинными ключами, например; я прав в этом суждении ?)
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164397
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидСжимаемость в два раза хуже почему-то... листовых блоков стало 144575 против прежних 73987.Ибо вставка в конец индекса - это одно, а в начало - это другое. Смотри на "Fill distribution" у индексов
...
Рейтинг: 0 / 0
25 сообщений из 69, страница 2 из 3
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Умолчательное направление при построении индекса по PK
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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