2000万件/月のデータベース

やや古い話で、1995~96年に開発したシステムの話。
今回は、このBlogの主旨であるpoorな話ではないかもしれませんが、十分に古いシステムの話なので、載せることにします。
これは、私の経験ではもっとも大量のデータを扱うシステムでした。今のコンピュータの性能ならたいしたことはないかもしれないですが、データベースの論理設計の段階で、最も大きなテーブルのレコード数が、約4億。1ヶ月分でも約2000万件です。環境は、マルチプロセッサのUNIXサーバーにOracle7。ただし、情報検索系のシステムなので更新は夜間処理でのレコード追加のみです。


さすがにこの規模になると、実装時に1つのテーブルとして定義したのでは、追加も検索も実用的なパフォーマンスが得られません。検索の要件として、月をまたがる検索は少ないので、1ヶ月分を1テーブルとして定義することにしました。問題はテーブル名をどうするかです。
検索の要件としては、当月のデータ、前月のデータ、前年同月のデータなどをよく使います。かといってそんな相対的な意味のテーブル名称にしたのでは、毎月テーブルの全データを1つ古い月のテーブルに移動させてやる必要があり、一晩かけても処理できません。とりあえず格納されるデータの年月そのものをテーブル名にするということにしました。
今度は、年月が名称になっているテーブルを、どうやってアクセスするかが問題です。ユーザがテーブルを選んで検索するという使い方なら、テーブル名が年月になっている方が好都合ですが、アプリケーションプログラムからアクセスする場合は、与えられた検索条件から動的にSQLを生成する必要があります。しかし、このとき開発に使った言語の中には、このような動的SQLに対応しないものもありました。
そこで思いついたのが、テーブルのエイリアスを使うという方法。テーブルの実体の名称は年月にし、エイリアスとして、当月、前月、前々月...と言う意味の名称を割り当てて行きます。月次ローテーション処理では、新しい月のテーブルをクリエイトし、実体とエイリアスの関連付けをずらして再定義した後、最も古い月のテーブルをドロップする。これなら大量のデータ処理は発生しません。検索側のアプリケーションもエイリアスからアクセスすれば、動的SQLにする必要はありません。
当時としては、なかなか上手い方法だと思ったのですが、今時の環境ならどうするんでしょうね。処理能力に頼って力技でも対応できるでしょうか?
私自身も、その後はこれほどの規模のデータを扱う機会はなかったので、残念ながら、大規模データベースならではの、これらの経験は活かすことがありませんでした。