ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
25 сообщений из 189, страница 4 из 8
  4  все
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346519
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
up.

Проверяю подключение клиента WI-2.5 к серверу LI-3.0, на котором пересоздана эта таблица (1 млрд строк).
Машина сервера после этого была перезагружена (shutdown -r now).

Таблица была создана под sysdba, в embedded-подключении (дабы быстрее) при этом не привилегированному юзеру с именем `u25` никаких прав на неё выдано не было - забыл про это.
Затем подключился к базе по tcp, с виндовой машины, под юзером `u25`. Само подключение (появление подсказки в isql) выполнилось практически мгновенно, т.е. как и в обычных случаях.

Далее ввёл запрос:
Код: plaintext
1.
SQL> set stat on;
SQL> select * from t where id = 789456123;

Сразу после этого в логе трейса появилось:
Код: plaintext
1.
2013-07-28T01: 02:37 .9650 (2211:0x7ff34c096148) TRACE_INIT
        SESSION_1
- но ТОЛЬКО это сообщение там и оставалось видимым в течение следующих 3 минут .


И только через 3 минуты в трейсе вылезло:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
2013-07-28T01: 05:34 .2520 (2211:0x7ff34c096148) UNAUTHORIZED PREPARE_STATEMENT
        test01 (ATT_43, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1896
                (TRA_46, CONCURRENCY | WAIT | READ_WRITE)

-------------------------------------------------------------------------------
select * from t where id = 789456123
 176287 ms

2013-07-28T01:05:34.2520 (2211:0x7ff34c096148) ERROR AT JStatement::prepare
        test01 (ATT_43, U25:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1896
335544352 : no permission for SELECT access to TABLE T

А isql выплюнул соотв-щий облом:
Код: plaintext
1.
Statement failed, SQLSTATE = 28000
no permission for SELECT access to TABLE T

Как говорилось выше в этом топике, на "холодной базе" первый запрос (даже по индексу PK) будет выполняться долго из-за вычитки PP.
Но ведь ДО начала этой вычитки FB проверяет мои права на запрашиваемый объект - не так ли ?
А права эти живут в крохотных RDB$-таблицах. Проверка этих RDB$таблиц должна выполняться мгновенно.

Тогда откуда лезут эти три минуты(!), чтобы дать в итоге облом по no permission for SELECT ?
...
Рейтинг: 0 / 0
28.07.2013, 01:24:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346524
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоид ЭКСПЕРИМЕНТ-2.
В первом окне ввожу запрос к таблице `t` на выборку данных (не подсчет строк - а именно выборку полей).
Во втором окне пытаюсь срубить деятельность окна_1 через
Код: sql
1.
commit; delete from mon$statements ...;



Результат: ноль. Окно_1 будет работать, невзирая на все потуги окна_2. Срубить окно_1 можно только через delete from mon$attachments.особенность текущей реализации, к сожалению. Удалить (сиречь: остановить) можно только активный риквест. А в твоем случае он всегда опознается как неактивный (stalled), мы это уже обсуждали недавно. Я подумаю, что тут можно сделать .Кое-что действительно сделано. Но хотелось бы решить вопрос со скоростью реакции на delete from mon$statements "радикально и навсегда".

Повторил этот эксперимент на "разогретой" базе.

Запустил сначала isql в первом окне и ввёл там:
Код: plaintext
1.
2.
C:\MIX\firebird\fb25>isql.exe 192.168.99.44:test01 -user sysdba -pas masterke -n
Database:  192.168.99.44:test01, User: sysdba
SQL> select * from t where id between 123456789 and 789456123;

ФБ занялся сканированием индекса в поисках записи с id >= 123456789. Он делает это настолько медленно, что никакого вывода строк на экран не происходит даже в течение 10-15 секунд.
Поэтому во втором cmd-окне можно неспешно:
1) запустить isql
2) ввести там:
Код: plaintext
SQL> commit; delete from mon$statements where mon$attachment_id<>current_connection; commit;

