Logical Replication関連の用語の訳語

[smatsudajp]

重要度: 中

問題点

バージョン10の目玉機能の1つのLogical Replicationに関連するいくつかの用語について訳語を決める必要がある。 Logical replication = ロジカルレプリケーション or 論理レプリケーション Publish Publisher Publication Subscribe Subscriber Subscription

背景

ベータ版が既にリリースされ、順調に行けば秋には製品版がリリースされます。 複数のファイルで使われる用語なので、今のうちに訳語について意思統一を図りたいです。

解決方法

合意できなければ多数決？

注意点

機能の概要およびこれらの用語の使い方は logical-replication.sgml を参照。 refの下にはpublicationとsubscriptionについてalter/create/dropがあります。

[smatsudajp]

個人的な好みは「論理レプリケーション」なのですが、「ロジカル～」を好む人も多いと予想。 PublixxxxとSubscrixxxxは面倒なので全部カタカナかなぁ…

[smatsudajp]

放置していましたが、10が正式リリースされたので、訳語も正式に決めないといけませんね。 MLに投げたときは、石井さんと田中さんが「ロジカルレプリケーション」、小泉さんと松田は「論理レプリケーション」を推していましたが、どうしましょう。

[KenichiroTanaka]

他に議論が無ければ、ちょうど半数ずつですので、以前も行ったように投票で決めてしまう方法ではいかがでしょうか。

[tatsuo-ishii]

検索すると、「論理プリケーション」が多いので、「論理レプリケーション」でも良いかなと思うのですが、そうすると、すでに"logical decoding"を「論理デコーディング」ではなくて「ロジカルデコーディング」にしている一貫性のなさが気になりますね。

PublixxxxとSubscrixxxxは面倒なので全部カタカナかなぁ… 私も面倒だと言う理由で賛成。

[smatsudajp]

logical replicationについては、小泉さんが言っている「物理レプリケーション」vs「論理レプリケーション」という構図で、私は「論理レプリケーション」を強く推したいです。「ロジカル」を強く推す方がいらっしゃればまた別ですが、投票するより前に再考して頂きたいと思います。 logical decodingについては、以前、私は深く考えずに「論理デコーディング」と訳してしまいましたが、技術的な詳細を全く理解していません。また、そのときに訳語の統一の行動を起こさなかったので、ロジカルと論理が併存して一貫性がなくなっています（すみません）。対応する「物理デコーディング」がなく、「論理」に深い意味がないのなら、これは"logical replication"の話とは独立して、単に訳語の統一という目的で、どちらかに倒せば良い話だと思います。なお、"logical replication"に深く関連する話であるなら、「論理デコーディング」に倒したいですが、関連しない話なのであれば、むしろ「論理レプリケーション」と「ロジカルデコーディング」にするぐらいが良いかも、と思います。

[tatsuo-ishii]

MySQLと違って、PostgreSQLのレプリケーションには、2種類の「物理レプリケーション」があります。すなわち、ファイルベースのログシッピングと、レコードベースのストリーミングレプリケーションです。

一方、"logical replication"は、ストリーミングレプリケーションと同じレコードベースのレプリケーションです。ファイルベースのログシッピングレプリケーションに対応する"logical replication"は今のところありません(あまりメリットがないので、将来も実装されないと思います)

PostgreSQLでは、このように「物理レプリケーション」と「論理レプリケーション」は非対称になっているので、若干注意が必要です。

というわけで、「物理レプリケーション」vs.「論理レプリケーション」 = "streaming replication" vs. "logical replication"ではありません。このあたり、誤解されそうな気がしてちょっと気になっています。

[smatsudajp]

「物理レプリケーション」はデータベースのレコードがマスタとスレーブで同じになるようにするもので、streaming replicationはその実装の一つ、「論理レプリケーション」はマスタと同じSQLをスレーブでも実行することでデータベースの内容を同じにしようとするもので、PostgreSQL 10のlogical replicationはそういうものに違いない、と思っていたのですが、違うのでしょうか？

[tatsuo-ishii]

PostgreSQLのlogical replicationは、SQLは実行しません。通常のバックエンドとは別のワーカープロセスの中で、エグゼキュータが直接更新操作を実行します。

[KenichiroTanaka]

＞「物理レプリケーション」vs.「論理レプリケーション」 = "streaming replication" vs. "logical 
＞replication"ではありません。このあたり、誤解されそうな気がしてちょっと気になっています。

私は、物理レプリケーションは、データベースのデータの中身を意識せず、ブロックの変更を
再生することでレプリケーションを実現する機能、論理レプリケーションはデータを理解して
レプリケーションを実現する機能という理解しています。このため、物理レプリケーション時は
リカバリ状態でレプリケーションが進行します。一方で、データベースにデータを理解させる必
要があるため、論理レプリケーション時にはデータベースは操作できるオープン状態である
必要があります。

この理解が正しい場合、

”物理レプリケーション”vs.”論理レプリケーション”
 = 
streaming replication（物理レプリケーションの実装の一つ） vs. logical replication（論理レプリケーションの実装の一つ）

の構造で良いのではないかと思っています。

＞SQLは実行しません。通常のバックエンドとは別のワーカープロセスの中で、エグゼキュータが
＞直接更新操作を実行します。
直接SQLが実行されるわけではありませんが、データベースはオープン状態でエグゼキュータがデータを
操作してレプリケーションを実現しているため、これも論理レプリケーションなのだと理解しています。

[KenichiroTanaka]

自分の文章を読んで気づいたのですが、

streaming replication（物理レプリケーションの実装の一つ） vs. logical replication（論理レプリケーションの実装の一つ）

が正しいならば、logical replicationを論理レプリケーションと訳すと混乱が生じるため、ロジカルレプリケーションの方が良いように思います。

[KenichiroTanaka]

すみません、[jpug-doc: 5527] 新機能の訳語のメールを見落としていました。 話をややこしくしてしまっていたらすみません。

[tatsuo-ishii]

「オープン状態」という状態はPostgreSQLにはないと思います。

それはさておいて、「データを理解する」というのが何を意味するのかは難しいところです。 「データを理解する」というと、データの意味を理解する→SQLレベルの理解→元のSQLがわかる、というところまでいっちゃうかもしれませんが、それは違います。たとえば、以下のようなSQLをpublisher側で発行します。 subscriber側にはt1はありますが、t2はないとします。

delete from t1 where j = (select j from t2 where j = 10);

このSQLは、レプリケーションされます。subscriber側にはt2が存在しないにも関わらず。

論理レプリケーションというのが、「マスタで実行したSQLをログに書いておいて、スレーブでそれを実行することによってレプリケーションする」だと思っている人がいたとしたら、PostgreSQLのロジカルレプリケーションを運用すると、色々嵌ることになるでしょう。

[smatsudajp]

読者が「論理レプリケーション」をどういう意味に捉えようと、「ロジカルレプリケーション」を「論理レプリケーション」とは違うものだと捉える人はいないと思います。どちらで訳そうが「PostgreSQLのlogical replicationって、自分の思っていたlogical replicationとはちょっと違うのね」という話でしょう。細かい実装が狭義の論理レプリケーションとは違うからロジカルレプリケーションにした方が良い、という考え方には同意しません。日本語の技術文書としてどっちが良いの、という話にするのが良いと考えます。

[KenichiroTanaka]

＞日本語の技術文書としてどっちが良いの、という話にするのが良いと考えます。 ご指摘の通りですね。思考が別の方向に飛んで行きました。

他に”ロジカルレプリケーション”を推すロジックはありません。