この記事は PostgreSQL Advent Calendar 2015 の22日目の記事です(代打)。
最近、Amazon RDS for PostgreSQLで、ip4rというEXTENSIONが使えるようになったみたいですが、ip4rって初めて聞いたので簡単に調べてみました。
このモジュールを入れることで、下記の5つのデータ型を利用できるようになります。
「ip4rって何のためにできたの？」と気になった方も多いかと思いますが、ip4rのページに下記のように書いてありました。
確かに、IPv4のアドレスだけ管理したいような時は、inet型やcidr型だと、CHECK制約とかで回避しないといけないので、無駄なコストになりそうですね。
注意しなければいけない点としては、ip4rで利用できる関数とビルトインのネットワークアドレス型で利用できる関数の差でしょうか。
ビルトインのネットワーク型で利用できるすべての関数と同様のものが、ip4rにあるわけではなさそうです。
ちなみに最初に書いた通り、ip4rはAmazon RDS for PostgreSQLでもサポートされていまして、RDSでは
IPアドレスの管理をしたい方は、ぜひ一度ネットワークアドレス型なりip4rを試してみてください。 簡単ではありますが、こちらからは以上です。
Tweet
最近、Amazon RDS for PostgreSQLで、ip4rというEXTENSIONが使えるようになったみたいですが、ip4rって初めて聞いたので簡単に調べてみました。
ip4rとは
ipという名前から連想されるように、ipアドレスやipアドレスの範囲を格納するデータ型です。このモジュールを入れることで、下記の5つのデータ型を利用できるようになります。
- ip4 ：IPv4のアドレス格納用のデータ型
- ip4r：IPv4のアドレスレンジ格納用のデータ型
- ip6：IPv6のアドレス格納用のデータ型
- ip6r：IPv6のアドレスレンジ格納用のデータ型
- ipaddress ：IPv4 or IPv6のアドレス格納用のデータ型
- iprange ：IPv4 or IPv6のアドレスレンジ格納用のデータ型
ネットワークアドレス型との比較
PostgreSQLには、ネットワークアドレス型がサポートされており、inet型、cidr型というものを使うことで、IPv4, IPv6にIPアドレス、アドレスレンジを格納できます。「ip4rって何のためにできたの？」と気になった方も多いかと思いますが、ip4rのページに下記のように書いてありました。
While PostgreSQL already has builtin types 'inet' and 'cidr', the authors of this module found that they had a number of requirements that were not addressed by the builtin type. Firstly and most importantly, the builtin types have no support for index lookups of the form (column >>= parameter), i.e. where you have a table of IP address ranges and wish to find which ones include a given IP address. This requires an rtree or gist index to do efficiently, and also requires a way to represent IP address ranges that do not fall precisely on CIDR boundaries. Secondly, the builtin inet/cidr are somewhat overloaded with semantics, with inet combining two distinct concepts (a netblock, and a specific IP within that netblock). Furthermore, they are variable length types (to support ipv6) with non-trivial overheads, and the authors (whose applications mainly deal in large volumes of single IPv4 addresses) wanted a more lightweight representation.つまり、乱暴に言うと下記の通りでしょうか。
- ビルトインのネットワークアドレス型では、(column >>= parameter)という演算子での検索にインデックスが利用できない(これが重要らしい)
- ひとつのデータ型に意味を込め過ぎている(inetには、アドレスレンジとアドレスレンジ内の単一のIPアドレスを格納可能で、IPv4,IPv6ともにサポートされている)
確かに、IPv4のアドレスだけ管理したいような時は、inet型やcidr型だと、CHECK制約とかで回避しないといけないので、無駄なコストになりそうですね。
注意しなければいけない点としては、ip4rで利用できる関数とビルトインのネットワークアドレス型で利用できる関数の差でしょうか。
ビルトインのネットワーク型で利用できるすべての関数と同様のものが、ip4rにあるわけではなさそうです。
ちなみに最初に書いた通り、ip4rはAmazon RDS for PostgreSQLでもサポートされていまして、RDSでは
CREATE EXTENSION ip4r;とやるだけで利用できるので、試すのも楽ちんでした。
IPアドレスの管理をしたい方は、ぜひ一度ネットワークアドレス型なりip4rを試してみてください。 簡単ではありますが、こちらからは以上です。