Повторил эти действия 4 раза.
Результат: окно-1 реагирует на delete from mon$statements (от окна-2) не сразу, а только через 20-30 секунд, а в последний раз - почти 4 минуты(!)
 
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.
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.
2013-07-28T 01:39:32 .3280 (2296:0x7f6f2781e018) EXECUTE_STATEMENT_START
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 40:
-------------------------------------------------------------------------------
delete from mon$statements where mon$attachment_id<>current_connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)

2013-07-28T01:39:34.3480 (2296:0x7f6f2781d1f8) DETACH_DATABASE
        /opt/fb30cs/security3.fdb (ATT_495, SYSDBA:NONE, NONE, <internal>)

2013-07-28T01:39:34.3480 (2296:0x7f6f2781d1f8) TRACE_FINI
        SESSION_2


2013-07-28T 01:43:11 .4380 (2296:0x7f6f2781e018) EXECUTE_STATEMENT_FINISH
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 40:
-------------------------------------------------------------------------------
delete from mon$statements where mon$attachment_id<>current_connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)
0 records fetched
 219109 ms, 33 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$RELATIONS                                     8                                                           

2013-07-28T01:43:11.4380 (2296:0x7f6f2781b148) FAILED EXECUTE_STATEMENT_FINISH
        test01 (ATT_66, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1588
                (TRA_73, CONCURRENCY | WAIT | READ_WRITE)

Statement 22:
-------------------------------------------------------------------------------
select * from t where id between 123456789 and 789456123
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T INDEX (RDB$PRIMARY1))
0 records fetched
 233700 ms, 406624 read(s)

