Greenplum はテーブルを作成します - 分散キー
Greenplum は、テーブルを作成するときに分散キーを指定する必要があります (テーブルを作成するには CREATEDBA 権限が必要です)。その目的は、データを均等に分散することです。各セグメント。分散キーの選択は非常に重要です。間違ったキーを選択すると、データが一意でなくなり、さらに深刻な場合、SQL パフォーマンスが大幅に低下します。
Greenplum には 2 つの分散戦略があります:
1.
Greenplum はデフォルトでハッシュ分散戦略を使用します。この戦略では、分散キー (略して DK) として 1 つ以上の列を選択できます。分散キーはハッシュ アルゴリズムを使用して、データが対応するセグメントに格納されていることを確認します。同じ分散キー値は同じセグメントにハッシュされます。データが各セグメントに均等に分散されないように、テーブルに一意のキーまたは主キーを設定することが最善です。 Grammar、によって配布されました。
主キーまたは一意キーがない場合、デフォルトで最初の列が分散キーとして選択されます。主キーを追加します
2.
データはランダムにセグメントに分割され、同じレコードが異なるセグメントに保存される場合があります。ランダム分散によりデータが均一であることが保証されますが、Greenplum にはノード間でデータを制約する一意のキーがないため、データが一意であることは保証できません。一意性とパフォーマンスの考慮事項に基づいて、ハッシュ分散を使用することをお勧めします。パフォーマンスの部分については、別のドキュメントで詳しく紹介します。文法、ランダムに配布。
1. ハッシュ分散キー
分散列または分散タイプを指定せずにテーブルを作成します。 ハッシュ分散テーブルはデフォルトで作成され、最初の列 ID フィールドが分散キーとして使用されます。
testDB=# create table t_hash(id int,name varchar(50)) distributed by (id); CREATE TABLE testDB=# testDB=# \d t_hash Table "public.t_hash" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | Distributed by: (id)
主キーを追加すると、主キーは ID 列ではなく分散キーにアップグレードされます。
testDB=# alter table t_hash add primary key (name); NOTICE: updating distribution policy to match new primary key NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index "t_hash_pkey" for table "t_hash" ALTER TABLE testDB=# \d t_hash Table "public.t_hash" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | not null Indexes: "t_hash_pkey" PRIMARY KEY, btree (name) Distributed by: (name)
ハッシュ分散テーブルが主キーまたは一意のキー値の一意性を実現できることを確認します
testDB=# insert into t_hash values(1,'szlsd1'); INSERT 0 1 testDB=# testDB=# insert into t_hash values(2,'szlsd1'); ERROR: duplicate key violates unique constraint "t_hash_pkey"(seg2 gp-s3:40000 pid=3855)
さらに、主キー列には引き続き一意のキーを作成できます
testDB=# create unique index u_id on t_hash(name); CREATE INDEX testDB=# testDB=# testDB=# \d t_hash Table "public.t_hash" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | not null Indexes: "t_hash_pkey" PRIMARY KEY, btree (name) "u_id" UNIQUE, btree (name) Distributed by: (name)
ただし、非主キー列は一意のインデックスを単独で作成することはできません。作成したい場合は、複数の分散キー列を含める必要があります
testDB=# create unique index uk_id on t_hash(id); ERROR: UNIQUE index must contain all columns in the distribution key of relation "t_hash" testDB=# create unique index uk_id on t_hash(id,name); CREATE INDEX testDB=# \d t_hash Table "public.t_hash" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | not null Indexes: "t_hash_pkey" PRIMARY KEY, btree (name) "uk_id" UNIQUE, btree (id, name) Distributed by: (name)
主キーを削除した後、元のハッシュ分散キーは変更されません。
testDB=# alter table t_hash drop constraint t_hash_pkey; ALTER TABLE testDB=# \d t_hash Table "public.t_hash" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | not null Distributed by: (name)
分散キーが主キーでも一意キーでもない場合、セグメント内に分散キーの同じ値が含まれていることを確認してみましょう。
次の実験では、名前列が分散キーであり、同じ名前の値を挿入すると、7 つのレコードがすべてセグメント ノード 2 に分類されることがわかります。
testDB=# insert into t_hash values(1,'szlsd'); INSERT 0 1 testDB=# insert into t_hash values(2,'szlsd'); INSERT 0 1 testDB=# insert into t_hash values(3,'szlsd'); INSERT 0 1 testDB=# insert into t_hash values(4,'szlsd'); INSERT 0 1 testDB=# insert into t_hash values(5,'szlsd'); INSERT 0 1 testDB=# insert into t_hash values(6,'szlsd'); INSERT 0 1 testDB=# testDB=# testDB=# select gp_segment_id,count(*) from t_hash group by gp_segment_id; gp_segment_id | count ---------------+------- 2 | 7 (1 row)
2. ランダム分散キー
ランダム分散テーブルを作成するには、distributed Random キーワードを追加する必要があります。どの列を分散キーとして使用するかは不明です。
testDB=# create table t_random(id int ,name varchar(100)) distributed randomly; CREATE TABLE testDB=# testDB=# testDB=# \d t_random Table "public.t_random" Column | Type | Modifiers --------+------------------------+----------- id | integer | name | character varying(100) | Distributed randomly
主キー/一意キーの一意性を検証すると、ランダム分布表では主キーと一意キーを作成できないことがわかります
testDB=# alter table t_random add primary key (id,name); ERROR: PRIMARY KEY and DISTRIBUTED RANDOMLY are incompatible testDB=# testDB=# create unique index uk_r_id on t_random(id); ERROR: UNIQUE and DISTRIBUTED RANDOMLY are incompatible testDB=#
データの一意性が確保できないことが実験からわかります。また、ポーリング挿入ではなく、ランダムに分散したテーブルにデータを挿入します。実験ではセグメントが3つありますが、1番に3レコード、2番に2レコードを挿入し、その後にデータを挿入しています。セグメント番号0。ランダムに分散されたテーブルがどのようにして均一なデータ分散を実現するのかは不明です。この実験では、ランダム分布表の同じ値が異なるセグメントに分布するという結論も検証されました。
testDB=# insert into t_random values(1,'szlsd3'); INSERT 0 1 testDB=# select gp_segment_id,count(*) from t_random group by gp_segment_id; gp_segment_id | count ---------------+------- 1 | 1 (1 row) testDB=# testDB=# insert into t_random values(1,'szlsd3'); INSERT 0 1 testDB=# select gp_segment_id,count(*) from t_random group by gp_segment_id; gp_segment_id | count ---------------+------- 2 | 1 1 | 1 (2 rows) testDB=# insert into t_random values(1,'szlsd3'); INSERT 0 1 testDB=# select gp_segment_id,count(*) from t_random group by gp_segment_id; gp_segment_id | count ---------------+------- 2 | 1 1 | 2 (2 rows) testDB=# insert into t_random values(1,'szlsd3'); INSERT 0 1 testDB=# select gp_segment_id,count(*) from t_random group by gp_segment_id; gp_segment_id | count ---------------+------- 2 | 2 1 | 2 (2 rows) testDB=# insert into t_random values(1,'szlsd3'); INSERT 0 1 testDB=# select gp_segment_id,count(*) from t_random group by gp_segment_id; gp_segment_id | count ---------------+------- 2 | 2 1 | 3 (2 rows) testDB=# insert into t_random values(1,'szlsd3'); INSERT 0 1 testDB=# select gp_segment_id,count(*) from t_random group by gp_segment_id; gp_segment_id | count ---------------+------- 2 | 2 1 | 3 0 | 1 (3 rows)
3. CTAS は元のテーブルの分散キーを継承します
Greenplum には 2 つの CTAS 構文がありますが、どちらの構文であっても、デフォルトでは元のテーブルの分散キーが継承されます。ただし、主キー、一意キー、APPENDONLY、COMPRESSTYPE (圧縮) など、テーブルの一部の特殊な属性は継承されません。
testDB=# \d t_hash; Table "public.t_hash" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | not null Indexes: "t_hash_pkey" PRIMARY KEY, btree (name) "uk_id" UNIQUE, btree (id, name) Distributed by: (name) testDB=# testDB=# testDB=# create table t_hash_1 as select * from t_hash; NOTICE: Table doesn't have 'DISTRIBUTED BY' clause -- Using column(s) named 'name' as the Greenplum Database data distribution key for this table. HINT: The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew. SELECT 0 testDB=# \d t_hash_1 Table "public.t_hash_1" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | Distributed by: (name) testDB=# testDB=# create table t_hash_2 (like t_hash); NOTICE: Table doesn't have 'distributed by' clause, defaulting to distribution columns from LIKE table CREATE TABLE testDB=# \d t_hash_2 Table "public.t_hash_2" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | not null Distributed by: (name)
CTAS が分散キーを変更するテーブルを作成する場合は、distributed by を追加するだけです。
testDB=# create table t_hash_3 as select * from t_hash distributed by (id); SELECT 0 testDB=# testDB=# \d t_hash_3 Table "public.t_hash_3" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | Distributed by: (id) testDB=# testDB=# testDB=# create table t_hash_4 (like t_hash) distributed by (id); CREATE TABLE testDB=# testDB=# \d t_hash4 Did not find any relation named "t_hash4". testDB=# \d t_hash_4 Table "public.t_hash_4" Column | Type | Modifiers --------+-----------------------+----------- id | integer | name | character varying(50) | not null Distributed by: (id)
CTAS を使用する場合は、ランダムに分散されたキーに特別な注意を払う必要があり、ランダムに分散されたキーを追加する必要があります。そうしないと、元のテーブルにはハッシュ分散キーが含まれ、新しい CTAS テーブルにはランダムに分散されたキーが含まれます。
testDB=# \d t_random Table "public.t_random" Column | Type | Modifiers --------+------------------------+----------- id | integer | name | character varying(100) | Distributed randomly testDB=# testDB=# \d t_random_1 Table "public.t_random_1" Column | Type | Modifiers --------+------------------------+----------- id | integer | name | character varying(100) | Distributed by: (id)
testDB=# create table t_random_2 as select * from t_random distributed randomly; SELECT 7 testDB=# testDB=# \d t_random_2 Table "public.t_random_2" Column | Type | Modifiers --------+------------------------+----------- id | integer | name | character varying(100) | Distributed randomly
参考:
「Greenplum エンタープライズ アプリケーションの実践」
「Greenplum 4.2.2 管理者ガイド」
上記は、Greenplum 作成テーブル - 配布キー_PHP チュートリアルの内容です。その他の関連コンテンツについては、注意してください。 PHP 中国語 Web サイト (www.php.cn)!

