インデックスの狂気：データベースの混乱を避ける方法

Techopediaスタッフ、2016年10月5日

持ち帰り：ホストのエリック・カバナは、ロビン・ブルーア博士、デズ・ブランフィールド、およびIDERAのバート・スカルツォとデータベースのインデックス作成について議論します。

あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。

Techopediaコンテンツパートナー

TechopediaスタッフはBloor Groupと提携しており、右側のオプションを使用して連絡できます。 業界パートナーとの連携方法については、ここをクリックしてください。

• プロフィール
• ウェブサイト

エリック・カバナ：ご列席の皆様 、こんにちは。おかえりなさい。 水曜日の東部4時です。プログラムを知っている人は、それが何を意味するのかを知っているので、Hot Technologiesの別のエピソードの時間です。 はい、確かに。 私の名前はエリック・カバナです。今日のセッションの司会者になります：「インデックスの狂気：データベースの混osを避ける方法」。 または、最後のメールブラストで「データベースの論争」と言ったように、最近は「論争」と呼ばれています。誰もがやっています。 本当にあなたのものについてのスライドがあります。 そして、私については十分です。

したがって、Hot Technologyシリーズは実際に1対1のライブアナリストブリーフィングであるブリーフィングルームとは対照的に、特定のスペースを定義するように設計されています。HotTechには2人のアナリストがいます。 今日、それは私たち自身のドクター・ロビン・ブロアとデータ科学者のデズ・ブランフィールドになるでしょう。 そして、今日の市場で起きていることを本当に象徴していると思うトピックについて話しています。

肝心なのは、最近私たちは複雑な世界にいるということです。 実際、15年、または20年を振り返ると、特にデータベーステクノロジーに関しては、当時とはまったく異なる世界でした。 以前は、データベースはかなり単純でした。 それらのほんの一握りがありました。 それらのほとんどはリレーショナルでした。 現在、このようなデータベーステクノロジーがすべて揃っています。 文字通り、アプリケーションを構築したい、またはデータを使って何かをしたい人のためのテーブル上のオプションのスコア。 すべてが変化しており、それはこれらのシステムを管理しようとする人々に影響を及ぼします。 今日は、この分野の真の専門家であるバートスカルツォと話をします。 彼はIDERAの上級製品管理者であり、そのすべてのデータを処理するために何ができるかについてです。 それで、私はそれを奪うためにドクター・ロビン・ブロアーに引き渡すつもりです。 ロビン、床はあなたのものです。

Robin Bloor：わかりました、その紹介に感謝します。 私はそれを考えます-それは両手だからです、私はこのホットテックショーの紹介として、データベースの最適化について一般的に話をしたいと思います。 DEC VAXプラットフォーム上のデータベースの機能に関する記事を書くのに使用していたので、テクノロジーと分析の分野で人生を始めました。 そのため、データベースの使用者は私に簡単な説明をしていました。 そして、私にそのようなことが起こるのは、なぜあなたはデータベースを持っているのですか？ つまり、当時は非常に多くの人々がキー値ファイルを作成し、それらを使用してインデックスシーケンシャルフォールシーと呼んでいますが、一種のデータベース機能を作成するために使用していました。他に何か？

それに対する答えは、Michael Stonebrakerがそれに対して最善の答えを出したと思います。彼は、「データベースは、データがどこにあるのか、どのプログラムが知ることができるかを知ることができます」と言いました。 そして、私はそれが面白いと思います。 それがゲームの性質です。 しかし、19年– 1989年頃、テクノロジー分析を始めました。その時点で、データベースは非常にシンプルで、リレーショナルデータベースは非常にシンプルでした。 当然、データを保存することができ、バックアップすることもできました。ACIDに準拠していましたが、オプティマイザーが非常に弱かったのです。 実際、彼らがオプティマイザー機能を持っていると主張するのは難しいでしょう。

その後、どんどん良くなりましたが、データベースが機能しなくなると、これらのカンガルーが何らかの形で表示されるようになったときに、遅くなる理由が非常に多くあります。 そして、それは私にポイントをもたらします：データベースには多くの機能がありますが、最も重要なものはクエリの最適化です。 それらがそれをしなかったら、それらを使用しない。 情報を迅速に取得することであり、同時に多くのユーザーがいるときにそれを実行できることです。これは難しい問題です。 そして、実際に見てみると、必要に応じて成熟したデータベースと呼びましょう。ただし、これらのデータベースのオプティマイザーはMicrosoft SQL Server、確かにTeradataとDB2です。建物。 あなたは知っている、彼らはしませんでした-誰かが座っていませんでした-2人、1年のプロジェクトで6人の男と一緒にノックします。 それはそのようには機能しません。 最適化機能は徐々に成長しており、多くの成長が必要です。 とにかく、データベースの背景について話しましょう。 さて、現在NoSQLデータベースについて言われていることは非常に多く、グラフデータベースに対する熱意もあります。 そして、HadoopなどでのSQLの使用。 しかし、問題の真実は、今すぐデータベースが必要な場合、完全に機能し、OLTPと大規模なクエリトラフィックが可能な場合、それはリレーショナルデータベースであるか、何もないことです。

リレーショナルデータベースの中で、Oracleは人気があります。 Microsoft SQL Serverは2番目だと思います。 OLTPとクエリのワークロードの両方に使用できますが、実際には、これらのワークロードを混在させることで実際に逃げることはできません。 OLTPワークロードとクエリワークロードには異なるインシデントが必要です。 SQLとグラフに代わるものがあります。 ほとんどの企業は1つの特定のデータベースで標準化しています。そのため、他のすべてのプレーヤーと何十年も戦い抜いたOracleが最も支配的なデータベースになりました。 単に企業ライセンスを販売できるようになったため、企業は、オラクルが単にそれらを行わない例外的な製品でのみ代替製品を使用するからです。 また、データベースは戦略的にも進化します。 そして、あなたはこのプレゼンテーションのために少し研究をしたことを知っています。それはちょっとしたことです。しばらくしてからですが、DBAの立場から見るという点で、彼らがどのように進化するか興味深いです。 これは私が目に見えないトレンドと呼んでいるものです。 それは、ムーアの法則の三乗です。 これはおおよそ次のようなものです。最大のデータベースは新しいデータベースであり、取り込むべきデータが多くなった古いデータベースはありません。 通常、新しい問題に適用されるのはデータベースです。 そして、実際にはデータ量の観点から成長します。 ムーアの立方体で大体 法律。 したがって、ムーアの法則は6年ごとに10倍です。 VLDBは、6年ごとに1000倍になる傾向があります。 1991年、1992年、大きなデータベースはメガバイト単位で測定されます。 '97および'98では、ギガバイト。 2003、 '4、テラバイト。 2009年、'10年、ペタバイトのデータベースを見始めました。 たぶん1つまたは2つのエクサバイトデータベースがあったと思いますが、私が聞いた最大の時間は200ペタバイトで、ペタバイトデータベースにデータを取得できません。 しかし、その大部分は明らかに新しい大規模なWeb 2.0企業になるでしょう。おそらく、Facebookはその方向に向かっているでしょう。

とにかく、実際にそれを見て、データベースがそのようなエスカレーションを大量に通過することを期待している場合、それは多くを求めています。 そして驚くべきことに、確かにペタバイトのレベルまで、彼らはかなりうまくやったようです。 つまり、新しいものではなく、古い製品について話しているのです。 彼らは非常にうまくいったようです。 データベースのパフォーマンス、ボトルネックを見ると、実際にそれらを気にしていたので、心配する必要がありました。 これは基本的にハードウェアの故障であることがわかります。 CPUのボトルネック、おそらくメモリのボトルネック、おそらくディスクのボトルネックがあります。 悲しみの原因となるネットワークである可能性があります。また、何をしているのかによって、ロックの問題が発生する可能性もありますが、通常はロックを呼び出す相手がプログラムにわからないためです。 したがって、データベースを調整する場合は、実際にデータベースを調整して、可能な限りこれらの5つの可能なボトルネックの間で踊るようにします。 特定のサーバーで構成できるメモリの量が劇的に増加するため、それは簡単なことではありません。 その後、CPUはマルチコア、ディスクになりました。今では、コモディティサーバーでも、何百テラバイト、4分の1ペタバイト、おそらくコモディティサーバーでも実行できると思います。 したがって、これらのすべての中で、あなたは遊ぶことができます、もちろんネットワークは異なる速度で行くことができますが、ほとんどの場合、データベースを扱う場合は、サーバー間でファイバーケーブルを持ち、その上で実行しているものは特にありませんそのように。