2013-07-28T01:43:11.4380 (2296:0x7f6f2781b148) ERROR AT JStatement::openCursor
        test01 (ATT_66, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1588
335544794 : operation was cancelled

2013-07-28T01:43:11.4390 (2296:0x7f6f2781e018) FREE_STATEMENT
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468

Statement 40:
-------------------------------------------------------------------------------
delete from mon$statements where mon$attachment_id<>current_connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (MON$STATEMENTS NATURAL)

2013-07-28T01:43:11.4400 (2296:0x7f6f2781e018) COMMIT_TRANSACTION
        test01 (ATT_68, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1468
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 1 read(s), 1 write(s), 1 mark(s)

Кажется, это как-то связано с тем, сколько времени прошло от момента старта select'a в окне-1 до момента ввода delete from mon$statements в окне-2. Есть подозрение, что чем дольше давать поискать окну-1 первую запись, тем дольше у него будет "отходняк" при получении команды обруба.

В общем, таблица-миллиардник и на ФБ-3 продолжает оставаться "серьёзным игроком" :-)
...
Рейтинг: 0 / 0
28.07.2013, 01:48:56
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346538
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Да, и еще.

Среди 1 млрд строк есть 12, у которых в поле `h`, заполнявшемся как hash(s), записаны дубли.
 
Код: 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.
Database:  test01.fdb
SQL> show table t;
ID                              INTEGER Not Null
S                               VARCHAR(36) Nullable
H                               BIGINT Nullable
CONSTRAINT INTEG_2:
  Primary key (ID)

SQL> set stat on; set explain on; select h,count(*) h_cnt from t group by h having count(*)>1;

Select Expression
    -> Filter
        -> Aggregate
            -> Sort
                -> Table "T" Full Scan

                    H                 H_CNT
===================== =====================
    23892282818693425                     2
    26121068392037974                     2
    39144859051103730                     2
    42731417555628722                     2
   116515253492760935                     2
   907260062758124950                     2
   916797897021246051                     2
   960976570354906997                     2
   969133800131399768                     2
   971045795196823170                     2
  1037847731177921477                     2
  1124736694581280582                     2

Current memory = 1428584
Delta memory = 364776
Max memory = 686304024
Elapsed time= 5695.44 sec
Cpu = 0.15 sec
Buffers = 8192
Reads = 24444277
Writes = 0
Fetches = 2024398059
SQL>
То есть, либо uuid_to_char(gen_uuid()) способен сгенерить 12 дублей на 1 млрд, либо хэши от этих 36-символьных строк могут совпадать ввиду коллизий (что странно на такой длине текста).
Точнее сказать пока не могу - надо вытряхнуть данные. Пытался создать индекс по `h` - умерло: top показывал, что процесс firebird вообще ни хрена не делает, а isql что-то там пытается грузить, но как-то вяло.
Сейчас просто натравлю запрос на извлечение по natural'у.
...
Рейтинг: 0 / 0
28.07.2013, 09:26:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346542
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоидлибо uuid_to_char(gen_uuid()) способен сгенерить 12 дублей на 1 млрд, либо хэши от этих 36-символьных строк могут совпадать ввиду коллизий (что странно на такой длине текста).Второй вариант. Коллизии, и только они.
Вот список 12*2 uuid-строк, по которым hash выдает одинаковые значения:HS1037847731177921477EA00D44E-64C9-48C0-8438-FA04AA662E051037847731177921477F3EDA604-DD22-449D-A5F2-6DB4204082F5112473669458128058212DB8574-AADC-45FA-A24B-CC4911CDC00F112473669458128058250F6FD32-7FEB-4E2A-A61C-5519467248A6116515253492760935BC4BB00D-8EA6-437F-B7EC-EBF25DF7D4F7116515253492760935D4DDAEA1-8E0A-4B5E-9D6C-E3874B83EB272389228281869342534585795-70B6-40F3-8859-B15851B2540A23892282818693425511DAF0B-FC44-4AB9-A8B3-CC6165897A0A261210683920379748E4622FF-9264-4285-8934-5B525CF2F9062612106839203797499CC7926-045F-40F2-A464-0AEFF07B52CF39144859051103730143AD095-6FEF-44E9-87D7-A135D24BC9E23914485905110373064BE5888-AE20-4218-A3A6-F492ACFAD28B4273141755562872243BF4105-5234-4662-903E-2EE9429E56A242731417555628722E5F4CCC6-4CE3-4301-BABE-14C83A58C8DB90726006275812495038D18A5B-46E5-4C1D-8D36-3180A280E75690726006275812495070979264-2CC6-4BBE-8D0F-A7213B07CA5691679789702124605138285431-2C6F-468B-B7CA-4A83F8666E1391679789702124605194BF2544-F47A-4209-B410-326597F1E5639609765703549069971D24B10E-EBE3-44EB-AA78-4A57167CD645960976570354906997736DA53E-4335-40E6-B879-D23218825FA5969133800131399768D4D0DAAF-0074-42F8-9487-08573F84EBD8969133800131399768FE7BF9D2-0755-425D-8554-234B26BDCBB8971045795196823170B115F1BB-6176-47AA-A7CE-60322918C472971045795196823170E7254E81-3D9B-48C2-9A65-AA27475B303BСтранно как-то это, на длине в 36 знаков.
...
Рейтинг: 0 / 0
28.07.2013, 10:08:10
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346780
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидТогда откуда лезут эти три минуты(!), чтобы дать в итоге облом по no permission for SELECT ?
насколько я помню - запрос сначала полностью препарится, потом проверяются права. А препарирование включает в себя скан всех PP.
...
Рейтинг: 0 / 0
28.07.2013, 21:13:31
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346781
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
dimitrА препарирование включает в себя скан всех PP.
(я и то помню это по тесту терабайтной БД).
а вроде предполагались какие-то улучшения в этом плане? Я именно про скорость prepare.
...
Рейтинг: 0 / 0
28.07.2013, 21:16:05
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346788
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
kdv,

предполагались, но пока есть по ним некоторые сомнения
...
Рейтинг: 0 / 0
28.07.2013, 21:22:50
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346807
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидТогда откуда лезут эти три минуты(!), чтобы дать в итоге облом по no permission for SELECT ?
насколько я помню - запрос сначала полностью препарится, потом проверяются права. А препарирование включает в себя скан всех PP.Погоди-ка... вот есть запрос: select ляляля from тратата1 join тратата2 on ...
Разве нельзя на стадии prepare сразу же вытряхнуть имена объектов (тратата1, тратата2), к которым хотят лезть, и тут же, до всяких там PP-вычиток, проверить права на них ?
...
Рейтинг: 0 / 0
28.07.2013, 21:45:26
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346826
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

это все делается на стадии препаре, просто в разные фазы. Простого парсинга тут недостаточно, т.к. надо проверять весь граф поднятых запросов зависимостей. Да и вообще, не получается там по-другому.
...
Рейтинг: 0 / 0
28.07.2013, 21:55:51
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346833
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrэто все делается на стадии препаре, просто в разные фазы. Простого парсинга тут недостаточно, т.к. надо проверять весь граф поднятых запросов зависимостей. Да и вообще, не получается там по-другому.А просвяти, плз: если запрос содержит обращения к 10 объектам БД, то что будет происходить при prepare:
1) парсер будет сначала вытряхивать одно имя за другим, НЕ проверяя права на них, до тех пор, пока не "распознает" 10-е имя; и только после получения 10-го имени начнётся проверка прав
либо
2) парсер вытряхнет имя_1, затем тут же будут проверены права на него; дальше, если права есть, парсер вытащит имя_2 итут же будут проверены права на имя_2, и т.п.
- ?
...
Рейтинг: 0 / 0
28.07.2013, 21:59:54
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346837
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

