ポリグロット・パーシステンス

2006年、私の同僚であるニール・フォードは、ポリグロットプログラミングという用語を作り出しました。これは、異なる言語が異なる問題に取り組むのに適しているという事実を利用するために、アプリケーションは複数の言語を組み合わせて記述されるべきであるという考えを表現したものです。複雑なアプリケーションは異なる種類の問題を組み合わせているため、すべての側面を単一の言語に当てはめようとするよりも、仕事に適した言語を選択する方が生産性が高くなる可能性があります。

ここ数年、新しい言語、特に関数型言語への関心が爆発的に高まっており、私はしばしばClojure、Scala、Erlangなどに時間を費やしたいと思っています。しかし、私の時間は限られており、私はもう一つの、より重要な変化であるデータベースの雪解けを優先しています。最初の兆候はクライアントや他の連絡先から届いており、その見通しは魅力的です。新しい戦略的なエンタープライズアプリケーションを開始する場合、もはや永続化がリレーショナルであるべきだと想定すべきではないと自信を持って言えます。リレーショナルオプションが適切な場合もありますが、他の選択肢を真剣に検討する必要があります。

この興味深い結果の1つは、ポリグロット・パーシステンス[1]への移行に備えていることです。そこでは、まともな規模の企業であれば、さまざまな種類のデータに対してさまざまなデータストレージテクノロジーを持つことになります。依然として大量のデータがリレーショナルストアで管理されますが、ますます、最初にデータをどのように操作したいかを尋ね、それからどのテクノロジーが最適かを判断するようになるでしょう。

このポリグロットの影響は、単一のアプリケーション内でも明らかになります[2]。複雑なエンタープライズアプリケーションは異なる種類のデータを使用し、通常はすでに異なるソースからの情報を統合しています。データの使用方法に応じて、このようなアプリケーションが異なるテクノロジーを使用して独自のデータを管理するのをますます見かけるようになるでしょう。この傾向は、アプリケーションコードをWebサービスを通じて統合する個別のコンポーネントに分割するという傾向を補完するものです。コンポーネント境界は、データの操作方法に合わせて選択された特定のストレージテクノロジーをラップするための良い方法です。

これは複雑さのコストがかかります。各データストレージメカニズムは、学習する必要のある新しいインターフェースを導入します。さらに、データストレージは通常、パフォーマンスのボトルネックとなるため、適切な速度を得るには、テクノロジーの仕組みについて多くのことを理解する必要があります。適切な永続化テクノロジーを使用することで、これは容易になりますが、課題はなくなるわけではありません。

これらのNoSQLオプションの多くは、大規模なクラスタで実行することを伴います。これは、異なるデータモデルだけでなく、一貫性と可用性に関するまったく新しい一連の質問をもたらします。トランザクションの単一の情報源はもはや支配力を持ちません（ただし、そのような役割はしばしば幻想的でした）。

そのため、ポリグロット・パーシステンスにはコストがかかりますが、メリットがあるため、実現するでしょう。リレーショナルデータベースが不適切に使用されると、アプリケーション開発に大きな負担がかかります。最近、アプリケーションが本質的にWebページを作成して提供しているチームと話しました。彼らはIDでページ要素を検索するだけで、トランザクションの必要はなく、データベースを共有する必要もありませんでした。このような問題は、彼らが使用しなければならなかった企業のリレーショナルハンマーよりも、キーバリューストアの方がはるかに適しています。仕事に適したNoSQLを選択した良い公的な例は、The Guardianです。彼らは以前のリレーショナルオプションよりもMongoDBを使用することで、明確な生産性の向上を感じています。

もう1つの利点は、クラスタ上で実行することです。多くのトラフィックにスケーリングすることは、垂直スケーリングではますます難しくなります。これは、私たちが長い間知っていた事実です。多くのNoSQLデータベースは、クラスタ上で動作するように設計されており、単一サーバーでは現実的ではない、より大量のトラフィックとデータに対応できます。企業がデータをより多く使用しようとするにつれて、この種のスケーリングはますます重要になります。gotoAarhus2011で説明されているデンマークの投薬システムは、この良い例でした。

これらすべてが大きな変化につながりますが、急速な変化ではありません。企業はデータストレージに関しては当然のことながら保守的です。

より差し迫った問題は、どのタイプのプロジェクトが代替の永続化モデルを検討すべきかということです。私の考えでは、まず、ユーティリティと戦略の二分法の戦略的な最終段階にあるプロジェクトのみを検討する必要があります。それは、ユーティリティプロジェクトには、新しいテクノロジーに見合うだけのメリットがないためです。

戦略的なプロジェクトがあれば、代替案を提起する2つの推進力があります。開発の負担を軽減するか、集中的なデータニーズに対処するかです。ここでも、多くのプロジェクト、おそらく大多数は、リレーショナルな正統性を堅持する方が良いと思います。しかし、そうでない少数派は重要なものです。

おそらくそれほど重要ではない1つの要素は、プロジェクトが新しいか、すでに確立されているかです。The GuardianのMongoDBへの移行は、数年前に開発されたコードベースで、昨年頃から行われています。ポリグロット・パーシステンスは、既存のコードベースに導入できるものです。

これらすべてが意味することは、エンタープライズアプリケーションの世界で働いている場合、今こそ代替データストレージオプションに精通する時です。これは急速な革命ではありませんが、次の10年間でデータベースの雪解けが急速に進むと確信しています。