データベースのパフォーマンス要因。 つまり、Dezがそれについて語るのは知っているので、これがどうなるのかは省略しますが、データベースの設計が悪いと、データベースのパフォーマンスが低下します。 プログラミングの設計が不適切な場合、データベースに非常に愚かなSQLをスローすることになる可能性があり、これには非常に長い時間がかかります。 同時実行とワークロードの混合、同時実行が多すぎると、ボトルネックの問題が発生します。 大きなクエリと非常に小さく、短く、鋭いクエリがある場合のワークロードの混合は、問題を引き起こします。 負荷分散の問題があります。 ほとんどのデータベースがそれを処理しますが、洗練された製品がない場合は、実際にクラスターのサイズを増やしたい場合は、いくつかのサーバーを追加するだけでは十分ではありません。 最適なパフォーマンスを得るには、実際に負荷のバランスを取る必要があります。 キャパシティプランニングを行う必要があります。 絶対に。 特に最近では、データ量がデータベースに使用されるよりも劇的に増加する昨今です。 また、データの取り込み方法、データの移動方法に関して、データレイヤー全体の問題があります。 データベースに時間通りにデータを取得しないことは、Windowsで動作するデータベースから24 x 7 x 375の操作に移行したため、パフォーマンスの問題になる可能性があります。データベースがダウンしているか、今日ではそうなる可能性は低いです。

Oracle DBAの問題。 これは私が考えていたものです。 私はOracle 7とともにOracleのDBAに参加しましたが、それを調整する方法を覚えています。 そして、実際に今Oracleを見ると、それは方法、方法、方法、方法の能力が向上しています。 ビットマップの索引付けなどがありますが、実際には、現時点でOracleデータベースに実際に存在するチューニングパラメーターの数を確認するのに時間をかけました。 また、350以上のチューニングパラメーターがあり、さらに100の隠されたパラメーターがあり、専門のDBAが知っているかもしれませんが、通常のOracle DBAは知りません。 つまり、この種のデータベースのチューニングは難しいことです。 それは決して簡単なことではありません。 あなたはそれを感じる必要があり、あなたはそれを長い間やっていなければならず、あなたはあなたが解決しようとしている問題を正確に知る必要があります。パフォーマンスは低下しますが、すべてのパフォーマンスではない場合があります。 重要なのは特定のクエリのパフォーマンスかもしれませんし、特定のデータとメモリを固定することでそれを修正できるかもしれませんし、インデックス付けで修正する必要があるかもしれませんし、別の方法でパーティション分割を開始する必要があるかもしれません。 できることはたくさんあります、それがポイントです。 したがって、結果として、彼らは頭の中でそれをするつもりはありません。DBAはツールが必要です。 次に、インデックス作成について説明するDezに話を進めます。

エリック・カバナ：わかった、デズ、持って行ってくれ。

Dez Blanchfield：ありがとう、Robin、そして表紙が大好きです。 あなたは私がエキサイティングなものに遠く離れて来ることさえできるように、あなたがそこにガントレットを投げたと思います。 しかし、データベース管理者にとっての今日の課題が何に変わったかについての私の見解として、私は私たちの小さな銀河の画像を使用しました。これは、私が環境に入ったときに私が想起しがちで、もはやないからですデータベースを管理したり、そのレベルでデータベースを設計したりする世界で。 しかし、あなたと同じように、ロビンと私は、管理者または開発者、または最終的には建築家として、長年データベースの世界に携わっており、クラストを獲得するためにより良いことができることに気付きました。 しかし、あなたはこのデータの銀河を見つめているように感じる傾向があります。今日、あなたが概説したように、私たちは非常に短い期間でメガバイトからペタバイトとエキソスケールに移行しました、物事の壮大なスキームで。 しかし、私の心に浮かぶフレーズは、データベースインデックスは今や黒人の芸術であり、エンタープライズレベルのビジネスアプリケーションやあなたを定式化するタイプのために、単なる人間が手を出すような種類のものではないということです。ただ話していた。 しかし、データベースの世界で得た歴史の種類について簡単に説明し、結論を導き出そうとしている場所の背景を理解してから、今日の友人と一緒にいくつかの資料を調べたかったのです。 IDERA、データベースのパフォーマンスを調整する方法についてはさまざまな考え方があると思うので、そのうちの1つは問題を投げかけています。 私が出くわす多くの店にとって、彼らは常に、データベース層、特にインデックス層でパフォーマンスチューニングを行うポイントに達しません。 。

多くの人が私の考えでは大きなアイアンアプローチを取っているだけで、古い映画や確かに最新のテレビ番組を見たことがあるなら、ここにフラッシュの写真があります古いキャラクターのフラッシュゴードンは、「フラッシュ」と呼ばれるようになったため、非常に速く、常にエネルギーが尽きてしまいがちです。 そして、これはデータベースのパフォーマンスに大きな鉄を投げたときに起こることです。 私の経験では常に、ゲームに高いパフォーマンスとハードワークを加え、オペレーティングシステムを最適化し、特定のポイントに調整することができます。 高速なマルチコア、マルチスレッドCPUを使用して、アプリケーションをより高速に実行し、大量のRAMを投入し、高スループットバックプレーンを使用し、ハードドライブからハードドライブをキャッシュしてソリッドステートに移行することができます。 、および高性能ストレージアレイ。 そして今でも、人々はデータベースエンジンにフラッシュやNVMeなどを投入し、このログイン時間の2倍のパフォーマンス向上が得られると考えています。 そして、常に彼らはいくらかの利益を得ます。 しかし、すべて同じ基本的なパフォーマンスチューニングの問題に戻ります。 クラスターが高速で動作するように、低遅延のネットワーク接続がたくさんあります。 また、データベースインフラストラクチャのクラスタリングのため、すべての作業を行うのは1台のマシンだけではありません。 しかし、あなたは同じ基本的なパフォーマンスの問題に戻る傾向があり、それはデータの読み取りです。 データの書き込みは、ほとんどの場合、かなり直線的な課題であり、適切に行われない限りです。

そして、今日の世界には課題があります。すべてのデータベースが平等に作成されるわけではありません。 データベースとクォートオンクォートの「データベース」があります。また、データベースエンジンについて考えるとき、人々はしばしば、SQLの世界における従来の通常の容疑者について考えます。 ご存じのように、OracleとMicrosoft SQL Serverがあり、オープンソースの世界にはMySQLがあります。MySQLは現在Oracleが所有していますが、まだオープンソースです。 そして、あまり一般的ではない容疑者であるNoSQLエンジンがあります。NoSQLエンジンは、まだインデックス作成とパフォーマンス管理に関する問題を抱えています。詳細には触れませんが、これらの数は増え続けています。開発者の観点からもパフォーマンスの観点からも物事​​は毎日現れ、データベースエンジンのように見えますが、それらは非常に異なる獣であり、どちらかを切り開くための独自の小さなニッチを持っていますメモリ内パフォーマンスまたはディスク上の線形スケール。 しかし、これはデータベースの世界では世界がどのように見えるかです。 これは2016年です。これは、データベースがどのようなものであるかを示す現在進行中のランドスケープマップを作成するさまざまな人々によるバージョン3のマップです。それの。 文字通り何百、何百、何百もの異なるメーカー、モデル、データベースのメーカー、常にSQLに準拠しています。 そして興味深いのは、彼らはすべて同じ課題に戻ってくるということです。 データベースエンジンのパフォーマンスとパフォーマンスチューニング、特にデータのインデックス方法によるチューニング。

