powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / GUID в качестве primary key
37 сообщений из 37, показаны все 2 страниц
GUID в качестве primary key
    #37517817
DelphiLexx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Использую в качестве первичных ключей GUID'ы (+ в репликации данных).
Стоит вопрос хранить его в явном виде в виде массива более 30 символов или
же в кодированном (с помощью стандартной ф-ции) 16 символов.
В явном виде было бы однозначно удобнее для отладки, но размер большой >30,
в неявном минус не удобство в отладке, но размер как минимум в 2 раза меньше.

Скажите, пожалуйста, влияет ли длина первичного ключа (если да то как сильно)
на скорость работы (выборка, обновления, удаления и т.п.) с базой данных?

P.S. FB 2.5
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517823
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ты integer, double, date тоже в строках хранишь? отлаживать ить удобнее. Если у тебя все в строках, то ГУИДы храни в строках, что уж единообразие рушить.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517840
DelphiLexx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_PisarevskyТы integer, double, date тоже в строках хранишь? отлаживать ить удобнее. Если у тебя все в строках, то ГУИДы храни в строках, что уж единообразие рушить.
GUID не строка - а массив байтов
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517859
olegenty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если уж на то пошло - GUID может быть только уникальным реквизитом справочников (для репликации). А ключи - просто целыми числами.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517875
DelphiLexx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegentyЕсли уж на то пошло - GUID может быть только уникальным реквизитом справочников (для репликации). А ключи - просто целыми числами.
Первичным ключом может быть что угодно (главное чтобы был уникален)
И все же влияет ли длина первичного ключа на скорость работы БД, если да,
то как сильно?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517883
olegenty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, влияет. На больших объемах данных. На маленьких - не заметишь.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517898
alexey.barkalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegentyДа, влияет. На больших объемах данных. На маленьких - не заметишь.
на больших это сколько - если таблицы милионники и их больше 100, или разницу заметишь
на более скромных объемах?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517905
DelphiLexx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexey.barkalovна больших это сколько - если таблицы милионники и их больше 100, или разницу заметишь
на более скромных объемах?
Тоже интересует этот вопрос
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517920
olegenty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проще всего ответить на твой вопрос, сваяв две базы с разными ключами, наполнив их тестовыми данными (в объемах, близких к боевым) и проведя тестовые запросы.

Считать больше данных с диска всегда медленнее, чем считать меньше данных с диска. Больший размер ключа - это больше данных. Разница будет видна только в конкретных условиях.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517960
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DelphiLexxGUID не строка - а массив байтов Курица не птица, прапорщик не офицер и далее по тексту? строка с чарактер сет октетс в аккурат и подходит для хранения массива байтов.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517961
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще - объемы ПК с GUID на диске будут гораздо больше, чем обычное число. Т.к. "инкрементный ПК" хорошо упаковывается, а нынешние GUID-ы не упаковываются.
я как-то писал статью
http://www.ibase.ru/devinfo/test2.htm

но было это давно, что-то могло измениться (не в лучшую сторону).
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517987
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvя как-то писал статью
В которой двоичные GUID-ы только упомянуты и не тестировались.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37517996
DelphiLexx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvеще - объемы ПК с GUID на диске будут гораздо больше, чем обычное число. Т.к. "инкрементный ПК" хорошо упаковывается, а нынешние GUID-ы не упаковываются.

А будет ли преимущество, если primary key все же хранить как integer, но в таблицы добавлять GUID'ное поле для уникальности и репликации?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518000
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DelphiLexx,

