powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Умолчательное направление при построении индекса по PK
69 сообщений из 69, показаны все 3 страниц
Умолчательное направление при построении индекса по PK
    #39163780
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Непонятно умолчательное направление при построении индекса по PK. То есть в 9 случаях из 10 подобное поле является целочисленным и заполняется автоинкриментом генератора, поэтому актуальность получения максимального значения по полю PK на порядок выше чем минимального. Но индекс для PK по умолчанию строиться ASC, что позволяет получать с использованием данного индекса только минимальное значение, Но не максимальное.

Т.е.
ALTER TABLE TEST
ADD CONSTRAINT PK$TEST_ID
PRIMARY KEY (ID);
Здесь Select max(id) from TEST не использует индекс, разумеется
Здесь Select min(id) from TEST использует индекс

ALTER TABLE TEST
ADD CONSTRAINT PK$TEST_ID
PRIMARY KEY (ID)
USING DESCENDING INDEX IX$TEST_ID;
Здесь будет наблюдаться обратная ситуация.

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

А как же генераторы?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163799
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposh,

все эти рассуждения чешуя. По хорошему нужны двунаправленные индексы и они должны создаваться по умолчанию. Но когда это сделают и сделают ли вообще неизвестно.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163811
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
"А как же генераторы?"
Запись может быть удалена

"нужны двунаправленные индексы"
Нужны, ой как нужны, но когда они появятся и появятся ли вообще?

А вот до их появления можно путем изменения умолчательного поведения улучшить ситуацию
Причем реализация вряд ли трудозатратна
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163813
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1) max(pk) это как-то совсем не по феншую
2) desc-индексы обычно чуть медленнее asc-индексов (ибо ключ длиннее)
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163818
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Shaposh!
You wrote on 5 февраля 2016 г. 13:00:06:

Shaposh> Непонятно умолчательное направление при построении индекса по PK.
> То есть в 9 случаях из 10 подобное поле является целочисленным и заполняется автоинкриментом генератора,
> поэтому актуальность получения максимального значения по полю PK на порядок выше чем минимального.
генератору похеру инкрементироваться, или декрементироваться.
равно как и значению поля суррогатного ключа.
инкрементируешь - твоё право.
но тогда не нужно в связи с этим пытаться изменить окружающий мир,
исходя из личного видения вселенской гармонии.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163829
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
О, опять "мимопроходящий умник" с бесполезными рассуждениями на философские темы.

Даже боюсь спросить как много разработчиков в процентном отношении получают целочисленный первичный ключ путём уменьшения генератора...
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163832
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposhактуальность получения максимального значения по полю PKВ где она ? Зачем это нужно ?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163844
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladshaposhактуальность получения максимального значения по полю PKВ где она ? Зачем это нужно ?
Для того, чтобы получить текущую (самую актуальную, самую свежую) какую-либо сущность. Получить её можно (и нужно) с помощью SELECT MAX(ID)
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163849
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ну мало ли задач при реализации бизнес-логики возникает.
Получить последнюю актуальную вставленную запись....
Что то там с неё прочитать

Мне от различных команд программистов при внедрениях просто надоело отвечать на вопрос "почему не используется индекс в запросе "SELECT MAX(ID)"
И вот никто ни разу не спросил ("почему не используется индекс при SELECT MIN(ID)")

Просто получать MIN(ID) действительно не нужно практически никогда
MAX(ID) - иногда нужно, но вот индекс для этого не подходит

Я не прошу так сделать, я предложил рассмотреть целесообразность этого
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163854
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposhНужны, ой как нужны, но когда они появятся и появятся ли вообще?
Когда кто-нибудь придумает алгоритм deadlock-free работы с двусвязным списком, чего за
последние 30 лет никто так и не сумел.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163858
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Shaposh!
You wrote on 5 февраля 2016 г. 13:26:02:

Shaposh> Я не прошу так сделать, я предложил рассмотреть целесообразность этого
юный наивный мечтатель
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163866
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
"Мимопроходящему умнику" - Ты для разнообразия, хоть что-нибудь адекватное по теме... Помимо своего обычного словесного поноса выдать в состоянии?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163870
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposh> что-нибудь адекватное по теме...

Хватит агриться уже.

По теме - по умолчанию-то оно так,
но вас же не заставляют, делайте DESC.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163876
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposhпоэтому актуальность получения максимального значения по полю PK на порядок выше чем минимального

Мне тоже кажется, что в большинстве (но далеко не во всех!) случаях в основном в таблице будт брать последние значения.
Хотя к самим генераторам это никакого отношения не имеет!

НО!

Как почти всегда в данных важно не только "как чаще всег очитают", но и соотношение как часто читают/как часто пишут. Простой пример - список и массив, в список легко данные вставлять, из массива легко читать.

shaposhцелесообразным по умолчанию строить DESС-индекс для поля PK.

