|
|
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. ятолкнулся с проблемой. Для нашей почтовой системы я решил завести черный список 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 06:38 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
alex_kсериями по 1000 insert into blackiplist (ip,flag) values (newvalue,1) затем после того как залил все записи, одной транзакцией: delete from blackiplist where flag=0 update blackiplist set flag=0 Насколько я понял - все новые записи имеют flag = 1 insert into blackiplist (ip,flag) values (newvalue,1) , а все старые записи имеют flag = 0; Исходя из того, что ты написал, происходит следующее: 1. К старым записям добавляешь новые с флагом 1 2. Удаляешь старые записи с флагом 0 3. Всем оставшимся записям устанавливаешь флаг 0 Моё предложение - поменяй местами п.2 и п.1 тогда п.3 станет, скорее всего, ненужным. И не трать на него время. 1. delete from blackiplist; заметь без (where flag=0) 2. insert into blackiplist (ip,flag) values (newvalue,1) 3. update blackiplist set flag=0 (честно говоря - я не понял зачем это надо.) Зачем вообще нужен Flag, если он всегда 0. alex_kможно ли сделать так: create table(ip integer not null primary key, flag integer)? Можно. Есть апишная функция перевода IP - из string в integer и обратно. Аналога этой функции для FreeBSD5.2 я не знаю, но должен быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 08:56 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
авторбаза разрослась до 700 метров. Сделай BACKUP-RESTORE и база ужмется и мусор соберется. авторкак сделать так, чтобы и записи обновлялись много и часто и не тормозил уборщик мусора? если это он, конечно Даже нужно - sweep interval=0, а по ночам делать backup с параметром -g ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 09:13 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
2Zmeishe по поводу флага и порядка действий. дело в том, что почтовый сервер должен иметь доступ к полному набору данных в любой момент времени. при этом он делает запрос вида select * from blackiplist where ip like '%12.23.34.45' and flag=0 новые данные закачиваются в таблицу кучей мелких транзакций(3000 примерно). поэтому они имеют флаг - 1 чтобы не мешались пока. потом одной транзакцией убиваютя старые записи, имеющие флаг 0 и все записи( а остались только с флагом 1) помечаются флагом 0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 09:56 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Тогда объясни, в чём ПРИНЦИПИАЛЬНАЯ разница, когда удалять старые записи. До вставки новых или после? Например, если это будет происходить в 3 часа ночи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 10:16 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
почтовый сервер может работать и в 3 часа ночи. он работает с записями имеющими флаг 0. если сначала удалить старые записи, имеющие флаг 0, то почтовому серверу неоткуда будет брать данные и спам может просочится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 10:56 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Ух. Давай рассуждать. Существуют ли в новом наборе, записи, которые есть в старом??? Поскольку PRIMARY KEY по IP, то в новом их не должно быть, либо вставка должна предваряться проверкой на существование IP в старом наборе. Если в новом наборе нет IP из существующего набора, то существующий набор потерял свою актуальность и его можно нещадно удалить до вставки. Если наоборот, НУЖНА проверка на существование IP, то могу предложить другую методику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 11:05 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Ну и кто говорил, что временные таблицы это лишний инструмент? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 11:08 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
я извиняюсь. я вас обманул насчет примари кей. нет там примари кей. есть составной индекс из ip и flag. дело в том, что новый набор строк, должен быть единственно присутствующим в базе. он на 99% дублирует старый набор, но я не знаю какие строки добавились, а какие удалились. мне показалось прощще перезаписывать всю таблицу. может быть я не прав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 11:16 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Ну Вы, блин, даёте! Чтоб из-за 1% ТАК сервак колбасить!? В основной таблице построй PIMARY KEY по IP. Выкини FLAG Создай служебную таблицу, например TB$REPLICATION(IP ...); По IP уникальный индекс, но не PIMARY KEY. Перед заливкой нового набора данных отключи этот индекс, залей данные, подтверди все транзакции, включи индекс. Далее выполни процедуру со следующими алгоритмами. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Удалять саму таблицу ни к чему. Пусть остаётся пустой до следующей репликации. Я бы сделал два поля для IP - одно integer для этой процедуры по репликации, другое varchar(...) для твоего like '%12.23.34.45' О результатах сообщи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 11:51 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
2Zmeishe вижу смысл, спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2004, 17:40 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Вообще для Интербэйса массовые удаления без последующего backup-restore не очень хороший режим работы. Т.к. база пухнет и далее по пунктам... ИМХО для такого режима лучше использовать что-то типа MySQL - шустрее будет работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 08:48 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
IgorKВообще для Интербэйса массовые удаления без последующего backup-restore не очень хороший режим работы. Т.к. база пухнет и далее по пунктам... Теоретически согласен. BackUp-Restore регулярно нужен. У меня каждую ночь BackUp и раз в неделю BackUp-Restore. Но. Массовые удаления, в данном конкретном случае, происходят в служебной таблице. Она НЕ используется в работе почтового сервера в режиме 24х7. По ней не происходит ежесекундного поиска. А в рабочей таблице всех изменений всего 1%, несмотря на массовость заливки и удаления. Я не думаю, что "...далее по пунктам..." приведёт к снижению производительности в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 09:06 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
сделал так: create table blackiplist(ip integer not null primary key) create table blackiplisttmp(ip integer) вставка происходит примерно 700 строк в секунду(это больше часа работы) обновление(удаление ненужных и вставка нужных) не засекал, но больше часа. сейчас пробую create table blackiplisttmp(ip integer not null primary key) скорость вставки вроде не уменьшилась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 09:13 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
по поводу mysql если уж так, то возможно сделать просто бинарный файл. размером в (2^32)/256 байт(примерно 500 метров). где каждый бит соответствует одному ip адресу. скорость я думаю юудет более чем приемлемая, а размер базы у меня сейчас итак 300 с лишним метров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 09:16 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
>> вставка происходит примерно 700 строк в секунду(это больше часа работы) Я не знаю как ты делаешь вставку записей, но я на Celeron 2 ГГц и на Win2000Proff (не Linux и не Unix) 1.5 млн записей из 20 полей insert за 7-9 мин. Может быть ты не отключил индекс? >>обновление(удаление ненужных и вставка нужных) не засекал, но больше часа. Это уже не три, как раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 09:29 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
индекс я не отключал, да. потому что его там небыло. create table blackiplist(ip integer) мож у меня клиентская прога тормозит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 09:45 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Каким компонентом пользуешься? Приведи кусок кода проги, где идёт вставка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 09:51 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
Поскольку заливка и обновление идёт одновременно с работой почтовика, то like '%12.23.34.45' добавляет тормозов. Моё предложение сделать IP - integer. Вот эту ГАДОСТЬ '%12.23.34.45' представить так: IP_begin = IP_String_to_integer('12.23.34.45'); /* Не помню я, как называется API функция перевода IP из строки в число */ IP_end = IP_String_to_integer('912.23.34.45'); тогда вместо (ip like '%12.23.34.45') будет (ip between :IP_begin and :IP_end) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 10:17 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
ZmeisheНе помню я, как называется API функция перевода IP из строки в число inet_addr & inet_ntoa ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 11:04 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
да я же написал, что ip integer!!! к стати, когда я сделал во временной таблице ip integer primary key, обновление из одной таблицы в другую произошло за 5 минут!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 13:02 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
БЛИН!!! "ТВОЮ МАТЬ, ТВОЮ МАТЬ" - СКАЗАЛ ПЕРЕВОДЧИК ВИДЕО-ФИЛЬМА. Я ЖЕ РУССКИМ ЯЗЫКОМ НАПИСАЛ ИНДЕКС ДОЛЖЕН БЫТЬ. А ЕСЛИ ХОЧЕШЬ ПОВЫСИТЬ ПРОИЗВОДИТЕЛЬНОСТЬ ПРИ ВСТАВКЕ ЗАПИСЕЙ В СЛУЖЕБНУЮ ТАБЛИЦУ, ТО НЕ PRIMARY KEY, А UNIQUE INDEX - ПЕРЕД ВСТАВКОЙ INACTIVE ПОСЛЕ ВСТАВКИ ACTIVE. Потому, что для primary key inactive/active не сделаешь. Оптимизируй клиента, но только по умному. И вся твоя репликация пройдёт на ура. Кофе попил и готово. Вот, а потом кто-нибудь будет вайдосить - IB-кривой, IB-тормозной, MS-Forever Жалко материться нельзя - самое время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 13:12 |
|
||
|
3 миллиона записей
|
|||
|---|---|---|---|
|
#18+
анализ клиентского кода показал, что процентов 70 машинного времени уходит на isc_dsql_allocate_statement никто не сталкивался? это нормально? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2004, 14:30 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=32469537&tid=1578868]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
31ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
2ms |
| others: | 238ms |
| total: | 345ms |

| 0 / 0 |