тут читали ?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518008
DelphiLexx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидчитали ?
прочитал, юмора не понял
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518031
miwaonline
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если мне не изменяет склероз, сабжевый вопросс уже поднимался, и Таблоид, как всегда дотошно и екстримально, проверял скорость. Разница была, но на миллионах записей в единицы, или десятки процентов.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518041
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, возможно я и ошибаюсь, но есть у меня ощущение, что большой индекс хоть и хуже на
выборках, но должен быть лучше на DML, поскольку разные коннекты могут работать с разными
индексными страницами, не толкаясь плечами.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518107
DelphiLexx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А будет ли преимущество, если primary key все же хранить как integer, но в таблицы добавлять GUID'ное поле для уникальности и репликации?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518199
Андрей Васильевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот честное слово - не понимаю я использование гуидов. Ну вот сходу если подумать, то удобство только в том что удобно разобрать таблицы на инсерты, но есть программы для сохранения ссылочной целостности. Больше не вижу плюсов. Использование инкрементов: вероятность появления переноса при увеличении на 1 в бите с номером p это 1/(2^p), да еще и то, что значение максимально компактно. А вот генерация гуида непонятно как(ну ладно понятно, но сложно и за большое количество инструкций), занимает больше место, да еще как-то надо быть уверенным в том, что гуид действительно уникален. Ладно можно ввести ограничение уникальности, но количество инструкций это не уменьшает. Да еще и на больших базах. Зачем такие сложности?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518293
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovбольшой индекс хоть и хуже на выборках, но должен быть лучше на DML, поскольку разные коннекты могут работать с разными индексными страницами, не толкаясь плечами.Размер ключа влияет на частоту расщепления страниц. При GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем 16 байт на ключ, при int - 4).
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518311
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DelphiLexxпрочитал, юмора не понял виноват, при указании ссылки потерял последнюю цифру номера темы.
Вот тест оттуда: http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=766493&msg=8966864
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518327
Фотография PEAKTOP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей ВасильевичВот честное слово - не понимаю я использование гуидов.
........................................
да еще как-то надо быть уверенным в том, что гуид действительно уникален.

GUID - действительно уникален.

А смысл использования - синхронизация данных N-баз филиалов с Центральной базой (кажется, здесь принято называть это репликацией).

Независимо от выбранного способа репликации (специально обученная тулза, голый SQL через cross-database запросы), так или иначе все упирается в решение задачи: "запись имеет ID. какой ID она имеет во внешней базе ?". Следовательно, при решении задачи репликации эту информацию нужно хранить. При использовании GUID мы можем ее не хранить, а идентификатор записи будет одинаковым как в ЦентральноБазе, так и в базе филиала, откуда запись пришла.

Вроде бы на первый взгляд - уменьшение размера БД, т.к. мы не храним информацию о соответствии записей в Центральной базе с записями в базах филиалов. Но при этом:
1) БД растет из-за того, что GUID весят гораздо больше, чем INTEGER.
2) Индекс по INTEGER - был и всегда будет самым производительным, ибо одно дело сравнить два LongInt, а другое - сравнить две string[32] (ну хорошо, пусть будет два array[0..31] of byte).

Я как-то задавался этим вопросом года два назад и решил поэксперементировать на рабочей базе клиента, введя дополнительные домены. Выигрыша не получил, зато получил проигрыш и время зря убил. (перевести все филиалы на GUID - одна неделя, репликация и отладка - вторая неделя, неделя эксперементов и получение личного опыта, что "все фигня, кроме пчел", и одна неделя - "вернуть все на родину").
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518370
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DelphiLexxА будет ли преимущество
Будет геморрой, приводящий к избыточности и тормозам.

ТаблоидПри GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем
16 байт на ключ, при int - 4).
Да, но расщепляться при этом будут разные страницы, так что этот процесс может идти
параллельно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518462
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидРазмер ключа влияет на частоту расщепления страниц. При GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем 16 байт на ключ, при int - 4). Ты залей лимон записей с guid и с int, потом посмотри кол-во страниц каждого индекса и ср. размер ключа.
Ни 4, ни 16 ты там не увидишь :)
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518612
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТы залей лимон записей с guid и с int, потом посмотри кол-во страниц каждого индекса и ср. размер ключа.
Ни 4, ни 16 ты там не увидишь :)Вот результат для 1 ляма GUID в базе с pagesize=4096: Average data length: 14.05
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
SQL> create database "ttt04.fdb" pagesize  4096 ;
SQL> commit;
SQL> exit;

[firebird@firebird firebird]$ isql -c 65536 ttt04.fdb
Database:  ttt04.fdb