PHPは、現代のWeb開発、特にコンテンツ管理とeコマースプラットフォームで依然として重要です。 1)PHPには、LaravelやSymfonyなどの豊富なエコシステムと強力なフレームワークサポートがあります。 2)パフォーマンスの最適化は、Opcacheとnginxを通じて達成できます。 3)PHP8.0は、パフォーマンスを改善するためにJITコンパイラを導入します。 4)クラウドネイティブアプリケーションは、DockerおよびKubernetesを介して展開され、柔軟性とスケーラビリティを向上させます。

PHPは、特に迅速な開発や動的なコンテンツの処理に適していますが、データサイエンスとエンタープライズレベルのアプリケーションには良くありません。 Pythonと比較して、PHPはWeb開発においてより多くの利点がありますが、データサイエンスの分野ではPythonほど良くありません。 Javaと比較して、PHPはエンタープライズレベルのアプリケーションでより悪化しますが、Web開発により柔軟性があります。 JavaScriptと比較して、PHPはバックエンド開発により簡潔ですが、フロントエンド開発のJavaScriptほど良くありません。

PHPとPythonにはそれぞれ独自の利点があり、さまざまなシナリオに適しています。 1.PHPはWeb開発に適しており、組み込みのWebサーバーとRich Functionライブラリを提供します。 2。Pythonは、簡潔な構文と強力な標準ライブラリを備えたデータサイエンスと機械学習に適しています。選択するときは、プロジェクトの要件に基づいて決定する必要があります。

