データベース管理者

データベースのスキルを向上させ、コミュニティの他の人から学びたいデータベースの専門家向けのQ&A

4
SSDはデータベースの有用性を低下させますか
今日私はロバート・マーティンについて聞いただけで、彼はソフトウェアの世界で有名な人物のようですので、タイトルがクリックの餌のように見えたり、口に言葉を入れているように見えるわけではありませんが、これは単に限られた経験と理解で彼から聞いたことをどのように解釈したか。 本日(ソフトウェアアーキテクチャ)、ロバート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つを仮定的に失うでしょう:インデックス付け、より速いシーク時間のためのインデックスを持つ利点がなくなったので。

1
クラスター化された列ストアからのこの削除には、熱心なスプール演算子が役立ちますか?
クラスター化された列ストアインデックスからのデータの削除をテストしています。 実行計画に大きな熱心なスプールオペレーターがいることに気付きました。 これは、次の特性で完了します。 6,000万行が削除されました 1.9 GiB TempDBを使用 実行時間14分 シリアルプラン 1スプールで再バインド スキャンの推定コスト:364.821 見積もりツールをだまして過小評価するようにすると、TempDBの使用を回避するより高速なプランが得られます。 推定スキャンコスト:56.901 (これは推定プランですが、コメントの数値は正しいものです。) 興味深いことに、次を実行してデルタストアをフラッシュすると、スプールは再び消えます。 ALTER INDEX IX_Clustered ON Fact.RecordedMetricsDetail REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON); スプールは、デルタストアにページのしきい値を超えるしきい値がある場合にのみ導入されるようです。 デルタストアのサイズを確認するには、次のクエリを実行して、テーブルの行内ページを確認します。 SELECT SUM([in_row_used_page_count]) AS in_row_used_pages, SUM(in_row_data_page_count) AS in_row_data_pages FROM sys.[dm_db_partition_stats] as pstats JOIN sys.partitions AS p ON pstats.partition_id = p.partition_id WHERE p.[object_id] = OBJECT_ID('Fact.RecordedMetricsDetail'); …

3
使用しているメモリが多すぎるMongoDB
MongoDBを数週間使用していますが、全体的な傾向として、mongodbのメモリ使用量が大きすぎる(データセット+インデックスのサイズ全体よりもはるかに大きい)ことがわかりました。 私はすでにこの質問とこの質問を読んでいますが、私が直面している問題に対処しているものはないようです。実際にドキュメントで説明されていることを説明しています 以下は、htopおよびshow dbsコマンドの結果です。 mongodbはメモリマップドIOを使用することを知っているので、基本的にOSはメモリ内のキャッシュを処理し、理論的には別のプロセスが空きメモリを要求したときに mongodb がキャッシュされたメモリを解放する必要がありますが、私たちが見たところ、そうではありません。 OOMは、他の重要なプロセス(postgres、redisなど)を殺す開始を開始します(この問題を克服するために、RAMを183GBに増やしましたが、現在は動作しますがかなり高価です。mongoは〜87GBのRAMを使用しています。データセット全体のサイズのほぼ4倍) そう、 これだけのメモリ使用量が本当に予想され、正常ですか?(ドキュメントによると、WiredTigerはキャッシュに最大で60%のRAMを使用しますが、データセットのサイズを考慮すると、86GBのRAMを使用するのに十分なデータさえありますか?) メモリ使用量が予想される場合でも、別のプロセスがより多くのメモリを要求し始めた場合、mongoが割り当てられたメモリを手放さないのはなぜですか?RAMを増やしてシステムを完全に不安定にする前に、mongodb自体を含め、他のさまざまな実行中のプロセスがLinux oomによって絶えず殺されていました。 ありがとう!

2
集計にインデックス付きビューを使用する-あまりにも良いですか?
かなり大きなレコード数(1000万から2000万行)のデータウェアハウスがあり、特定の日付の間にレコードを数えるクエリや、特定のフラグを持つレコードを数えるクエリを実行することがよくあります。 SELECT f.IsFoo, COUNT(*) AS WidgetCount FROM Widgets AS w JOIN Flags AS f ON f.FlagId = w.FlagId WHERE w.Date >= @startDate GROUP BY f.IsFoo パフォーマンスはそれほど悪くありませんが、比較的遅くなる可能性があります(コールドキャッシュで10秒程度)。 最近、私GROUP BYはインデックス付きビューで使用できることを発見し、次のようなものを試しました CREATE VIEW TestView WITH SCHEMABINDING AS SELECT Date, FlagId, COUNT_BIG(*) AS WidgetCount FROM Widgets GROUP BY Date, FlagId; GO CREATE UNIQUE CLUSTERED …

