Tarantool DBMS の高レベルのレプリケーション

こんにちは、DBMS 用のアプリケーションを作成しています。 タランツール Mail.ru Group が開発したプラットフォームで、高性能 DBMS と Lua 言語のアプリケーション サーバーを組み合わせています。 Tarantool に基づくソリューションの高速性は、特に DBMS のインメモリ モードのサポートと、データを含む単一のアドレス空間でアプリケーション ビジネス ロジックを実行できる機能によって実現されます。 同時に、ACID トランザクションを使用してデータの永続性が保証されます (WAL ログはディスク上に維持されます)。 Tarantool には、レプリケーションとシャーディングのサポートが組み込まれています。 バージョン 2.1 以降、SQL 言語でのクエリがサポートされています。 Tarantool はオープンソースであり、Simplified BSD ライセンスに基づいてライセンスされています。 商用の Enterprise バージョンもあります。

力を感じます！ (…パフォーマンスをお楽しみください)

上記のすべてにより、Tarantool はデータベースで動作する高負荷アプリケーションを作成するための魅力的なプラットフォームになります。 このようなアプリケーションでは、多くの場合、データの複製が必要になります。

前述したように、Tarantool にはデータ レプリケーションが組み込まれています。 その動作原理は、マスター ログ (WAL) に含まれるすべてのトランザクションをレプリカ上で順番に実行することです。 通常、このようなレプリケーション (さらにこれをレプリケーションと呼びます) 低レベルの) は、アプリケーションのフォールト トレランスを確保したり、クラスター ノード間で読み取り負荷を分散したりするために使用されます。

米。 1. クラスター内のレプリケーション

代替シナリオの例としては、あるデータベースで作成されたデータを、処理/監視のために別のデータベースに転送することが挙げられます。 後者の場合、より便利な解決策は次のとおりです。 上級 レプリケーション - アプリケーション ビジネス ロジック レベルでのデータ レプリケーション。 それらの。 DBMS に組み込まれた既成のソリューションを使用するのではなく、開発中のアプリケーション内で独自にレプリケーションを実装します。 このアプローチには利点と欠点の両方があります。 メリットを挙げてみましょう。

1. トラフィックの節約:

• すべてのデータを転送することはできず、その一部のみを転送することはできます (たとえば、特定の基準を満たす一部のテーブル、その列またはレコードの一部のみを転送できます)。
• 非同期 (Tarantool の現在のバージョン - 1.10 で実装される) または同期 (Tarantool の以降のバージョンで実装される) モードで継続的に実行される低レベルのレプリケーションとは異なり、高レベルのレプリケーションはセッションで実行できます (つまり、アプリケーションは最初にデータ (交換セッション データ) を同期し、その後レプリケーションが一時停止し、その後次の交換セッションが発生するなど)。
• レコードが数回変更されている場合は、最新バージョンのみを転送できます (マスター上で行われたすべての変更がレプリカ上で順番に再生される低レベルのレプリケーションとは異なります)。

2. HTTP 交換の実装に難しいことはなく、リモート データベースを同期できます。

米。 2. HTTP 経由のレプリケーション

3. データが転送されるデータベース構造は同じである必要はありません (さらに、一般的な場合、異なる DBMS、プログラミング言語、プラットフォームなどを使用することも可能です)。

米。 3. 異種システムでのレプリケーション

欠点は、平均して、プログラミングは構成よりも難しく、コストがかかるため、組み込み機能をカスタマイズする代わりに独自の機能を実装する必要があることです。

状況において上記の利点が重要である (または必要な条件である) 場合は、高レベルのレプリケーションを使用することが理にかなっています。 Tarantool DBMS で高レベルのデータ レプリケーションを実装するいくつかの方法を見てみましょう。

トラフィックの最小化

