goto Aarhusにて、NoSQLの実務経験に関するトラックがありました。私はNoSQLデータストアの基本原則を説明する最初の講演を依頼されました。NoSQLの起源、NoSQLデータモデルの形式、多くのNoSQLデータベースが整合性の問題をどのように考えているか、そしてPolyglot Persistenceの重要性について話します。

近年、スキーマレスデータの利点についての話が増えています。スキーマレスであることは、NoSQLデータベースへの関心の主な理由の1つです。しかし、スキーマレスであることには、データベースとインメモリデータ構造の両方に関して、多くの微妙な点があります。これらの微妙な点は、スキーマレスの意味と、スキーマレスアプローチを使用することの長所と短所の両方に存在します。

NoSQL Distilledという書籍を執筆した際、ほとんどの章を要約して、再読する際の参考にしました。これらの要点をウェブサイトにも掲載し、読者が要点を確認できるようにしました。

goto Aarhusのトラックの1つでは、NoSQLベンダーがそれぞれのツールについて語る機会が設けられました。トラックの最後に、さまざまな講演者がパネルディスカッションを行い、NoSQLに関する共通の問題について議論しました。私はこのトラックには参加していませんでしたが（私の講演は数日後でした）、パネルディスカッションには参加しました。

QCon London 2012の基調講演では、データが私たちの生活においてどのような役割を果たしているか（そして、単に大きくなる以上のことをしていること）について考察します。まず、データの世界がどのように変化しているかを見ていきます。データは増加し、より分散化し、よりつながりが強くなっています。次に、業界の対応策を見ていきます。NoSQLの台頭、サービス統合への移行、イベントソーシングの登場、クラウドの影響、そして視覚化の役割が大きくなった新しい分析です。現在、データがどのように利用されているかを簡単に見ていきます。特に、発展途上国におけるデータについてRebeccaが重点的に説明します。最後に、ソフトウェア専門家としての私たちの個人的な責任にとって、これらすべてが何を意味するのかを考えます。

主にアプリケーション開発の管理に携わる人向けに書かれた、エンタープライズにおけるデータストレージの未来に関するインフォデッキです。リレーショナルデータベースが主流であった理由、NoSQLがこの前提に挑戦している理由を説明し、アプリケーションの多様なニーズに応じて複数のデータストレージ技術が使用されるPolyglot Persistenceの未来を描いています。

Nosql Distilledの執筆中に最初に頭に浮かんだトピックの1つは、NoSQLデータベースがリレーショナルモデルとは異なるデータモデルを使用していることでした。私が調べたほとんどの情報源では、少なくとも4つのデータモデルグループが挙げられています。キーバリュー、ドキュメント、カラムファミリ、グラフです。このリストを見ると、最初の3つには大きな類似点があります。すべてが密接に関連するデータの豊富な構造を基本的なストレージ単位としています。キーバリューストアの場合は値、ドキュメントストアの場合はドキュメント、カラムファミリストアの場合はカラムファミリです。DDDの用語では、このデータグループはDDD集約です。

数年前に、プログラミング言語関係の人が、Javaによって引き起こされた言語の「核の冬」について話しているのを聞きました。誰もがJavaの計算モデル（C#は当時、単なる模倣と見なされていました）に収束してしまったため、プログラミング言語の創造性が失われてしまったという感覚でした。その感覚は今では薄れてきていますが、おそらくもっと重要な雪解けが始まっているのかもしれません。それは、データベースについての思考のより長く、より深い凍結です。

JSONデータ構造をサーバーに流し込むことは、最近よく見かけるようになりました。JSONドキュメントは、集約指向データベースまたはリレーショナルデータベースのシリアライズされたLOBを使用して、直接永続化できます。JSONドキュメントは、Webブラウザに直接提供したり、サーバーサイドのページレンダラーにデータ転送するために使用したりすることもできます。JSONがこのように使用されている場合、オブジェクト指向言語を使用すると、JSONをオブジェクトに変換して再びレンダリングする必要があるため、プログラミングの労力が無駄になると言われています。無駄という点には同意しますが、それはオブジェクトの問題ではなく、カプセル化の理解が不足していることが問題だと私は主張します。

多くの組織では、永続データは中央データベース管理グループによって管理されるリレーショナルデータベースに格納されることが想定されています。このような中央制御には、通常、統合データベースの使用を中心としたさまざまな理由があります。中央データグループは、不正なデータ、重要な共有リソースの速度を低下させる可能性のあるクエリ、およびエンタープライズ全体で一貫性のあるデータモデルの排除を懸念しています。

これらの目標は立派なものですが、その結果の1つは、データの格納に関するかなりの儀式です。データベースにカラムを追加するのに数週間かかる変更指示書についての苦情をよく耳にします。短期間の進化型設計に慣れている現代のアプリケーション開発者にとって、このような儀式は遅すぎるだけでなく、煩わしいものです。

そのため、アプリケーション開発グループは、DBAを回避するためにNoSQLデータベースを使用していることを私に教えてくれます。彼らがここで「単なるデータストア」を使用していることが役に立ちます。「適切なデータベース」ではありません。そうすれば、DBAをループから外すことができ、多くの場合、DBAに知らされなかったり、DBAが気にしないことを嬉しく思ったりします。

Nosql Distilledの作業を開始するとすぐに、私たちは難しい難問に直面しました。それは、私たちは何について書いているのかということです。NoSQLデータベースとは正確には何でしょうか？この概念について明確な定義はなく、商標も、標準グループも、マニフェストもありません。

2006年、私の同僚であるNeal Fordは、Polyglot Programmingという用語を作り出しました。これは、さまざまな言語がさまざまな問題に取り組むのに適しているという事実を利用するために、アプリケーションはさまざまな言語の組み合わせで記述されるべきであるという考えを表しています。複雑なアプリケーションはさまざまな種類の問題を組み合わせているため、ジョブに適した言語を選択する方が、すべての側面を単一の言語に適合させようとするよりも生産性が高くなる場合があります。

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