1
sys.stats_columnsは間違っていますか?
Foo列ID1, ID2と複合主キーが定義されたテーブルがあるとしますID2, ID1。(私は現在、この方法で定義された複数のテーブルを持つSystem Center製品を使用しています。プライマリキー列は、テーブル定義に表示されるのとは逆の順序でリストされています。) CREATE TABLE dbo.Foo( ID1 int NOT NULL, ID2 int NOT NULL, CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED (ID2, ID1) ); GO -- Add a row and update stats so that histogram isn't empty INSERT INTO Foo (ID1, ID2) VALUES (1,2); UPDATE STATISTICS dbo.Foo; のkey_ordinal列はsys.index_columns、複合主キーで宣言されたのと同じ順序でインデックス列を示します。 SELECT t.name, i.name, …

2
ブロックされたプロセスレポートの空のブロックプロセス
拡張イベントを使用してブロックされたプロセスのレポートを収集していますが、何らかの理由で一部のレポートでblocking-processノードが空です。これは完全なxmlです。 <blocked-process-report monitorLoop="383674"> <blocked-process> <process id="processa7bd5b868" taskpriority="0" logused="106108620" waitresource="KEY: 6:72057613454278656 (8a2f7bc2cd41)" waittime="25343" ownerId="1051989016" transactionname="user_transaction" lasttranstarted="2017-03-20T09:30:38.657" XDES="0x21f382d9c8" lockMode="X" schedulerid="7" kpid="15316" status="suspended" spid="252" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2017-03-20T09:39:15.853" lastbatchcompleted="2017-03-20T09:39:15.850" lastattention="1900-01-01T00:00:00.850" clientapp="Microsoft Dynamics AX" hostname="***" hostpid="1348" loginname="***" isolationlevel="read committed (2)" xactid="1051989016" currentdb="6" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> <executionStack> <frame line="1" stmtstart="40" sqlhandle="0x02000000f7def225b0edaecd8744b453ce09bdcff9b291f50000000000000000000000000000000000000000" /> <frame line="1" …

2
SELECT *がSELECT fooよりもはるかに高速なのはなぜですか?
次のような値とハッシュの表を考えてみましょう。 +------------+----------+------+-----+---------+----------------+ | 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 | …

4
PostgreSQLで2つのテーブルに同じコンテンツがあるかどうかを確認する
これはすでにStack Overflowで要求されていますが、MySQLのみです。PostgreSQLを使用しています。残念ながら(そして驚くべきことに)PostgreSQLにはのようなものはないようですCHECKSUM table。 PostgreSQLのソリューションは問題ありませんが、一般的なソリューションの方が優れています。http://www.besttechtools.com/articles/article/sql-query-to-check-two-tables-have-identical-dataを見つけましたが、使用されているロジックがわかりません。 背景:データベースを生成するコードを書き直したので、古いコードと新しいコードが同じ結果を生成するかどうかを確認する必要があります。

3
MySQL 5.6からデフォルトでquery_cache_typeが無効になっているのはなぜですか?
MySQL 5.6にアップグレードし、dbサーバーのロードが大幅に増加query_cache_typeするのを確認し始め、最終的には5.6からデフォルトでオフになっていることがわかりました 。 再度有効にし、読み込みが減少するのを確認します。なぜ、MySQL 5.6からデフォルトでこの値が無効になっているのですか?有効にすると問題が表示されません。

3
列に複数のレコードの同じデータが含まれる行を選択する
という列があるテーブルがありますarticle_title。テーブル名がであるとしましょうarticles。article_titleデータが複数のレコードで同じであるレコードを見つける必要があります。 ここに私が持っているものがあります: select a.* from articles a where a.article_title = (select article_title from articles where article_title = a.article_title AND a.id <> articles.id)

2
CREATE INDEXとALTER TABLE ADD INDEX-MySQLism、またはSQL Standard?
奇妙な問題に出くわしました。これにより、インデックスの作成方法によっては、インデックス名が必要になります。 http://dev.mysql.com/doc/refman/5.5/en/create-index.html http://dev.mysql.com/doc/refman/5.5/en/alter-table.html CREATE INDEX `random_name` ON `my_table` (`my_column`); # Requires an index name ALTER TABLE `my_table` ADD INDEX (`my_column`); # Does not require an index name CREATE INDEX呼び出しでは、インデックス名が必要にならないように思われます。これがMySQLismなのかSQL標準なのか疑問に思っていますか?

