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

ですから、私のdb設計を完​​全に制御することはできません。そのため、このシナリオの目的のために現在のシステムの多くの側面を変更することはできません。 デザインの側面をどのように再考すべきかについてのコメントはおそらく正しいが、役に立たない:) 私は非常に大きなテーブルがあり、幅が約150フィールド、行が約600mあり、多数のプロセスを駆動します。これはデータウェアハウスの状況にあるため、スケジュールされたロードプロセス以外では更新/挿入が行われないため、インデックスが大量に作成されます。 このテーブルをパーティション分割しようとする決定が下されており、パーティション分割されたテーブルのインデックス作成に関して懸念があります。私はパーティション分割の経験がないので、入力やリンクを歓迎します。私はBOLまたはmsdnで私が特に望んでいるものを見つけることができませんでした。 現在IncidentKey、varchar(50)一意であるとは呼ばないフィールドにクラスターを作成します。1〜100個の同じレコードを持つことができますIK（コメントは不要です）。古いIncidentKeyレコードで新しいデータを取得することが多いため、どちらもシーケンシャルではありません。 IncidentDateパーティションが正しく機能するためには、パーティション化フィールドをクラスター化インデックスキーに含める必要があることを理解しています。そうなると思っていますIncidentKey, IncidentDate。 問題は、「新しい」パーティションのレコードがクラスター化インデックスの「古い」パーティションのレコードの前にある場合、クラスター化インデックスの仕組みはパーティションテーブルの2パートキーでどのように機能するかです。 たとえば、5つのレコードがあります。 IncidentKey Date ABC123 1/1/2010 ABC123 7/1/2010 ABC123 1/1/2011 XYZ999 1/1/2010 XYZ999 7/1/2010 新しいレコードを取得する場合ABC123, 2/1/2011は、クラスター化インデックスのBEFORE にある必要がありXYZ999, 1/1/2010ます。これはどのように作動しますか？ 断片化とポインターを想定していますが、デュアルパートキーを持つパーティションテーブルの非パーティションクラスター化インデックスの物理ストレージと構成に関する情報が見つかりません。

16 sql-server  index  sql-server-2008-r2  partitioning 

システムビューにsys.partitionsは、特定のパーティション内の行の総数である「行」列があります。パーティション化されていない（または見方によってはパーティションが1つしかない）テーブルの場合、この列はテーブル内の行数を示します。 私はこの列がどれほど正確か、そしての代わりにそれを使用できるかどうかに興味がありSELECT COUNT(1) FROM TableNameます。テーブルを作成して数千行を追加し、数百を削除し、さらに数千を追加するなど、いくつかの実験を行いましたが、カウントは常に無効になっています。ただし、約700ミリ行と複数のインデックスを持つ1つのテーブルがあります。sys.partitionsクラスター化インデックスの行は再び無効になりますが、他のインデックスにはわずかな変動（+ -20k）が見られます。 この行がどのように計算され、表示されるのと同じくらい正確かどうかは誰にもわかりますか？

13 sql-server  sql-server-2008-r2  sql-server-2012  partitioning  count 

シナリオ： 2つのデータベース：DB_AとDB_Archive、tableAと呼ばれる非常に大きなテーブル1つ。 過去2か月のレコードに対してtableAがDB_Aで頻繁にクエリされるため、60日を超えるレコードは毎日DB_Aから削除され、主にDB_Archiveに移動されて「分離」されます。 このプロセスは時間がかかり、多くのリソースを消費するため、このプロセスを削除します。日付列のパーティション関数を使用してDB_Aにテーブルパーティションを実装し、1つのパーティションに2か月未満のすべてのレコードと別のパーティションに2か月以上のすべてのレコードを格納することを考えています。私の質問： このシナリオは、2つの異なるデータベースがある場合のように動作しますか？tableAにレコードを照会する> getdate（）-30、アーカイブパーティションを読み取りますか？ インデックスもパーティション化する必要があると思いましたか？ 明日パーティション関数が「変更」されるという事実にどう対処しますか、つまり、今日関数を作成した場合（7月2日、その範囲は5月2日ですが、明日は5月3日です）。動的パーティション関数を作成できますか？

13 sql-server  sql-server-2005  partitioning 