PHPは、サーバー側で広く使用されているスクリプト言語で、特にWeb開発に適しています。 1.PHPは、HTMLを埋め込み、HTTP要求と応答を処理し、さまざまなデータベースをサポートできます。 2.PHPは、ダイナミックWebコンテンツ、プロセスフォームデータ、アクセスデータベースなどを生成するために使用され、強力なコミュニティサポートとオープンソースリソースを備えています。 3。PHPは解釈された言語であり、実行プロセスには語彙分析、文法分析、編集、実行が含まれます。 4.PHPは、ユーザー登録システムなどの高度なアプリケーションについてMySQLと組み合わせることができます。 5。PHPをデバッグするときは、error_reporting()やvar_dump()などの関数を使用できます。 6. PHPコードを最適化して、キャッシュメカニズムを使用し、データベースクエリを最適化し、組み込み関数を使用します。 7

PHPが多くのWebサイトよりも優先テクノロジースタックである理由には、その使いやすさ、強力なコミュニティサポート、広範な使用が含まれます。 1)初心者に適した学習と使用が簡単です。 2)巨大な開発者コミュニティと豊富なリソースを持っています。 3)WordPress、Drupal、その他のプラットフォームで広く使用されています。 4)Webサーバーとしっかりと統合して、開発の展開を簡素化します。