2
範囲タイプの正確な等価性に起因する不適切なクエリプランの処理方法
tstzrange変数の正確な等価性が必要な更新を実行しています。〜1M行が変更され、クエリには〜13分かかります。の結果はここでEXPLAIN ANALYZE見ることができ、実際の結果はクエリプランナーが推定した結果とは大きく異なります。問題は、インデックススキャンで単一の行が返されることを期待していることです。t_range これは、範囲タイプの統計が他のタイプの統計とは異なる方法で保存されるという事実に関連しているようです。pg_stats列のビューを見ると、n_distinctis -1であり、他のフィールド(most_common_valsなどmost_common_freqs)は空です。 ただし、t_rangeどこかに統計が保存されている必要があります。完全に同等ではなくt_rangeで「within」を使用する非常に類似した更新の実行には約4分かかり、実質的に異なるクエリプランを使用します(こちらを参照)。一時テーブルのすべての行と履歴テーブルのかなりの部分が使用されるため、2番目のクエリプランは理にかなっています。さらに重要なことは、クエリプランナーがのフィルタに対してほぼ正しい行数を予測することt_rangeです。 の分布t_rangeは少し珍しいです。このテーブルを使用して別のテーブルの履歴状態を保存していますが、他のテーブルへの変更は大きなダンプで一度に発生するため、の値はあまり多くありませんt_range。の一意の値のそれぞれに対応するカウントはt_range次のとおりです。 t_range | count -------------------------------------------------------------------+--------- ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00") | 994676 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") | 36791 ["2014-06-27 07:00:00+00","2014-08-01 07:00:01+00") | 1000403 ["2014-06-27 07:00:00+00",infinity) | 36791 ["2014-08-01 07:00:01+00",infinity) | 999753 t_range上記のdistinctのカウントは完了しているため、カーディナリティは〜3Mです(このうち〜1Mは、いずれかの更新クエリの影響を受けます)。 クエリ1のパフォーマンスがクエリ2よりもはるかに低いのはなぜですか?私の場合、クエリ2が適切な代替品ですが、正確な範囲の均等性が本当に必要な場合、Postgresでよりスマートなクエリプランを使用するにはどうすればよいですか? インデックス付きのテーブル定義(無関係な列の削除): Column | Type | Modifiers ---------------------+-----------+------------------------------------------------------------------------------ history_id | integer | not null default nextval('gtfs_stop_times_history_history_id_seq'::regclass) …

1
すべての列レコードを小文字に変換します
PostgreSQL 9.1を使用していますが、ユーザーテーブルにlogin列があります。 ログイン名は大文字と小文字が区別されます。たとえば、Bob、MikE、johnです。これらすべてのレコードを小文字に変換したいと思います。どうやってやるの?

2
UNPIVOTを使用する場合、SQL Serverでデータ型の長さが同じである必要があるのはなぜですか?
UNPIVOT正規化されていないデータに関数を適用する場合、SQL Serverではデータ型と長さが同じである必要があります。データ型が同じでなければならない理由を理解していますが、なぜUNPIVOTは同じ長さを必要とするのですか? ピボットを解除する必要がある次のサンプルデータがあるとします。 CREATE TABLE People ( PersonId int, Firstname varchar(50), Lastname varchar(25) ) INSERT INTO People VALUES (1, 'Jim', 'Smith'); INSERT INTO People VALUES (2, 'Jane', 'Jones'); INSERT INTO People VALUES (3, 'Bob', 'Unicorn'); 次のような列FirstnameとLastname列をアンピボットしようとすると: select PersonId, ColumnName, Value from People unpivot ( Value FOR ColumnName in (FirstName, LastName) …

8
空のテーブルのデータベースを照会する方法
一部の「開発者」のために、システムで作業していたため、空のテーブルに問題がありました。クラウドへの転送中にいくつかのテーブルがコピーされましたが、それらのテーブルのデータはコピーされていませんでした。 空のユーザーテーブルを見つけるために、システムテーブルに対してクエリを実行したいと思います。MS SQL 2008 R2を使用しています。 助けてくれてありがとう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.