データベースインデックス作成は興味深いトピックであるため、すぐにデータベースインデックス作成について説明します。デモでは、さらに詳しく説明する必要があります。 しかし、データベースインデックスのパフォーマンスチューニングは、データが高速かつ高速な形式でアクセスできることを保証する限り、世界の始まりと終わりの場所であるというのはかなり受け入れられており、標準的な業界慣行だと思います。 しかし、データベースのインデックス付けとは何ですか？ 日常の人間として慣れ親しんでいる形式でのインデックス作成について考える場合、本のインデックスページを考えてください。 本の中に何か、特に百科事典のようなもの、または何らかの形の参考資料のようなものを見つけたいなら、私がダムのトピックのようなものを探しているこのページのようなものを探しているなら百科事典で。 私は、ダム、水の集水域、そして一般に人工的に作られた大きなビルドアップエリアへのすべての言及を見つけたいです。 私は後ろに行き、アルファベット順に並べられたリスト、AからZ、左から右、そしてDを見つけます。「ダム」という言葉を見つけ、それを見ることができます16、38、41ページに参​​照があり、それらのページに移動して目をスキャンすると、「ダム」という単語への参照が見つかります。これは基本的にデータベース内の同じ概念です。しかし、今では多くの点でロケット科学です。 そのため、私が今までによく知ったすべてのデータベース管理者は、経験がどんなものであっても、インデックスがあらゆるデータベースの世界でパフォーマンスを調整するための最も重要なツールであると考えています。どんな場合でも。

一般に、データベースのインデックス作成について話すとき、多くの一般的なアプローチがあります。 また、データベースのインデックスが複雑になるほど、データのインデックス付けのアプローチが複雑になります。 しかし、基本的に、データのインデックス作成について考えるときは、名前のリストを持っているファイルがあると想像してください。 アルファベット順に並べ替えることはできません。 20個あると想像してください。 並べ替える場合-そのリスト内のデータを上から下に検索する場合、名前のリストだとしましょう。 ランダムな名前を選択し、そのリストを上から下に線形形式でスクロールし始め、それが順序付けられていないリストである場合、平均検索時間と最大検索時間として考えられる2つの基準があります。 2行目にタイプミスがあり、「最大検索時間」である必要があります。申し訳ありませんが、私の平均検索時間は基本的にN + 1を2で割ったもので、平均で50％の時間がかかりますリストの一番上から一番下までスキャンして、そのリスト内のランダムなものを見つけます。 そして、そこにある2行目は「最大検索時間」である必要があります。しかし、最大検索時間は基本的にアイテムの数です。つまり、20個のリストがある場合、最も時間がかかるということです。そのデータベース内の何かを検索するには、上から下に移動します。この単純化された例では20アイテムです。 そして、それは非常に遅いプロセスであり、パフォーマンスを調整する方法は本当にありません。 そして、そのデータを取得してインデックスを作成する他のタイプの方法があります。これは、実際には、バイナリ、Bツリー、ビットマップ、ハッシュ、クラスター化および非クラスター化など、実際のデータへのポインターの短いリストです。そして、空間、フィルター、XML、フルテキストなど、さまざまなタイプのデータがあります。

バイナリは、データがそれに役立つものに非常によく使用されるものです。 おそらく、Bツリーは一般的な意味で最も一般的な単一のものであり、歴史的には、任意の形式のデータのインデックスを構成する一般的な方法であり、ポインタを移動するとロガー、選択、挿入および削除が比較的簡単になりますポインター、ポイントへの参照。 ビットマップのような他のタイプもあります。データ型は、何らかの形式の関連する範囲を持っているかどうかなどに関係します。 ハッシュは、大きなオブジェクト、特にブログや画像に対して非常にうまく機能します。 また、データのインデックス付けには、さまざまな種類の科学的アプローチ、数学的アプローチがあります。 単なる人間にとって、彼らはこのレベルで話すのは興味深い挑戦です。 データベース管理者のパフォーマンスレベルでそれについて話すとき、彼らは本当にロケット科学者になり、人々は学位を取得します。RobinBloor博士は確かにそれを行っており、IBMや過去数十年の間に他の大きなブランド。 ですから、私の見解では、実際にはシステムの前に座ることができ、それを引き離して見せることができます。パフォーマンスの問題がコマンドラインまたはグラフィックユーザーインターフェイスの開始ツールで発生した正確な場所で、データの詳細を調べて問題の場所を特定し、その中にインデックス、サブインデックス、またはプライマリインデックスとセカンダリインデックスを構築しますデータを見つけ、それを使って物事を見つけます。 しかし、何百ものブランド、メーカー、モデル、メーカー、データベースの種類がある私たちが見せたその風景について考えるとき、私たちは人間が作ることができる、まさにその時を過ぎたのです。私たちが持っているデータベースエンジンの種類の感覚。 特に、最近ではリレーショナルデータベースプラットフォームの主要ブランドであるOracleのようなものに戻っただけです。

ERPやHRなどの専用プラットフォーム、または金融システムのいずれかから処理する必要があるデータベースの数、またはさまざまな理由でホームベーキングプラットフォームであるかどうか、データベースおよびデータベーステーブルとレコードの数対処することは天文学的であり、あなたは物理的に手でそれを行うことはできません。 そして、今度は追加の問題が発生しました。昔は、データベースサーバーが机の下に置かれていました。 放課後の小さな子供の頃、私はもともとApple IIes、そしてdBase II、dBase IIIのようなDOS PCベースのシステムでデータベースソフトウェアに取り組んでいたことがあります。範囲、さらにはVAXとPDP、さらにその上のログファイル。 そしてSabreのようなもの、そして最終的にはいくつかのSQLデータベースが登場しました。 しかし、最近データベースエンジンについて考えているとき、それらは左下隅のように見えます。 データベースサーバーは、机の下の床に座っている1台のマシンではありません。 データベースエンジンとクラスターのコピーを実行している数百台のマシンであり、数百テラバイトのデータ（ペタバイトではないにしても数千テラバイト）にまで拡張します。 そして極端な場合でさえ、Robin Bloor博士が言及したように、いくつかの特定のユースケース-航空会社、特に政府機関-はエクサバイトに達することができると。 それらはまだかなりニッチなものですが、特にドットコムブームから現在に至るまで、数百テラバイト、さらには数十ペタバイトも珍しくはありません。Web2.0企業と呼ばれるもの、Facebook、Google、Yahooなどなどなど。

また、物事が外部サービスに移行しているという複雑さもあります。 インフラストラクチャを提供するサービスアプローチとして、インフラストラクチャプラットフォームとソフトウェアがあります。 特に、Oracleやそのクラウドプラットフォーム、データベース、サーバーのようなものだけを購入できないプラットフォームサービス。 そのため、アプリケーションの非常に迅速な開発を行うことができ、データベースをサーバーにプラグインするだけです。 背後にあるものについて考える必要はありません。 欠点は、データベースがどのように設計され、実装されているかについて、多くの場合、問題が発生してパフォーマンスが問題になり、データベースが破損している理由を診断するための適切なツールを探すまで考えないことですパフォーマンスの問題がある場所。 そして、常に、そのデータのインデックス付け方法とそのデータに使用したインデックスの種類の一般的な問題に戻り、それが超人的なパフォーマンス要件に戻ります。 適切なシステムと適切なツールにアクセスしてそれらのエンジンをパフォーマンス調整し、ホットスポットを見つけて、クエリの場所、データの移動場所、クエリの種類、クエリの構造、クエリの実行者、クエリがキューに入れられているかどうか、キャッシュする必要があるかどうか。 どのような複製を探しますか？

ですから、私は、世界最高のデータベースの達人、基本的にはデータベースアーキテクト、データベース管理者、パフォーマンスベースでさえ、適切なツールを活用し始めることが非常に必要であると考えています。任意のデータベースエンジンに最適なパフォーマンスインデックスチューニングを提供します。 私たちが扱っているスケールと物事が動いているスピードのため、私たちは単に手でそれを行うことはできません。そして、そうすることを試みると、他のパフォーマンスの問題を引き起こす可能性があります。私たちは問題を解決しようとしています。そして、私たちはそれを私たちがバートに渡すところだと信じており、私たちは彼らがこのさまざまな問題を解決した方法と彼らのツールができることの種類について話しているところです特にOracleの世界ではそうです。 そして、それで、バート、私はあなたに渡すつもりです。

