Firebird+ODBC

[Алексей++]

RXL, имею в виду, что целостность связей контролируется не СУБД, а программистом в программе

PK приделывал

Код:

alter table MESS_LOG add  primary key(MESSAGE_ID)

- результат по времени такой же

Предлагаю эксперимент.

подойдёт ли вырезание одной этой таблицы ? То есть удаляю всё, кроме таблицы, получаю маленькую БД для экспериментов?  Или нужно именно с "чистого листа" ?

И вот это подозрительно:

у меня сейчас не полмиллиона, а 50 тысяч

Добавлено через 8 минут и 22 секунды:
отрезал всё, оставил только эту таблицу (индекс есть, ключа нет). Сделал бэкап/восстановление. Затем удаление записей - время такое же

куда бечь ? )))

[HandKot]

Странно, что отключение индекса не замедляет удаление записей, выбранных по индексированному полю. Разница должна быть существенной

не знаю птицу и говорю по аналогии с MSSQL
1. все зависит от кол-ва записей, т.е если удаляется 50000 записей, а в таблице 51 тысяча, то и  с индексом или без будет обычный скан всей таблицы

2.

Код:

alter table MESS_LOG add  primary key(MESSAGE_ID)

по умолчанию создается кластерным и при удалении будет  "индекс скан" - что для кластерного аналогично "табле скан"
в общем надо смотреть план запроса

Алексей1153++,
первый подход - если оценить кол-во удаляемых записей и кол-во записей в таблице, то чему равно их соотношение?
если после удаления в таблице остаётся записей намного меньше, то можно использовать следующий подход
1. создаём новую таблицу аналогичной структуры
2. вставляем в неё записи, которые должны остаться после удаления
3. дропаем старую таблицу
4. новую таблицу переименовываем в старую

второй подход - удаление порциями, т.е в цикле по N-записей (определяется экспериментами) удаляем
этот подход хорош при удалении большого кол-во записей (и если первый подход не применим). Плюс подхода в том, что меньше мспользуется лог и меньше наблюдается блокировок

[Алексей++]

если оценить кол-во удаляемых записей и кол-во записей в таблице, то чему равно их соотношение?

удаляется всё. Все записи подходят под условие в where

создание копии таблицы - это ой ой, птица такое просто так не пропустит ) Там нужно сначала удалить все связанные с таблицей процедуры, затем триггер (он у меня там один - на вставку), только потом будет можно удалить таблицу. Затем всё это обратно восстанавливать нужно. Хотелось бы без этих усложнений, конечно

операция удаления в программе должна быть "целой", то есть сказали почистить журнал на такое-то  количество сообщений, - раз и почистили

а что за лог ? Я не использую никакого лога всё равно, может энто нужно отключить ?


Добавлено через 23 секунды:
ещё , кстати, может эта вся бодяга - некий глюк версии 1,5 птицы ?

Добавлено через 4 минуты и 12 секунд:
ещё встречал вариант - помечать удалённые записи, не удаляя их реально.

но попробовал -
Update MESS_LOG set del_flag =1

время такое же - 27 секунд на 50 тыс записей

[Oldy]

Алексей1153++, попробуй создать DESC индекс на поле MESSAGE_ID. Сравни планы когда MESSAGE_ID - РК и когда у MESSAGE_ID есть DESC индекс. 

[RXL]

Oldy, такое уже было - на предыдущей странице. Результат един.

Леш, а можно создать ключ, целостность которого обеспечивается движком базы? Ну просто очень медленно. Я вчера создал твою таблицу в MySQL 5.5, заполнял на 50 и 100 тыс записей и удалял с индексом и без: разброс составил 0.8-1.0 сек.

[Oldy]

Прошу прощения. Куда смотрел?

[Алексей++]

RXL, Oldy, вот результаты и без индекса, и с ключом+индекс .  Время не отличается

(click to show)

(click to show)

я щас попробую поставить птицу 2,5,1

но как потом заставить клиентов перейти на неё - это вопрос открытый

Ром, за MySQL я и не сомневаюсь, уже была возможность оценить

[RXL]

Леш, скажи, а почему у тебя почти все поля NULL? Сущности в программе имеют аналогичное поведение - с неопределенностью?

[Алексей++]

Таблица разрасталась, когда добавлялись новые поля - они, естественно NULL по умолчанию. В программе при чтении смотрится - если NULL , оставляется значение по умолчанию в структуре данных