составляется весь список и потом проверяется оптом
...
Рейтинг: 0 / 0
28.07.2013, 22:01:33
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346845
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrсоставляется весь список и потом проверяется оптомОК, с этим понятно.
Но вернусь к первому вопросу: вот когда в запросе есть только 1 объект - почему для препарирования запроса надо лазить по всем PP ? Чем это вызвано ?
...
Рейтинг: 0 / 0
28.07.2013, 22:06:40
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346848
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоидпочему для препарирования запроса надо лазить по всем PP ? Чем это вызвано ?
склероз у тебя, хотя dataaccesspaths ты вроде неоднократно читал. по PP сервер вычисляет кардинальность таблицы, т.е. сколько там может быть записей (теоретически).
...
Рейтинг: 0 / 0
28.07.2013, 22:09:07
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346851
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvТаблоидпочему для препарирования запроса надо лазить по всем PP ? Чем это вызвано ?
склероз у тебя, хотя dataaccesspaths ты вроде неоднократно читал. по PP сервер вычисляет кардинальность таблицы, т.е. сколько там может быть записей (теоретически).не-е, это я помню!
У мну вопрос простой: зачем он начинает считать "скока вешать граммов" до того, как поймёт, имеет ли он право вообще трогать сей товар! Почему нельзя сначала в rdb$-таблицы полезть и проверить, есть ли права на соотв-щую таблицу у того, кто её "хочет" ?
...
Рейтинг: 0 / 0
28.07.2013, 22:13:22
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346855
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидУ мну вопрос простой: зачем он начинает считать "скока вешать граммов" до того, как поймёт, имеет ли он право вообще трогать сей товар! Почему нельзя сначала в rdb$-таблицы полезть и проверить, есть ли права на соотв-щую таблицу у того, кто её "хочет" ?
нет, ты перескакиваешь с вопроса на вопрос. Prepare строит план и проверяет права.
Зачем Prepare считывает PP? Чтобы узнать кардинальность таблиц и построить план запроса.
Можно отделить в Prepare построение плана от проверки прав? Ответ тут 14629558
Увы.
...
Рейтинг: 0 / 0
28.07.2013, 22:15:41
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346859
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kdvМожно отделить в Prepare построение плана от проверки прав?