Bert Scalzo：ありがとう。 みなさん、ようこそ、私の名前はバート・スカルツォ、IDERAで働いています。 私は、データベース製品の一部のシニアプロダクトマネージャーです。 今日はそれらのいくつかを紹介します。 しかし、インデックスについてお話したいと思います。誰もがここで言ったことすべて、特に最後のスライドでは、インデックスが非常に複雑になったため、ツールが必要になったことに同意します。 したがって、Oracleインデックスの設計は、昔のように簡単ではありません。 多くの人は選択肢を見ると自信が持てません。私は歴史から引き出されたと言って、「これらの問題で唯一の確実性は、何も確実ではないということです」と言っています。 X、Y、またはZのインデックスを作成する必要があるとわかっていても、これらのオプティマイザーは期待どおりに動作しない場合があるため、実際にインデックスを作成するまでは確信が持てないためです そのため、インデックスの設計には多くの試行錯誤があります。 さて、古き良き時代には、インデックスが必要な場合、通常2つの質問、または1つの質問がありました。 それはユニークでしたか、それともユニークではありませんでしたか？ また、インデックスが多すぎると挿入、更新、削除の速度が低下するため、「1つのテーブルで最大いくつのインデックスを使用できますか？」などの他のことを考えたかもしれません。 また、データベースシステムにいて、データベースエンジンのページまたはブロックサイズに基づいて制限があったこともありましたが、実際にはかなり単純だったため、複数列インデックスに含めることができる列の数に制限がありました古き良き時代に インデックスを作成したか、しませんでした。 実際、すべてがBツリーにありました。 重複を許可することも許可しないこともできました。 人生は素晴らしく、人生はシンプルでした。

さて、今日の生活はそれほど良くも単純でもありません。 Bツリーとビットマップ、ビットマップ結合を使用できるようになったため、以前の方法で赤いGhostbusterのサインを使用しました。 そして、これらのいくつかがすぐに説明します。 クラスター化および非クラスター化、一意または重複、順または逆順、関数ベース、パーティション化または非パーティション化。 パーティショニングが含まれている場合、それはグローバルまたはローカルのパーティショニングですか？ それについても説明します。 また、インデックス付きの組織化テーブルと呼ばれるものもあります。 そして、実際にはここから抜け出した他の半ダースがあります。なぜなら、インデックスはあなたが思っていたよりもはるかに厳しいことをあなたに納得させるはずだからです。 この特定のスライドでは、図の左上の部分から始めて、表を用意します。 そして、最初に決定しなければならないことは、データベースのバージョンとデータベースのベンダーに応じて、オブジェクトテーブルを許可するのか、それともリレーショナルのみですか？ 右側を下って、リレーショナルテーブルを作成していると言います。 さて、私が自問しなければならない次の質問は、それはクラスターにあるのでしょうか？ そして、しばらくOracleを使用してきた多くの人は、クラスタがOracle 6日間戻ってきたことを思い出すでしょう。 今日はおそらくあまり使われていませんが、最初にそのブランチを下ってみましょう。

テーブルをクラスターに配置する場合、そのテーブルにクラスター化インデックスを作成する必要があります。 さて、Oracleでは、テーブルをクラスター化したときに、基本的に行を保存していたか、値が類似している行が互いに近くにありました。 そのため、クラスター化インデックスが必要であり、そのクラスター化インデックスはパーティション化されていない可能性があります。 つまり、クラスター化されたテーブルをどのように分割するかについて、実際にはパーティション分割の方法はありませんでした。 厳密にはパーティション分割されていません。 また、パーティション化されていないため、グローバルでした。 グローバルとは何かをすぐに説明します。 そして、それは常にBツリーでした。 言い換えれば、私がそのブランチに行ったとき、それは非常に簡単でした。私は多くの選択肢がありませんでした。 さて、いくつかのバージョンで許可されていたクラスター化テーブルで非クラスター化インデックスを作成した場合、再び非パーティション化されました。 パーティション化されていない場合、唯一の選択肢はグローバルです。 そのため、Bツリーまたはビットマップを選択できます。 繰り返しますが、データベースのバージョンに依存していました。 しかし、今度は、リレーショナルテーブルに戻って、再び右側を下ってみましょう。今度は、プレーンで、古い、通常の、ヒープテーブルを作成します。リレーショナルテーブルです。 表スペースに配置されます。 最初にここから右側を下っていきます。 それが組織、ヒープです。 次の質問は、「このテーブルをパーティション分割しますか？」です。「オプティマイザはクエリを最適化する方法について賢くなります。 」しかし、多くのDBAは、あなたがそうする理由は管理目的であると言うでしょう。 10億行のテーブルがある場合、それをパーティションまたはバケットに分割すると、最後のバケットにデータを追加するときに、ほんの数百万行のデータを削除してインデックスを作成できます。 そのデータを挿入してから、そのバケットだけでそのインデックスを再構築できます。

パーティションの削除などの一部の最適化手法にとっては優れた手法でしたが、実際の価値は小さな部分で管理タスクを管理または実行できることでした。 組織のヒープに移動するとき、最初の質問は「パーティションを分割したかどうか」でした。左に移動して、テーブルをパーティション分割しません。 さて、これを言うと奇妙に思えるかもしれませんが、パーティション化されていないテーブルを使用して、慣れているようにインデックスをパーティション分割することはできません。また、インデックスをパーティション分割することもできます。 落ち着いて考える。 いつも考えていたように、テーブルには基本的に1つのバケットがありますが、インデックスには複数のバケットがあります。 バケットの数とテーブルの数とインデックス内のバケットの数との間に不一致がある場合、それがグローバルの意味です。 したがって、テーブルがパーティション分割されておらず、インデックスがパーティション分割されている場合、不一致があるため、グローバルと見なされます。 ここで、組織のヒープに戻り、代わりにパーティション側に戻ります。 パーティションテーブルがあり、テーブルに4つのバケット、4つのパーティションがある場合、インデックスがテーブルデザインに一致するように、インデックスに4つのバケットを含めることができます。 そして、それは、右側の終わりです。 それはローカルと見なされます。 ローカルインデックスとは、基本的に、テーブルとインデックスのパーティション分割が同じ方法で行われ、バケットの数が同じであることを意味します。 そして、ローカルインデックスを取得したら、それはBツリーまたはビットマップになる可能性があり、そのような緑色の矢印が上がると、それがBツリーであっても、まだ選択できることがあることがわかります。 機能ベースにすることもできます。 また、ビットマップの場合、ビットマップにはさまざまな種類があります。 ビットマップ結合インデックスと呼ばれるものがあります。 データウェアハウジングを行っている場合、これはスタースキーマまたはデザインの非常に一般的なインデックスです。 何が起こるかというと、インデックスはテーブル内でポイントする行IDを持っていますが、親テーブルの行IDも持っているので、スキーマ設計にスターを付けて、探しているのです。ファクトテーブルでは、ファクトテーブルのそのインデックスは、関心のあるデータを指し示し、ディメンションのすべての行を指すので、インデックスは1つだけで済みます。

実際、これは何年も前のデータベースであるRed Brickが原因で発生しました。多くの人がそれを覚えているかもしれません。 したがって、この写真を見ると、写真が大きくなるため、すべてをこの写真に入れたわけではないことを念頭に置いてください。ここでは、右上の部分に追加の問題があります。 。 逆順インデックスですか？ また、「逆順インデックスが必要なのはなぜですか？ Oracleのクラスター環境にいる場合、実際のアプリケーションクラスターを実行している場合、インデックスを順序どおりに保持している場合、逆にならないため、大量の処理が発生している場合同じ値または同じインデックス値、何が起こるかは、Bツリーのホットエリアになります。 つまり、競合やロックが発生してそのようなものにアクセスしようとすることを意味し、ネットワーク内のノード間でそれを行うことになります。 さて、逆順インデックスを設定すると、今ではそれを取り消すことができます。 「同様の値はツリーの異なる部分にあるため、ツリー内のホットエリアを競合する個別のノードはありません。」と言うことができます。また、一部のオプションではuniqueが機能しないことにも注意してください。 。 ご覧のように、3、5、8、11の番号が付けられているため、一意のインデックスを取得できない場合があります。 同様に、逆インデックスを作成できない場合もあります。また、ロギングまたはロギングなし、並列および非並列などの追加の問題があります。 メモリ内の特定の領域に物事を割り当てることができます。