SQL> set stat off;
SQL> commit;
SQL> set echo off;
SQL> recreate table ttt(uid char(16) character set octets not null, primary key(uid));
commit;
set stat on;
set term ^;
execute block as
declare n int = 1000000;
begin
  while (n>0) do insert into ttt values(gen_uuid()) returning :n-1 into n;
end^
set term ;^
commit;
set stat off;
set echo on;

Код: 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.
[firebird@firebird firebird]$ gstat -r -t TTT ttt04.fdb

Database "ttt04.fdb"
Database header page information:
        Flags                   0
        Checksum                12345
        Generation              13
        Page size               4096
        ODS version             11.2
        Oldest transaction      8
        Oldest active           9
        Oldest snapshot         9
        Next transaction        10
        Bumped transaction      1
        Sequence number         0
        Next attachment ID      2
        Implementation ID       24
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Nov 9, 2011 15:56:18
        Attributes              force write

    Variable header data:
        *END*


Database file sequence:
File ttt.fdb is the only file

Analyzing database pages ...
TTT (128)
    Primary pointer page: 165, Index root page: 166
    Average record length: 21.00, total records: 1000000
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 15152, data page slots: 15152, average fill: 62%
    Fill distribution:
         0 - 19% = 0
        20 - 39% = 1
        40 - 59% = 0
        60 - 79% = 15151
        80 - 99% = 0

    Index RDB$PRIMARY1 (0)
        Depth: 3, leaf buckets: 7360, nodes: 1000000
         Average data length: 14.05 , total dup: 0, max dup: 0
        Fill distribution:
             0 - 19% = 70
            20 - 39% = 3
            40 - 59% = 2434
            60 - 79% = 3044
            80 - 99% = 1809

А int-ключи трамбуются очень серьёзно: средняя длина ключика = 1 байту :-)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
 [code=plaintext]set stat off;
commit;
set echo off;
--recreate table ttt(uid char(16) character set octets not null, primary key(uid));
recreate table ttt(id int primary key);
commit;
set stat on;
set term ^;
execute block as
declare n int = 1000000;
begin
  --while (n>0) do insert into ttt values(gen_uuid()) returning :n-1 into n;
  while (n>0) do insert into ttt values(:n) returning :n-1 into n;
end^
set term ;^
commit;
set stat off;
set echo on;

[firebird@firebird firebird]$ gstat -r -t TTT ttt04.fdb

Database "ttt04.fdb"
Database header page information:
Flags 0
Checksum 12345
Generation 25
Page size 4096
ODS version 11.2
Oldest transaction 16
Oldest active 17
Oldest snapshot 17
Next transaction 18
Bumped transaction 1
Sequence number 0
Next attachment ID 5
Implementation ID 24
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Nov 9, 2011 15:56:18
Attributes

Variable header data:
*END*


Database file sequence:
File ttt04.fdb is the only file

Analyzing database pages ...
TTT (129)
Primary pointer page: 22762, Index root page: 22763
Average record length: 9.00, total records: 1000000
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 12346, data page slots: 12346, average fill: 52%
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 12345
60 - 79% = 0
80 - 99% = 0

Index RDB$PRIMARY2 (0)
Depth: 3, leaf buckets: 3392, nodes: 1000000
Average data length: 1.01 , total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 3391
60 - 79% = 1
80 - 99% = 0
Как сильно повлияет такая разница (14 раз) на число расщеплений и будет ли это вообще "просаживать" производительность - не знаю.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518698
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чем больше записей, тем лучше будут сжиматься GUID ключи
Разницы в 14 раз конечно нет - сравни кол-во страниц идексов.
Правда, индекс по int оказался слабее заполнен - это от того, что ты задом наперёд INT ключи вставлял.
Если бы вставлял последовательно, то заполнение было бы гораздо выше.
Но для честного сравнения с GUID нужно генерить случайные значения.
Ну а для эмуляции ПК - каверное всё же последовательно возрастающие.

