データ管理ガイド

境界づけられたコンテキストは、ドメイン駆動設計の中心的なパターンです。これは、大規模なモデルとチームを扱うためのDDDの戦略的設計セクションの焦点です。DDDは、モデルを異なる境界づけられたコンテキストに分割し、それらの相互関係を明示的にすることで、大規模なモデルを扱います。

ユビキタス言語は、エリック・エヴァンスがドメイン駆動設計で使用している用語で、開発者とユーザーの間で共通の厳格な言語を構築するプラクティスを指します。この言語は、ソフトウェアで使用されるドメインモデルに基づいている必要があります。そのため、ソフトウェアは曖昧さに対処するのが苦手なため、厳格である必要があります。

私は、単一のアプリケーションによって制御およびアクセスされるデータベースをアプリケーションデータベースと呼んでいます（統合データベースとは対照的です）。単一のアプリケーションのみがデータベースにアクセスするため、データベースは、その1つのアプリケーションのニーズを簡単に満たすように具体的に定義できます。これにより、より具体的なスキーマが得られ、通常は理解しやすく、統合データベースよりも複雑さが軽減されます。

多くの企業は、ビジネスインサイトを提供し、最終的には自動化されたインテリジェントな意思決定を行うために、大規模にデータを民主化することを期待して、次世代のデータレイクに投資しています。データレイクアーキテクチャに基づくデータプラットフォームには、大規模に約束が果たされないという共通の失敗モードがあります。これらの失敗モードに対処するには、レイクの一元化されたパラダイム、またはその前身であるデータウェアハウスから移行する必要があります。最新の分散アーキテクチャから引き出すパラダイムに移行する必要があります。つまり、ドメインを最優先事項として考え、プラットフォーム思考を適用してセルフサービスのデータインフラストラクチャを作成し、データを製品として扱う必要があります。

ビジネスケイパビリティ中心のチームとは、その仕事がビジネスの特定の領域に長期的に連携しているチームです。チームは、そのビジネスケイパビリティがビジネスに関連している限り存在します。これは、プロジェクトスコープの提供に必要な期間のみ存続するプロジェクトチームとは対照的です。

NoSQLデータベースは新しく、関心を集めていたため、プラモッド・サダラージと私は、このテクノロジーへの適切な入門書がないことが、実務者がそれらをいつどのように使用するかについて適切な意思決定を行うことを困難にしていると感じました。そこで、私たちはデータモデル、分散データの問題、一貫性の考慮、スキーマ移行、およびさまざまなスタイルのNoSQLデータベースのいくつかの例を網羅した短い（152ページ）の概要を作成しました。

2012年、gotoカンファレンスから、NoSQLデータベースに関する入門講演でNoSQLトラックを開始するように依頼されました。私は、Twitterミートアップのハッシュタグの背後にある定義を形成する共通の特徴を紹介し、一般的なNoSQLデータモデルと、分散データストレージシステムにおける一貫性の問題について話しました。私たちの本と同様の分野を網羅していますが、同じ深さには踏み込んでいません。ただし、短いビデオの概要を好む場合は、妥当な要約になります。（これは私の最も人気のある講演であり、goto YouTubeビデオで750,000回以上視聴されています。）

NoSQL Distilledの作業を開始した途端、私たちは扱いにくい難題に直面しました。私たちは何について書いているのでしょうか？NoSQLデータベースとは一体何なのでしょうか？この概念の強力な定義はなく、商標も、標準グループも、マニフェストさえありません。

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

書籍『NoSQL Distilled』を設計した際、再読する読者のために、各章の最後に要約のキーポイントをまとめました。これらのキーポイントをウェブサイトにも掲載し、読者の皆様が重要なポイントを再確認できるようにしました。

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

「ビッグデータ」は、業界で最も話題の言葉の1つに急速に躍り出ましたが、この言葉の背後にある真に重要な変化を見失ってはいけません。データソースの量、速度、価値は急速に増加しています。データ管理は、5つの広範な分野で変化する必要があります。より広範なソースからのデータの抽出、新しいデータベースと統合アプローチによるデータ管理のロジスティクスの変化、分析プロジェクトの実行におけるアジャイル原則の利用、ノイズからシグナルを分離するためのデータ解釈のテクニックの重視、そしてそのシグナルをより理解しやすくするための適切に設計された可視化の重要性です。要約すると、大規模な分析プロジェクトは必要なく、代わりに、新しいデータ思考が通常の業務に浸透することを望んでいます。

QCon London 2012での基調講演では、データが私たちの生活で果たしている役割（そして、データが単に大きくなっている以上の役割を果たしていること）について考察します。まず、データの世界がどのように変化しているか（成長し、より分散化され、接続されている）を見ていきます。次に、業界の対応として、NoSQLの台頭、サービス統合への移行、イベントソーシングの登場、クラウドの影響、そして可視化の役割が大きくなった新しい分析について見ていきます。次に、現在データがどのように使用されているかを簡単に見ていきます。特にレベッカは発展途上国でのデータに焦点を当てます。最後に、ソフトウェア専門家としての私たち個人の責任について考察します。

