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

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

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

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

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

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

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

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

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

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

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

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

ТаблоидПри GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем
16 байт на ключ, при int - 4).
Да, но расщепляться при этом будут разные страницы, так что этот процесс может идти
параллельно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
09.11.2011, 15:24
    #37518462
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GUID в качестве primary key
ТаблоидРазмер ключа влияет на частоту расщепления страниц. При GUID число расщеплений должно быть в 4 раза больше (ибо при GUID имеем 16 байт на ключ, при int - 4). Ты залей лимон записей с guid и с int, потом посмотри кол-во страниц каждого индекса и ср. размер ключа.
Ни 4, ни 16 ты там не увидишь :)
...
Рейтинг: 0 / 0
09.11.2011, 16:36
    #37518612
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GUID в качестве primary key
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
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / GUID в качестве primary key / 25 сообщений из 37, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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