クラウドの登場で冗長化が当たり前の現代にあってもデータベースに関しては多くの制約がある。
- データは整合性の取れた状態で更新する必要があり完全な分散処理が難しい
- 扱うデータ量は年々増加しており、そのデータ量を処理できるようスケールさせる必要がある
- その結果としてデータベースのコストがシステム全体のコストの大半を占めるようになってきている
最初の制約は、ただ単純にライターインスタンスの性能がスケールできないだけでなく、結果として無停止運用に対する制約にも影響する。
無停止運用については従来は Oracle RACによる冗長化構成が唯一の解決策だったが、近年は、Cloud Spanner、CockroachDB、TiDBといった分散データベースも盛んになってきている（あまり採用事例を聞かないがAurora Multi Masterもある）。これらのデータベースではデータをシャーディングしたりブロック単位でロックすることで書き込みもスケールすることができるようになっている。
ただ、こういった分散データベースはOLTPに特化することが多く、OLAP用途には向かないことが多い。1億レコードを超えるような大量のデータを扱う場合にはパフォーマンスが伴わない。
従来、このような用途にはOLAP専用のデータベースを持つDWHが使われてきた。（日本だとDr.SUMがよく使われている気がする。使い勝手に難がありあまり使われてないが、SQLServerとOracleには昔からOLAP機能が付いている。また、これらの商用データベースは列圧縮によりDWH的な用途にもある程度対応ができるようにもなっていたりする）
ビジネス自体はそう変わっていないと思うのだけれども、全国展開する企業には日々の消費行動をリアルタイムで把握したいという経営サイドのニーズがあり、日々発生するトランザクション量はうなぎのぼりに増えている。そのため、日次でも数千万〜億単位のレコードを扱わざるを得ないケースが増えている。
ここ10年で見るとこういった大量データの分析に対する解決策はクラウドDWHというかBigQuery一択だったように思う（最近ようやくSnowflakeという選択肢も出てきているけれども）。オンプレDWHでは実現できなかった無制限のデータ量に対する高速処理が実現できたことが大きい。
それが、ここ最近になってデータレイクに移りはじめそうな雰囲気が出はじめている。個人的にデータレイクがいいなと思うのはデータの配置先が専用ストレージではなく一般的なオブジェクトストレージであることだ。
発生トランザクションがうなぎのぼりといういうことはシステム移行が必要なデータも莫大になることを意味する。1日分のデータを入れるだけならともかく10年以上蓄積されたデータを運ぶとなるとなかなかに大変だ。しかしクラウドのオブジェクトストレージに（CSVやperquetといった）汎用的な形式で格納されていれば移動させる手段も多く、セミリアルタイムな同期も難しくない。
PerquetとIcebergによる標準化により構造化データの保管と管理が標準化されたことでコンピューティングリソースとデータ管理が切り離せるようになったというのは大きな変化で専用DWHに溜め込むという時代は過去のものになっていくのではないかと思う。
3番目のコストだが、2極化が進んでいるように思う。
ひとつは貧者のためのデータベースだ。昨今のマシンは速いので、ある程度の規模までなら1台でさばける。むしろ1台でさばけるデータ量ならメモリ上でデータを処理したほうが明らかに効率的でSQLite の分散化や Duckdb によるOLAP という発想が生まれる。1台運用はさすがに業務的にまずいという場合には、NeonやAurora Serverlessのような利用量に最適化したデータベースを使うことも考えられる。
貧者の発想といっても馬鹿にしているわけでなく、大企業であってもすべてのシステムで大量データが必要なわけではない。それなりに使えれば十分なシステムには安価な対応策を、重要なシステムはお金がかかってもスケール可能にしておくという判断が必要になる。
大規模にスケールさせるという観点では、個人的には2番目のトピックで取り上げたデータレイクの流れが重要となり、HTAPによるOLTPは主流にならないのではないかと思っている。
これはDB付属の全文検索機能よりelasticsearchが使われるのと同じでパフォーマンス特性が違うものが密に結合するとスケールがむずかしくなるという理由による。
ここからは個人的な妄想だが、データをローカルデータ（アクセスしてきたその人だけしか見えない）とグローバルデータ（誰もがアクセスする）に分け、後者はデータレイクに集約、前者は基本ローカルデータを扱いつつ、データレイクにも透過的にアクセス可能、そういう仕組みになっていくのではないかと思う。
このとき重要になるのはローカルデータのグローバルデータへの反映で、結果データの反映管理が問題となってくる。データレイクのデータはリアルタイム更新が得意ではなくある程度バッチ更新が前提となる。
ローカルデータの登録時にグローバルデータ反映のフラグをつけて、グローバルデータに反映したかどうかによって取得を変える（あるいはマージする）仕組みが必要になる。グローバルデータへの反映はメッセージキューで行うとしても、この処理をいちいち作り込むのは面倒であり透過的に処理してくれると非常にうれしい。Spanner などで利用されているグローバルで正確なタイムスタンプを使えばできそうな気もする。
一時期グローバル分散データベースというものが流行ったが、法律や通信遅延の制約もありデータは国別に置きたいし、実際、世界で同じデータベース構造でビジネスを維持するというのは現実的ではない。
むしろ、ローカルデータとグローバルデータをうまく使うことこそがこれからの重要なトピックなのではないかと思う。（批判があればぜひ）