データレイクは、ビッグデータの世界におけるデータ分析パイプラインの重要なコンポーネントを説明するために、この10年で登場した用語です。その概念は、組織内の誰もが分析に必要とする可能性のあるすべての生のデータを1つのストアに保存することです。一般的に、人々はHadoopを使用してレイク内のデータに対して作業を行いますが、その概念は単にHadoopよりも広範囲です。

Datensparsamkeitはドイツ語で、英語に適切に翻訳するのが難しい言葉です。これは、データを取り込み、保存する方法に対する考え方であり、本当に必要なデータのみを処理する必要があると言っています。

10代の頃、人工知能（AI）が今後数年で素晴らしいことをしてくれるだろうと聞いたのを覚えています。それから数十年経った今、そのうちのいくつかが実現しつつあります。最近の最大の成果は、コンピューターがお互いに対戦することで囲碁のプレイを教え合い、人間の専門家が理解するのが難しい戦略で、急速に人間よりも熟練したことでした。今後数年で何が起こるのだろうかと自然に思います。コンピューターはすぐに人間よりも優れた知能を持つようになるのでしょうか？（最近の選挙結果を考えると、それはそれほど難しいハードルではないかもしれません。）

しかし、これらの話を聞くたびに、数十年前のパブロ・ピカソのコンピューターに関するコメントを思い出します。「コンピューターは役に立たない。答えしかくれないからだ」。機械学習などの手法によって得られる推論の種類は、結果が本当に印象的であり、ソフトウェアのユーザーや開発者として私たちにとって役立つでしょう。しかし、答えは役に立ちますが、常に全体像を表しているわけではありません。私は学校の初期の頃にこれを学びました。数学の問題に答えを提供するだけでは、ほんのわずかな点数しか得られず、満点を取るには、どのように答えを得たかを示す必要がありました。答えにたどり着いた推論は、結果そのものよりも価値がありました。これは、独学で囲碁を学んだAIの限界の1つです。彼らは勝つことができますが、彼らの戦略を説明することはできません。

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

ここ数年、新しい言語、特に関数型言語への関心が爆発的に高まっており、Clojure、Scala、Erlangなどを掘り下げてみたいと思うことがよくあります。しかし、私の時間は限られており、DatabaseThawというより重要な変化に優先順位を与えています。クライアントやその他の連絡先から最初の滴が届き始めており、その見込みは魅力的です。あなたが新しい戦略的なエンタープライズアプリケーションを開始する場合、永続化はリレーショナルであると想定するべきではないと断言しても差し支えないでしょう。リレーショナルオプションが正しい場合もありますが、他の代替案を真剣に検討する必要があります。

ほとんどのエンタープライズアプリケーションは、データベースに永続的なデータを保存します。このデータベースは、アプリケーションの状態の運用更新と、意思決定支援や分析に使用されるさまざまなレポートをサポートします。ただし、運用ニーズとレポートニーズは、スキーマからの異なる要件や異なるデータアクセスパターンなど、大きく異なることがよくあります。この場合、レポートニーズをレポートデータベースに分離するのが賢明な場合が多く、レポートデータベースは、重要な運用データのコピーを取得しますが、別のスキーマで表します。

「『戦争と平和』は素晴らしい本です。」

「ちょっと見せてください...この本は表紙がボロボロで残念です。」

2つの文で、それぞれ「本」という言葉を使用しています。私たちは毎日、このような組み合わせに気づくことなく見過ごしていますが、その中で「本」という言葉がそれぞれの文でまったく異なる意味を持っていることに気づくことはありません。

数か月前のロンドンのQCon会議に参加していたとき、すべての講演にオブジェクト/リレーショナルマッピング（ORM）ツールに関する皮肉な発言が含まれているように思われました。私は、講演者に送信された会議のメールをもっと注意深く読むべきだったと思います。間違いなく、45分ごとに少なくとも一度はORMに軽蔑を浴びせるように全員に指示するようなものがそこに書かれていたでしょう。しかし、お分かりのように、私はこのORMへの嫌悪に対して少し反発したいと思っています。なぜなら、その多くは正当なものではないと考えているからです。

人々がエンタープライズアプリケーションを起動するとき、最も初期の質問の1つは「データベースとどのように通信するか」です。最近では、「リレーショナルデータベースとこれらのNOSQLデータベースのどちらを使用すべきか」というわずかに異なる質問をするかもしれません。しかし、考慮すべきもう1つの質問があります。「そもそもデータベースを使用する必要がありますか？」

ソフトウェアシステムでは、ユーザーがデータ構造に独自のフィールドを定義できるようにするのが一般的な機能です。住所録について考えてみましょう。追加したいものがたくさんあります。新しいソーシャルネットワークが毎日登場する中、ユーザーは連絡先にBunglr IDの新しいフィールドを追加したいと思うかもしれません。