PHPは、特にWeb開発の分野で、最新のプログラミングで強力で広く使用されているツールのままです。 1)PHPは使いやすく、データベースとシームレスに統合されており、多くの開発者にとって最初の選択肢です。 2)動的コンテンツ生成とオブジェクト指向プログラミングをサポートし、Webサイトを迅速に作成および保守するのに適しています。 3)PHPのパフォーマンスは、データベースクエリをキャッシュおよび最適化することで改善でき、その広範なコミュニティと豊富なエコシステムにより、今日のテクノロジースタックでは依然として重要になります。

PHPでは、弱い参照クラスを通じて弱い参照が実装され、ガベージコレクターがオブジェクトの回収を妨げません。弱い参照は、キャッシュシステムやイベントリスナーなどのシナリオに適しています。オブジェクトの生存を保証することはできず、ごみ収集が遅れる可能性があることに注意する必要があります。

\ _ \ _ Invokeメソッドを使用すると、オブジェクトを関数のように呼び出すことができます。 1。オブジェクトを呼び出すことができるように\ _ \ _呼び出しメソッドを定義します。 2。$ obj(...)構文を使用すると、PHPは\ _ \ _ Invokeメソッドを実行します。 3。ロギングや計算機、コードの柔軟性の向上、読みやすさなどのシナリオに適しています。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

SAP NetWeaver Server Adapter for Eclipse
Eclipse を SAP NetWeaver アプリケーション サーバーと統合します。

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

SecLists
SecLists は、セキュリティ テスターの究極の相棒です。これは、セキュリティ評価中に頻繁に使用されるさまざまな種類のリストを 1 か所にまとめたものです。 SecLists は、セキュリティ テスターが必要とする可能性のあるすべてのリストを便利に提供することで、セキュリティ テストをより効率的かつ生産的にするのに役立ちます。リストの種類には、ユーザー名、パスワード、URL、ファジング ペイロード、機密データ パターン、Web シェルなどが含まれます。テスターはこのリポジトリを新しいテスト マシンにプルするだけで、必要なあらゆる種類のリストにアクセスできるようになります。

ドリームウィーバー CS6
ビジュアル Web 開発ツール

MantisBT
Mantis は、製品の欠陥追跡を支援するために設計された、導入が簡単な Web ベースの欠陥追跡ツールです。 PHP、MySQL、Web サーバーが必要です。デモおよびホスティング サービスをチェックしてください。
