PostgreSQLのテーブルのためのugabid

yugabytedbは2つの階層で構成されています.ysgql APIのPostgreSQLは、分散ストレージとトランザクションのdocdbの上に接続されています.Docdbは他のAPIにもアクセスされます.そうすると、名前空間は異なります.docdbでは、テーブルまたはインデックスはtable_id . Docdbは完全な辞書を開けませんtable_name and keyspace_name 属性も記録される.これは、DocDBの統計情報、宝くじ、またはコンソールでは、Web GUIのようなhttp://master:7000 エンドポイント

つのテーブルと1つのインデックスには、ランダムなバージョン4 UUIDのようなテーブルレスIDがあります.d34e4e6f23e143c89e2b4da77f06beb4 テーブル用demo and 7f8815d76bff44c7a320f28d80d836d8 インデックスdemoi キー空間でdatabase1 .
Cassandra互換インタフェースのycqlから作成しました.

create keyspace database1;
use database1;
create table demo(col1 int primary key, col2 int)
 with transactions = { 'enabled' : true };
create index demoi on demo (col2);

しかし他のバージョンはUUID ( 13桁による)を表示し、keyspaceとtable nameを複製します.手がかりはysql oidカラムにありますPostgreSQL OID .
これらのテーブルは、PostgreSQL互換のAPIであるysqlから作成されました.

create database database1;
create database database2;
\c database1;
create schema schema1;
create schema schema2;
create table schema1.demo (col1 int primary key, col2 int unique, col3 int, col4 int[]);
create table schema2.demo as select * from schema1.demo;
\c database2;
create schema schema1;
create schema schema2;
create table schema1.demo (col1 int primary key, col2 int unique, col3 int, col4 int[]);
create table schema2.demo as select * from schema1.demo;
create index demoi on schema1.demo(col3);
create index demog on schema1.demo using gin(col4);

SQLは複雑なスキーマを持つことができます.クラスタ内で

複数のデータベースdatabase1 and database2 ) ここではシステムに加えて).彼らはkeyspace で

複数のスキーマschema1 , schema2 ) 私が同じ名前を使用しても、それぞれのデータベースでは異なっています.スキーマ名はDocDBレベルでは不明です

スキーマ内のテーブルとインデックス.これはdocdbでテーブル名として表示されますが、キースペース内でも一意ではありません.なぜなら、別のスキーマやAPIがあるからです.

テーブルはDocDBレベルでは知られていないユニークな所有者を持っています

これには1つの結果があります.keyspace_name , table_name 対あなたが必要table_id .
私の例では、最初の行をクリックするとdemo とのテーブル詳細に行くhttp://master:7000/table?id=00004089000030008000000000004104 . それを示すPGSQL_TABLE_TYPE その型として.PostgreSQL OIDで識別されたPostgreSQLのテーブル型を意味します.YSQL OID . 最後の行をクリックするとhttp://master:7000/table?id=7f8815d76bff44c7a320f28d80d836d8 どのショーYQL_TABLE_TYPE . これは、ycql APIが作成したことを意味します.そして、このテーブルは実際にインデックスです.
いつものように、命名は混乱しているかもしれません.なぜなら、YogabyteDBのような新しいデータベースでさえ、その背後にある歴史があるからです.yugabytedbは分散ストレージのdocdbで始まり、keyspaceにテーブルを格納します.それらはカサンドラで使用されるのと同じ用語です.それから、最初のAPIはyugabytedb問い合わせ言語(yql)でした.しかしその後、より洗練されたSQL APIが登場しました.yqlはycqlになりました(Cはクラウド用ですが、Cassandraを聞くことができます).SQL APIはysqlです.しかし、ある日、私たちはMySQL互換APIを持っているかもしれないので、内部的にはテーブルがどこから来たかを知っていなければなりません(OIDはPostgreSQLにのみ意味を持ちます)、これはpgSQLテーブルタイプです.
あなたは、この引用を知っています:「コンピュータサイエンスで2つの難しいもの:キャッシュ無効化と命名物があります」.The Current schema version=2 上記のスクリーンショットでは、キャッシュ無効化(辞書はマスターにあります.そして、TServerセッションによってキャッシュされるので、各々のDDLはバージョン番号を増やします).命名困難はyugabytedbの柔軟な2層構造のためである.各々の層は、それ自身の語彙を持っているかもしれません.パニックしないでください、開発者の擁護者は助けるためにあるprevious post docdb(Cassandra Sharding Language)とYysql(PostgreSQL宣言のパーティションから)で意味を持つ“分割”用語について.
私はkeyspace_name , table_name テーブルを識別できません.しかし、以下のように使えます:http://yb1.pachot.net:7000/table?keyspace_name=database1&table_name=demo そして、この属性を持つYSSQLテーブルがあっても、これは意味的にYCQLTable not found! YCQLのものがなければ.YCQLでは、keyspace_name , table_name テーブルを識別します.
今、あなたはどんなテーブル、ycqlまたはyqltable_id ( UUID列に表示されます)そして、現在の0 xとして、あなたが認識しているかもしれませんが、最後の4桁は実際にはPostgreSQL OIDのための16進数です( YSSQL OID列に表示されます).また3000 and 8000 YSQLのマジックナンバーとして.最初の桁はデータベースのOIDです(このキーはKeyspace列に表示されます).
The layout は