そして、これはOracleの機能のかなりの部分をまだ残しています。 Oracle 12を見ると、この写真に追加できるものがさらに6つほどあると思います。 インデックス作成は非常に複雑であり、前のスピーカーに同意します。これをナビゲートして適切な選択を行うには、ツールが必要です。 おそらく、このような写真と、物事をどのように選択するかについての何らかの方法論が必要であり、ツールがそこに到達するのに役立つことを願っています。 そして、それは試行錯誤になるでしょう。 私はいつも人々に「跳躍する前に見てください」と言います。そして、あなたはここで小さな犬を見ることができます、彼は見ずにジャンプします、彼はサメと一緒に水になります、または水に飛び込む準備ができています、そして彼は自分自身を突き刺すつもりです。 インデックスを作成しても、物事が良くなるとは限らないため、インデックス作成について考える必要があります。 実際、インデックスを作成すると速度が低下する可能性があります。 また、クエリのパフォーマンスは、ある選択肢を別の選択肢よりも大幅に向上させることができます。 そして、良い例を挙げましょう。 デザインのスタースキーマを実行していて、ディメンションテーブルでビットマップインデックスを使用する場合と、「Bツリーインデックスを使用する」と言う場合は、ビットマップとB-木。 1つのソリューションは、他のソリューションよりも1桁、または場合によっては数桁高速になると言えます。 しかし、データウェアハウジング環境など、1つの環境で機能するものは、OLTP環境ではおそらく適切な選択ではないことに留意してください。

たとえば、トランザクションテーブルを取得し、トランザクションテーブルにビットマップインデックスを配置する場合、ビットマップ、これらの長い文字列などを計算してリセットするのはコストがかかるため、OLTPテーブルでは、ビットマップが非常に頻繁にヒットする可能性がありますインデックスは更新のためだけのものではないため、破損し、システムの速度が低下する可能性があります。 高速アクセスには適していますが、更新には適していません。 インデックスには試行錯誤が必要だと思います。 もはや黄金のルールはありません。この方程式にはさまざまな変数がありすぎて知ることができません。最終的に、データベース内の実行を見たり計画を説明して、適切な選択を行っているかどうかを確認する必要があります。 また、計画の分析は、それ自体が科学に近い場合もあります。 今日はそれを取り上げません。これは別のトピックですが、インデックスデザインを当たり前のこととは考えないでください。 前の写真で示したこれらのクレイジーなインデックスタイプがすべてあり、前のスピーカーが話した正当な理由があります。 これらは、データベースベンダーのどこかにチェックリストを配置するのに便利な機能であるため、作成されただけではありません。 これらのインデックスが重要であり、大きな違いを生むユースケースまたはシナリオがあります。 それでは、ツールの1つでさまざまな種類のインデックスの例をいくつか紹介します。 あなたがそれを見ることができるように、私はちょうど私のスクリーンを立ち上げさせてください。 さて、ここで私は中に座っています-このアプリケーションを最小化します。 VMwareの内部に座って、Windows Server 2012 VMを実行しています。

そして、あなたが見ることができる、私は人に知られているほぼすべてのツールを持っています。 プロダクトマネージャーとして、私は自分の競争を常に意識する必要があります。そのため、私が持っているツールだけでなく、競合他社は何をしているのでしょうか。 DBArtisanと呼ばれるこのツールをここに用意しました。これは既に実行していますが、今後も使用する予定です。 そして、これは本当に便利なツールです。Oracleのエンタープライズマネージャー、SQL ServerのSQL Management Studio、MySQLのMySQL Workbench、サポートしている他の12のデータベースを使用する代わりに、私のデータベースはすべてこの1つのツールに組み込まれています。 DB2があり、MySQL、Oracle、Postgres、SQL Server、Sybaseがあります。この特定のものには6つのデータベースしかありません。なぜなら、ツールは12個のデータベースをサポートしていますが、貧弱なVM、6個のデータベースを同時に実行し、デモを行うことは、私のハードウェアが促進するのと同じくらいです。 それでは、今すぐオラクルに戻ってみましょう。気づいたら、これらはすべて同じです。 DB2でのパフォーマンスを測定する場合、Oracleでの選択と同じです。 カバーの下では、さまざまなことを行っているため、何が起こっているかを知る必要はありませんが、一貫したインターフェイスを提供して、複数のデータベースプラットフォームの専門家になることができます。 そして、この議論のトピックであるインデックスの操作も含まれます。

ここに来て、最初にいくつかのテーブルを見てみましょう。いくつかのテーブルがある映画データベースがあります。 そして、顧客テーブルのような特定のテーブルをここで見ると、テーブルのデザイン、テーブルの列、各列の情報を見ることができます。 テーブルのプロパティはありますが、インデックス用のタブがあり、テーブルのインデックスがあることがわかります。 これらのインデックスの1つがPKインデックスであり、プライマリキーであることに注意してください。 これらの他のクエリは、クエリアクセスを改善するための単なるインデックスのように見えます。たとえば、姓または名でクエリを実行するか、電話番号と郵便番号を調べます。 そして、この郵便番号のような特定のインデックスを選択し、ダブルクリックすると、今、それがユニークでないインデックスであり、ビットマップ、ユニークでない他のタイプのいくつかがあることがわかります。一意、ソートされているかどうか、そのロギングかどうか、逆順かどうか、関数ベースかどうか。 ああ、これは私がカバーしなかった楽しいものです。 実際に不可視のインデックスを持つことができます。 そして、「さて、なぜ目に見えないインデックスを作成したいのでしょうか？」と言うでしょう。まあ、良い例を挙げましょう。 実稼働システムにいて、パフォーマンスの問題があり、インデックスを作成しても問題が解決するかどうかわからないので、インデックスを作成して実稼働を遅くしたくないが、何らかの方法でそれをテストすることができます。 本番ではインデックスを非表示として作成できます。つまり、オプティマイザを呼び出すアプリケーションコードの多くはそのインデックスを使用しません。 作成され、有効ですが、使用されません。 次に、このインデックスが役立つと思われるクエリ、または一連のクエリを実行し、ヒントを挿入して、「ねえ、オプティマイザ、目に見えないインデックスがあります。使用してほしいそして今、実稼働環境で何かをテストしましたが、実行中の実稼働環境でアプリケーションを壊していません。 それが不可視のインデックスの使用です。 それについて最初に聞いたとき、それは愚かに聞こえますが、用途があります。

また、インデックスで、それらが並列であるかどうか、また、それらが並列であるインスタンスの数を定義することもできます。 さて、非クラスターまたは非実アプリケーションのクラスター環境では、非ラック、並列とは、試行するためにクエリを起動できるサブプロセスの数と、より速くまたはより迅速に物事を試行するワーカープロセスを意味します。 また、並列インスタンスは、実際のアプリケーションクラスターにいる場合、たとえば10個のノードがある場合、作業を分割できるノードの数はいくつですか？ たぶん、それは10のうちの4つで、それぞれに4つのサブプロセスがあります。 それは一例です。 そして、キー圧縮があります。 実際にインデックスを圧縮できますか？ はい、もしくは、いいえ。 そしてもちろん、インデックスに指定できるストレージパラメータがあります。 さて、これらはインデックスの問題というよりも実際にはストレージパラメーターであるため、これらについては説明しませんでした。 そして最後に、これらのパーティションを作成するかどうかを決定します。 少しここにドロップします。 別のスキーマに移動します。 これはスタースキーマであり、たとえば、この期間テーブルはディメンションテーブルです。 スタースキーマデザインを行ったことがある場合、通常は時間のディメンションがあるため、このデータベースとこのスタースキーマでは、期間が時間ディメンションになります。 今、私はそれがおかしいように見えることを知っています、「うん、それらのすべての列を見てください-正規化について聞いたことがありますか？」さて、あなたはデータウェアハウスまたはスタースキーマ設計にいるとき、通常、テーブルはありません。一般的な人が見て、「これはあまりよく設計されていません」と言うテーブルがあります。しかし、それがデータウェアハウジング環境での方法です。

