タグ付けされた質問 「indexing」

今日の私の同僚は、アプリケーションのすべてのクエリを調べ、それに応じてインデックスを追加することを提案しました。 私たちのアプリケーションはまだリリースされていないため、これは時期尚早な最適化だと思います。ライブになったら遅いクエリを監視し、それに応じてインデックスを追加することをお勧めします。 データベースを設計する際の一般的なコンセンサスは何ですか？新しいクエリを作成するたびに一致するインデックスを追加する必要がありますか？それとも、それがどのように進行するかを監視して確認する方が良いでしょうか？

61 database  database-design  indexing 

MySQLWorkbenchで、デザインをフォワードエンジニアリングする前にインデックスを保存する方法を選択できることに気付きました。ストレージタイプは次のとおりです。 BTREE RTREE ハッシュ これを調査して、頭上にある情報を見つけたので、これらの違いや、なぜ選択する必要があるのか​​、あるいはその両方に関する実用的な情報を探しています。 また、ストレージタイプを選択したことがないため、MySQLがデフォルトのストレージタイプ（BTREE？）を選択していると思います。

36 performance  mysql  indexing 

次の問題があります：200万件を超えるレコードを含むデータベースがあります。各レコードには文字列フィールドXがあり、フィールドXに特定の文字列が含まれるレコードのリストを表示します。各レコードのサイズは約500バイトです。 より具体的にするために、アプリケーションのGUIには、文字列を入力できるテキストフィールドがあります。テキストフィールドの上に、テキストフィールドの文字列に一致する（最初のN、たとえば100）レコードを表示するテーブルがあります。テキストフィールドに1文字入力または削除すると、テーブルの内容をその場で更新する必要があります。 適切なインデックス構造やキャッシュを使用してこれを行う効率的な方法があるのだろうか。上記で説明したように、クエリに一致する最初のN個のアイテムのみを表示します。したがって、Nが十分に小さい場合、データベースから一致するアイテムをロードすることは大きな問題ではありません。さらに、アイテムをメインメモリにキャッシュすると、検索が高速になります。 主な問題は、パターン文字列を指定して、一致するアイテムをすばやく見つける方法だと思います。DBMSの機能に依存することはできますか、それともインメモリインデックスを自分で構築する必要がありますか？何か案は？ 編集 私は最初の実験を実行しました。レコードを異なるテキストファイルに分割し（ファイルあたり最大200レコード）、ファイルを異なるディレクトリに配置しました（1つのデータフィールドの内容を使用してディレクトリツリーを決定しました）。最終的に、約40000個のディレクトリに約50000個のファイルが作成されます。次に、Luceneを実行してファイルのインデックスを作成しました。Luceneデモプログラムを使用した文字列の検索は非常に高速です。分割とインデックス作成には数分かかりました。これは、クエリしたい静的なデータセットであるため、私にはまったく受け入れられます。 次のステップでは、Luceneをメインプログラムに統合し、Luceneから返されたヒットを使用して、関連するレコードをメインメモリにロードします。

32 database  algorithms  data-structures  indexing 

複数のチャネルを持つデバイスのオブジェクトモデルを作成しています。クライアントと私の間で使用される名詞があるChannelとChannelSet。（「セット」は順序付けられており、適切なセットがそうではないため、意味的に正確ではありません。しかし、それは別の時代の問題です。） C＃を使用しています。以下に使用例を示しChannelSetます。 // load a 5-channel ChannelSet ChannelSet channels = ChannelSetFactory.FromFile("some_5_channel_set.json"); Console.Write(channels.Count); // -> 5 foreach (Channel channel in channels) { Console.Write(channel.Average); Console.Write(", "); } // -> 0.3, 0.3, 0.9, 0.1, 0.2 すべてがダンディです。 ただし、クライアントはプログラマーではないため、ゼロインデックスによって完全に混乱します。最初のチャネルはチャネル1です。しかし、C＃との一貫性を保つために、ChannelSetインデックスをゼロから維持したいと思います。 これにより、開発チームとクライアントが相互作用するときに、いくつかの切断が確実に発生します。しかし、さらに悪いことに、これがコードベース内でどのように処理されるかに矛盾があると、潜在的な問題になります。たとえば、次のUI画面では、エンドユーザー（1インデックス作成の観点から考える）がチャネル13を編集しています。 そのSaveボタンは、最終的にいくつかのコードになります。ChannelSetインデックスが1の場合： channels.GetChannel(13).SomeProperty = newValue; // notice: 13 または、インデックスがゼロの場合： channels.GetChannel(12).SomeProperty = newValue; // notice: 12 私はこれをどのように扱うか本当によくわかりません。私は、順序付けられた整数インデックス付きのもの（ChannelSet）を、C＃ユニバースの他のすべての配列およびリストインターフェイスと一貫性を保つこと（ゼロインデックス付けChannelSet）をお勧めします。しかし、その後、UIとバックエンドの間のすべてのコードには翻訳（1を引く）が必要になります。そして、誰もが陰湿で一般的なオフバイワンエラーが既にどの程度存在するかを知っています。 …

