Redshiftにおいて、バキュームは、システムを使用しない時間帯に行うのが定石です。
VACUUM は、夜間や指定されたデータベース管理期間など、クラスターのアクティビティが最小限になると予想される期間に実行します。
しかし、グローバル展開しているシステムは、使用しない時間帯がないため、使用中にバキュームを行わざるを得ません。
そこで、バキューム中にクエリ性能がどの程度落ちるのか知らべてみました。
続きを読むRedshiftにおいて、バキュームは、システムを使用しない時間帯に行うのが定石です。
VACUUM は、夜間や指定されたデータベース管理期間など、クラスターのアクティビティが最小限になると予想される期間に実行します。
しかし、グローバル展開しているシステムは、使用しない時間帯がないため、使用中にバキュームを行わざるを得ません。
そこで、バキューム中にクエリ性能がどの程度落ちるのか知らべてみました。
続きを読むIEnumerable
MSDNフォーラムの以下の投稿に基づいた検証の続きです。
DBのテーブルからレコード数によって文字列として作成し利用する方法
たとえばテーブルに レコードが3レコードあるとき , 1 TIME, 2 TIME, 3 TIME レコードが5レコードあるとき , 1 TIME, 2 TIME, 3 TIME, 4 TIME, 5 TIME というように 文字列を作成するにはどのような方法があるでしょうか? ...
今度はDataTableの行数参照の処理時間を検証します。以下のコードで「行数の参照処理」を変更して検証を行います。
DataSet ds = new DataSet(); DataTable dt = ds.Tables.Add("table"); dt.Columns.Add(); for (int i = 0; i < 100000; i++) { dt.Rows.Add("hoge"); } Stopwatch w = new Stopwatch(); w.Start(); /* * 行数の参照処理 */ w.Stop(); Console.WriteLine("経過時間:{0}ミリ秒", w.ElapsedMilliseconds);
int count; for (int i = 0; i < 1000000; i++) { count = ds.Tables["table"].Rows.Count; }
結果は513ミリ秒でした。
int rowCount = ds.Tables["table"].Rows.Count; int count; for (int i = 0; i < 1000000; i++) { count = rowCount; }
結果は5ミリ秒でした。
一度変数に取得した方が速いです。
MSDNフォーラムで以下の投稿がありました。
DBのテーブルからレコード数によって文字列として作成し利用する方法
たとえばテーブルに レコードが3レコードあるとき , 1 TIME, 2 TIME, 3 TIME レコードが5レコードあるとき , 1 TIME, 2 TIME, 3 TIME, 4 TIME, 5 TIME というように 文字列を作成するにはどのような方法があるでしょうか? ...
よい機会なので、文字列連結の処理時間を計測してみることにしました。検証は以下のコードで行いました。
Stopwatch w = new Stopwatch(); w.Start(); for (int i = 1; i <= 10000; i++) { // 文字列連結処理 } w.Stop(); Console.WriteLine("処理時間:{0}ミリ秒", w.ElapsedMilliseconds);
連結方法 | コード | 処理時間(ミリ秒) |
---|---|---|
単純な連結 | s += ", " + i.ToString("d") + " TIME"; | 1695 |
string.Format | s += string.Format(", {0} TIME", i); | 1641 |
string.Concat | s = string.Concat(s, ", " , i, " TIME"); | 1953 |
StringBuilder | s.AppendFormat(", {0} TIME", i); | 13 |
やっぱりStringBuilderが圧倒的に速いですね。