Да фиг с ним, отделением. Таблоид-то спрашивает про очерёдность. Права проверяются на все
объекты, задействованные во всех возможных ветках всех возможных планов. Если права на
операцию нет, то проверка на это, произведённая чуть раньше (при добавлении объекта в
список и граф) и выкинувшая исключение, сэкономит кучу времени.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
28.07.2013, 22:20:29
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346861
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvPrepare строит план и проверяет права.Если сначала строится план, и только после проверяются права, то выглядит это как-то... странно! Будешь ли ты оценивать время движения по платной дороге, не выяснив, есть ли у тебя хотя достаточно бабла в кармане для оплаты ?
kdvЗачем Prepare считывает PP? Чтобы узнать кардинальность таблиц и построить план запроса.Да понимаю я это, разумеется.
kdvМожно отделить в Prepare построение плана от проверки прав? Ответ тут 14629558
Увы.к сож-ю, ответ ДЕ не прояснил мне моцк:dimitrПростого парсинга тут недостаточно, т.к. надо проверять весь граф поднятых запросов зависимостей. Да и вообще, не получается там по-другому. Ну, подняли граф зависимостей, там 10 объектов.
Что мешает сначала выяснить права на них, немедленно выдавая отказ в работе при отсутствии хотя бы одного из прав, а затем вычитывать PP ??
...
Рейтинг: 0 / 0
28.07.2013, 22:27:26
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346902
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Тут еще один таракан на тему скорости вылез.
Пересоздал базу с нуля, поставил в ней FW = OFF, добавил кеш до 16384.
Создал таблицу t(id int, s char(36));
Добавил в эту таблицу свой любимый млрд строк, поле `s` генерил через uuid_to_char(), в поле id записывал gen_id(g, 1).
Добавил индекс: create index t_s on t(s); commit;

А теперь хочу всё таки еще раз выяснить: нет ли сдублированных значений в `s`.
И делаю запрос:
Код: sql
1.
2.
3.
SQL> select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id;

PLAN JOIN (T1 NATURAL, T2 INDEX (T_S))