25 c#  object-oriented  indexing  setters 

適切な正規化を行った後でも、テーブルのインデックスを作成する必要がありますか？これはパフォーマンスにどのように影響しますか？適切に正規化した後、何らかの形でパフォーマンスに影響を与えますか？ 主キーと外部キーが既にある場合、通常どの列にインデックスが付けられますか？ データベースを正規化することはすでに効果的であるようです。しかし、索引付けがデータベースに与える影響をスキップしたかもしれません。これは、クエリを使用する場合にのみ有効ですか？これはどのように機能/実行し、データベースを改善しますか？

14 database  sql  indexing  normalization 

四分木を実装しています。このデータ構造を知らない人のために、次の小さな説明を含めます。 クワッドツリーはデータ構造であり、3次元空間でのオクトリーと同じようにユークリッド平面にあります。クワッドツリーの一般的な用途は、空間インデックスです。 それらがどのように機能するかを要約すると、クワッドツリーは、最大容量と初期バウンディングボックスを持つコレクションです（ここでは長方形としましょう）。最大容量に達したクワッドツリーに要素を挿入しようとすると、クワッドツリーは4つのクワッドツリーに分割されます（その幾何学的表現は、挿入前のツリーの4分の1の面積になります）。各要素は、その位置に応じてサブツリーに再配布されます。長方形を操作するときの左上の境界。 したがって、クワッドツリーはリーフであり、その容量よりも要素が少ないか、4つのクワッドツリーを子として持つツリー（通常、北西、北東、南西、南東）です。 私の懸念は、重複を追加しようとした場合、同じ要素が数回または同じ位置にあるいくつかの異なる要素である場合、四分木はエッジの処理に根本的な問題があることです。 たとえば、容量が1の四分木と、境界ボックスとして単位長方形を使用する場合： [(0,0),(0,1),(1,1),(1,0)] そして、左上の境界が原点である長方形を2回挿入しようとします（または、N> 1の容量を持つ四分木にN + 1回挿入しようとした場合も同様です）。 quadtree->insert(0.0, 0.0, 0.1, 0.1) quadtree->insert(0.0, 0.0, 0.1, 0.1) 最初の挿入は問題になりません： ただし、最初の挿入でサブディビジョンがトリガーされます（容量が1であるため）。 したがって、両方の長方形は同じサブツリーに配置されます。 次に、2つの要素が同じ四分木に到着し、サブディビジョンをトリガーします… 以下同様に、サブディビジョンメソッドは無期限に実行されます。なぜなら、（0、0）は、作成された4つのうち常に同じサブツリーにあるため、無限再帰問題が発生するためです。 重複した四分木を持つことは可能ですか？（そうでない場合、それをとして実装できますSet） 四分木のアーキテクチャを完全に壊すことなく、この問題をどのように解決できますか？

10 data-structures  trees  indexing 

最近、ドキュメントインデックスエンジンの制限にからかわれています。かなり堅牢な検索機能を必要とする小さなWebサイトを開発していましたが、ハードウェアの制約により、このニーズを処理するLucene風のソリューション（通常のSolrやElasticSearchなど）を展開できませんでした。 それでも、データベースを多用する複雑なデータや計算を提供する必要がありましたが、25万件を超える潜在的なレコードを処理する必要はありませんでした。これを処理するためだけにSolrまたはESインスタンス全体をデプロイすることは、無駄に思えました。 考えてみたらかなり大きな問題のようです。ほとんどの人は、SQLだけで検索要件を処理します。彼らはデータに対してSQLクエリを実行するだけです。彼らの検索機能もひどいものになります。 一部のシステム（特に共有ホスト）では、ブランケットフルテキストワイルドカード検索を行うと速度が大幅に低下し、特に複雑なクエリや多数の結合がある場合にデータベースがダウンする可能性があります。 ユーザーからの単一のリクエストに対して複数のクエリを実行することになります。ますます複雑なクエリでこれを回避できるかもしれませんが、前のポイントを参照してください。 フルテキストエンジンに通常存在する機能の欠如。 データベースにはサーバーとしてデプロイする必要があるという同じ問題があり、その後SQLiteが登場し、突然、単一のファイルに自己完結型のデータベースをデプロイできるようになりました。私のグーグルは何も生成していません-全文索引付け/検索のためにこのようなものが存在するかどうか疑問に思います。 軽量のドキュメントインデックスを実装するか（たとえば、別の質問への回答で説明されているように）、またはこれらの状況でSQLを使い続けるかを決定するときに考慮すべき要素は何ですか？