したがって、高レベルのレプリケーションの利点の XNUMX つはトラフィックの節約です。 この利点を十分に発揮するには、各交換セッション中に転送されるデータ量を最小限に抑える必要があります。 もちろん、セッションの終了時に、データ受信者がソースと同期する必要があることを忘れてはなりません (少なくとも、レプリケーションに関係するデータの部分については)。

高レベルのレプリケーション中に転送されるデータ量を最小限に抑えるにはどうすればよいですか? 簡単な解決策は、日付と時刻でデータを選択することです。 これを行うには、テーブルに既に存在する日付/時刻フィールド (存在する場合) を使用できます。 たとえば、「注文」ドキュメントには「必要な注文実行時間」フィールドが含まれる場合があります。 delivery_time。 このソリューションの問題は、このフィールドの値が注文の作成に対応する順序である必要がないことです。 したがって、フィールドの最大値を思い出すことができません delivery_time、前の交換セッション中に送信され、次の交換セッション中により高いフィールド値を持つすべてのレコードを選択します delivery_time。 フィールド値が低いレコードが交換セッションの間に追加された可能性があります delivery_time。 また、順序が変更された可能性もありますが、フィールドには影響しませんでした。 delivery_time。 どちらの場合も、変更はソースから宛先に転送されません。 これらの問題を解決するには、データを「重複して」転送する必要があります。 それらの。 各交換セッションでは、フィールド値を含むすべてのデータを転送します。 delivery_time、過去のある時点 (たとえば、現在の瞬間から N 時間) を超えます。 ただし、大規模システムの場合、このアプローチは非常に冗長であり、私たちが目指しているトラフィックの節約がゼロになってしまう可能性があることは明らかです。 さらに、転送されるテーブルには、日付/時刻に関連付けられたフィールドがない場合があります。

もう XNUMX つの解決策は、実装の点でより複雑ですが、データの受信を確認することです。 この場合、各交換セッション中にすべてのデータが送信されますが、受信者はその受信を確認していません。 これを実装するには、ソース テーブルにブール列を追加する必要があります (たとえば、 is_transferred）。 受信者がレコードの受信を確認すると、対応するフィールドは次の値を取得します。 true、その後、エントリは交換に関与しなくなります。 この実装オプションには次の欠点があります。 まず、転送されるレコードごとに確認応答を生成して送信する必要があります。 大まかに言えば、これは転送されるデータ量が XNUMX 倍になり、ラウンドトリップ数も XNUMX 倍になることに相当します。 第 XNUMX に、同じレコードを複数の受信者に送信する可能性はありません (最初に受信した受信者は、自分自身と他のすべての受信者に対して受信を確認します)。

上記の欠点を持たない方法は、送信されたテーブルに列を追加して、その行の変更を追跡することです。 このような列は日時型にすることができ、レコードが追加/変更されるたびに (追加/変更とともにアトミックに) アプリケーションによって現在時刻に設定/更新される必要があります。 例として、列を呼び出してみましょう update_time。 転送されたレコードのこの列の最大フィールド値を保存すると、この値で次の交換セッションを開始できます（フィールド値を持つレコードを選択します） update_time、以前に保存された値を超えています）。 後者のアプローチの問題は、データ変更がバッチで発生する可能性があることです。 列のフィールド値の結果として update_time 一意ではないかもしれません。 したがって、この列は分割された (ページごとの) データ出力には使用できません。 データをページごとに表示するには、効率が非常に低い可能性が高い追加のメカニズムを発明する必要があります (たとえば、次の値を持つすべてのレコードをデータベースから取得するなど)。 update_time 指定された値よりも高く、サンプルの先頭から特定のオフセットから開始して特定の数のレコードを生成します)。

