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

データベースにはかなりの量のデータがあります。整形式のテーブルと、データ間の冗長性を備えたテーブル間の良好な関係があります。しかし、正規化はどこまで行えばよいのでしょうか？正規化が多すぎるとパフォーマンス上の欠点がありますか？

30 performance  learning  normalization 

PostgreSQL 9.2には、約70個のテーブルを持つメインスキーマと、それぞれ30個のテーブルからなる可変構造のクライアントごとのスキーマを持つデータベースがあります。クライアントスキーマには、メインスキーマを参照する外部キーがあり、その逆はありません。 以前のバージョンから取得した実際のデータをデータベースに入力し始めたところです。メインスキーマの非常に中央のテーブルで一括削除を行う必要があったときに、DBは約1.5 GBに達しました（数週間で数十GBに達すると予想されています）。関係するすべての外部キーは、DELETE CASCADEでマークされます。 これに長い時間がかかることは驚きではありませんでしたが、12時間後には、最初からやり直してDBを削除し、移行を再開する方が良いことが明らかになりました。しかし、後でDBが稼働し、さらに大きくなったときにこの操作を繰り返す必要がある場合はどうなりますか？より高速な代替方法はありますか？ 中央テーブルから最も遠いテーブルから開始し、テーブルごとに依存する行を削除する依存テーブルを参照するスクリプトを書いたら、もっと速くなるでしょうか？ 重要な詳細は、いくつかのテーブルにトリガーがあることです。

30 postgresql  performance  delete  postgresql-9.2 

