[Moscow.pm] Написал интерфейс к базе от ipgeobase.ru

[Ruslan Zakirov]

Кстати идея про разбиение. Это может быть просто конфигурационным
параметром. Задаете его при заливке в БД и в программе знаете его. Чем
меньше блоки, тем больше база, но быстрее сканирование.

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

Статус прийдется выкинуть, но он не нужен.

Отличная получилась дискуссия. Поправлю на днях и соберу новую версию.

2009/12/1 Ruslan Zakirov <ruslan.zakirov на gmail.com>:
> 2009/12/1 Sergey Zhuravlev <sergey.zhuravlev на gmail.com>:
>> 2009/12/1 Ruslan Zakirov <ruslan.zakirov на gmail.com>:
>>> Посмотрел EXPLAINы в Pg, стало более понятно. При двух условиях, когда
>>> каждое отдельно условие не ограничивает диапазон, оценки количества
>>> строк сильно зашкаливают. Это понятно. Не учитывается связь между
>>> значениями начала и конца.
>>>
>>> По этому PG и скорее всего mysql отказываются от index based range
>>> scan и переходят к full sequential index scan. Если знать максимальный
>>> размер блока ( MAX(iend-istart) ), то, добавив дополнительные условия,
>>> можно помочь БД получить более точную оценку и выбрать оптимальный
>>> план.
>>
>> Для ipgeobase это действительно должно сильно помочь.
>>
>> У нас используется другая база для определения региона по ip,
>> и там самая большая сеть 15.0.0.0 - 22.255.255.255 (США)
>> Соответственно в нашем случае такая оптимизация не выстрелит ;-)
>> Хотя, конечно, можно большие сети разбивать на куски, скажем /16
>
> У вас в БД есть блоки покрывающие подсети или вы просто не делаете
> локацию внутри США?
>
>
> --
> Best regards, Ruslan.
>



-- 
Best regards, Ruslan.