以前のアプローチをわずかに改善することで、データ転送の効率を向上させることができます。 これを行うには、変更を追跡するための列フィールド値として整数型 (長整数) を使用します。 列に名前を付けましょう row_ver。 この列のフィールド値は、レコードが作成/変更されるたびに設定/更新する必要があります。 ただし、この場合、フィールドには現在の日時が割り当てられず、何らかのカウンターの値が XNUMX ずつ増加して割り当てられます。 その結果、コラムは、 row_ver 一意の値が含まれており、「デルタ」データ (前回の交換セッションの終了以降に追加/変更されたデータ) を表示するだけでなく、それを簡単かつ効果的にページに分割するために使用することもできます。

高レベルのレプリケーションのフレームワーク内で転送されるデータ量を最小限に抑える最後に提案された方法が、私には最も最適で普遍的であるように思えます。 さらに詳しく見てみましょう。

行バージョンカウンターを使用したデータの受け渡し

サーバー/マスター部分の実装

MS SQL Server には、このアプローチを実装するための特別な列タイプがあります。 rowversion。 各データベースには、次のような列を持つテーブルでレコードが追加/変更されるたびに XNUMX ずつ増加するカウンターがあります。 rowversion。 このカウンタの値は、追加/変更されたレコードのこの列のフィールドに自動的に割り当てられます。 Tarantool DBMS には、同様の組み込みメカニズムがありません。 ただし、Tarantool では手動で実装することは難しくありません。 これがどのように行われるかを見てみましょう。

まず、少し用語について説明します。Tarantool のテーブルはスペースと呼ばれ、レコードはタプルと呼ばれます。 Tarantool ではシーケンスを作成できます。 シーケンスは、順序付けされた整数値の名前付きジェネレーターにすぎません。 それらの。 これはまさに私たちの目的に必要なものです。 以下ではそのようなシーケンスを作成します。

Tarantool でデータベース操作を実行する前に、次のコマンドを実行する必要があります。

box.cfg{}

その結果、Tarantool はデータベース スナップショットとトランザクション ログを現在のディレクトリに書き込み始めます。

シーケンスを作成しましょう row_version:

box.schema.sequence.create('row_version',
    { if_not_exists = true })

オプション if_not_exists 作成スクリプトを複数回実行できます。オブジェクトが存在する場合、Tarantool はそのオブジェクトを再度作成しようとしません。 このオプションは、後続のすべての DDL コマンドで使用されます。

