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

パフォーマンスまたは管理性のためにデータベーステーブルを複数のセグメントに分割します。

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

1
日付によるインデックスの最適化
この質問は、データベース管理者の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 >= …

3
パーティションキーもプライマリキーの一部である必要がありますか?
主キーではない列に基づいてテーブルをパーティション分割していますか?今日、パーティション列を主キーの一部にする必要があるかどうかに関するいくつかの矛盾する情報を読みました。私の腸はノーと言うが、私は100%確信していない。だから質問... パーティション列はプライマリの一部である必要がありますか?どちらの方法がお勧めですか? パーティションキーのインデックスを作成する必要がありますか、それともDBMSが自動的にインデックスを作成しますか?


2
既存の非パーティションテーブルをパーティション化する方法
データのある既存のテーブルがあります: dbo.Test (col1,col2,col3....) ON [PRIMARY] このようにパーティション分割されるようにこのテーブルを変更する必要があります。 dbo.Test(col1,col2,col3....) ON Ps_Date(Col2) テーブルをドロップして再作成せずにこれを達成するにはどうすればよいですか?

1
シークし、パーティションテーブルでスキャンします…
Itzik Ben-Ganの PCMagでこれらの記事を読みました。 シークし、スキャンしますパートI:オプティマイザがシークを最適化しない場合、 スキャンしますパートII:昇順キー 現在、すべてのパーティションテーブルで「グループ化された最大」問題が発生しています。Itzik Ben-Ganが提供するトリックを使用して max(ID)を取得しますが、実行されない場合があります。 DECLARE @MaxIDPartitionTable BIGINT SELECT @MaxIDPartitionTable = ISNULL(MAX(IDPartitionedTable), 0) FROM ( SELECT * FROM ( SELECT partition_number PartitionNumber FROM sys.partitions WHERE object_id = OBJECT_ID('fct.MyTable') AND index_id = 1 ) T1 CROSS APPLY ( SELECT ISNULL(MAX(UpdatedID), 0) AS IDPartitionedTable FROM fct.MyTable s WHERE $PARTITION.PF_MyTable(s.PCTimeStamp) …

2
このパーティションビューで無関係なテーブルをオプティマイザに強制的に削除させることはできますか?
私は大きなテーブルのさまざまなアーキテクチャをテストしていますが、私が見た提案の1つは、大きなテーブルを一連の小さな「パーティション」テーブルに分割するパーティションビューを使用することです。 1、2、3、4 このアプローチをテストする中で、あまり意味をなさない何かを発見しました。ファクトビューの「パーティション列」でフィルタリングすると、オプティマイザーは関連するテーブルのみを検索します。さらに、ディメンションテーブルのその列でフィルタリングすると、オプティマイザーは不要なテーブルを削除します。 ただし、ディメンションの他の側面でフィルタリングすると、オプティマイザーは各ベーステーブルのPK / CIを検索します。 問題のクエリは次のとおりです。 select od.[Year], AvgValue = avg(ObservationValue) from dbo.v_Observation o join dbo.ObservationDates od on o.ObservationDateKey = od.DateKey where o.ObservationDateKey >= 20000101 and o.ObservationDateKey <= 20051231 group by od.[Year]; select od.[Year], AvgValue = avg(ObservationValue) from dbo.v_Observation o join dbo.ObservationDates od on o.ObservationDateKey = od.DateKey where od.DateKey …

2
データが「自然にパーティション化可能」である場合、マシン間でPostgreSQLをパーティション分割する最新の方法は何ですか
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 6年前に移行され ました。 「NoSQL」の分野に数年滞在した後、今ではその性質が非常に「リレーショナル」な問題を抱えています。今日、私は以前とはまったく異なる目でデータストアを見ています。Riakのようなものは、単一の障害点、「メンテナンスのためのダウン」などに耐えることができないという方法で私を台無しにしました。これは、非常に高い要件を持たない(またはまだ)個人的なプロジェクトです。 おそらく、私の問題は解決が非常に「簡単」だからです。少なくとも概念レベルでは(RDBM自体がテーブルにもたらす制約を無視して)。 少量の「共有」データがあり、自由に複製できます。ハード一貫性の要件はありません。これはダイナモのようなデータベースに保存でき、無限に拡張できます。ただし、可能であれば、単一のデータベースを使用したいと考えています。 「ユーザーごとの」データがたくさんあります。つまり、すべてのユーザーが絶対に妥当なサイズのデータ​​を持っている多くのユーザーが、単一のPostgreSQLノードに保存するのに本当に適しています。最大で数万件のレコードについて話しています。 クロスユーザーに問い合わせる必要はなく、クロスユーザーの原子性は必要ありません。 これは非常に簡単に実現できます。少なくとも「NoSQLの目」で見ているときは。 ここに私の素朴なスターターのアイデアがあります: 極端な場合、ユーザー全体をRiakの単一のキー/値としてシリアル化できます。もちろん、数メガバイトのデータを絶えずデシリアライズするのは遅いので、PostgreSQLの使用を検討しています。各ユーザーのデータ内に原子性/トランザクションが必要なため、Riak K / Vの多くは不要です。 ユーザーごとにSQLiteデータベースを使用し、GlusterFSのようなものを使用して冗長性と可用性を実現できます。これはおそらく、PostgreSQLを使用しても同様に良いものが見つからない場合に選択するソリューションです。長所:本当にうまくスケールダウン/スケールアップできます; 短所:SQLiteよりもPostgreSQLの型と厳格さを好む したがって、PostgreSQLシャーディングソリューションから私が理想的に要求するものは次のとおりです。 すべてのユーザーのデータのコピーを(異なるマシン上に)自動的に保持します。ユーザー/シャードごとにマスターノードを動的に切り替えることができる(以前のマスターがダウンした場合)。 サーバーノードを追加/削除することにより、動的にスケールアップ/ダウンすることができます。たいていはRiakができるように。 アプリケーションが、どのノードといつ通信するかを知る必要はありません。

1
増分更新後に統計が消える
増分統計を利用する大規模なパーティションSQL Serverデータベースがあります。すべてのインデックスはパーティション分割されています。パーティションごとにオンラインでパーティションを再構築しようとすると、インデックスが再構築された後にすべての統計が消えます。 以下は、AdventureWorks2014データベースを使用してSQL Server 2014の問題を再現するスクリプトです。 --Example against AdventureWorks2014 Database CREATE PARTITION FUNCTION TransactionRangePF1 (DATETIME) AS RANGE RIGHT FOR VALUES ( '20130501', '20130601', '20130701', '20130801', '20130901', '20131001', '20131101', '20131201', '20140101', '20140201', '20140301' ); GO CREATE PARTITION SCHEME TransactionsPS1 AS PARTITION TransactionRangePF1 TO ( [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], …

2
SQL Serverは、2つの同等にパーティション分割されたテーブルでの並列マージ結合を最適化しません
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 非常に詳細な質問をおApびします。問題を再現するための完全なデータセットを生成するクエリを含め、32コアマシンでSQL Server 2012を実行しています。ただし、これはSQL Server 2012に固有のものではないと思い、この特定の例ではMAXDOPを10に強制しました。 同じパーティション構成を使用してパーティション化された2つのテーブルがあります。パーティショニングに使用される列でそれらを結合すると、SQL Serverは予想されるほど並列マージ結合を最適化できないため、代わりにHASH JOINを使用することにしました。この特定のケースでは、パーティション関数に基づいてクエリを10個の独立した範囲に分割し、SSMSでそれらのクエリを同時に実行することにより、はるかに最適な並列MERGE JOINを手動でシミュレートできます。WAITFORを使用してすべてを正確に同時に実行すると、すべてのクエリが、元の並列HASH JOINで使用された合計時間の約40%で完了します。 同等にパーティション化されたテーブルの場合に、SQL Serverがこの最適化を独自に行う方法はありますか?SQL Serverは一般にMERGE JOINを並列化するために多くのオーバーヘッドが発生する可能性があることを理解していますが、この場合、オーバーヘッドが最小限の非常に自然なシャーディングメソッドがあるようです。おそらく、オプティマイザーがまだ十分に認識できないほど特殊なケースでしょうか? この問題を再現するために、単純化されたデータセットを設定するSQLは次のとおりです。 /* Create the first test data table */ CREATE TABLE test_transaction_properties ( transactionID INT NOT NULL IDENTITY(1,1) , prop1 INT NULL , prop2 FLOAT NULL ) /* Populate table with …

2
postgresで既存のテーブルをパーティション分割する方法は?
日付範囲ごとに100万行以上のテーブルをパーティション分割したいと思います。これは、多くのダウンタイムを必要とせずに、またはデータを失うリスクを負うことなく、通常どのように行われますか?ここに私が検討している戦略がありますが、提案があります: 既存のテーブルがマスターであり、子はそれを継承します。時間が経つにつれて、マスターから子にデータが移動しますが、データの一部がマスター表にあり、一部が子にある期間があります。 新しいマスターテーブルと子テーブルを作成します。子テーブルの既存のテーブルにデータのコピーを作成します(したがって、データは2つの場所に存在します)。子テーブルが最新のデータを取得したら、今後すべての挿入を変更して新しいマスターテーブルを指し、既存のテーブルを削除します。

1
データベースアーカイブソリューション
私が投稿した質問に続いて、大量のアクセス頻度の高いテーブルを別のデータベースに移動することをお勧めしますか?、PostgreSQLでのデータベースアーカイブに利用できるさまざまなテクニック/ソリューションを探しています。 私が考えることができるいくつかのソリューションは次のとおりです。 テーブルのパーティション分割 別のテーブルスペースおよび/またはスキーマ アーカイブされたレコード/テーブルを別のハードディスクに移動する 他の提案/ポインター/ソリューションは本当に歓迎され、高く評価されています。 注: CentOS5.2でPostgreSQL v9.1.3を実行しています

2
3500万行以上のテーブルに対応する効果的なmysqlテーブル/インデックスデザイン、200以上の対応する列(ダブル)、任意の組み合わせをクエリ可能
次の状況でのテーブル/インデックスの設計に関するアドバイスを探しています。 複合主キー(assetid(int)、date(date))を含む大きなテーブル(株価履歴データ、InnoDB、3500万行および成長)があります。価格情報に加えて、各レコードに対応する必要がある200のdouble値があります。 CREATE TABLE `mytable` ( `assetid` int(11) NOT NULL, `date` date NOT NULL, `close` double NOT NULL, `f1` double DEFAULT NULL, `f2` double DEFAULT NULL, `f3` double DEFAULT NULL, `f4` double DEFAULT NULL, ... skip a few … `f200` double DEFAULT NULL, PRIMARY KEY (`assetid`, `date`)) ENGINE=`InnoDB` DEFAULT CHARACTER …

4
SQL大規模テーブルの設計
SQL Server 2008のテーブル設計に関する一般的な質問があります。現在、600 GBを超えるテーブルがあり、1日に約3 GBで成長しています。このテーブルには適切な指標がありますが、クエリを実行するときやそのサイズのために、大きなハングアップになりつつあります。問題は、年と月でテーブルを複数のテーブルに分割するか(これにより、他の部門が大規模なデータセットを分割する方法に適合します)、またはSQL Serverに組み込まれたパーティションを活用する必要があります。パーティショニングを使用すると、コードの変更が少なくて済むようです。パーティション分割時に読んだものから、まだ1つのテーブルを照会するだけで、サーバーはデータの取得方法を処理します。複数のテーブルルートを使用する場合、複数のテーブルからデータをプルする必要があります。

3
パーティションキーを更新して、パーティション間で行を移動できますか?
これはかなり単純な質問だと思いますが、実際にはこれに対する答えを見つけるのに苦労しました。 質問:パーティション列を更新してパーティションの境界を越えるだけで、パーティションテーブル内のデータ行をあるパーティションから別のパーティションに移動できますか? たとえば、パーティションキーを持つテーブルがある場合: CREATE TABLE SampleTable ( SampleID INT PRIMARY KEY, SampleResults VARCHAR(100) NOT NULL, ) 主キーにマップするパーティション関数を使用して: CREATE PARTITION FUNCTION MyPartitionFunc (INT) AS RANGE LEFT FOR VALUES (10000, 20000); SampleIDを1から(たとえば)500,000に変更して、最初のパーティションから3番目のパーティションに行を移動できますか? 注:どちらもパーティション分割をサポートしているため、SQL Server 2005と2008の両方としてこれをタグ付けしています。彼らはそれを異なって扱いますか?

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