А это на что может повлиять ?

Добавлено через 13 минут и 42 секунды:
с птицей 2.5.1 запрос выполнился за 41 секунду , но зато коммит мгновенный. Итого, с минуты снизили время до 41 секунды. 

Ерунда же всё равно...

[Sla]

А может птица себя так ведет при удалении записей?

А если создать программный курсор и удалять по одной записи - что будет со временем?

[Алексей++]

кому не лень, попробуйте у себя (пароль к закачке в ЛС скину сейчас )

http://zalil.ru/33506486


Добавлено через 19 секунд:

А если создать программный курсор и удалять по одной записи - что будет со временем?

а как это делается ?

[Sla]

а как это делается ?

Ты меня пугаешь ....

я не знаю как это делается

типа такого

Код:

$result = mysql_query('select * from table where id<NNNN');
while ($row = mysql_fetch_assoc($result)) {
    mysql_query("delete from table where id =". $row[id]);
    

}

[RXL]

Таблица разрасталась, когда добавлялись новые поля - они, естественно NULL по умолчанию. В программе при чтении смотрится - если NULL , оставляется значение по умолчанию в структуре данных

А это на что может повлиять ?

Такие поля лучше делать "NOT NULL DEFAULT value", если конечно в программе специально не обрабатывается ситуация неопределенности.
На удаление, по идее, повлиять не должно, но кто знает пути FB... Как минимум это дополнительная метаинформация в каждой строке. Просто у меня возникла такая мысль: если логическое удаление связано с UPDATE, то:
* приводит ли UPDATE к физическому копированию строки?
* влияет ли на этот процесс наличие NULL столбцов?

Ну и классика: выполняй операцию порционно. Каждая порция начинается с запуска транзакции, выполнения операций над N строк и COMMIT. N находится экспериментально. Типично - от 1000 до 10000.

[Oldy]

Sla, FB 1.5 этого не  умеет.
Алексей1153++, На скорость удаления могут влиять параметры Page Size, Forced Writes, Sweep interval

[Oldy]

попробовал:

План
PLAN (MESS_LOG INDEX (RDB$PRIMARY1))

Адаптированный план
PLAN (MESS_LOG INDEX (INTEG_1))

50237 record(s) was(were) deleted from MESS_LOG

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 1s 312ms
Current memory = 2 827 692
Max memory = 3 043 668
Memory buffers = 2 048
Reads from disk to cache = 5 107
Writes from cache to disk = 2 630
Fetches from cache = 251 806

мои:
Forced writes=on
Sweep interval=20000

твой Page Size =1024

[Алексей++]

я этих настроек в конфиге не вижу что-то

[Oldy]

Алексей1153++, при Page Size = 8192

План
PLAN (MESS_LOG INDEX (RDB$PRIMARY1))

Адаптированный план
PLAN (MESS_LOG INDEX (INTEG_1))

50237 record(s) was(were) deleted from MESS_LOG

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 453ms
Current memory = 17 508 488
Max memory = 17 737 248
Memory buffers = 2 048
Reads from disk to cache = 643
Writes from cache to disk = 0
Fetches from cache = 251 289

[Алексей++]

ну так как это настраивается ?  И почему, кстати, меньше страница - быстрее работа, не понимаю )

[RXL]

Не, Леш, есть проверенные практикой наиболее оптимальные размеры страниц. Это 4 и 8 кБ. Более мелкие страницы увеличивают объем IO.

[Алексей++]

Рома, это я понимаю. Но смотрю посты Олди и перестаю понимаю что-то )))

И где это всё настраивается, тоже не знаю. В конфиге таких параметров не вижу

[Oldy]

Алексей1153++,
http://www.ibase.ru/ibfaq.htm#fwoff
http://www.ibase.ru/devinfo/garbage.htm

[Алексей++]

Олди, благодарю, увеличение страницы очень даже помогло! )

как-то так

gbak -user uuu -pas ppp -r "1.fbk" "1.fdb" -o -v -p 8192

у меня на машине теперь делается за ~5 секунд (команда+коммит) на 50 тыс записей . то есть, у клиентов полмиллиона записей должны не более, чем за минуту сохраниться

у них всех железо покруче, вроде бы сейчас ЧОПы стараются обновляться )