ワシントンDCで開催されたSpringOne Platformにおいて、R2DBCが発表された。これはリアクティブプログラミングの観点からリレーショナルデータベースに対して新たに設計された実験的なAPIだ。ADBA仕様に影響を与えることを最終目標としている。
Cloud Foundry Java Experience LeadのBen Hale氏によると、R2DBCは4つの設計原則に基づいて設計されたという。
- Reactive Streamsのタイプとパターンを活用する。
- データベースに到るまで、すべて完全にノンブロッキングである。
- ユーザビリティに関係なく、実装固有である最小限の操作までドライバSPIを縮小する。
- ドライバAPI上に複数の「人間向け」APIを構築可能にする。
これはHale氏のプレゼンテーションから引用したシンプルなSelectステートメントの例だ。
connectionFactory.create()はコネクションのMonoを返す。Hale氏は実行の最終結果についてこう語った。「最終的に、誰かがサブスクライブすると、コネクションを取得して、クエリを実行し、Rowのそれぞれについて値、例えば整数を返し、最終結果として整数のFluxになります。コネクションのライフサイクルは、サブスクライブでのみオープンされ、完了するとクローズされます」
もちろん、SPI上に構築されたクライアントは、これをさらに簡単化することができる。Hale氏は詳細を隠した例を示した。
SPIを用いてトランザクション内でPrepared Insertがどうなるかを以下に示す。
Hale氏がプレゼンテーションで認めたように、これはすごいわけではないが、クライアントで簡単化することができる。
R2DBCの代わりはいくつかある。ひとつはスレッドプールでJDBCをラップすることだ。しかし、これはバックプレッシャー機能を提供しない。すなわち、無限のキューはリソースの枯渇につながり、有限のキューはブロッキングにつながる。もうひとつはADBAだ。Hale氏は慎重にこう語った。
私たちはかなり初期にADBAに参加していましたが、CompletableFutureが実際にReactiveであるかについて多くの議論があり、結局、離れてR2DBCに取り組むことになりました。しかし、R2DBCの取り組みは実証されて動作するAPIができたので、私たちは再び参加するよう招かれています。そのため、これが実際にADBAになるかもしれません。こうしたプロジェクトの最終目的は、ある程度はそこにあります。
Hale氏は今後の計画に関して、R2DBCは実験的なものであり、試すには十分安定しているけれども決して製品に使えるものではない、と明言した。BLOB/CLOBハンドリングの欠如や執筆時点でPostgreSQLしかサポートしていないなど、多数のエッジケースがあることに注意すべきだ。しかし、Hale氏は他のデータベースの実装を見てみたいと願っている。彼は次のように締めくくった。
Springは仕様を作りません。私たちは仕様の先導者ではありませんし、仕様をホストしているわけでもありません。このプロジェクトの全体目標は、ADBA仕様に影響を与えることであり、それが可能な限り最善のシナリオです。でも、間違いなく、私はADBA仕様がひどいのを容認するような人物ではありません。私たちのアドバイスを彼らが受け入れないなら、リアクティブであることは非同期であることと違うのだということを彼らが理解しないなら、その時は、Springチームがやることになるでしょう。
Rate this Article
- Editor Review
- Chief Editor Action