На кол-во расщеплений страниц индекса влияет как распределение значений ключей (случайное для GUID против последовательного для INT), так и заполненность страниц.
Так что я бы сказал, что для ПК-GUID конкуренция за вставку в индекс должна быть гораздо ниже, чем для последовательных INT значений.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518744
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladя бы сказал, что для ПК-GUID конкуренция за вставку в индекс должна быть гораздо ниже, чем для последовательных INT значений.А как можно понять, что при работе 100500 коннектов на вставку некоторые из них будут томиться в ожидании именно индекса (а не генератора, скажем; при условии, что я дёргаю gen_id с шагом 1, а не "пачками") ?
В логе сервера всё равно ничего не увидишь :(

ЗЫ. Кстати, в "одной другой субд" уже давно есть (числовые) индексы реверсивного ключа - как раз для предотвращения конфликтов крайнюю индексную страницу дерева при многочисленных вставках.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518775
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА как можно понять, что при работе 100500 коннектов на вставку некоторые из них будут томиться в ожидании именно индекса (а не генератора, скажем; при условии, что я дёргаю gen_id с шагом 1, а не "пачками") ? Ни как. Разве что смотреть вывод lock print для классика.

ТаблоидВ логе сервера всё равно ничего не увидишь :(А при чём тут лог сервера ?
Напомню - он существует исключительно для информации о ошибках, в основном о фатальных (и для твоих любимых сетевых )

ТаблоидЗЫ. Кстати, в "одной другой субд" уже давно есть (числовые) индексы реверсивного ключа - как раз для предотвращения конфликтов крайнюю индексную страницу дерева при многочисленных вставках. Пиши udf, если это для тебя настолько важно.

Только я тебе сразу скажу - при твоих десятках индексов на таблицу это не поможет :)
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #37518847
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad(и для твоих любимых сетевых )я думаю, они тут многими горячо "любимы". Разговор про них начался больше года назад...
"Но это уже совсем другая история" (С)
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
GUID в качестве primary key
    #39078357
eXandr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет, вопрос а тройке-четверке FB не планируется добавить GUID тип? ну чтобы он хранился как бинари (16 байт) и кастился в строку?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #39078376
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
eXandr,

в тройке точно нет. Да и в четвёрке вряд ли. А нафига?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #39078472
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
eXandr,

в 2.5 добавлены функции char_to_uuid, uuid_to_char, gen_uuid.
все работает с
CHAR(16) CHARACTER SET OCTETS.

см. документацию, стр 350.
http://www.ibase.ru/firebird/Firebird_2_5_Language_Reference_RUS.pdf
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #39078504
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
поправка - gen_uuid еще в 2.1 появился.

однако, вопрос с "непоследовательностью" gen_uuid все равно остается. В MS SQL есть newsequentialid
" Можно воспользоваться для формирования идентификаторов GUID функцией NEWSEQUENTIALID, что позволяет уменьшить конфликты страниц на конечном уровне индексов. "

Иначе вставка в такой ПК раза в три медленнее (в ФБ, тест Таблоида и Ковязина).

писать feature request в трекер?
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #39078524
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvоднако, вопрос с "непоследовательностью" gen_uuid все равно остается.

Лично я бы uuid-ключи генерил на клиенте, а там этот вопрос решается легко.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #39078526
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvвставка в такой ПК раза в три медленнее (в ФБ, тест Таблоида и Ковязина).

Именно сама вставка или генерация uuid по сравнению с последовательностью?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #39078551
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

вставка в таблицу с ПК bigint/uuid. Проблема известная, и есть во всех СУБД с b-tree индексами. Кроме того, ключ обычного guid-uuid плохо упаковывается, и индекс сам по себе получается еще и в 4 раза больше, чем в случае последовательных (упакованных) значений.
...
Рейтинг: 0 / 0
GUID в качестве primary key
    #39078762
fb_user
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdvпоправка - gen_uuid еще в 2.1 появился.

однако, вопрос с "непоследовательностью" gen_uuid все равно остается. В MS SQL есть newsequentialid
" Можно воспользоваться для формирования идентификаторов GUID функцией NEWSEQUENTIALID, что позволяет уменьшить конфликты страниц на конечном уровне индексов. "

Иначе вставка в такой ПК раза в три медленнее (в ФБ, тест Таблоида и Ковязина).

писать feature request в трекер?
Однозначно писать
...
Рейтинг: 0 / 0
37 сообщений из 37, показаны все 2 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / GUID в качестве primary key
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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