6列の最小値を取得したい状況です。 これを達成するためにこれまでに3つの方法を見つけましたが、これらの方法のパフォーマンスに懸念があり、どちらがパフォーマンスに優れているかを知りたいと思います。 最初の方法は、大きなcaseステートメントを使用することです。上記のリンクの例に基づいて、3列の例を次に示します。6つの列を見るので、私のcaseステートメントはもっと長くなります。 Select Id, Case When Col1 <= Col2 And Col1 <= Col3 Then Col1 When Col2 <= Col3 Then Col2 Else Col3 End As TheMin From MyTable 2番目のオプションはUNION、複数の選択ステートメントで演算子を使用することです。Idパラメーターを受け入れるUDFにこれを配置します。 select Id, dbo.GetMinimumFromMyTable(Id) from MyTable そして select min(col) from ( select col1 [col] from MyTable where Id = @id union …

29 sql-server  sql-server-2005  performance  aggregate 

今日私はロバート・マーティンについて聞いただけで、彼はソフトウェアの世界で有名な人物のようですので、タイトルがクリックの餌のように見えたり、口に言葉を入れているように見えるわけではありませんが、これは単に限られた経験と理解で彼から聞いたことをどのように解釈したか。 本日（ソフトウェアアーキテクチャ）、ロバートC.マーティンの講演でビデオを見ていました。ビデオの後半では、データベースのトピックが主な焦点でした。 彼の発言を理解したところ、SSDはデータベースの有用性を（かなり）低下させると言っていたようです。 この解釈に至った経緯を説明するには： 彼は、HDD /スピニングディスクでは、データの取得が遅い方法について説明しました。しかし、最近ではSSDを使用している、と彼は指摘しました。「RAM is coming」で始まり、RAMディスクについて言及し続けますが、RAMディスクと呼ぶことはできないと言うので、RAMと言うことに頼ります。したがって、RAMでは、すべてのバイトが取得するのに同じ時間がかかるため、インデックスは必要ありません。（この段落は私によって言い換えられています） だから、彼はDBの代わりにRAMを（コンピューターのメモリのように）提案することは（それは私が彼の声明を解釈したものだから）意味をなさない。オンデマンドでディスクファイルからプルしない限り） だから、私はRAMで考えることに頼った、彼はSSDを意味します。したがって、その場合、彼はSSDがデータベースの有用性を低下させると言っています。彼は「私がオラクルだったら怖いだろう。私が存在する理由の根底にあるのは蒸発する」とさえ言う。 SSDについての私のわずかな理解から、O(n)シーク時間であるHDDとは異なり（私は思う）、SSDは近くO(1)、またはほぼランダムです。だから、彼の提案は私にとって興味深いものでした。数年前に私が初めてデータベースを紹介されたとき、教授が通常のファイルシステムに対する利点を説明していたとき、私はデータベースの主な役割は本質的に非常にインデックス付けされたファイルシステムであると結論付けました（最適化、キャッシュ、同時アクセス、など）、したがって、SSDでインデックスが必要ない場合、この種のデータベースの有用性は低下します。 それにもかかわらず、私が初心者であることを前にすると、純粋なファイルシステムではなくDBをアプリケーションの主要なポイントとして誰もが使用し、彼が単純化しすぎていると感じたため、それらがあまり有用ではなくなると信じることは難しいデータベースの役割。 注：彼が何か違うことを言わないように最後まで見ました。 参考までに、42：22はデータベーストピック全体が表示されるとき、43： 52は 「なぜデータベースがあるのか​​」で始まるときです。 この答えは、SSDがDBを大幅に高速化すると言っています。 この質問は、最適化がどのように変更されるかについて尋ねます。 TL; DR私の質問は、サーバ市場で広くSSDの使用の出現は（それは今後のだか、すでに起こっているかどうか）のデータベースの有用性を減らすのですか？ プレゼンターが伝えようとしていたのは、SSDを使用すると、データをディスクに保存でき、SSDのように古いHDDのようにデータを取得するのに時間がかかることを心配する必要がないということでしたO(1)（おもう）。そのため、それが真実である場合、それはそれが持っていた利点の1つを仮定的に失うでしょう：インデックス付け、より速いシーク時間のためのインデックスを持つ利点がなくなったので。

28 database-design  performance  index  hardware  ssd 

次のような値とハッシュの表を考えてみましょう。 +------------+----------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +------------+----------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | val | char(9) | NO | | NULL | | | val_hashed | char(50) | YES | | NULL | …

28 mysql  performance  select 

テーブルパーティションの長所と短所の概念をつかむのが困難です。8つのテーブルを持つプロジェクトの作業を開始しようとしていますが、そのうちの1つは1億8千万から2億6千万件のレコードを保持するメインデータテーブルになります。適切にインデックスが付けられたテーブルになるので、9〜13個のテーブルを作成する必要があるこの方法で、テーブルレコードを2,000万に制限することを考えています。 しかし、同じマシン（32GB RAM）に座っているため、パフォーマンスがどのように改善されるかについてはよくわかりません。 私はMySQLを使用しており、テーブルはMyISAMであり、大きなテーブルにはidフィールドにインデックスがあり、フルテキスト検索などの複雑さはありません。 また、テーブルのパーティション分割とデータベースのパーティション分割についても明らかにしてください。

28 mysql  database-design  performance  partitioning  myisam 

TRACKING_NUMBER列にクラスター化インデックスが設定されたテーブルに行を挿入するSQLステートメントがあります。 例えば： INSERT INTO TABL_NAME (TRACKING_NUMBER, COLB, COLC) SELECT TRACKING_NUMBER, COL_B, COL_C FROM STAGING_TABLE 私の質問は-クラスター化インデックス列のSELECTステートメントでORDER BY句を使用するのに役立ちますか、またはORDER BY句に必要な追加の並べ替えによってゲインが無効になりますか？

28 sql-server  performance  insert  clustered-index 

パフォーマンス関連の質問があります。マイケルという名のユーザーがいるとしましょう。次のクエリを実行します。 UPDATE users SET first_name = 'Michael' WHERE users.id = 123 同じ値に更新されている場合でも、クエリは実際に更新を実行しますか？もしそうなら、どうすればそれを防ぐことができますか？

28 postgresql  performance  update  postgresql-performance 

ユーザーが現在遅いと感じるサイト（Moodle）を運営しています。私は、ディスク上に一時テーブルを作成するMySQLの問題を突き止めたと思います。created_tmp_disk_tablesMysql Workbenchサーバー管理で変数を見ると、その数は約50テーブル/秒で増加します。1日の使用後、created_tmp_disk_tables> 100kです。また、メモリは解放されていないようです。システムがほとんど使用できなくなり、MySQLを再起動するまで、使用量は増加し続けます。私はほぼ毎日それを再起動する必要があり、利用可能なメモリの約30〜35％を使用して開始し、80％で1日を終了します。 データベースにblobがなく、クエリを制御できないため、クエリを最適化することもできません。Percona Confirguration Wizardも使用しましたを使用して構成ファイルを生成しましたが、my.iniでも問題は解決しませんでした。 ご質問 MySQLがディスク上に一時テーブルを作成しないようにするには、何を変更すればよいですか？変更する必要がある設定はありますか？もっとメモリを投入する必要がありますか？ MySQLがメモリを使い果たすのを止めるにはどうすればよいですか？ 編集 slow_queriesログを有効にすると、クエリのSELECT GET_LOCK()ログが遅いことがわかりました。クイック検索の結果、PHP構成で永続的な接続が許可されていたことがわかりました（mysqli.allow_persistent = ON）。これをオフにしました。これにより、MySQLがメモリを消費する割合が減少しましたが、一時テーブルはまだ作成されています。 また、key_buffer sizeが十分に大きいことも確認しました。変数を見ましたkey_writes。これはゼロでなければなりません。そうでない場合、key_buffer_size.I have zero key_readsand zeroを増やすkey_writesので、key_buffer_sizeが十分に大きいます。 私は増加tmp_table_sizeし、max-heap-table-sizeテーブルがメモリに収まることができないことを示すことがありcreated_tmp_disk_tablesの増加として1024Mに。これで解決しませんでした。 参照：http : //www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-by-on-disk-temporary-tables/ 編集2 sort_merge_passesSHOW GLOBAL STATUS出力で1秒あたりの数が多い場合は、sort_buffer_size値を増やすことを検討できます。私はsort_merge_passes1時間で2つ持っていたので、sort_buffer_size十分に大きいと考えています。 参照：Mysqlマニュアル sort_buffer_size 編集3 @RolandoMySQLDBAの提案に従って、ソートバッファーと結合バッファーを変更しました。結果は下の表に表示されていますが、created_tmp_tables_on_diskまだ高いと思います。値を変更しcreated_tmp_tables_on_disk、1日（8時間）後にチェックして平均を計算した後、mysqlサーバーを再起動しました。他の提案はありますか？ある種のコンテナに収まらないものがあるように思えますが、それが何であるかを判断することはできません。 +---------------------+-------------+-------------+--------------------+ | Tmp_table_size, | Sort_buffer | Join_buffer | No of created | | max_heap_table_size | | | tmp_tables …

27 mysql  performance  windows  database-tuning  temporary-tables 

Perconaサーバー、MariaDB、および場合によっては他のいくつかのフォークに対して、MySQLサーバーrpmのパフォーマンステスト（別名、ベイクオフ）を行います。この質問をすることで、適切なパフォーマンステストのセットアップの背後にある方法論をよりよく理解できることを望んでいます。私は実際のテストを実行するためにsysbenchを使用する予定でしたが、何に対してもオープンです。 テストの結果を1対1で比較し、RDBMSのみがバリアントであることを確認するには、どのような手順を実行する必要がありますか？ どこから始めますか？ 結果を評価するにはどうすればよいですか？ どのようなアドバイスをいただけますか？

27 mysql  performance  performance-testing  mariadb  percona 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 PostgreSQL 9.0.8にはオブジェクトの大きなテーブル（1500万行以上）があり、そのために古いフィールドをクエリしたいと思います。 スケーラビリティと同時実行性を目的として、クエリを数百万で除算し、数日前の日付のupdated_atフィールドを使用してすべてのデータをフェッチしたい。 100万のIDで多くのインデックスとクエリを試しましたが、HerokuのRoninハードウェアで100秒未満のパフォーマンスを得ることができないようです。 これを可能な限り効率的にしようとしていない提案を探しています。 TRY＃1 EXPLAIN ANALYZE SELECT count(*) FROM objects WHERE (date(updated_at)) < (date(now())-7) AND id >= 5000001 AND id < 6000001; INDEX USED: (date(updated_at),id) 268578.934 ms TRY＃2 EXPLAIN ANALYZE SELECT count(*) FROM objects WHERE ((date(now()) - (date(updated_at)) > 7)) AND id >= …

27 postgresql  performance  index  partitioning  postgresql-performance 

私は毎日1つのテーブルで約36Kレコードを変更する必要があるプロジェクトを作成しています。私は何が良くなるのだろうかと思っています： 行を削除して新しい行を挿入する、または 既存の行を更新する 私にとっては、すべての行を削除して新しい行を挿入する方が簡単ですが、これがテーブルとインデックスを断片化し、パフォーマンスに影響を与える場合、可能な限り更新を行い、必要な場合にのみ削除/挿入することをお勧めします。 これは毎晩のサービスになりますが、プロセス自体の速度を改善するつもりはありません。私は、このテーブルに対するクエリのパフォーマンスについて、私が既に8,900万件のレコードを持っている場合と、この夜間のプロセスがどのように影響するかについてより懸念しています。 この夜間のプロセスのために、レコードを削除/挿入するか、既存のレコードを更新する必要がありますか（可能な場合）？

27 sql-server  sql-server-2005  performance  fragmentation  application-design 

同じデータを読み取りながら、非常に異なる論理読み取りを報告する3つの簡単なテストを次に示します。 セットアップ 次のスクリプトは、100個の同一行を持つテストテーブルを作成します。各行には、行外に格納されるのに十分なデータを含むxml列が含まれます。私のテストデータベースでは、生成されるxmlの長さは各行で20,204バイトです。 -- Conditional drop IF OBJECT_ID(N'dbo.XMLTest', N'U') IS NOT NULL DROP TABLE dbo.XMLTest; GO -- Create test table CREATE TABLE dbo.XMLTest ( ID integer IDENTITY PRIMARY KEY, X xml NULL ); GO -- Add 100 wide xml rows DECLARE @X xml; SET @X = ( SELECT TOP (100) …

26 sql-server  performance  blob  database-internals 

Microsoft SQL Server Profilerを時々実行すると、作成する新しいインデックスと統計情報がたくさんあります（「... 97％の改善が見込まれる...」）。 私の理解から、追加されたすべてのインデックスは、SQL SELECTクエリを高速化できますが、インデックスを調整する必要があるため、クエリも低速化UPDATEできINSERTます。 私が疑問に思うのは、いつ「多すぎる」インデックス/統計がありますか？ たぶんこれに関する明確な答えはありませんが、いくつかの経験則があります。

26 sql-server  performance  index  index-tuning 

これは私が定期的に出くわす問題であり、まだ良い解決策を見つけていません。 次のテーブル構造を想定 CREATE TABLE T ( A INT PRIMARY KEY, B CHAR(1000) NULL, C CHAR(1000) NULL ) 及び要件はNULL可能列のいずれかかどうかを決定することであるBまたはC実際に含むNULL値（及び場合どのように一方（S））。 また、テーブルに数百万行が含まれていると仮定します（このクラスのクエリのより一般的なソリューションに興味があるため、覗くことができる列統計はありません）。 これにアプローチする方法はいくつか考えられますが、すべてに弱点があります。 2つの別個のEXISTSステートメント。これには、a NULLが見つかるとすぐにクエリがスキャンを停止できるという利点があります。ただし、実際に両方の列にが含まれていないNULL場合、2回の完全スキャンが実行されます。 単一の集計クエリ SELECT MAX(CASE WHEN B IS NULL THEN 1 ELSE 0 END) AS B, MAX(CASE WHEN C IS NULL THEN 1 ELSE 0 END) AS C FROM T …

26 sql-server  performance