...и вот тут засада, добавление "самого большого" значения в DESC-индекс сильно дороже, чем в ASC-индекс
соотв. с добавлением "самого маленького" - наоборот

http://www.sql.ru/forum/1187963/pk-indeks-ascending-ili-descending

Поэтому если таблицу часто читают и намнооого реже пишут, то можно убрать PK и вместо него явно завести Unique-индекс.

Но это насколько я понял на практике сродни ловле блох и очень редко будет заметно: вычитывание индекса с диска в память в любом случае намного дольше, чем поиск в памяти по "неудобному" индексу, и поэтому ускорение второго шага почти никогда ничего не даст.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163877
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустамно вас же не заставляют, делайте DESC.

заставляют. Сделать руками индекс для PK невозможно.

http://www.sql.ru/forum/1187963/pk-indeks-ascending-ili-descending
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163884
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Shaposh!
You wrote on 5 февраля 2016 г. 13:37:48:

Shaposh> "Мимопроходящему умнику" - Ты для разнообразия, хоть что-нибудь адекватное по теме...
зайко, тебе ж давно уже не 20, а жить в реальном мире так и не научился...
мечтай, мечтай
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163887
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да я так и делаю. Но вопрос-то не во мне

Я предположил, что изменение направления построения ключа для ПК выглядит обоснованно, ибо имеет плюсы и не имеет минусов

Dimitr указал, что минусы есть - чуть меньшая производительность

Этого достаточно, чтобы получить заключение - действительно, данный вопрос должен решаться архитектором БД при создании PK-ключа
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163890
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Arioch!
You wrote on 5 февраля 2016 г. 13:44:09:

Arioch> заставляют. Сделать руками индекс для PK невозможно.
ADD CONSTRAINT ... PRIMARY KEY ... USING DESCENDING INDEX ...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163892
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящий,

тебе ссылку зачем дали? прочитай в ней ВТОРОЕ сообщение, а ?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163897
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну или я Сибирякова не понял, странно что в той теме никто этого не упомянул
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163901
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Arioch!
You wrote on 5 февраля 2016 г. 13:47:39:

Arioch> тебе ссылку зачем дали?я не хожу по ссылкам.
ради тебя сделал исключение.
прочитал.

вывод: вася, ты лошара (с)
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163905
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arioch,

он говорил что в USING нельзя использовать существующий индекс, но зато создаётся новый с требуемым тебе направлением.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163906
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arioch> Сделать руками индекс для PK невозможно.

Ты бред какой-то несёшь.

Код: sql
1.
2.
3.
alter table add constraint PK
primary key (ID)
using descending index SpecialForOpex



Ку ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39163907
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockДля того, чтобы получить текущую (самую актуальную, самую свежую) какую-либо сущность.Причём тут значение суррогатного ПК ?

YuRockПолучить её можно (и нужно) с помощью SELECT MAX(ID)А я думал свежесть определяется датой, а актуальность - флагом состояния...
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по 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
Умолчательное направление при построении индекса по PK
    #39164461
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЗЫ. А что должно было вылезти на диске, который "со скоростью ram" ?

стоимость перестройки деревьев индексов при массовом добавлении новых листьев "в хвост" и "в гриву"

...а пока ты замерил скорость записи новых данных на HDD
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164470
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

вопрос в том, какой процент в базе таких ID составляет от остальных ID, которые GUID, хэш, и прочее, и которым этот MAX(ID) абсолютно пофиг. Вангую в 60% (для max(id)). Собственно, подозреваю, что как раз этот max(id) чаще нужен не сам по себе, а в сочетании с group by.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164479
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AriochТаблоидЗЫ. А что должно было вылезти на диске, который "со скоростью ram" ?

стоимость перестройки деревьев индексов при массовом добавлении новых листьев "в хвост" и "в гриву"

...а пока ты замерил скорость записи новых данных на HDDесли речь идёт о PK, то значения будут монотонно возрастать. И листья будут массово добавляться либо только в хвост, либо только в гриву.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164485
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvвопрос в том, какой процент в базе таких ID составляет от остальных ID, которые GUID, хэш, и прочее, и которым этот MAX(ID) абсолютно пофиг. Вангую в 60% (для max(id)).Двунаправленный скан может быть полезным, КМК, только для данных, которые каким-то образом связаны с "осязаемыми величинами": временем (прежде всего), деньгами / количеством, скоростью, температурой и проч.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164584
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladYuRockДля того, чтобы получить текущую (самую актуальную, самую свежую) какую-либо сущность.Причём тут значение суррогатного ПК ?

