最近、.NET/Windowsプラットフォーム用に特別に設計されたオープンソースのドキュメント指向NoSQLであるRavenDBを提供するHibernatingRhinosのCEO兼創設者であるOrenEiniにインタビューする機会がありました。
Orenは、Microsoftおよび.NETエコシステムに重点を置いて、開発の世界で20年以上の経験があります。 2007年以来Microsoftの最も価値のある専門家の1人として認められているオレンは、「DSLs in Boo：Domain SpecificLanguagesin.NET」の著者でもあります。彼は、DevTeach、JAOO、QCon、Oredev、NDC、Yow！などの業界会議で頻繁に講演しています。およびProgressive.NET。
以下の完全なインタビューを読むことができます：
1。このデジタル化された世界では、データは最も価値のある資産の1つになっています。したがって、データの保存、整理、および処理の方法は、ビジネスの成功にとって非常に重要です。企業がますます多くのデータに襲われるにつれて、データストレージと分析はますます複雑になっています。今日の企業が直面している一般的なデータベース管理の課題について教えてください。
主な問題は、データのサイズだけだと思います。ビッグデータや、数百テラバイト単位で測定されるデータセットの管理の複雑さについて必ずしも話しているわけではありません。組織内にあるデータベースとデータサイロの数について話しています。すべてがデジタルであるため、共有ドライブ上のExcelスプレッドシートに常駐するビジネスクリティカルな機能と、所有権を受け入れることを恐れて誰も近づきたくないサーバーでの顧客購入の履歴データがあります。
組織全体が何を知っているかを理解するだけでも、複雑な作業になる可能性があります。ひび割れをすり抜けるデータは悲しいことに一般的です。
会社全体の集中型リポジトリを作成する試みも失敗する運命にあります。会社のさまざまな部分は、明白なことのように見えるものについて非常に異なる考えを持っています。たとえば、請求部門は、顧客がマーケティング部門とは非常に異なる概念を持っています。データを一般的な型に適合させようとすると、誰もが不利益を被ります。
2。これらの課題をどのように克服しますか？効果的なデータベース管理ソリューションを選択することが最初のステップだと思いますか？そして、なぜですか？
最初のステップは、組織レベルで、データの所有権と責任のルールを定義することです。最も基本的なレベルでは、請求は顧客が延滞支払いステータスにあるものは何でもという概念を所有し、マーケティングは顧客の利益を所有します。アイデアは、組織内に情報のサイロを作成することではなく、さまざまなニーズを明確に認識させることです。それが完了すると、組織内の適切なデータフローを定義できます。
請求部門は、部門内での顧客の形を変更する自由を維持しながら、組織の他のメンバーが顧客のビューを利用できるようにします。
この例として、請求部門とマーケティング部門、および顧客の概念を使用して、ビジネスについて最初に話すことができるようにします。これは重要です。それをもう少し技術的な方法に移すために、私たちはサービスとデータフロー契約について話している。ベゾスの使命と、それがどのようにAmazonを変革したかを紹介します。考え方は単純です。組織全体を単一の全体として扱うのではなく、特定のサイズを超えるとほとんど不可能ですが、それらの間に非常に明確な境界がある協力組織の集まりとして扱います。
これらの境界があり、組織内のデータフローについてよく理解できたら、配管工を受け入れて、データフローを中央の場所にリダイレクトして分析するなどの作業を行うことができます。
そのような公開されたインターフェースを持つことは、いくつかのものの振る舞いを変える時が来たときに大いに役立ちます。外部の動作が同じである限り、処理方法を自由に変更できます。
3。近年、企業はさまざまなタイプのNoSQLデータベースを採用しています。ますます機密性の高いデータがNoSQLデータベースに保存されるようになると、セキュリティの問題がますます懸念されるようになります。これについてどう思いますか？
概して、NoSQLデータベースのセキュリティが欠如している最も一般的な理由は、オペレーターの過失です。ここでは、2つの異なる問題を明確に区別したいと思います。 RedisなどのNoSQLデータベースがあり、そのセキュリティモデルは、信頼できる環境での実行を明示的に示しています。 Redisにはいくつかの基本的なセキュリティ機能がありますが、一般的な想定では、これらは3番目または4番目の防御線としてのみ機能することを目的としています。
MongoDBなどの他のNoSQLデータベースは、敵対的なネットワーク（つまり、インターネット）で実行されることが期待されています。ただし、セキュリティなしでMongoDBをセットアップするのは簡単です。表面的には、MongoDBは安全な構成で提供され、ローカルマシンのみをリッスンできます。
MongoDBにリモートで接続しようとしたときに最初に見つかるのは、セキュリティをまったく使用せずにMongoDBへのリモートアクセスを有効にする方法を説明するガイドです。
ある程度、これはオペレーターの過失です。しかし、広く開かれたままになっているMongoDBデータベースの数が非常に多いことを考えると、これは途方に暮れていると思います。中国では、オープンなMongoDBデータベースに2億を超えるCVがあり、誰かが詮索するのを待っていました。不注意に設定されたデータベースにより、ロシアのバックドアが2,000を超える企業に公開されました。
セキュリティがあれば、二度とチャンスはありません。
対照的に、RavenDBは、脆弱な構成での実行を単に拒否します。ローカルマシン上でセキュリティなしでRavenDBを実行できますが、適切な保護手段なしでデータベースをインターネットに公開しようとすると、データベースは適切に設定する方法を説明するエラーを返します。
ほとんどの人が必要最小限の作業を行うと想定して、最大のギャップを埋め、これが発生したときに最終的な状態が良好であることを確認します。
4。 RavenDBについて言えば、顧客により多くの価値を付加する最も重要な機能のいくつかを挙げていただけますか？ RavenDBは、機能とパフォーマンスの点で他のベンダーの中でどのように際立っていますか？
RavenDBは、10年以上にわたって実稼働システムで実行されています。元のバージョンにまでさかのぼる最も強力な機能のいくつか。運用環境に動的に反応する能力は、最も明白なものです。 RavenDBは、何が起こっているか（着信クエリ、サーバーの負荷など）を継続的に分析し、リソースの割り当てや内部構造などを変更することでそれに対応します。つまり、フルタイムのDBAがデータベースをベビーシッターにする代わりに、データベースで管理できます。独自の業務。
RavenDBの作業を開始したとき、リレーショナルデータベースのすべての利点（高速、ACID、信頼性）を備えながら、欠点（厳密なスキーマ、継続的なメンテナンス、高度な複雑さ）を備えていないデータベースが必要でした。
私たちが始めたとき、私はこれがどれほど大きな仕事であるかを知りませんでした。過去10年間で、多くの注意を払うことなく、正常に機能するデータベースを構築する多くの経験を積んできました。 RavenDBは、パフォーマンスに重点を置いた実装を容易にするように設計されています。 Raspberry Pi（25 $、1 GHz、1 GB RAM）マシンの最近のベンチマークでは、1秒間に5,000回を超える書き込みが発生しました。コモディティハードウェアでは、1秒あたり100,000を超える書き込み、1秒あたり1,000,000を超える読み取りを実現できます。
これらはすべて単一ノード上にありますが、RavenDBは最初から分散データベースでした。これは、クラスターを数分でセットアップでき（もちろん、安全な方法でセットアップでき）、可用性と堅牢性の高いシステムを使用できることを意味します。
他では利用できない独自の機能をいくつか提供しています。 ETLはRavenDBの内部に組み込まれており、豊富なデータフローを可能にするためにお客様によって頻繁に利用されています。異種のピースからソリューションをつなぎ合わせる必要はありません。ボックス内にすべて揃っているので、問題なく機能します。
サブスクリプション機能は、私が特に誇りに思っている機能です。これにより、進行中のクエリを実行できます。データベースは最初に、クエリに一致するすべての結果を提供します。このクエリは引き続きサブスクライブされているため、データベースは、クエリに一致するように入力または更新されたときに、クエリに一致する新しいドキュメントを送信します。これにより、堅牢なビジネスプロセスとバックエンドシステムを簡単に構築できます。
RavenDBを、ドキュメント、キー値、バイナリデータ、分散カウンター、グラフクエリを処理できるマルチモデルデータベースにすることに多大な努力を注いできました。
5。そして最後に、データベース管理システムの将来はどうなるのでしょうか。今後3〜4年でどのように変化しますか？
マルチモデルデータベースにさらに焦点が当てられるようになります。必要なデータの種類ごとに専用のソリューションを展開し、各部分の複雑な統合に対処する代わりに、市場は単一のボックスでオプションの完全なスイートを提供できる統合ソリューションに移行しています。
クラウドは今後も重要になりますが、オンプレミスシステムと分散システムに別れを告げるのは急いではありません。多くのお客様がエッジや時折接続されているシステムで処理を行っているのを目にしています。過去のデータセンターがクラウドに移行するという焦点のシフトが見られると思いますが、実際の処理の多くはエッジとモバイルデバイスに分散されます。そのためには、データの分散と、データをクラウドにプッシュしてクラウドからデータをプルする方法について、異なる考え方が必要です。
かつてはハイエンドシステムの独占的な範囲であった分散データ処理の種類に、さらに重点が置かれるでしょう。
景観がどのように変化するか、そして増大し続ける複雑さと機能性を処理するためのツールと方法論をどのように構築するかを見るのは確かに非常に興味深いでしょう。