さて、これらの列がすべてあるので、何が起こるかを見てください。それを見てください。すべての列にインデックスがあります。 さて、OLTP環境では、それはノーだろう。 すべての操作が遅くなります。 データウェアハウジング環境では、バッチロードサイクル中にそれらを削除します。 オーバーヘッドやインデックスなしでロードし、インデックスを再作成します。 また、テーブルをパーティション分割した場合、テーブル内のすべてのバケットのインデックスを削除する代わりに、そのバッチロードサイクル中にデータが入るバケットにインデックスを削除できます。 そして、それらのバケットのインデックス部分のみを再作成します。 そのため、非常に管理しやすくなっています。 そして、私が見た場合-ここに「ホリデーフラグ」と呼ばれる列があり、基本的にははいまたはいいえです。 これはビットマップインデックスであり、ほとんどの人にとって「まあ、それは理にかなっている」と言うことに注意してください。はい、いいえ、YまたはN、意味のある値は2つだけです。 また、ビットマップインデックスのドキュメントを読むと、カーディナリティの低いものを選択するように常に指示されるためです。

ここで、ファクトテーブルの1つに移動します。ここに注文があります。 そして、これは1日あたりの私の注文です。 そして、あなたは今、かなりの数の列を持っていること、そして再び、私は数個以上のインデックスを持っていることを見るでしょう。 そしてここに、ユニバーサルプライスコードと呼ばれるものがあります。 これは小売店用でした。そのため、店で何かを購入するとき、これらの小さなバーコードを知っています。これが普遍的な価格コードです。 現在、何百万もの普遍的な価格コードがあります。 さて、ものを販売しているこの特定の会社については、おそらく170万から200万のユニバーサル価格コードがありました。したがって、170万の異なる値が高いカーディナリティのように聞こえるので、これはビットマップインデックスにならないことが予想されます。 しかし、実際には、データウェアハウジング環境では、これをビットマップにする必要があります。 では、その理由を説明しましょう。 このユニバーサル価格コードには170万の異なる値があります。この注文テーブルの行の数は、数億から数十億の行です。 私のインデックスは、テーブルのサイズまたはカーディナリティと比較してカーディナリティが低いです。 そのため、カーディナリティは低くなります。 ここではビットマップを選択する170万の異なる値があるため、直感に反しますが、ビットマップインデックスは便利です。 今、ビットマップ結合インデックスを使用したいことがわかっていれば、現在製品はそれをサポートしていませんが、次のリリースで追加されていますが、これは別の選択肢です。 また、スタースキーマでは、ビットマップインデックスがファクトテーブルにあり、Bツリーの1つのインデックスがファクトテーブルの行を指し、次にそのファクトのディメンションテーブルで明らかになったすべての行を指すことを忘れないでください。 そして、そこには別のオプションがあります。 それで、見てみましょう、私は今テーブルから出たいです、そして、インデックスの下で同じ情報を持っていることをすぐにあなたに見せたいです、そして私は同じ基本的なことをするつもりです。

さて、私がこれを取り上げた理由は、あなたが気づくかもしれないということです。ちょっと主キーがないのです。 主キーはキー制約で実行されるため、実際には制約定義でカバーされます。 これらは、制約の一部ではないインデックスになります。 「ちょっと待って、それは外部キーのように見えるかもしれません。外部キーは制約です」と言うかもしれませんが、外部キーとほとんどのデータベースは、外部キー列にインデックスを自動的に作成しません。お勧めします、そしてあなたはそこに行きます-私はすべて同じ選択肢を再び持っています。 そして、圧縮するためだけに変更したい場合は、それを行うことができます。

現在、圧縮はBツリーインデックスでのみ機能します。 それが許可するのは、Bツリーのさまざまなノードを見ると、値の一部を圧縮できることです。 実際には、テーブル圧縮のような圧縮ではなく、非リーフノードのBツリーに格納されているものの圧縮です。 それは多くのスペースを節約しませんが、違いを生むことができます。 それに気づいたので、私は時間にかなり近づいているので、やりたいことは、戻って共有を停止することです。 また、idera.comで14日間のトライアル用に製品を公開しています。 特に複数のデータベースプラットフォームを使用する場合は、非常に優れた製品です。 2つまたは3つの異なるデータベースを使用する場合、このツールを使用すると作業がはるかに楽になります。 インデックスの設計と選択を支援するツールがあり、DB Optimizerと呼ばれるツールがあります。 今日はそれをカバーできませんでした。 そして、あなたが私に連絡したい場合、私のメールアドレスがあります、それは、またはあなたは私のプライベートメールで私を捕まえることができます、そして私はブログを持っています、私はそこにウェブサイトとブログ、そしてLinkedInプロファイルを持っています。 だから、製品に関連していなくても、私に何でも気軽に連絡してください。データベースについて話したいだけなら、私は心のオタクで、テクノバブルについて知りたいです。

エリック・カバナ：わかった、デズ、ロビン、少なくともあなたにはそれぞれいくつかの質問があると確信している。ここに数分残っている。 デズ、どう思う？

Dez Blanchfield：私はあなたに尋ねなければならない一つの素晴らしい質問があります。それは私の心の奥に座っていました。 あなたが見た最もクレイジーなシナリオは何ですか？ 私はあなたのブログを読みました、私はあなたをよくフォローしています-あなたはおそらくあなたがほとんどすべての可能性が低い人の一人であり、ロビン・ブローア博士は私が会った2番目だと思います私の生涯。 しかし、あなたはおそらく、すべてのクレイジーなシナリオを見たことがあります、あなたが見た最もクレイジーなシナリオのいくつか、あなたが遭遇したこと、そしてちょうど対処することができなかった人間のように、あなたは歩くことができましたこのDBArtisan全体でジェダイマインドトリックを実行しますか？

Bert Scalzo：かつてデータベースデザインで、ファイルレイアウト設計での考え方を非常によく考えていた顧客がいたので、データベースを正規化するとき、最初にやろうとすることは繰り返しグループの。 まあ、彼らは列を持っていて、それを長い、またはBLOBまたはCLOBにし、その中に値、番号1、セミコロン、値番号2、セミコロン、値番号、セミコロンを入れて、彼らは数千の値を持ちますその列で検索する必要がありましたが、「なぜこの処理が非常に遅いのですか？」というようなものです。そして、「まあ、あなたは自分のやったことのインデックスを作成できません。ただそのため、計画を使用して、彼らがする必要があるのはそのテーブルを正規化することであることを実際に示しました。 正規化は物事を改善する学問的な運動であるためではなく、彼らはそのフィールドでクエリを望んでいたので、それをインデックス化できるようにしたかったので、繰り返しグループでインデックス化できなかった、または少なくとも簡単にできない。 そして、それはおそらく私が今まで見た中で最悪のことです。

Dez Blanchfield：ええ、どれくらいの頻度で出くわすかは興味深いです。データベースに関する課題は、科学であることを人々は忘れています。 そして、このスペース全体で学位と博士号を取得し、そこに論文を書いている人々がいます。そして、あなたはあなたのTOADハンドブックと他の記憶からのものを含む全体の盗品を書きました。 ある種のクォート・オン・クォート「ビッグデータ」に向かう傾向–必要に応じて、データベースアーキテクチャとデータベーステクノロジー、データベースサイエンスの基礎を忘れている人が多いようです。 従来のデータベースプラットフォームからの移行と、私たちが効果的に地面に釘付けにしたと考える従来のデータベースに関するフィールドで見ているものは、パフォーマンスチューニングとスケーリングの例にすぎません。 多くの人々が再学習し、彼らがそこに座って、ユーリカの瞬間のような「a-ha」の瞬間を経験しているのを見ていますか？このビッグデータは実際には本当に大きなデータベースのようなものです それはそこにあり、人々はあなたに返事をして、「私たちは忘れていた、私たちが知っていたこと、そしてあなたを私たちを暗い側から連れ戻すことができますか？」

Bert Scalzo：ええ、いや、これはなんとなく認めなければならないのは恐ろしいことですが、リレーショナルデータベースベンダーもKool-Aidを飲みました。 覚えているなら、10年ほど前に、構造化されていないデータをリレーショナルデータベースに格納し始めましたが、これはやや奇妙なことでした。そして、データ、リレーショナルデータベースはNoSQLタイプを追加していますもの。 実際、Oracle 12のCR2ではまだ公開されていませんが、ベータ版を見ると、ベータ版プログラムの場合、シャーディングがサポートされています。 これで、NoSQLシャーディングの概念が追加されていないリレーショナルデータベースができました。 そして、「a-ha」の瞬間は、「a-ha」に向かうリレーショナル側の人々にとってより重要であるように思われます。上に行って、ダークサイドに参加しました。

