Реляционная база данных для отслеживания адресов IPv6 / IPv4 - сработает ли предложенная мной схема?

Question

Фон

Я создаю приложение IPAM для отслеживания и хранения метаданных для отдельных адресов IPv4 и IPv6.Бэкэнд должен быть скучной, независимой от поставщика реляционной базой данных.

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

(Я не пытаюсь задокументировать все адресное пространство, только действующие адреса, используемые произвольными клиентами.)

Схема

Нормализоватьстроковое представление заданного IP-адреса и использование его в качестве первичного ключа.Адреса IPv4 преобразуются в IPv6 и имеют префикс ffff.Адреса IPv6 сжимаются и в нижнем регистре.

Во втором поле указывается, для какой версии протокола используется рассматриваемая запись - 4 или 6. Идея заключается в том, что если пользователь ищет записи в подсети IPv4, я могу быстроисключить пространство IPv6 или наоборот.

Следующие восемь полей (тьфу) являются целочисленными представлениями каждого октета в адресе (octet_1, octet_2 и т. д.).

Индексы

Первичный ключ уже должен иметь свой собственный уникальный индекс.

Создать дополнительный индекс на (version, octet_1, ..., octet_8).

Запрос

Для поиска определенного IP-адреса любой версии я могу просто нормализовать строку IP так же, как указано выше, и выполнять поиск по первичным ключам.

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

С какими проблемами я могу столкнуться при этом подход?Предложения по улучшению?

Что-нибудь от ipv4s casted as ipv6 are not the same thing до your index will explode / write performance will suck - это честная игра.

Я создал тестовый POC, который проверяет функциональность этой схемы, но меня беспокоитлюбые возможные недостатки этой модели в производственной среде.

Answer 1

В разделе «Схема» вы не указали фактическую схему.

«Адреса IPv4 преобразуются в IPv6 и с префиксом ...» выдают, что вы не понимаете намерения и цели IPV6.

"IPv6-адреса получают ... в нижнем регистре."выдает, что вы не понимаете различия между значением и представлением значения («получить в нижнем регистре» может повлиять на представление значения, но оно никогда не будет влияет на само значение ).

"если пользователь ищет записи в подсети IPv4" выдает, что вы не понимаете разделенияВызывает беспокойство создатели 7-уровневой модели OSI при разработке своей модели сетевых коммуникаций.«Поиск записей» не является функцией на том же уровне, что и IP (v4 / v6).

«Первичный ключ уже должен иметь свой собственный уникальный индекс».выдает, что вы не понимаете управление реляционными данными.

Возможно, вы почувствуете, что это не ответ на ваш вопрос, но на самом деле это так.

Answer 2

Если вы можете выбрать базу данных, перейдите на PostgreSQL. Он имеет встроенные типы для IP-адресов и поэтому предлагает отличную производительность и возможности

Но вы сказали, что хотите быть независимым от базы данных, поэтому давайте сосредоточимся на этом. В этом случае я бы сделал только строковое представление с адресами IPv4 с префиксом :: ffff :, но затем использовал бы только шестнадцатеричную запись в нижнем регистре без сжатия. Таким образом, IPv4-адрес 10.11.12.13 станет 0000: 0000: 0000: 0000: 0000: ffff: 0a0b: 0c0d.

Почти все базы данных имеют хорошую индексацию по строкам, и с помощью этой нотации вы можете легко выполнять запросы подсетей и диапазонов. Если вы хотите, чтобы все адреса IPv4 просто запрашивали LIKE '0000: 0000: 0000: 0000: 0000: ffff:%'. Поскольку он привязан в начале, стандартный индекс btree должен хорошо работать. Вы можете выполнять более сложные запросы для диапазонов с помощью операторов <и>, которые также могут получить преимущество от стандартного индекса. Это должно дать вам большинство запросов подсети.

В вашем приложении не должно быть слишком сложно проанализировать строки с помощью inet_pton и т. Д., Чтобы преобразовать их во все, что вам нужно.

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