レコード数６億件（RDBMS）

とあるシステムの設計をしていて、毎日30万件以上、月1000万件、年間１億２千万件、と試算した。少なくは無いがものすごく多いとも思わない。
５年分くらいはデータを保持したいので、６億件１テーブルに保持したいといったら、基盤チームからやめてくれと懇願されました。1レコードはそんなに大きくはないので1kバイトないくらい。仮に1kバイトとして、5年で大体600Gくらいかな。別にかまわないと思うのだけど。
6億件全体をこねこねすることもないのでパフォーマンスも問題ない。Insertもパーティショニングをつかえば問題ないと思います。
世の中的には、どうなんでしょうか？

AIの活用が今後増えていくと思いますが、そういった素データの保持が重要な気がします。今回のケースは本当に保持が必要か再検討しますが、600Gぐらいでうろたえるなと思いました。

RDBMSの機能と活用について

自分は、とある場所で勉強会を月１回主催しています。毎回色々なテーマで勉強をするのですが、その中で思ったことがあります。

アーキテクチャの議論の中で、いわゆる３階層構造（データベース、アプリケーションサーバー、クライアント）の構成は、現在はあまりにもアプリケーションサーバーに処理が偏りすぎていて効率的ではないのではという議論がありました。

今自分が直面している課題は、

何十万件のレコードをデータベースからとってきて、金額を計算して、別のテーブルに書き込むという処理で、短時間の間にその処理を完了しなければならないという者です。

要件はたったそれだけなのですが、実現にはいくつかのやり方があります。

パターン１　データを一気にアプリケーションサーバーにもってきて、金額計算をして、テーブルに書き込む。
問題点：アプリケーションサーバーのメモリをものすごく食う。何十万回のINSERTが発生する。→アプリケーションサーバーでエラーが発生するかも。書き込みにものすごく時間がかかる。（もちろん高速化のテクニックはいくつかありますが）

パターン２　データをグルーピングして、塊ごとにLOOPさせて、金額計算をして、テーブルに書き込む。（１の派生系）
問題点：１よりはメモリを食わないが（それでも書き方によるが）、やはり書き込みに時間がかかる。（多重LOOPの中でSQLを発行するのは最悪）

パターン３　SQLで金額計算まで行い、テーブル間でデータをコピーする。
上記問題点は起きないが、ビジネスロジックがSQLに埋め込まれる。
（ストアドプロシージャだとデータベースの中にビジネスロジックが埋め込まれる）

パターン３は、明らかにトレンドに反するが、処理速度は段違いとなる。
机上の計算だと、何十倍も処理速度の差が出て来ることになる。

現在のトレンドだと、RDBMSは、入れ物であってロジックを実装することは、ほとんど無い。（トリガーや参照整合性制約や、チェック制約を実際に使うことは最近ほどんど見かけない）なので、アプリケーションサーバーの役割が増大してしまっている。
（一部バッチ処理にストアドプロシージャを使うことがあるが）

今日やった勉強会では、RDBMSでできることは、RDBMSでやったほうがいいのではという結論になった。（SQLを舐めすぎ！！）

また複雑なSQLに対する恐怖感があるのでは無いかということを感じた。最近のRDBMSは、サブクエリなんかなんとも無い。

それこそ、キーでもってデータを取り出すだけならNO SQLでいいのではと思う。

よって、今年の目標は、RDBMSを極めることとした。