Он молотил два часа и было нгепонятно, закончится это когда-нить или нет. Я срубил его и увидел по трейсу, что правильно сделал (см статистику!):
Код: 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.
2013-07-28T21:56:12.6930 (4467:0x7fe8418d35b8) EXECUTE_STATEMENT_START
        test01 (ATT_11, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1916
                (TRA_52, CONCURRENCY | WAIT | READ_WRITE)

Statement 259:
-------------------------------------------------------------------------------
select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (T1 NATURAL, T2 INDEX (T_S))

2013-07-28T23:51:49.8400 (4467:0x7fe8418d35b8) FAILED EXECUTE_STATEMENT_FINISH
        test01 (ATT_11, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1916
                (TRA_52, CONCURRENCY | WAIT | READ_WRITE)

Statement 259:
-------------------------------------------------------------------------------
select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (T1 NATURAL, T2 INDEX (T_S))
0 records fetched
 6937146 ms , 1264903 read(s), 5397222 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                   632066    632066                                                           

2013-07-28T23:51:49.8940 (4467:0x7fe8418d35b8) ERROR AT JStatement::fetch
        test01 (ATT_11, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
        C:\MIX\firebird\fb25\bin\isql.exe:1916
335544794 : operation was cancelled

Товарищи! "Чё-то не того!" 632 тыс записей обмолочено за 6900 сек - это что же получается-то ?!
...
Рейтинг: 0 / 0
29.07.2013, 00:24:06
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346903
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
PS. Добавил в условие join'a предыдущего запроса "дёргание" генератора, чтобы в другом окне хотя бы видеть скорость изменений:
Код: plaintext
1.
2.
SQL> select first 1 t1.* from t t1 join t t2 on t1.s=t2.s and t1.id<t2.id and t1.id+gen_id(g,1)>=0;

PLAN JOIN (T1 NATURAL, T2 INDEX (T_S))

Результат: ужасный кошмар. За полчаса обмолочено менее 180 тыс строк:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SQL> select  current_timestamp, gen_id(g,0) from rdb$database;

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-28 23:53:41.7730             1000004160


SQL> select  current_timestamp, gen_id(g,0) from rdb$database;

        CURRENT_TIMESTAMP                GEN_ID
========================= =====================
2013-07-29 00:23:23.6460             1000182007

И типичная картина из top'a в это время (да, я понимаю, что 4 Гб памяти мало - но пока это всё, что есть; но с серваком работаю я один):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
top - 00:27:28 up 23:55,  2 users,  load average: 1.27, 1.38, 1.40
Tasks: 122 total,   1 running, 121 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.7%us,  1.5%sy,  0.0%ni, 88.6%id,  6.1%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  3.2%us,  1.6%sy,  0.0%ni, 88.7%id,  6.4%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  1.9%us,  0.8%sy,  0.0%ni, 92.8%id,  4.5%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  1.3%us,  0.7%sy,  0.0%ni, 95.3%id,  2.7%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  2.3%us,  1.0%sy,  0.0%ni, 92.7%id,  3.9%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  1.5%us,  1.0%sy,  0.0%ni, 91.7%id,  5.8%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  1.8%us,  1.1%sy,  0.0%ni, 86.7%id, 10.5%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  1.3%us,  0.5%sy,  0.0%ni, 94.4%id,  3.8%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4056652k total,  3945504k used,   111148k free,     4300k buffers
Swap: 16383996k total,    27412k used, 16356584k free,  3506812k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4467 firebird  20   0  603m  90m 3424 S  2.7  2.3  99:21.21 firebird
...
Рейтинг: 0 / 0
29.07.2013, 00:31:13
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346930
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

индекс T_S какого размера, в страницах?
1264903 read(s)
как бы намекает, что он тупо не влезает в кэш, а значит читается каждый раз, с диска.
...
Рейтинг: 0 / 0
29.07.2013, 01:59:34
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38346980
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvиндекс T_S какого размера, в страницах?
1264903 read(s)
как бы намекает, что он тупо не влезает в кэш, а значит читается каждый раз, с диска.Индекс весит 9.1 млн страниц.
Не понимаю, что тут фатального: "не влезает в кеш". В пром. системах полно таблиц-монстров, индексы которых не влезают в кеш - но ворочаются же.
 
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.
Analyzing database pages ...
T (129)
    Primary pointer page: 183, Index root page: 187
    Total formats: 2, used formats: 1
    Average record length: 43.20, total records: 1000000000
    Average version length: 9.00, total versions: 1000000000, max versions: 1
    Average fragment length: 5.00, total fragments: 224006938, max fragments: 1
    Average unpacked length: 44.00, compression ratio: 1.02
    Pointer pages: 26742, data page slots: 24147141
    Data pages: 24147141, average fill: 96%
    Primary pages: 20407914, full pages: 24147139, swept pages: 0
    Fill distribution:
         0 - 19% = 0
        20 - 39% = 1
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 24147140

    Index T_S (0)
        Root page: 21213781, depth: 5, leaf buckets: 9108033, nodes: 1000000000
        Average node length: 36.11, total dup: 0, max dup: 0
        Average key length: 32.11, compression ratio: 1.12
        Average prefix length: 6.88, average data length: 29.12
        Clustering factor: 999999950, ratio: 1.00
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 1
            80 - 99% = 9108032
PS. тьфу... забыл я, что гстат показывает total dup... надо было сразу сюда посмотреть.
...
Рейтинг: 0 / 0
29.07.2013, 09:10:25
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38347035
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Таблоид,

Ребята, миллиарды записей -- это не для таких СУБД. Не для традиционных. Только columnstore.
...
Рейтинг: 0 / 0
29.07.2013, 10:07:06
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348006
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
ТаблоидЧто мешает сначала выяснить права на них, немедленно выдавая отказ в работе при отсутствии хотя бы одного из прав, а затем вычитывать PP ??Попытка выполнить запрос не обладая привилегиями почти наверняка "криминал", встречается относительно легитимных запросов крайне редко, ну допустим 1%, ради одного процента шулеров будешь перетряхивать всю проверку? Хотя с другой стороны очень легкий способ вызвать отказ в обслуживании. Вот ради превентивных мер против DOS может и стОит перетряхнуть?

MasterZivРебята, миллиарды записей -- это не для таких СУБД. Не для традиционных. Только columnstore.Для или не для, но многие проблемы можно поймать только нагрузочным тестом превышающим рабочую нагрузку. Спрашивается нахрена котлы проверять давлением превышающим рабочее? вот и миллиард примерно для того же самого.
...
Рейтинг: 0 / 0
29.07.2013, 23:48:49
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348025
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
 
0xFFIvan_PisarevskyСпрашивается нахрена котлы проверять давлением превышающим рабочее? вот и миллиард примерно для того же самого.
Нам в институте читали курс ТММ ("Теория машин и механизмов"), так вот: силовые тросы лифтов в жилых домах рассчитаны на нагрузку, в 12 (двенадцать) раз превышающую ту, что написана на куске жести, привинченной в кабине лифта.
...
Рейтинг: 0 / 0
30.07.2013, 00:37:01
| Ответить | Цитировать | Написать  
Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
    #38348047
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Ivan_PisarevskyХотя с другой стороны очень легкий способ вызвать отказ в обслуживании.я пока вижу одно: таблица в 1 млрд записей очень трудно ворочается. Она постоянно вытесняется на диск и "вычитка" PP становится явно узким местом. И даже select first 1 из неё запросто может стать гемором для бедного сервера.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
[root@vmoel63 fb30]# /opt/fb30cs/bin/isql -n test01.fdb
sDatabase:  test01.fdb
SQL> select current_timestamp from rdb$database; set stat on;  select first 1 * from t; 

        CURRENT_TIMESTAMP
=========================
2013-07-30 01:25:53.0380 // это в логе трейса появилось сразу, а дальше - более двух минут тишина


S                                              ID
==================================== ============
7B090244-F381-4640-8E41-B59201027A52            1

Current memory = 1223456
Delta memory = 278592
Max memory = 1292504
 Elapsed time= 164.79 sec 
Cpu = 0.00 sec
Buffers = 16384
Reads = 26771
Writes = 0
Fetches = 16135
SQL>

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.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
2013-07-30T01:25:53.0380 (1813:0x7f0b05226148) FREE_STATEMENT
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)

Statement 17:
-------------------------------------------------------------------------------
select current_timestamp from rdb$database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$DATABASE NATURAL)

2013-07-30T01:28:37.8080 (1813:0x7f0b05226148)  PREPARE_STATEMENT 
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 23:
-------------------------------------------------------------------------------
select first 1 * from t
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
  164769 ms 


2013-07-30T01:28:37.8080 (1813:0x7f0b05226148) EXECUTE_STATEMENT_START
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 23:
-------------------------------------------------------------------------------
select first 1 * from t
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)

2013-07-30T01:28:37.8200 (1813:0x7f0b05226148) EXECUTE_STATEMENT_FINISH
        /var/db/fb30/test01.fdb (ATT_56, SYSDBA:NONE, NONE, <internal>)
                (TRA_75, CONCURRENCY | WAIT | READ_WRITE)

Statement 23:
-------------------------------------------------------------------------------
select first 1 * from t
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
1 records fetched
     11 ms, 2 read(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                       1
...
Рейтинг: 0 / 0
30.07.2013, 01:36:29
| Ответить | Цитировать | Написать  
25 сообщений из 189, страница 4 из 8
  4  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Его Величество Миллиард (эксперименты с таблицей в 10E9 строк)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38346903&tid=1564260]:
 0ms
get settings:
 6ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 54ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 40ms
get tp. blocked users:
 1ms
others: 185ms
total:  314ms
созд. / загр.: 314ms
x
x
Закрыть


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