OLTPにおいてRDBMSのスケールアウトは重要か?

だいぶいろいろとりこみましたが、一部はタイトルの議論をしています。
6
前へ 1 2 ・・ 8 次へ
marble @marblejenka

まあ知ってる業務要件の違いというのも。web系ならわかるけど、1000とか10000ノードでスケールアウトしてほしい要件って僕はやったことないというだけかもですね。

2010-08-12 12:04:45
Kazunori Sato @kazunori_279

@marblejenka でもOracle以外みんなshared nothingを選んでるのは、やっぱりエンタープライズでもスケールアウトしたいからだと思うよ

2010-08-12 12:04:47
marble @marblejenka

@kazunori_279 なるほどー。まあ時代の流れというのはあるのかもです。ASMとかもスケールアウトするぜみたいな話って最近聞きましたし。いや僕は実務経験長くないので、必要なところでは必要なのかもしれないですが。

2010-08-12 12:09:23
marble @marblejenka

あとまあ、わかんないけど、スケールアウトってパフォーマンス悪くなったらハードウェア買ってね、という話に聞こえなくもない。グリッドなんとかのときには結構そんなノリだったという話を聞かなくもない。技術的には、スケールアウト可能な実装が優れているという認識はありますが。

2010-08-12 12:14:06
marble @marblejenka

まあ大きいところの大きい案件で、それなりに長い期間使用する前提で負荷見積もりをするような仕事だったので、スケーラビリティで困らなかっただけという話ですかね。

2010-08-12 12:16:48
Kazunori Sato @kazunori_279

@marblejenka 基幹系でもスパコンでも、ノイマン型のボトルネックはディスクI/OとメモリI/O。スケールアウトできるアプリはノイマン型の制約を超えられるからね

2010-08-12 12:17:28
marble @marblejenka

@kazunori_279 なんかまた壮大な話ですな。ノイマン型の制約を超えるというのはどういう意味ですか?

2010-08-12 12:21:15
Kazunori Sato @kazunori_279

@kynhat 昔のRDBだと「1ノードの性能=サービスのスループット」でしたが、NoSQLだと1ノードが遅くても多数ノード並べられます

2010-08-12 12:22:22
Kazunori Sato @kazunori_279

@marblejenka ハイエンドUNIX機のTPC-Cベンチ担当さん曰く、128CPUマシンをいかに細かく内部分割して内部スケールアウトするかがコツたと。大きいCPU+メモリじゃI/Oネックになるので、(少なめのCPU+メモリ)×多数にしてローカリティ出すって。

2010-08-12 12:29:05
marble @marblejenka

@kazunori_279 それをクラスタなりデータセンターでやる感じですよね。その辺はわかります。必要かどうかは要件次第とは思いますが。

2010-08-12 12:33:34
Kazunori Sato @kazunori_279

@marblejenka なので汎用機でもハイエンドUNIXでも、伝統的にパーティショニング技術が高度に発展してるんだよね

2010-08-12 12:34:03
Kazunori Sato @kazunori_279

@marblejenka いや、それを1台のサーバー内でやるって話。

2010-08-12 12:34:51
Kazunori Sato @kazunori_279

@marblejenka まとめると:数10CPU機になると、まるごと1台の大型サーバーとして使うとI/Oやバスがネックで性能がリニアに上がらない。なので内部分割して内部スケールアウトしてるのがハイエンド事例の実情。。ってことです

2010-08-12 12:40:31
marble @marblejenka

@kazunori_279 まあそういうことを要求する業務があるというのはわかります。取引所とか。アクセラレータを使う場合ですら似たような感覚ですし。でも、要件自体がハイエンドでなければかずのりさんが言うような高いハードは使わないし、重要でないケースはありますよ。

2010-08-12 12:46:04
marble @marblejenka

@kazunori_279 スケールアウトの発想が大事でないというつもりはないのですが、web scaleなスケールアウトとか、HPC的なアーキテクチャは必要ないという要件のほうが大多数だと思うのですよ。

2010-08-12 12:47:39
Suguru ARAKAWA @ashigeru

@marblejenka それもどこかで転換するかもね

2010-08-12 12:52:21
Kazunori Sato @kazunori_279

@marblejenka でも、元の話はRACだから、RAC使うような案件だとミッドレンジ~ハイエンドのUNIXサーバー使うのが普通。CPU数も8~32くらいだけど、HPC用途じゃないよ。

2010-08-12 12:52:30
Kazunori Sato @kazunori_279

@marblejenka RAC使わないような規模の案件ならもちろん同意。RAC使うような億単位の案件だと、アプリ側でがんばってshardingしてスケールアウトしたり、shared nothingなDB2で複数サーバーに分割したりとかになる

2010-08-12 12:55:43
Kazunori Sato @kazunori_279

s/とかになる/とかも選択肢になる/

2010-08-12 12:56:34
marble @marblejenka

@ashigeru したらおもしろいと思います。

2010-08-12 12:57:29
marble @marblejenka

@kazunori_279 なんとなくあれですね。多分金融の分野の話を知っているからか、ハイエンドがどのへんかという感覚がちがうのでちょっと齟齬があったようです。RACがハイエンドという認識はありませんでした。

2010-08-12 13:00:48
marble @marblejenka

@kazunori_279 あと、僕は計算負荷の増大に対してサーバーのスケールアウトで対応できるようなものは経験があるのですが、オン中のtxはそれほど多くないものだったので、データストアにそれほどこだわりがないというのもすれちがいの原因かなと思います。

2010-08-12 13:02:51
marble @marblejenka

でもなー、確かにそれなりのハードだった気はするけど、何十/何百CPUとかではなかったなあ。

2010-08-12 13:04:06
Kazunori Sato @kazunori_279

@marblejenka @satoruf OLTPもバッファとか上手に設計するとCPUちゃんとサチりますよ。

2010-08-12 13:04:59
Kazunori Sato @kazunori_279

@marblejenka @satoruf さんがsequent+Oracleで数10CPUがきれいにサチったという事例を教えてくれました

2010-08-12 13:06:07
前へ 1 2 ・・ 8 次へ