例としてスペースを作成してみましょう。

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        },
        {
            name = 'row_ver',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

ここでスペースの名前を設定します(goods)、フィールド名とそのタイプ。

Tarantool の自動インクリメント フィールドもシーケンスを使用して作成されます。 フィールドごとに自動インクリメントする主キーを作成しましょう id:

box.schema.sequence.create('goods_id',
    { if_not_exists = true })
box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

Tarantool は、いくつかのタイプのインデックスをサポートしています。 最も一般的に使用されるインデックスは TREE タイプと HASH タイプで、名前に対応する構造に基づいています。 TREE は最も汎用性の高いインデックス タイプです。 これにより、体系的な方法でデータを取得できます。 ただし、同等の選択には HASH の方が適しています。 したがって、主キーには HASH を使用することをお勧めします (私たちはそうしました)。

コラムを利用するには row_ver 変更されたデータを転送するには、シーケンス値をこの列のフィールドにバインドする必要があります row_ver。 ただし、主キーとは異なり、列フィールドの値は row_ver 新しいレコードを追加するときだけでなく、既存のレコードを変更するときにも XNUMX ずつ増やす必要があります。 これにはトリガーを使用できます。 Tarantool には XNUMX 種類のスペース トリガーがあります。 before_replace и on_replace。 スペース内のデータが変更されるたびにトリガーが起動されます (変更の影響を受けるタプルごとに、トリガー関数が起動されます)。 とは異なり on_replace, before_replace-triggers を使用すると、トリガーが実行されるタプルのデータを変更できます。 したがって、最後のタイプのトリガーが私たちに適しています。

box.space.goods:before_replace(function(old, new)
    return box.tuple.new({new[1], new[2], new[3],
        box.sequence.row_version:next()})
end)

次のトリガーはフィールド値を置き換えます row_ver 格納されたタプルをシーケンスの次の値に変換する row_version.

宇宙からデータを抽出できるようにするために goods 列ごと row_ver、インデックスを作成しましょう。

box.space.goods:create_index('row_ver', {
    parts = { 'row_ver' },
    unique = true,
    type = 'TREE',
    if_not_exists = true
})

インデックス タイプ - ツリー (TREE）、 なぜなら列の値の昇順でデータを抽出する必要があります row_ver.

スペースにデータを追加してみましょう。

box.space.goods:insert{nil, 'pen', 123}
box.space.goods:insert{nil, 'pencil', 321}
box.space.goods:insert{nil, 'brush', 100}
box.space.goods:insert{nil, 'watercolour', 456}
box.space.goods:insert{nil, 'album', 101}
box.space.goods:insert{nil, 'notebook', 800}
box.space.goods:insert{nil, 'rubber', 531}
box.space.goods:insert{nil, 'ruler', 135}

なぜなら最初のフィールドは自動インクリメントするカウンターで、代わりに nil を渡します。 Tarantool は次の値を自動的に置き換えます。 同様に、列フィールドの値として row_ver nil を渡すことも、値をまったく指定しないこともできます。 この列はスペースの最後の位置を占めます。

挿入結果を確認してみましょう。

tarantool> box.space.goods:select()
---
- - [1, 'pen', 123, 1]
  - [2, 'pencil', 321, 2]
  - [3, 'brush', 100, 3]
  - [4, 'watercolour', 456, 4]
  - [5, 'album', 101, 5]
  - [6, 'notebook', 800, 6]
  - [7, 'rubber', 531, 7]
  - [8, 'ruler', 135, 8]
...

ご覧のとおり、最初と最後のフィールドは自動的に入力されます。 スペースの変更をページごとにアップロードする関数を簡単に作成できるようになりました。 goods:

local page_size = 5
local function get_goods(row_ver)
    local index = box.space.goods.index.row_ver
    local goods = {}
    local counter = 0
    for _, tuple in index:pairs(row_ver, {
        iterator = 'GT' }) do
        local obj = tuple:tomap({ names_only = true })
        table.insert(goods, obj)
        counter = counter + 1
        if counter >= page_size then
            break
        end
    end
    return goods
end

関数はパラメータとして値を受け取ります row_ver、そこから変更をアンロードする必要があり、変更されたデータの一部を返します。

Tarantool でのデータ サンプリングはインデックスを通じて行われます。 関数 get_goods インデックスによるイテレータを使用します row_ver 変更されたデータを受信します。 イテレータのタイプは GT (Greater Than、より大きい) です。 これは、イテレータが渡されたキー（フィールド値）から始まるインデックス値を順番に走査することを意味します。 row_ver).

イテレータはタプルを返します。 その後 HTTP 経由でデータを転送できるようにするには、タプルをその後のシリアル化に便利な構造に変換する必要があります。 この例では、これに標準関数を使用します。 tomap。 使用する代わりに tomap 独自の関数を作成できます。 たとえば、フィールドの名前を変更したい場合があります。 name、フィールドを通過しないでください code そしてフィールドを追加します comment:

local function unflatten_goods(tuple)
    local obj = {}
    obj.id = tuple.id
    obj.goods_name = tuple.name
    obj.comment = 'some comment'
    obj.row_ver = tuple.row_ver
    return obj
end

出力データのページ サイズ (XNUMX つの部分のレコード数) は変数によって決まります。 page_size。 この例では、値は page_size 実際のプログラムでは、通常はページ サイズの方が重要です。 それは空間タプルの平均サイズによって異なります。 最適なページ サイズは、データ転送時間を測定することで経験的に決定できます。 ページサイズが大きいほど、送信側と受信側の間の往復回数は少なくなります。 こうすることで、変更をダウンロードする全体の時間を短縮できます。 ただし、ページ サイズが大きすぎると、サーバーでのサンプルのシリアル化に時間がかかりすぎます。 その結果、サーバーに送信される他のリクエストの処理に遅延が発生する可能性があります。 パラメータ page_size 設定ファイルから読み込むことができます。 送信されるスペースごとに、独自の値を設定できます。 ただし、ほとんどのスペースでは、デフォルト値 (100 など) が適切な場合があります。

関数を実行してみましょう get_goods:

tarantool> get_goods(0)

---
- - row_ver: 1
    code: 123
    name: pen
    id: 1
  - row_ver: 2
    code: 321
    name: pencil
    id: 2
  - row_ver: 3
    code: 100
    name: brush
    id: 3
  - row_ver: 4
    code: 456
    name: watercolour
    id: 4
  - row_ver: 5
    code: 101
    name: album
    id: 5
...

フィールド値を取得しましょう row_ver 最後の行から関数を再度呼び出します。

tarantool> get_goods(5)

---
- - row_ver: 6
    code: 800
    name: notebook
    id: 6
  - row_ver: 7
    code: 531
    name: rubber
    id: 7
  - row_ver: 8
    code: 135
    name: ruler
    id: 8
...

そしてまた：

tarantool> get_goods(8)
---
- []
...

ご覧のとおり、このように使用すると、関数はすべてのスペース レコードをページごとに返します。 goods。 最後のページの後には空の選択範囲が続きます。

スペースに変更を加えてみましょう。

box.space.goods:update(4, {{'=', 6, 'copybook'}})
box.space.goods:insert{nil, 'clip', 234}
box.space.goods:insert{nil, 'folder', 432}

フィールド値を変更しました name XNUMX つのエントリに加え、XNUMX つの新しいエントリを追加しました。

最後の関数呼び出しを繰り返してみましょう。

tarantool> get_goods(8)
---



- - row_ver: 9
    code: 800
    name: copybook
    id: 6
  - row_ver: 10
    code: 234
    name: clip
    id: 9
  - row_ver: 11
    code: 432
    name: folder
    id: 10
...

この関数は、変更および追加されたレコードを返しました。 したがって、関数は get_goods を使用すると、最後の呼び出し以降に変更されたデータを受信できます。これが、検討中のレプリケーション方法の基礎となります。

JSON 形式での HTTP 経由の結果の発行については、この記事の範囲外としておきます。 これについてはここで読むことができます: https://habr.com/ru/company/mailru/blog/272141/

クライアント/スレーブ部分の実装

受信側の実装がどのようなものかを見てみましょう。 ダウンロードしたデータを保存するためのスペースを受信側に作成しましょう。

box.schema.space.create('goods', {
    format = {
        {
            name = 'id',
            type = 'unsigned'

        },
        {
            name = 'name',
            type = 'string'

        },
        {
            name = 'code',
            type = 'unsigned'

        }
    },
    if_not_exists = true
})

box.space.goods:create_index('primary', {
    parts = { 'id' },
    sequence = 'goods_id',
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

空間の構造は、ソース内の空間の構造に似ています。 ただし、受信したデータを他の場所に渡すつもりはないので、列 row_ver 受信者のスペースにありません。 フィールド内 id ソース識別子が記録されます。 したがって、受信側では自動インクリメントする必要はありません。

さらに、値を保存するためのスペースが必要です row_ver:

box.schema.space.create('row_ver', {
    format = {
        {
            name = 'space_name',
            type = 'string'

        },
        {
            name = 'value',
            type = 'string'

        }
    },
    if_not_exists = true
})

box.space.row_ver:create_index('primary', {
    parts = { 'space_name' },
    unique = true,
    type = 'HASH',
    if_not_exists = true
})

ロードされたスペースごとに (フィールド space_name) 最後にロードされた値をここに保存します row_ver （分野 value）。 列は主キーとして機能します space_name.

空間データを読み込む関数を作ってみましょう goods HTTP経由で。 これを行うには、HTTP クライアントを実装するライブラリが必要です。 次の行はライブラリをロードし、HTTP クライアントをインスタンス化します。

local http_client = require('http.client').new()

json デシリアライゼーション用のライブラリも必要です。

local json = require('json')

データ読み込み関数を作成するにはこれで十分です。

local function load_data(url, row_ver)
    local url = ('%s?rowVer=%s'):format(url,
        tostring(row_ver))
    local body = nil
    local data = http_client:request('GET', url, body, {
        keepalive_idle =  1,
        keepalive_interval = 1
    })
    return json.decode(data.body)
end

この関数は、URL アドレスに対して HTTP リクエストを実行し、送信します。 row_ver をパラメータとして受け取り、リクエストの逆シリアル化された結果を返します。

受信したデータを保存する関数は次のようになります。

local function save_goods(goods)
    local n = #goods
    box.atomic(function()
        for i = 1, n do
            local obj = goods[i]
            box.space.goods:put(
                obj.id, obj.name, obj.code)
        end
    end)
end

データをスペースに保存するサイクル goods トランザクションに配置されます (関数はこのために使用されます) box.atomic) ディスク操作の数を減らします。

最後に、ローカル空間同期機能 goods ソースを使用すると、次のように実装できます。

local function sync_goods()
    local tuple = box.space.row_ver:get('goods')
    local row_ver = tuple and tuple.value or 0

    —— set your url here:
    local url = 'http://127.0.0.1:81/test/goods/list'

    while true do
        local goods = load_goods(url, row_ver)

        local count = #goods
        if count == 0 then
            return
        end

        save_goods(goods)

        row_ver = goods[count].rowVer
        box.space.row_ver:put({'goods', row_ver})
    end
end

まず、以前に保存した値を読み取ります row_ver 宇宙用 goods。 それが欠落している場合 (最初の交換セッション)、次のようにみなします。 row_ver ゼロ。 サイクルの次は、指定された URL のソースから変更されたデータをページごとにダウンロードします。 各反復で、受信したデータを適切なローカル空間に保存し、値を更新します。 row_ver （宇宙で row_ver そして変数の中で row_ver) - 値を取得します row_ver ロードされたデータの最後の行から。

偶発的なループ (プログラム内でエラーが発生した場合) を防ぐために、ループ while と置き換えることができます for:

for _ = 1, max_req do ...

関数を実行した結果、 sync_goods 空間 goods 受信機にはすべてのスペース レコードの最新バージョンが含まれます。 goods ソースで。

明らかに、データの削除をこの方法でブロードキャストすることはできません。 そのような必要がある場合は、削除マークを使用できます。 スペースに追加する goods ブールフィールド is_deleted レコードを物理的に削除する代わりに、論理的な削除を使用します。フィールド値を設定します。 is_deleted 意味に true。 場合によってはブールフィールドの代わりに is_deleted フィールドを使用する方が便利です deleted、レコードの論理削除の日時が格納されます。 論理削除を実行すると、削除対象としてマークされたレコードがソースから宛先に転送されます (上記のロジックに従って)。

シーケンス row_ver 他のスペースからデータを送信するために使用できます。送信されるスペースごとに個別のシーケンスを作成する必要はありません。

Tarantool DBMS を使用してアプリケーションで高レベルのデータ レプリケーションを行う効果的な方法を検討しました。

所見

1. Tarantool DBMS は、高負荷アプリケーションを作成するための魅力的で有望な製品です。
2. 高レベルのデータ レプリケーションには、低レベルのレプリケーションに比べて多くの利点があります。
3. この記事で説明されている高レベルのレプリケーション方法を使用すると、最後の交換セッション以降に変更されたレコードのみを転送することで、転送されるデータの量を最小限に抑えることができます。

出所： habr.com