Dez Blanchfield：そうですね 、あなたは多くの厄介なデータへのシフトを言っているのです。私が正しいと理解していれば、私たちが今ビッグデータプラットフォームと呼んでいるものを理解しています。そんなに古いわけではありませんが、それは彼らが自分たちのリレーショナルデータベースで何をしているのかに焦点を合わせ直して、より多くの投資を得るという意味ではないのですか？

Bert Scalzo：いいえ、通常、「ビッグデータ型のニーズ」を引用していたと思われる場合、彼らは他のデータベースプラットフォームに行って何かをする必要はなく、 -リレーショナルな方法で、データベースベンダーは、それらのことを行うために、リレーショナルデータベース内で同じ非リレーショナル技術を提供しています。 JSONデータ型やデータ自体に埋め込まれた意味を持つ他の複雑なデータ型などの非構造化データがある場合、データベースベンダーはそれをサポートするだけでなく、ACIDを提供します非構造化データのコンプライアンス。 リレーショナルデータベースは新しい技術とテクノロジーを採用しているため、「a-ha」は「アプリケーション開発者である私たちが何かを学んでいないので、もう一度学習する必要がある」ということではないようです。 、私たちは今、このようにしています。従来のリレーショナルデータベースでそのようにして、ここでこのデータベースで行うようにそれを行うにはどうすればよいでしょうか？」そしてそれはより一般的になりつつあり、データベースベンダー自身が可能にしているそれ。

Dez Blanchfield：そうですね 、DBArtisanとそのツールのこの分野での伝統的な容疑者は誰ですか？ あなたが最近書いたものについていくつかの宿題をしました、そして、あなたが何かを書いた記憶から、それはあなたのブログの1つであったと思います、Oracle世界での極端なデータベースのパフォーマンス。 いつだったか思い出せませんが、今年の記憶からか、去年の終わりからこのことを書いたと思います。 そして、私が今日話しているトピックのタイプの伝統的で通常の容疑者であるように思われました。人々は非常に大規模なデータベース環境に行き、あなたがそれで極端な利益を求めているものを探します。 DBArtisanを取り上げて、それを有効に活用している人たちが、あなたがそこにいるという普通の容疑者は誰ですか？

Bert Scalzo：ええ、私たちにはたくさんの顧客がいます。実際、今日、私は非常に大きな政府機関で働いていました。やり直し、どうやってやるのかではありません。 そして、それは大丈夫です、つまり、誰もが何かをする方法を知っているべきですが、生産性は「何」を成し遂げているのです。 ビジネスからタスクを実行するように求められた場合、それが彼らが興味を持っているすべてです。いつタスクが完了したかを示すチェックマークが表示されましたか？ そこにたどり着くために私が使ったテクニックやテクノバブルはありません。 そのため、私たちのツールは何に焦点を当て、生産性を大幅に向上させます。それは本当に大きな利点です。前述したように、一部のデータベースはデータベースプラットフォーム専用のツールを提供します。 12のデータベースプラットフォームに対応しています。 同じワークフロー、同じグラフィカルユーザーインターフェイス、同じナビゲーションを使用しています。 ユーザーに特権を付与する方法、またはデータベースでテーブルまたはインデックスを作成する方法を知っている場合、同じルックアンドフィールと同じワークフローであるため、12のすべてで実行できます。 それはお客様にとって大きな価値があります。

Dez Blanchfield：ええ、私は、人々が彼らの人的資源から彼らの金のためにより多くの強打を得たいと思うと思います。 そして、Oracle、Ingres、DB2の個々のスペシャリストがいた時代は終わりました。 人々はあらゆる取引のジャックになることが期待されているので、このことは絶対に命を救ったと思います。

ロビン・ブロア博士に手渡す前に、最後の簡単なことを一つだけ。 14日間の無料ダウンロードがあるとおっしゃいましたが、どうするのですか。先に進んで、それを行う場合は、ちなみに、Bloor tech labに入れて、これをスピンします自分で試してみてください。今日までそれをする機会がありませんでした。 14日間のトライアルについて言及しましたが、コンピューターのVMで実行していると言いましたが、それはラップトップだと思います。 ロビンに質問を返す直前に、14日間の試用版を実際に使用して使用するためのエントリーレベルのセットアップは何ですか？

Bert Scalzo：任意のWindows環境。したがって、Windows 7、1つのCPUと4つのメモリのギグを備えた仮想マシン。 私たちは本当に太っているツールでも高価なツールでもありません。 同じWindowsの同じVMでデータベースサーバーを実行したい場合は、さらに追加する必要がありますが、データベースサーバーまたは別のVMでデータベースを実行している場合は、ロードするVMと製品の実行は非常に軽量です。1CPU、4ギガメモリ、ほとんどすべてのバージョンのWindows – 32ビットと64ビットの両方のインストールをサポートしています。 ただし、データベースベンダーのクライアントをインストールする必要があります。 したがって、Oracleに接続する場合は、SQLネットクライアントをインストールする必要があります。これは、データベースと通信するためにOracleが必要とするものだからです。

Dez Blanchfield：とても簡単に聞こえます。 このツールが人々の命を救うことを認識していること以外に、これから人々が奪うことを望んでいることよりも、それをダウンロードして遊んでみるべきだということです。 14日間の無料トライアルを提供していることを考えると。 そして、何も余分にインストールすることなく、現在のラップトップで実行できます。既にデータベース管理を行っている場合、データベースを既に使用しており、それらのツールをすべて備えており、ローカルVMまたはローカルデスクトップでは、インストールして操作するのは簡単なようです。 だから私は人々がそうすることを強くお勧めします。

ロビン、質問はあると思うし、エリック、おそらく聴衆からもらったと思うので、ロビン、どうやってあなたに渡して、エリックに戻るのか？

Robin Bloor：ええ、わかりました、私は言いたいことがあります。つまり、このエリアは魅力的でした。いつも歯を切ったからです。 しかし、真実は、おそらく1998年、1999年頃から、オラクルが実際にできることを流し続けてきました。 また、SybaseとMicrosoft SQL Serverを知っていましたが、どちらもOracleができることと比べるとかなり単純です。 あなたはあなたが私を笑わせた-つまり、あなたがシャーディングについて話し始めたとき、私は私の口を覆った。 Oracleはこれを以前に行いました。 Oracleはある時点で導入し、オブジェクトリレーショナルのアイデアに神経質になったため、Oracleにオブジェクト表記法とオブジェクトストレージのようなものを作成する機能を導入し、エンジニアの1人と話しました。彼らがそれを導入して数年後、私は何人がそれを使用したかを尋ねました。 そして、NoSQLのトレンド分析を試み始めた場合にも同じことが起こると思います。 間違いだと思いますが、私はあなたの考えに興味があります。 確かに、彼らはクールエイドを飲みます。 彼らは、Cassandraのような大きなNoSQLデータベースと同様の主張をできるようになったように感じますが、ご存知のように、それはあなたにとって意味がありますか？

バート・スカルツォ：いいえ、頭に釘を打ちました。 リレーショナルを行う場合は、Oracle、SQL Server、DB2、Postgresなどのリレーショナルベンダーを選択しますが、非リレーショナルな処理を行う場合は、ビッグデータスペースまたはNoSQLスペースで、適切な仕事に適切なツールを選択します。 そして、それが最初に私のリレーショナルデータベースベンダーに自然に行くとは思わない。 次に、他のリンクルを追加します。つまり、クラウドで利用可能なものは何ですか？ データベースを前提から外したい多くの人々。 次に、クラウドプロバイダーを見て、「わかりました、何を提供しますか、私のニーズに合ったデータベースは何がありますか、それらはどれくらい売れていますか、率直に言って、そのデータベースを使用するための料金や料金は何ですか？」 1時間ごと、または1日ごとにクラウドで。 ギガバイトまたはテラバイト単位ですか？」そして、MongoやCassandraのような比較的新しいデータベースがいくつかあるかもしれません。多分それらの料金は安いので、マルチペタバイトタイプのビッグデータを実行する場合は、コストの観点からのみ、クラウド内のNoSQLデータベースは最も費用対効果の高い方法である可能性があるため、考慮する必要があります。