pg_database.oid                pg_class.oid
           vvvv                        vvvv
       00000000-0000-3000-8000-000000000000
                     ^    ^
        UUID version 3    variant DCE 1.1, ISO/IEC 11578:1996

英語でそれを言うことは簡単ではありません、幸いにも、すべては正規化されて、SQLからフェッチされることができます:

select  
  '0000'||lpad(to_hex(datoid::int),4,'0')
  ||'0000'||'3000'||'8000'
  ||'00000000'||lpad(to_hex(reloid::int),4,'0') 
as uuid, datname, relname, relkind, amname, nspname  from
(select oid reloid, relname, relnamespace, relkind, relowner, relam  from pg_class) rel
natural left join (select nspname,oid relnamespace from pg_namespace) ns
natural left join (select amname,oid relam from pg_am) am
cross join (select datname,oid datoid from pg_database where datname=current_database()) dat
where nspname not in ('pg_catalog','information_schema')
order by relkind desc, 1
;

そして、あなたはテーブルまたはインデックス名(内部的に「関係」と呼ばれている)で、私のスクリーンショットと同じことを認めることができますrelname を返します.relkind ), スキーマ名(内部名前"と呼ばれます.nspname PostgreSQLでは、データベース名(datname を返します.table_id ):

               uuid               |  datname  |    relname    | relkind | amname | nspname
----------------------------------+-----------+---------------+---------+--------+---------
 0000408a00003000800000000000410e | database2 | demo          | r       |        | schema1
 0000408a000030008000000000004115 | database2 | demo          | r       |        | schema2
 0000408a000030008000000000004111 | database2 | demo_pkey     | i       | lsm    | schema1
 0000408a000030008000000000004113 | database2 | demo_col2_key | i       | lsm    | schema1
 0000408a000030008000000000004118 | database2 | demoi         | i       | lsm    | schema1
 0000408a000030008000000000004119 | database2 | demog         | i       | ybgin  | schema1
(6 rows)

私はdatabase2 これは、キー空間にあるテーブルとインデックスだけを見る理由ですdatabase2 上記のスクリーンショットで.
2つのテーブルrelkind=r with oid 0 x 410 eと0 x 4115 )と3つのインデックスrelkind=i with oid 0 x 4113 0 x 4118 0 x 4119があります.アクセスメソッド(amname ) are lsm LSMツリーインデックスとybgin LSM木の上のGINインデックスのyugabytedb実現のために.
しかし、あなたはテーブルのためにアクセスメソッドを見ませんdemo_pkey . その理由は、YugabyteDBのテーブルは、プライマリキーによって高速アクセスするためのMySQL InnoDB、SQL Serverクラスタ化インデックス、またはOracle IOTのように、主キーインデックスに格納されていることです.PostgreSQL辞書はヒープテーブルのために設計されています.ヒープテーブルはすべてのインデックスがセカンダリキーです.これがテーブルの物理的な名前です_pkey suffixはインデックス(relkind='i' and amname='lsm' ). 論理名relkind='r' , は、そのOIDをtable_id .
もう少し微妙なものがある.共有テーブルは同じストレージを共有します:

create database database3 with colocated=true;
\c database3
create table demo1 (a int);
database3=# create table demo2 (a int) with (colocated=false);
create table demo0 (a int);

テーブルが共存しているかどうかは、データベースUIDとTable OIDで構成されているUUIDで表示されます.

              uuuid               |  datname  | relname | relkind | amname | nspname
----------------------------------+-----------+---------+---------+--------+---------
 0000414c00003000800000000000414d | database3 | demo1   | r       |        | public
 0000414c000030008000000000004150 | database3 | demo2   | r       |        | public
 0000414c000030008000000000004153 | database3 | demo0   | r       |        | public

主キーを定義せずに、内部キーが生成されますが、LSMインデックスは表示されません.
テーブルOIDパートのためのZeors、およびいくつかの追加タグを持つテーブルとしての配置されたタブレットHasa UUID0000414c000030008000000000000000.colocated.parent.uuidDEMO 1またはDEMO 0を別のテーブルとしてクリックすることができますが、同じテーブルIDを共存させます.