Здравствуйте.
ятолкнулся с проблемой.

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

наладил обновление с одного из сайтов, примерно 3 миллиона адресов.

сделал таблицу следующим образом:
create table blackiplist(ip varchar(20) not null primary key, flag integer)

затем раз в сутки заливал обновленную таблицу таким образом:
сериями по 1000 insert into blackiplist (ip,flag) values (newvalue,1)
затем после того как залил все записи, одной транзакцией:
delete from blackiplist where flag=0
update blackiplist set flag=0

вот.
работало все это часа по три.
база разрослась до 700 метров.
стал постоянно свопится диск и тормозить всю систему. хотя проверка конкретного айпишника делается практически мгновенно.
но из-за тормозов диска, сервак практически не работает.
пришлось прибить все это.
я так подозреваю, что это работает автоматический уборщик мусора.

вопрос.
можно ли сделать так:
create table(ip integer not null primary key, flag integer)?
обновлять все одной транзакцией или лучше дробить?
отключать ли индекс на первичный ключ? если это возможно вообще...
стоит ли базу разбивать на разные файлы? так, на всякий случай спрашиваю...

как сделать так, чтобы и записи обновлялись много и часто и не тормозил уборщик мусора? если это он, конечно...

FreeBSD5.2, FireVird1.5

2Zmeishe
по поводу флага и порядка действий.
дело в том, что почтовый сервер должен иметь доступ к полному набору данных в любой момент времени.
при этом он делает запрос вида
select * from blackiplist where ip like '%12.23.34.45' and flag=0

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

почтовый сервер может работать и в 3 часа ночи.
он работает с записями имеющими флаг 0.
если сначала удалить старые записи, имеющие флаг 0, то почтовому серверу неоткуда будет брать данные и спам может просочится.

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

2Zmeishe
вижу смысл, спасибо

сделал так:
create table blackiplist(ip integer not null primary key)
create table blackiplisttmp(ip integer)

вставка происходит примерно 700 строк в секунду(это больше часа работы)
обновление(удаление ненужных и вставка нужных) не засекал, но больше часа.

сейчас пробую
create table blackiplisttmp(ip integer not null primary key)
скорость вставки вроде не уменьшилась.

по поводу mysql
если уж так, то возможно сделать просто бинарный файл. размером в (2^32)/256 байт(примерно 500 метров).
где каждый бит соответствует одному ip адресу.
скорость я думаю юудет более чем приемлемая, а размер базы у меня сейчас итак 300 с лишним метров.

индекс я не отключал, да.
потому что его там небыло.
create table blackiplist(ip integer)

мож у меня клиентская прога тормозит?

да я же написал, что ip integer!!!
к стати, когда я сделал во временной таблице ip integer primary key, обновление из одной таблицы в другую произошло за 5 минут!!!

анализ клиентского кода показал, что процентов 70 машинного времени уходит на
isc_dsql_allocate_statement

никто не сталкивался? это нормально?

без.
а зачем там параметры? и как это влияет на производительность?

да, в 4 раза быстрей стало :-) спасибо

а еще? может еще что нужно учесть?

итого, около 20 минут весь процесс.

по поводу сборки.
стоит делать после всего select count*)?

раза три-четыре обновил таблицы, база стала 500 метров.
сделал select count(*) from blackiplist сделалось быстро, секунд за 30.
сделал select count(*) from blackiplistmp - до сих пор делается.
оно и понятно, 3 миллиона записей удалил.
вот теперь думаю.
может сделать как-то так:

create table blackiplisttmp(ip integer not null unique,
flag integer)

где флаг означает - 0, хз, 1 - добавился, 2 - не изменился.
сначала все пометить как 0.
каждый ip из файла ищщется в базе. если такой есть, то помечается как 2(не изменился) если нету, добавляется с флагом 1.

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

что думаете?

да нет :-)
мне число строк не нужно.

я просто хотел принудительную сборку мусора сделать, чтобы она не началась сама.

или я не прав?

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

ну а потом-то что?
ну сделаю я бэкап и что?
мусор то останется в базе, его тоолько в бэкапе не будет.

так нельзя ресторе делать. процессы куда конектится будут, пока идет рестор?

ну ничего тут развернулась дискуссия :-)

я так понял, когда делается бэкап базы, в оригинальном файле тоже происходит сборка мусора, правильно?