7.3.38. logical_table_remove
#
7.3.38.1. 概要#
Added in version 5.0.5.
logical_table_remove
は指定した論理テーブルのテーブルとそのカラムを削除します。もし、テーブルのキーあるいはそのテーブルのカラムにインデックスが張ってある場合はそれらも削除します。
シャードの一部を指定すると、そのシャードのテーブルは削除しません。テーブル内のレコードを削除するだけです。
例えば、テーブル内に以下のレコードがあるとします。
レコード1:
2016-03-18 00:30:00
レコード2:
2016-03-18 01:00:00
レコード3:
2016-03-18 02:00:00
範囲として 2016-03-18 00:00:00
から 2016-03-18 01:30:00
までを指定すると、「レコード1」と「レコード2」を削除します。「レコード3」は削除しません。テーブルも削除しません。
Added in version 6.0.1: dependent
パラメーターを使うと、対象テーブルを参照しているテーブル・カラムと対象シャードに関連しているテーブルも一緒に削除できます。
Added in version 6.0.9: force
パラメーターを使うと壊れているテーブル・カラムでもできるだけ削除することができます。
7.3.38.2. 構文#
このコマンドにはたくさんの引数があります。
必須引数は2つあります。 logical_table
と shard_key
です。
logical_table_remove logical_table
shard_key
[min=null]
[min_border="include"]
[max=null]
[max_border="include"]
[dependent=no]
[force=no]
7.3.38.3. 使い方#
削除したい論理テーブル名とシャードキーを指定します。
このセクションでは次のことについて説明します。
基本的な使い方
論理テーブルの一部を削除
削除できないケース
関連するテーブルと一緒に削除
可能な限り壊れているテーブルを削除
利用リソースの削減
7.3.38.3.1. 基本的な使い方#
このコマンドを使うには事前に sharding
プラグインを登録します。
実行例:
plugin_register sharding
# [[0,1337566253.89858,0.000355720520019531],true]
logical_table
と shard_key
だけを指定することで対象論理テーブル用のすべてのテーブルを削除できます。
以下は2つのシャードを作成するコマンドです。
実行例:
table_create Logs_20160318 TABLE_NO_KEY
# [[0,1337566253.89858,0.000355720520019531],true]
column_create Logs_20160318 timestamp COLUMN_SCALAR Time
# [[0,1337566253.89858,0.000355720520019531],true]
table_create Logs_20160319 TABLE_NO_KEY
# [[0,1337566253.89858,0.000355720520019531],true]
column_create Logs_20160319 timestamp COLUMN_SCALAR Time
# [[0,1337566253.89858,0.000355720520019531],true]
存在するシャードは logical_shard_list で確認できます。
実行例:
logical_shard_list --logical_table Logs
# [
# [
# 0,
# 1337566253.89858,
# 0.000355720520019531
# ],
# [
# {
# "name": "Logs_20160318"
# },
# {
# "name": "Logs_20160319"
# }
# ]
# ]
すべてのシャードを削除できます。
実行例:
logical_table_remove \
--logical_table Logs \
--shard_key timestamp
# [[0,1337566253.89858,0.000355720520019531],true]
すべてのシャードを削除した後はシャードは存在しません。
実行例:
logical_shard_list --logical_table Logs
# [[0,1337566253.89858,0.000355720520019531],[]]
7.3.38.3.2. 論理テーブルの一部を削除#
次のパラメーターでシャードの範囲を指定できます。
min
min_border
max
max_border
各パラメーターについては logical_select の以下のドキュメントを参照してください。
指定した範囲がシャード内のすべてのレコードを含んでいなかったら、そのシャードのテーブルは削除しません。テーブル内の対象レコードのみ削除します。
指定した範囲がシャード内のすべてのレコードを含んでいれば、そのシャード用のテーブルを削除します。
以下はこの挙動を示すための論理テーブルです。この論理テーブルには2つのシャードがあります。
実行例:
table_create Logs_20160318 TABLE_NO_KEY
# [[0,1337566253.89858,0.000355720520019531],true]
column_create Logs_20160318 timestamp COLUMN_SCALAR Time
# [[0,1337566253.89858,0.000355720520019531],true]
load --table Logs_20160318
[
{"timestamp": "2016-03-18 00:30:00"},
{"timestamp": "2016-03-18 01:00:00"},
{"timestamp": "2016-03-18 02:00:00"}
]
# [[0,1337566253.89858,0.000355720520019531],3]
table_create Logs_20160319 TABLE_NO_KEY
# [[0,1337566253.89858,0.000355720520019531],true]
column_create Logs_20160319 timestamp COLUMN_SCALAR Time
# [[0,1337566253.89858,0.000355720520019531],true]
load --table Logs_20160319
[
{"timestamp": "2016-03-19 00:30:00"},
{"timestamp": "2016-03-19 01:00:00"}
]
# [[0,1337566253.89858,0.000355720520019531],2]
Logs_20160318
テーブルには次のレコードがあります。
レコード1:
"2016-03-18 00:30:00"
レコード2:
"2016-03-18 01:00:00"
レコード3:
"2016-03-18 02:00:00"
Logs_20160319
テーブルには次のレコードがあります。
レコード1:
"2016-03-19 00:30:00"
レコード2:
"2016-03-19 01:00:00"
次の範囲は Logs_20160318
テーブル内の「レコード1」を含んでいませんが、 Logs_20160319
テーブルのすべてのレコードを含んでいます。
パラメーター |
値 |
---|---|
|
|
|
|
|
|
|
|
この範囲を指定した logical_table_remove
は Logs_20160318
テーブルの「レコード2」と「レコード3」を削除します。しかし、 Logs_20160318
テーブルは削除しません。なぜなら、 Logs_20160318
テーブルには「レコード1」があるからです。
この範囲を指定した logical_table_remove
は Logs_20160319
テーブルを削除します。なぜなら、この範囲は Logs_20160319
テーブルのすべてのレコードを含んでいるからです。
この範囲を指定した logical_table_remove
を使う例です。
実行例:
logical_table_remove \
--logical_table Logs \
--shard_key timestamp \
--min "2016-03-18 01:00:00" \
--min_border "include" \
--max "2016-03-19 01:30:00" \
--max_border "include"
# [[0,1337566253.89858,0.000355720520019531],true]
dump を使うと Logs_20160318
テーブルに「レコード1」があることを確認できます。
実行例:
dump
# plugin_register sharding
#
# table_create Logs_20160318 TABLE_NO_KEY
# column_create Logs_20160318 timestamp COLUMN_SCALAR Time
#
# load --table Logs_20160318
# [
# ["_id","timestamp"],
# [1,1458228600.0]
# ]
7.3.38.3.3. 削除できないケース#
いくつか削除できない場合があります。詳細は 削除できないケース を参照してください。なぜなら logical_table_remove
も同じようにチェックしているからです。
7.3.38.3.5. 可能な限り壊れているテーブルを削除#
Added in version 6.0.9.
対象のテーブルが壊れていた場合は削除できません。しかし、 force
パラメーターを指定することで可能な限り削除することができます。
--force yes
を指定すると、対象テーブルを可能な限り削除します。 --force yes
と一緒に --dependent yes
も指定することができます。
以下は --force yes
の挙動を示すサンプルスキーマです。
実行例:
table_create Logs_20160320 TABLE_NO_KEY
# [[0,1337566253.89858,0.000355720520019531],true]
column_create Logs_20160320 timestamp COLUMN_SCALAR Time
# [[0,1337566253.89858,0.000355720520019531],true]
table_create Timestamps TABLE_PAT_KEY Time
# [[0,1337566253.89858,0.000355720520019531],true]
column_create Timestamps logs_20160320_timestamp \
COLUMN_INDEX Logs_20160320 timestamp
# [[0,1337566253.89858,0.000355720520019531],true]
Timestamps.logs_20160320_timestamp
が壊れていると Logs_20160320
を削除できません。
実行例:
logical_table_remove \
--logical_table Logs \
--shard_key timestamp
# [
# [
# -55,
# 1337566253.89858,
# 0.000355720520019531,
# "object corrupt: <[object][remove][index][Logs_20160320.timestamp][set] hook has a dangling reference: <Timestamps.logs_20160320",
# [
# [
# "remove",
# "lib/groonga/plugins/sharding/logical_table_remove.rb",
# 2929
# ]
# ]
# ]
# ]
--force yes
パラメーターを使うと、たとえ Timestamps.logs_20160320_timestamp
が壊れていても Logs_20160320
とこのテーブルのカラムを削除できます。
実行例:
logical_table_remove \
--logical_table Logs \
--shard_key timestamp \
--force yes
# [[0,1337566253.89858,0.000355720520019531],true]
Logs_20160320
とそのテーブルのカラムと Timestamps.logs_20160320_timestamp
が削除されます。
実行例:
object_exist Logs_20160320
# [[0,1337566253.89858,0.000355720520019531],false]
object_exist Logs_20160320.timestamp
# [[0,1337566253.89858,0.000355720520019531],false]
object_exist Timestamps.logs_20160320_timestamp
# [[0,1337566253.89858,0.000355720520019531],false]
--force yes
パラメーターは危険なパラメーターです。通常これを使う必要はありません。
7.3.38.3.6. 利用リソースの削減#
このコマンドが使うリソースを削減できます。詳細は 利用リソースの削減 を参照してください。なぜなら logical_table_remove
は table_remove と同じロジックを使っているからです。
7.3.38.4. 引数#
このセクションでは logical_table_remove
の引数について説明します。
7.3.38.4.1. 必須引数#
いくつか必須の引数があります。
7.3.38.4.1.1. logical_table
#
論理テーブル名を指定します。これは _YYYYMMDD
をテーブル名から除いたものです。実際のテーブルが Logs_20150203
や Logs_20150203
といったものなら、論理テーブル名は Logs
です。
logical_table も参照してください。
7.3.38.4.2. 省略可能引数#
いくつか省略可能な引数があります。
7.3.38.4.2.1. min
#
shard_key
カラムの最小値を指定します。
min も参照してください。
7.3.38.4.2.2. min_border
#
最小値を含めるかどうかを指定します。 include
か exclude
を指定します。デフォルトは include
です。
min_border も参照してください。
7.3.38.4.2.3. max
#
shard_key
カラムの最大値を指定します。
max も参照してください。
7.3.38.4.2.4. max_border
#
最大値を含めるかどうかを指定します。 include
か exclude
を指定します。デフォルトは include
です。
max_border も参照してください。
7.3.38.4.2.5. dependent
#
Added in version 6.0.1.
対象シャードに依存しているテーブル・カラムも一緒に削除するかどうかを指定します。
以下が依存していると判断する条件です。もし、テーブル・カラムがこれらの条件のどれか1つでも満たしていてれば、そのテーブル・カラムは対象シャードに依存しています。
対象シャードを参照しているテーブル・カラム
対象シャード用のテーブル(= 名前の末尾が対象シャードと同じ
_YYYYMMDD
で、対象シャードが参照しているテーブル)
yes
を指定した場合は、対象シャードに依存しているテーブル・カラムも削除します。 yes
を指定しなければ削除しません。もし、対象シャードを参照しているテーブル・カラムが1つ以上あればエラーになります。もし、対象シャード用のテーブルがあっても、それらを削除しません。
このパラメーターは注意して使ってください。危険なパラメーターです。
このパラメーターの使い方は 関連するテーブルと一緒に削除 を参照してください。
7.3.38.4.2.6. force
#
Added in version 6.0.9.
もし問題があったとしても対象テーブル・カラムを削除したいかどうかを指定します。
このパラメーターは注意して使ってください。危険なパラメーターです。
このパラメーターの使い方は 可能な限り壊れているテーブルを削除 を参照してください。
7.3.38.5. 戻り値#
このコマンドが成功したときは以下のようにボディは true
になります:
[HEADER, true]
このコマンドが失敗すると、 HEADER
にエラーの詳細が含まれます。
HEADER
については 出力形式 を参照してください。