Robin Bloor：はい、そうです。 つまり、私の経験では、リレーショナルデータベースに関することです。これは、傷を付けるのに十分な長さです。確かに、それを適用し始めると、実際にリレーショナルとは何かを理解するという常識がたくさんあります。 、1人の顧客と一度コンサルティングを行ったことを覚えています。彼らは私を部屋に連れて行って、ある種のエンティティダイアグラムを作成し、会社の主要システムがどのようなものであるかのモデルである3番目の標準フォームを作成しました。 そこには240のテーブルがあり、彼らは言った。「まあ、それについてどう思いますか？ 私たちはこのためのデータベースを構築するつもりです」と「それについてどう思いますか」と言いました。「うまくいくとは思わない」と言いました。 11方向の結合内に特定の構造を作成するために。 そして、それはリレーショナルについて理解することです。 だから、私はあなたがどれほど悪いデザインに出会うかという点に興味があります。 つまり、DBArtisanには何の問題もありません。非常に賢明なことをしていて、複数のプラットフォームで実際に表示できるという事実は素晴らしいと思いますが、デザインがどこで問題になっているのでしょうか人々がスノーフレークを取得するのではなく、スタースキーマにたどり着いた場合、人々はあらゆる種類の心痛を解決できたはずです。

バート・スカルツォ：まあ、私は誇大なまたは慢なように聞こえたくありませんが、私は頻繁に言うでしょう。 明らかに、私が関与しているデータベースの大部分には、問題があります。 データベースオプティマイザーツールなどのツールはそれらの問題を解決するのに役立つため、これは良いことですが、私にとって本当に面白いのは、多くの問題が何度も何度も同じ単純な問題であることです。 先日、11方向の結合クエリを持つ顧客と仕事をしていたのですが、「わかりました、なぜwith句を使用しなかったのですか？」 「それが何であるかわからない。」そして、私は言った、「そしてここであなたのサブセレクトをあなたの相関と非相関で見てください」と私は言いました。 「それは、外側からのテーブル参照です。」と言いました。「それを正しいレベルに移動し、必要以上に深く埋め込まないでください。オプティマイザを混乱させます。」そして、いくつかの微調整を行います。約2時間実行されていたものを10分に短縮しました。その場合、私たちは彼らが書いたSQLを改善する以外に何もしませんでした。 問題は、非学術的環境でプログラミングを学ぶ多くの大学と多くの人々が、それを記録された時間プロセスまたは行指向プロセスとして学習することであり、リレーショナルは自然指向のセットであり、あなたは良いSQLを書くためにセットで考える必要があります。

Robin Bloor：はい、そうだと思います。 そして、あなたは理解する必要があります、それは人々がこのようなもののABCを知るべきだということです。 関係ありません。 適切に設計され、モデル化されたデータベースでさえ、結合に時間がかかり、並べ替えに時間がかかることに気付かないと、合理的なことをすることができなくなります。 世界がそれらを速くする方法を見つけたことがないので、彼らはそうします。 彼らは、データを整理して他の方法よりも速くする方法を見つけました。NoSQLデータベースに対して私が言わなければならない熱意の多くは、単に結合を避けることです。 NoSQLデータベースのいずれかに参加した場合、彼らはひどく吸い込むので、彼らは単に同じデータの広がりを持つデータベースの構築を開始します。 そう思いませんか？

Bert Scalzo：ああ、絶対に。 笑わなければなりません。なぜなら、私はリレーショナルデータベースの前に戻り、IngresがRTI（Relational Technology Institute）であり、SQLがなく、SQLの前のリレーショナル言語があったからです。 Ingresでは、当時はQuelと呼ばれていました。 したがって、ネットワークやより高度なグラフィカル、または階層のようなこれらの古いデータベースパラダイムから得たものは、数十年後にリレーショナルパラダイムを経て、今では再びほぼ階層に戻っているように感じます。 私たちが元に戻したようなものです。

Robin Bloor：はい、そうです。 エリックに手渡してください。私は時間を使いすぎていますが、聴衆から質問がありますか、エリック？

エリック・カバナ：いくつかあります。 ここでは少し長くなりますが、私はあなたにいくつか投げます。 目に見えないインデックスに関する質問がいくつかありました。 1つの質問は、「誰かがそれらを見るためにあなたのツールを使用する必要がありますか？」でした。もう1つの質問は、「まあ、もしあなたが盲目なら？」です。

Bert Scalzo：それはいいものです。

エリック・カバナ：好奇心が強い質問なので、参考までに。

Bert Scalzo：いいえ、私たちのツールは必要ありません。 これはOracleの機能であり、不可視のインデックスです。 基本的に、Oracleはデータディクショナリに、「オプティマイザー、このインデックスを無視します。 ここにありますが、SQLコマンドのオプティマイザーヒントのヒントを介して物理的に指示されない限り、これを使用しないでください。」そして、いや、私たちのツールは必要ありません。単純な古いインデックスであり、任意のツールで見ることができます。オプティマイザは「通常のクエリ処理では無視します」と言うだけです。使いたい場合は、指示する必要があります。 私が説明したシナリオでは、実稼働環境でインデックスを作成したいが、レポートや既に実行されているものを壊さないようにしたいが、テストしたい場合は、それを行うことができます。 それが最も有用なものです。

エリック・カバナ：それは良いことです。そして、ここに別の良い質問がありました。 「これらの新しいインメモリデータベースのいくつかはどうですか？ インメモリデータベーステクノロジーは、インデックス作成に関してゲームをどのように変えますか？」

Bert Scalzo：ええと 、私たち–いいですね、誰かがその質問をしてくれてうれしいです。もう30分は行かなければなりません。 いいえ、インメモリ、データベースベンダーによって異なります。 さて、通常、私は、オラクルが構築したテクノロジーが素晴らしいので、オラクルが行うことは何でも賞賛しますが、隠れて引き裂いて、インメモリがオラクルで、オラクルでデータベース、実際には、行ストアをディスク上に保持し、列ストアをメモリ内にロードします。テーブル全体を保持するのに十分なメモリがない場合、その部分に戻ります。 メモリに収まらず、行ストアを実行するため、テーブルに対して実際に選択を行うことができ、テーブルの半分については、テーブルの従来の行をヒットするインデックスを使用し、残りの半分については選択は実際に外に出て、メモリ内検索からすべてを取得するだけなので、たとえば、SQL ServerがHekatonテクノロジー、ご存知のようにSQL 2014で実装する方法が異なり、改善されていますSQL 2016では、いくつかの点で、それらはインメモリのより真のバージョンであり、各実装には長所と短所がありますが、カバーの下で見て、実現する必要があります。 というのは、「このテーブルはメモリ内です。すべてのインデックスを作成するだけです」と言った顧客がいて、「テーブルはサーバーにあるメモリよりも大きいので、ある時点で、クエリの一部がディスクにヒットします。」

Eric Kavanagh：それはいい説明です。 それは良いことです。 さて、皆さん、今年の残りの期間にこれらの人々とさらにいくつかのウェブキャストをする予定です。彼がプレゼンテーションをしていることを聞いたときはいつでも戻ってきます。 専門家と話すのはいつも楽しいです。 これらのウェブキャストはすべて、後で見るためにアーカイブします。 Bertの連絡先情報をもう一度ご紹介します。ダウンロード用のリンクを掘り下げてメールで送信しようとしますが、いつでも真にメールを送信できます：、このためにさらに多くのウェブキャストが用意されています今年、私たちは今すぐed calをやっているので、皆さん、来年本当に聞きたいトピックがあったら、恥ずかしがらないでください：皆さん、気をつけてください。 バイバイ。

Techopediaコンテンツパートナー

TechopediaスタッフはBloor Groupと提携しており、右側のオプションを使用して連絡できます。 業界パートナーとの連携方法については、ここをクリックしてください。

• プロフィール
• ウェブサイト