Комментарии 9
В таблице лучше хранить не начала и концы диапазонов, а блоки netnum/netmask, если диапазон нужно выразить несколькими такими блоками — то разбивать (но, обычно, адреса и выдают блоками). Поиск делать по ip & netmask == netnum, и сортировать по убыванию по количеству бит в netmask. Такую структуру можно вообще без базы данных создать, в виде префиксного дерева — будет работать очень быстро. Но даже в вашей схеме можно было бы использовать функцию INET_ATON(), чтобы запрос выглядел опрятнее.
В вашем варианте сортировка может работать не совсем правильно, при одинаковых sip надо искать наименьший eip.
И ещё момент, у вас в примере запроса sip и eip сравниваются с разными адресами — вы что-то хотели этим проиллюстрировать, или опечатка?
В вашем варианте сортировка может работать не совсем правильно, при одинаковых sip надо искать наименьший eip.
И ещё момент, у вас в примере запроса sip и eip сравниваются с разными адресами — вы что-то хотели этим проиллюстрировать, или опечатка?
+1
кажется статья о том, как вы скачивали архив и дамп загоняли в БД, но не об определении провайдера по IP.
+5
Ripe, это не весь интернет.
Проще всего воспользоваться готовой базой от maxmind:
dev.maxmind.com/geoip/geoip2/geolite2-asn-csv-database
Кроме ipv4 ещё бывают ipv6.
Выше вам указали на INET_ATON, для ipv6 надо использовать INET6_ATON.
p.s. Мой ipv6 адрес от домашнего провайдера:
2a00:1c78:1:1e95:1114:6cd:600a:111
Проще всего воспользоваться готовой базой от maxmind:
dev.maxmind.com/geoip/geoip2/geolite2-asn-csv-database
Кроме ipv4 ещё бывают ipv6.
Выше вам указали на INET_ATON, для ipv6 надо использовать INET6_ATON.
p.s. Мой ipv6 адрес от домашнего провайдера:
2a00:1c78:1:1e95:1114:6cd:600a:111
+2
Ripe, это не весь интернет.да, вы правы.
Кроме ipv4 ещё бывают ipv6.в ripe они есть, но в статье не рассмотрены
Проще всего воспользоваться готовой базой от maxmind:
dev.maxmind.com/geoip/geoip2/geolite2-asn-csv-database
бесплатная версия же урезана. А полная версия только за деньги.
0
Возможно, но в исходных условиях было сказано «IP -> Country Code». Для этого достаточно и урезанной версии. Далее, с учетом того, что анонсы более специфичные, чем /24, фильтруются, можно считать, что все адреса из блока /24 с вероятностью приближающейся к 1 будут иметь один Country Code (и один Organization Id), соответственно, и проверку можно значительно ускорить / упростить за счет другой структуры таблицы в БД.
Касательно взаимосвязи между объектами в RIPEdb: www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types
Касательно взаимосвязи между объектами в RIPEdb: www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types
0
В базе, сделано верно, надо хранить именно диапазон, начало и конец в виде чисел (не слушайте глупости других комментаторов).
Когда потребуется повысить скорость поиска, то сможете выкинуть SQL и перейти на более быструю базу в которой по sip, eip построить базу с BTREE индексами, они отлично ложатся именно на диапазон.
Тогда поиск станет моментальным, а скорость ответа возрастёт минимум в 100 раз.
Как пример, решение с бд в 40 миллионов записей (все провайдеры мира), база данных Tarantool, язык golang.
Скорость нахождения ответа через api (REST/JSON) — 1.8мс-2мс. То есть, фактически все реальные затраты это кодирование/декодирование json + tcp/ip конекты. :)
Кстати, по некоторым табличкам не хватает индексов, а они сильно влияют на скорость поиска в SQL!
Ну а по теме самой статьи и её сути, могу сказать только то что мельчает хабр, ежегодный постоянный регресс. И это печально… Целая статья о скачивании и заливке базы в бд :(
Грустно это.
Когда потребуется повысить скорость поиска, то сможете выкинуть SQL и перейти на более быструю базу в которой по sip, eip построить базу с BTREE индексами, они отлично ложатся именно на диапазон.
Тогда поиск станет моментальным, а скорость ответа возрастёт минимум в 100 раз.
Как пример, решение с бд в 40 миллионов записей (все провайдеры мира), база данных Tarantool, язык golang.
Скорость нахождения ответа через api (REST/JSON) — 1.8мс-2мс. То есть, фактически все реальные затраты это кодирование/декодирование json + tcp/ip конекты. :)
Кстати, по некоторым табличкам не хватает индексов, а они сильно влияют на скорость поиска в SQL!
Ну а по теме самой статьи и её сути, могу сказать только то что мельчает хабр, ежегодный постоянный регресс. И это печально… Целая статья о скачивании и заливке базы в бд :(
Грустно это.
+1
Нужно больше таких статей.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как я определял провайдера по IP