ハッシュパーティションについて

Question

ハッシュパーティションについての質問です。
「達人に学ぶDB設計徹底指南書」という本で勉強しているのですが、ハッシュパーティションについて以下のような記述があります。
「ハッシュ関数でパーティションキーの値を分散させます。これは名前の通り、ハッシュ関数でパーティションキーの値を分散させます。したがって、一般的にはパーティションの数がいくつになるかを事前にユーザー側が指定しない使い方をします。」
調べてみても、よくわからなかったのですが、本の記述によれば、レンジパーティションとリストパーティションではパーティションをいくつにするかということはユーザー側が指定するわけですが、なぜハッシュパーティションではそのようにはなっていないのでしょうか？
それは、すなわち勝手にDBMSが判断するということになると思うのですが、なぜでしょうか？
普通に考えると、パーティションをいくつにするか、という情報はユーザー側で与えてやらないと、適切なパーティションの数が用意できないように思えるからです。
お分かりの方、回答お願いします。

Answer 1

まだクローズされてないみたいなので推測交じりで回答してみます。

まず前提としてリストパーティション、レンジパーティションの２つと、
ハッシュパーティションの違いは理解できてますでしょうか。

一応違い云々については、
参考までにこちらも合わせて読んでみて下さい。(PostgreSQLのやつですが・・・)

#ここで言う「ユーザー」って誰？
さてここから本題です。
実の所ハッシュパーティションを用いる場合もテーブル数は指定可能です。
(Oracleのようにハッシュアルゴリズムの選択はできないので2の累乗にしないとメリットの教授が行えないDBMSもあれば、
ハッシュアルゴリズムは指定したパーティション数に応じて決定するDBMSもありますが。)

ではここでいうユーザが指定できないっていうのは嘘じゃないって話に思われますが、
当方の解釈ではここのユーザーというのは、
**「DBMSを直接扱う開発者」ではなく「システムを利用するユーザー、またはシステム運用チーム」**を指すのではないかなと思われます。(これは推測で筆者様ではないので本当の意図は分かりませんが・・・)

ここから先は上記を前提で話を展開します。

#事前に数を決める・決められないって何？
さてここから本題ですが、
パーティションの数が決められる・決められないという何かについて説明してみます。

パーティション数が決められる。
つまりこれはシステム利用ユーザーや運用チームとの要件決定時点でパーティション数を確定することが可能なことを表していると思われます。

例えばレンジパーティションであれば、
年月単位でパーティション化する方針となれば年内で「12」個必要なのが確定しますよね？
(例えば大量データから１月分の集計を高速化したいなどの要望があれば年月単位のパーティションが有効です。)

次にリストパーティションですが、
こちらは日本の地域単位でパーティション化する方針となれば「8」必要なのが確定しますよね？
（地域数はWikiの八地方区分を参考として決定してみました。この分け方は大量のデータから地方ごとの集計が多い場合に有効です。）

つまり上記のパーティション方法での数というのは、
システム都合で数を決定するのでなく要件に合わせて数を決定するということが重要となることが多いわけです。

上記に対してハッシュパーティションはどうでしょうか？
これはOrlofskyさんのおっしゃる通りI/O分散がパーティション化する目的であって、
意味ごとの分類や期間による分類と勝手が違い他のパーティション方法と比較すると数の持つ重要性は希薄化します。

ハッシュパーティションで重要なのは、
「負荷の分散」ということであって意味ごとの分類ではないことに注意してください。

つまり十分に負荷分散の要件を満たしおり、
データ格納量も１テーブルごとにある程度抑えられるのであれば、
数というのはシステム利用ユーザー側・運用チームにはあまり関係ないわけです。

そのため要件定義段階でも、
「システム上問題ないレベルの数ならいいのでは？」という話にしかならないでしょう。

そういう意味も込められて、
書籍では事前に数を決められる・決められないを述べているのかなと勝手に解釈しています。

あくまで個人的な考えなのでご参考程度に留めておいて下さいね＾＾；

Answer 2

パーティションの中にサブパーティションとしてハッシュ・パーティションを使うことでI/O分散を図る、など大規模なDBではよく使います。