10 web-development  indexing 

これは私が長い間疑問に思っていた（そして尋ねられた）質問です。 （ほとんど？すべて？）プログラミング言語では、配列、文​​字列などのインデックスはゼロから始まります。多くの言語で採用され、時間が経つにつれて慣例になったことを認識していますが、だれでもこの起源を指摘できますか？ おそらく、それはすべてバイナリに根ざしていることに関係しているのではないかと思いました。しかし、私は10進法での必要性を引き継ぐという考えがわかりません-なぜインデックスを1から始めないのですか？ ゼロからインデックスを開始する決定が説明されている可能性があるプログラミング言語の歴史的な知識を持っている人はいますか？ ありがとうございました！ 編集：ダイクストラの文章は、数学的な観点からさらに役立ちますが、すべての言語がゼロインデックス化されているわけではないことを彼は指摘しました。WBTの説明は、なぜメモリアドレスに基づいてゼロから始めるのかについても理にかなっています。（一部の言語は、配列操作に基づいてわずかに異なるインデックス付けを処理することを知っています。） 私は必ずしも理由を探る必要はありません（理解を深めるのに役立つので非常に感謝しています）が、いつこれが規則になったのか、および/または特定の言語にたどり着くことができるかどうかという線に沿って探します。 したがって、たとえば、K＆RのCでは、配列のインデックスについて説明するとき、KまたはRは「配列の添え字は常にCでゼロから始まる...」（p。22）と説明し、後で文字を処理する関数について説明します。配列、「...より有用な設計は、行の長さ、またはファイルの終わりが検出された場合はゼロを返すことです。ゼロは、有効な行の長さになることはないため、許容できるファイルの終わりを返します。」（p.127） K＆Rに基づいて、私は次のように収集します。a）規則は他の場所から採用されているため、Cはゼロインデックスの背後にあるインスピレーションではありません。b）2番目の例に基づいて使用する理由はもっと深い可能性があります。私はK＆Rがその明確な散文で非常に広く評価されていることを知っています。それが、これを含めるもう1つの理由です。別の文書化された言語がゼロインデックスの背後にある理由を説明するために私が期待したことの例を示すためです。 私はWBTとbtillyの両方が同等に良い理由を提供していると思います。設計の決定を文書化した古い（Cより前の）言語を知っている人はいるかもしれません。同時に、そのような情報が存在しない可能性があることも認識しています。

8 programming-languages  history  array  indexing 

私が持っているPBFファイル国に関する以下の情報が含まれています。 それぞれ独自の経度、緯度、プロパティを持つノード。2Dスペースにポイントを格納するために使用されます。 それぞれのプロパティを持つ方法は、ノードを介して接続されます。道路、境界を保存するために使用されます。 このファイルの圧縮形式は80 MBですが、圧縮解除してDBに保存すると、592 MBになります。 ええ、それはベルギーだけの国のためのものです。フランス、ドイツ、イタリアを一緒に保管することを想像してください。 たとえば、アントワープからブリュッセルを通ってシャルルロワまでの単一の高速道路を見てみましょう。これは、高速道路のすべてのターンを格納するための大量のノードで構成されますが、これらすべてのターンが必要ですか？疑わしい。 私が何ができるようになりたいのか教えてみましょう： さまざまなズームレベルで地図を表示したい。少なくとも大都市、小都市、街路レベル。 2点間のルーティング情報を取得できるようにしたい。 GPS位置に最も近い道路を計算できるようにしたい。 データベース内のインデックスを使用して、場所を検索します。 ただし、最も重要なのは、データベースがモバイルデバイスに保存されるため、データベースが大きくなりすぎないことです。 そこで、2つの手法の組み合わせについて考えました。 すべての個々のノードの保存/処理を回避するための、表示目的の画像タイル。 道路に関する情報とともに、ルート情報の道路の端点を保存します。 この問題は、この情報だけではGPS位置に最も近い道路を計算できないことです。高速道路の曲がりを想像すると、2つの端点だけで高速道路にいると判断できません。エンドポイント間で中間ノードを保存することを考えていましたが、生成には非常にコストがかかると思います。また、道路の端点（Tスプリットのようなもの）を決定することは、T字型スプリットの上部に中点を保存する必要があるかどうかを理解する必要があるため、それほど簡単なことではありません。 したがって、画像タイルを使用すると表示が簡単です。しかし、ルーティングとGPS位置検索を行う簡単な方法を見つけることができません。どのようなストレージテクニックを検討する必要がありますか？80 MBファイルがのデータベースに変わるのは少し不便592 MBですが、そのサイズをできるだけ小さくしたいと思います... これをできるだけ効率的に行うにはどうすればよいですか？ディスクとCPUに関して。WP7をターゲットにしています...

8 algorithms  database-design  storage  map  indexing