YuRockПолучить её можно (и нужно) с помощью SELECT MAX(ID)А я думал свежесть определяется датой, а актуальность - флагом состояния...
Не надо про коня.
Регулярно возникают задачи, в которых необходима сквозная нумерация. Тот же номер смены в торговой сети - удобно монопольно добавить запись с MAX(ID)+1 в пк. Это крайне удобно во всех отношениях - номер предыдущей смены узнать очень просто.
И вот плохо, когда номер последней смены не по индексу ищется.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164587
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это я отвечал, когда это нужно. Не спорю, что это редкий случай, для которого можно вручную указать desc для пк.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164608
ZeroMQ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shaposh3,5%. Я посчитал что это "дорого" за возможность индексированного поиска MAX(ID)
Ни в одном проекте не использовал MAX/MIN по первичному ключу. Даже не представляю, для чего это может понадобиться, кроме возможности огрести проблем в многопользовательском режиме.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164611
ZeroMQ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockhvladпропущено...
Причём тут значение суррогатного ПК ?

пропущено...
А я думал свежесть определяется датой, а актуальность - флагом состояния...
Не надо про коня.
Регулярно возникают задачи, в которых необходима сквозная нумерация. Тот же номер смены в торговой сети - удобно монопольно добавить запись с MAX(ID)+1 в пк. Это крайне удобно во всех отношениях - номер предыдущей смены узнать очень просто.
...
Генератор прочесть нельзя?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164629
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZeroMQYuRockпропущено...

Не надо про коня.
Регулярно возникают задачи, в которых необходима сквозная нумерация. Тот же номер смены в торговой сети - удобно монопольно добавить запись с MAX(ID)+1 в пк. Это крайне удобно во всех отношениях - номер предыдущей смены узнать очень просто.
...
Генератор прочесть нельзя?
Нет, он будет неинициализирован для конкретной торговой точки в центральной базе. ПК из двух ключей - TERMINAL_ID,ID.
А процедурки работают одинаково на всех базах.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164630
ZeroMQ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRockZeroMQпропущено...

Генератор прочесть нельзя?
Нет, он будет неинициализирован для конкретной торговой точки в центральной базе. ПК из двух ключей - TERMINAL_ID,ID.
А процедурки работают одинаково на всех базах.
Сурово как.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39164821
shaposh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ZeroMQ >> Сурово как

Нет, просто жизнь богаче наших схем
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165349
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидесли речь идёт о PK, то значения будут монотонно возрастать.

...или убывать, смотря что в триггере напишешь.

Таблоидлибо только в хвост, либо только в гриву.

Угу, и если бы как-то убрать bottleneck по сбросу 15М записей на HDD (RAM disk, желательно сразу партицию в обход файловой системы), то затраты на перестройку "грив" и "хвостов" (и их разница) были бы, вероятно, заметны
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165386
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Yurock!
You wrote on 8 февраля 2016 г. 11:48:19:

Yurock> Регулярно возникают задачи, в которых необходима сквозная нумерация.
в таких задачах "нумерация" не используется как РК.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165477
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МимопроходящийHello, Yurock!
You wrote on 8 февраля 2016 г. 11:48:19:

Yurock> Регулярно возникают задачи, в которых необходима сквозная нумерация.
в таких задачах "нумерация" не используется как РК.
Поздравляю, в очередной раз удачно в атмосферу вбросил.
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165481
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Yurock!
You wrote on 8 февраля 2016 г. 13:18:00:

YurockМП> в таких задачах "нумерация" не используется как РК.
> Поздравляю, в очередной раз удачно в атмосферу вбросил.мда...
если такие "самородки" проектируют БД, то комментарии излишни.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165612
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мимопроходящийесли такие "самородки" проектируют БД, то комментарии излишни.


Зато потом какое пространство для творчества - "как сделать бездырочную нумерацию, если у меня PK и есть номер, а документы удаляли вразнобой полгода"...
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165752
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DarkMasterМимопроходящийесли такие "самородки" проектируют БД, то комментарии излишни.


Зато потом какое пространство для творчества - "как сделать бездырочную нумерацию, если у меня PK и есть номер, а документы удаляли вразнобой полгода"...Не понял, о чем речь вообще, о каких документах.
В моем случае этот ID в ПК - номер смены - он уникальный на торговой точке, числовой и бездырочный и никто никогда смены не удаляет, особенно вразнобой. Каждый день открывается одна смена (примерно), т.е. за всю жизнь программы в этой таблице будет максимум тысячи записей.
Теперь обьясни мне, почему не использовать этот идентификатор как ключ ПК? Зачем вводить рядом такое же поле?
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165761
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
юрок, ты не обижайся.
ответь на пару вопросов.

1. ты самоучка?
2. как ты относишься к древней статье Толика Тенцера?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Умолчательное направление при построении индекса по PK
    #39165904
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
господа, предлагаю вернуться в чуть более конструктивное русло.
3 поста отправились в утиль.
...
Рейтинг: 0 / 0
69 сообщений из 69, показаны все 3 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Умолчательное направление при построении индекса по PK
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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