私は、2億4000万行の非常に頻繁に更新されるテーブルを持っています（そして成長しています）。3時間ごとに150万行が挿入され、150万行が削除されます。クラスターをSSDに移動すると、この一括挿入（コピーを使用）時間は22分から2.3分に短縮されました。削除時間も改善されました。この一括更新は2時間ごとまたは1時間ごとに行う予定です。 現在のパフォーマンス（SSD後）は、より頻繁な更新と互換性がありますが、書き込みの増幅と組み合わされたNANDの耐久性の限界によるSSDの死に関するいくつかの恐ろしい話を読みました。SSDは高価なので、可能な限り将来的にその死を押し上げたいと思います。したがって、私の質問：削除とその後のバキュームでディスクファイルは実際にどうなりますか？私は2つのディスク書き込みがあると思います。1つは行を削除済みとしてマークし、もう1つはバキュームして上書き可能としてマークします。削除とバキュームを行う代わりに、一括挿入/削除のたびにテーブルを作成および削除するテーブルをパーティション分割すると、SSDの摩耗を最小限に抑えることができますか？

13 postgresql  partitioning  delete  storage  vacuum 

次の場合 -- table ddl create table dbo.f_word( sentence_id int NULL, sentence_word_id int NULL, word_id int NULL, lemma_id int NULL, source_id int NULL, part_of_speech_id int NULL, person_id int NULL, gender_id int NULL, number_id int NULL, tense_id int NULL, voice_id int NULL, mood_id int NULL, case_id int NULL, degree_id int NULL, citation …

12 sql-server  partitioning  sql-server-2014 

バージョン：SQL Server 2008 R2 Enterprise Edtn。（10.50.4000） パーティション戦略を評価するために、このクエリを作成して、パーティションのインデックスに対するアクセス方法を取得しました（用語の最も広い意味では、ヒープを削除しています）。私は、パーティション表への私の焦点を絞るように、私は私が見てする必要があると考えているrange_scan_countとsingleton_lookup_countしたが、ハードディスクの時間概念化が生じています。 SELECT t.name AS table_name, i.name AS index_name, ios.partition_number, leaf_insert_count, leaf_delete_count, leaf_update_count, leaf_ghost_count, range_scan_count, singleton_lookup_count, page_latch_wait_count , page_latch_wait_in_ms, row_lock_count , page_lock_count, row_lock_wait_in_ms , page_lock_wait_in_ms, page_io_latch_wait_count , page_io_latch_wait_in_ms FROM sys.dm_db_partition_stats ps JOIN sys.tables t ON ps.object_id = t.object_id JOIN sys.schemas s ON t.schema_id = s.schema_id …

12 sql-server-2008-r2  partitioning 

大量の気象モデルデータをPostgreSQLデータベースに入れています。マシンには8つのコアと16 GBのRAMが搭載されています。PostGIS 2.1でPostgreSQL 9.3を実行しています。各テーブルには、さまざまな気象データ（気温、露点、風など）があります。各テーブルには6〜7列があります。緯度、経度、ポイントジオメトリ、標高、モデルが関連する日時、および対象となる1〜2のデータ値です。データは主に、時間と高度によって境界ボックスを照会されます。テーブルあたり約145,757,360行になります（現在より古いデータはもはや関係がなくなり、削除されます）。テーブルのサイズは、おおよそ、インデックスなしで約10 GBと推定されます。（これは、52バイトのデータと1行あたり23バイトのオーバーヘッドです）。新しいモデルデータが利用可能になると、データは定期的に更新/挿入されます。注意： だから私はこれらの2つの計画を見ています： ポイントジオメトリの追加のインデックスを使用して、（日時、標高）でインデックスを付けてクラスタ化するだけです。古い行を削除し、vacuum / analyzeを実行し、再クラスター化する通常のcronジョブを実行します。 日時でパーティション化し、ジオメトリのインデックスを持つテーブルごとに標高でクラスタ化してインデックス化します。通常のcronジョブを実行して、新しいテーブルを追加し、古いテーブルを削除します。 さらに、 したがって、テーブルを削除する方がはるかに効率的で、削除およびバキューム処理を行うことを知っています。しかし、それ以外の場合はパフォーマンスが向上しますか？ パーティションは、すべてのテーブルが均等に更新されて削除されるまで適切ではない場合に適切ですか（ドキュメントでは、一部のテーブルのみを選択した場合にパーティションが最適に機能することが示されています）？ データを配信する場合、選択はクラスター化インデックスよりも高速になりますか？複数のリクエストが一度に行われる場合、答えは変わりますか？ ありがとうございました。必要なデータをすべて入れてほしい。知らない場合はお知らせください。追加します。

12 postgresql  database-design  partitioning  postgis  postgresql-9.3 

はい、私はデータの正規化が（現状のまま）私の優先事項であることを認識しています。 私は列の車両データを格納する65個の列を持つテーブルを持っている：used_vehicle、color、doors、mileage、priceなど、合計65インチ 今、私はそれを分割して持つことができるVehicleテーブル、VehicleInterior、VehicleExterior、VehicleTechnical、VehicleExtra（すべての一対一のメインとVehicleテーブル）。 約500万行（車両）があるとします。 上SELECTでのWHERE句：パフォーマンスが（どちらの場合は、上の少なくともインデックスを付けて検索するほうが良いでしょうIDs）： Vehicle 65列のテーブルまたは VehicleテーブルJOINSに関連するすべてのデータを返すために、他の4つのテーブル（すべてで5万行）にVehicle？ （データベースエンジンごとに、PostgreSQLやMySQLを検討してください）。 以前の経験から得られた詳細な洞察を本当に感謝しますか？

12 postgresql  database-design  performance  partitioning  postgresql-performance 

次のような分割テーブル構造があります。 CREATE TABLE measurements ( sensor_id bigint, tx timestamp, measurement int ); CREATE TABLE measurements_201201( CHECK (tx >= '2012-01-01 00:00:00'::timestamp without time zone AND tx < ('2012-01-01 00:00:00'::timestamp without time zone + '1 mon'::interval)) )INHERITS (measurements); CREATE INDEX ON measurements_201201(sensor_id); CREATE INDEX ON measurements_201201(tx); CREATE INDEX ON measurements_201201(sensor_id, tx); .... …

11 postgresql  partitioning  query-performance  postgresql-9.6 

いつデータベースを分割したくないですか？（MySQLパーティショニングを考える） 私の場合 私は数百万行から始めます。そこから成長するはずです。 最も頻繁なクエリ制約として機能する文字フィールドの主キー（および検索が頻繁に-少なくとも1秒に数回）。 主キーは、パーティションキーとして機能するようにハッシュされます 上記の頻繁なクエリでプルされるすべての行が更新されます （日付列などに対する）頻度の低い検索では、すべてのパーティションをヒットする必要があります 最後の点でさえ、ルックアップは並行して実行されないので、すべての場合において、これは勝利ですか？パーティショニングの欠点は何ですか？少なくとも、100万件以上のレコードを表示しているときに、誰もがデフォルトで使用するものではないのですか？ 更新-私はzgguyの回答を選択しましたが、私にとって非常に有用な同様の質問に対する本当に良い回答へのリンクを含む自分の調査の結果に自分の回答を追加したことに注意してください。

10 mysql  database-design  partitioning 

データベースに非常に大きなテーブルがいくつかありますが、このデータのかなりの部分が「古い」ものです。 私の制御が及ばない状況のため、この「古い」データを削除することは許可されていません。その他の制限は、データベースを変更できないことです。つまり、データベースにファイルグループを追加できます。現在の状態では、すべてがPRIMARYファイルグループに存在しています。 これらのテーブルを「新しい」、「古い」、「アーカイブ」などのいくつかのパーティションに分割することを考えていました。この目的で使用したい「ステータス」列があります。 説明されているシナリオと制限を考えると、パーティション分割がここで意味をなすかどうか疑問に思っていました。つまり、テーブルがこのようにパーティション化されているが、すべてのパーティションが同じファイルグループにある場合、SQL Serverは、「新しい」データが存在する基になるファイル内の特別な領域を見つけるのに十分スマートであり、 「古い」データのあるエリア？ 言い換えると、私のデータの80％が「古い」としましょう。SQL Serverには、基になるファイルの100％へのアクセスを回避し、「新しい」データを含む20％のみにアクセスするメカニズムがありますか（もちろん、WHEREクエリの句でパーティション列を指定するとします）。 私はこれに答えると思います、パーティションが内部でどのように実装されているかを理解する必要があります。私はどんなポインタにも感謝します。

10 sql-server  partitioning  filegroups 

効率的に分割したい大きなテーブル（数億行）があります。私の質問は、パーティションサイズとパーティション数の間にトレードオフがあるかどうかです。私が理解している限り、クエリは（ほとんどのクエリに対して）クエリに適用可能なパーティション内のみを検索する必要があるため、パーティションで使用される列に対するほとんどのクエリはより高速になります。したがって、効率を最大化するには、大きなテーブルを最大数のパーティションに分割する必要があるので、各パーティションをできるだけ小さくする必要があります。MySQLの場合、これは1024パーティションを意味します。しかし、多数のパーティションを持つことにはパフォーマンス上の欠点がありますか？そうであれば、どのようにして最適なパーティション数を見つけるのでしょうか？ 注：stackoverflowについては多少似た質問がすでにありますが、（私の観点から）マークを逃す答えは1つだけです。だから私は私自身の方法で質問を述べます...うまくいけばそれはより明確です

10 mysql  performance  partitioning 

SQL Serverでのパーティション分割は初めてです。BrentOzarのガイドから学びました。 数回、奇妙なシナリオに遭遇しました。私が走るとき： SELECT * FROM ph.FileGroupDetail ORDER BY partition_number Go 2つの異なるpartition_numbersで2回表示されている同じファイルグループがあり、1つは範囲値で最後に正しく、もう1つはnullのrange_valueで最初にあります。 画像を拡大するにはここをクリック いくつかの質問： これはどのように起こっていますか？どこで間違っていますか？ どうすれば問題を解決できますか？つまり、最初に空のパーティションが既にあるので、それを最初に取り除く方法です。 ファイル（空の場合は機能していました）とファイルグループを削除しようとしましたが、ファイルグループは削除できないと述べました。 誰かがこれがどのように起こったのか、そしてパーティション2のエントリを取り除く方法を説明してくれませんか？

10 sql-server  sql-server-2008-r2  partitioning 

私はSQL Serverのパーティション分割を扱ったことがありませんが、現在、ボリュームがおそらくそれを保証するデータベースの設計に直面しています。システムはクーポン用です。クーポンは定期的に発行され、通常は6週間ごとに発行されますが、特別イベントなどの臨時の発行も行われます。1,500万人の顧客がおり、各発行イベントに対して、すべての顧客が6種類の異なるクーポンタイプを受け取り、合計9000万のクーポンインスタンスを提供します。通常、クーポンの有効期間は6週間ですが、クーポンインスタンスの償還データを追跡して6か月間維持する必要があります。無効なクーポンの引き換えリクエストは、POSによって検証されるため、データベースに到達しません。 6か月間で、クーポンインスタンステーブルには最大3億6,000万行、リデンプションテーブルには最大7,200万行（最大20％の償還率を想定）を格納する必要があります。これらの数値は単一のパーティションには大きすぎると感じますか？ 私の質問は-パーティションキーとして何を使うのですか？明らかな候補の1つは、発行イベントによるもので、約6つのパーティションを提供します。しかし、それでも、パーティションサイズが大きすぎて最適なパフォーマンスを実現できないと思いますか？たとえば、発行イベント+カスタマーIDの最後の桁など、2つのキーでパーティション化することはできますか？したがって、ロジックは次のようになります。 If issuance event = 1 and last digit of customer id < 5 then Store in partition 1 Else if issuance event = 1 and last digit of customer id >4 then Store in partition 2 Else if issuance event =2 and last digit of customer …

10 sql-server  partitioning 

SQL Server 2016に3つのクラスター化列ストアインデックス（CCI）テーブルがあります。これらのCCIはすべて、テナントIDに基づいて同じパーティションスキームにあります。最近、一貫性のない方法で、結合からこれらのテーブルへの単純な選択ステートメントでデッドロックが発生しています。デッドロックするクエリの例： SELECT TOP 33 r.tenantid FROM Table_r r INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey WHERE r.TenantId = 69 AND pe.TenantId = 69 AND cm.TenantId = 69 エラーメッセージ： トランザクション（プロセスID 56）は、別のプロセスで汎用の待機可能なオブジェクトリソースでデッドロックされ、デッドロックの犠牲者として選択されました。トランザクションを再実行します。 手がかり： クエリがCCI以外の別のインデックスを使用する場合、デッドロックは発生しません。 3つのテナントフィルターのうち2つを削除しても、デッドロックしません。 トップ32以下を選択しても、デッドロックは発生しません。 OPTION（MAXDOP 1）を追加しても、デッドロックは発生しません。 スクランブルされたPRODレプリカ、PROD読み取り専用セカンダリ、およびPROD自体でこれを再現できます。 この動作をDEVまたはINTで再現できません。 3つのテーブル結合すべてにWITH（NOLOCK）を追加すると、依然としてデッドロックが発生します クエリ自体がデッドロックします。他にアクティブなプロセスがない場合はデッドロックします。 並列処理のないクエリプランはデッドロックしない デッドロックxmlはこちら PRODバージョン： …

10 sql-server  sql-server-2016  partitioning  deadlock  columnstore