Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード

2017-12-10

MySQL Connector/J(JDBC Driver) で接続時に任意の collation_connection をセットする

MySQL Connector/J(JDBC Driver) で接続時に任意の collation_connection をセットする には以下の用に JDBC URL に「connectionCollation=utf8mb4_bin」のように設定すれば良い。

jdbc:mysql://aurora01.cluster-*******.ap-northeast-1.rds.amazonaws.com:3306/mydb?connectionCollation=utf8mb4_bin

参考

MySQL クライアントプログラム mysql、mysqladmin、mysqlcheck、mysqlimport、および mysqlshow は、次のように、使用するデフォルトの文字セットを特定します。

C アプリケーションは、サーバーに接続する前に次のように mysql_options() を呼び出すことによって、OS 設定に基づいて文字セットの自動検出を使用できます。

mysql_options(mysql,
              MYSQL_SET_CHARSET_NAME,
              MYSQL_AUTODETECT_CHARSET_NAME);
MySQL :: MySQL 5.6 リファレンスマニュアル :: 10.1.4 接続文字セットおよび照合順序

Use characterEncoding=utf8mb4& for jdbc url

jdbc:mysql://x.x.x.x:3306/db?useUnicode=true&characterEncoding=utf8mb4
java - utf8mb4 in MySQL Workbench and JDBC - Stack Overflow

connectionCollation

If set, tells the server to use this collation via 'set collation_connection'

Since version: 3.0.13

MySQL :: MySQL Connector/J 5.1 Developer Guide :: 5.1 Driver/Datasource Class Names, URL Syntax and Configuration Properties for Connector/J

2017-12-07

Aurora MySQL互換に LOAD コマンドで CSV ファイルをロードしようとすると "ERROR 1148 (42000)" で失敗する

Aurora MySQL互換というより MySQL の話です。


事象

% mysql  --local-infile -h aurora01.cluster-******.ap-northeast-1.rds.amazonaws.com -u awsuser -p
mysql> LOAD DATA LOCAL INFILE '.test.csv' INTO TABLE TEST FIELDS TERMINATED BY ',' ENCLOSED BY '"';
ERROR 1148 (42000): The used command is not allowed with this MySQL version

原因


解決

% mysql  --local-infile -h aurora01.cluster-******.ap-northeast-1.rds.amazonaws.com -u awsuser -p
mysql LOAD DATA LOCAL INFILE 'test.csv' INTO TABLE TEST FIELDS TERMINATED BY ',' ENCLOSED BY '"';

参考

LOAD DATA ステートメントの LOCAL バージョンのサポートに関しては、セキュリティーについての潜在的な問題が 2 つあります。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 6.1.6 LOAD DATA LOCAL のセキュリティーの問題

You can specify that as an additional option when setting up your client connection:

mysql -u myuser -p --local-infile somedatabase

This is because that feature opens a security hole. So you have to enable it manually in case you really want to use it.

sql - ERROR 1148: The used command is not allowed with this MySQL version - Stack Overflow

mysql コマンド行クライアントの場合、--local-infile[=1] オプションを指定することによって LOAD DATA LOCAL を有効にするか、--local-infile=0 オプションを指定することによってこれを無効にします。mysqlimport の場合、ローカルデータファイルのロードはデフォルトでオフになっており、--local または -L オプションを使用してこれを有効にします。いずれの場合でも、ローカルロード操作を正常に使用するには、サーバーがこの操作を許可していることが必要。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 6.1.6 LOAD DATA LOCAL のセキュリティーの問題

2017-09-15

MySQL で NOT NULL 制約のある列に複数行インサートするとその型のデフォルト値が入る

MySQLSQL モードが STRICT モードでない場合、NOT NULL 制約のある列に複数行インサートするとその型のデフォルト値(0とか空文字)が入る(1行インサートだとエラーで入らない)。


検証結果

  • Amazon Aurora with MySQL Compatibility に接続する
$ mysql -h ******.******.ap-northeast-1.rds.amazonaws.com -u awsuser -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 53
Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
  • データベースを選択する
mysql> use mydb;
Database changed
  • テーブルを作成する
mysql> create table `not_null_test` (
    ->   `id` int(10) unsigned not null,
    ->   `int_col` int(10) unsigned not null,
    ->   `char_col` char(10)  not null,
    ->   `ts_col` timestamp not null,
    ->   primary key (`id`)
    -> ) engine=innodb default charset=utf8;
Query OK, 0 rows affected (0.05 sec)
  • SQL モードは設定されていない
mysql> select @@global.sql_mode;
+-------------------+
| @@global.sql_mode |
+-------------------+
|                   |
+-------------------+
1 row in set (0.02 sec)
  • 1行インサートはエラーになる
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be null
  • 複数行インサートは成功する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null), (2, null, null, null);
Query OK, 2 rows affected, 4 warnings (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 4
  • テーブルのデータを確認する
mysql> select * from not_null_test;
+----+---------+----------+---------------------+
| id | int_col | char_col | ts_col              |
+----+---------+----------+---------------------+
|  1 |       0 |          | 2017-09-15 06:54:07 |
|  2 |       0 |          | 2017-09-15 06:54:07 |
+----+---------+----------+---------------------+
2 rows in set (0.02 sec)
  • SQLモードを STRICT_ALL_TABLES にする
mysql> set sql_mode='strict_all_tables';
Query OK, 0 rows affected (0.03 sec)
  • 1行インサートは失敗する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be null
  • 複数行インサートも失敗する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null), (2, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be nul

参考

単列インサートの場合はNOT NULLが指定されたカラムにNULL値が挿入されるとそのクエリはエラーとなって失敗するが、複数列インサートの場合は警告(warning)を発するものの、クエリは正常に受け付けられる。

その際、NULL値が指定された各カラムにはそれぞれのカラムのデータ型の暗黙的なデフォルト値が挿入される。(数値型なら0、文字列型なら空文字''、etc…)

MySQLにおけるNOT NULLカラムへのインサート時の挙動 - Sojiro’s Blog

NOT NULL として宣言されているカラムへの NULL の挿入。複数行の INSERT ステートメントまたは INSERT INTO ... SELECT ステートメントの場合、このカラムは、そのカラムデータ型の暗黙のデフォルト値に設定されます。これは、数値型では 0、文字列型では空の文字列 ('')、および日付と時間型では「0」の値です。サーバーは SELECT からの結果セットを検査して、それが単一行を返すかどうかを確認しないため、INSERT INTO ... SELECT ステートメントは複数行の挿入と同じ方法で処理されます。(単一行の INSERT の場合は、NULL が NOT NULL カラムに挿入されても警告は発生しません。代わりに、このステートメントがエラーで失敗します。)

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.2.5 INSERT 構文

明示的な DEFAULT 句のない NOT NULL カラムに対するデータエントリでは、INSERT または REPLACE ステートメントにカラムの値を含まれていない場合、または UPDATE ステートメントがカラムを NULL に設定する場合、MySQL はその時点で有効な SQL モードに従ってカラムを処理します。

  • 厳密な SQL モードを有効にした場合、トランザクションテーブルに対してエラーが発生し、ステートメントがロールバックされます。非トランザクションテーブルではエラーが起きるが、これが複数行ステートメントの 2 行目以降の行に対するエラーの場合、先行する行が挿入されています。
  • 厳密モードが有効でない場合、MySQL はカラムデータ型の暗黙的なデフォルト値にカラムを設定します。

(中略)

セクション5.1.7「サーバー SQL モード」を参照してください。

所定のテーブルに対して、SHOW CREATE TABLE ステートメントを使用すると、どのカラムに明示的な DEFAULT 句があるかを確認できます。

暗黙的なデフォルトは次のように定義されます。

  • 数値型のデフォルトは 0 です。ただし、例外として AUTO_INCREMENT 属性で宣言された整数型または浮動小数点型のデフォルトは、そのシーケンスの次の値になります。
  • TIMESTAMP 以外の日付と時間型のデフォルトには、「ゼロ」値が適切です。explicit_defaults_for_timestamp システム変数が有効な場合、これは TIMESTAMP にも当てはまります (セクション5.1.4「サーバーシステム変数」を参照してください)。それ以外の場合、テーブルの最初の TIMESTAMP カラムのデフォルト値は現在の日付と時間になります。セクション11.3「日付と時間型」を参照してください。
  • ENUM ではない文字列型のデフォルト値は空の文字列です。ENUM のデフォルトは、最初の列挙値です。
MySQL :: MySQL 5.6 リファレンスマニュアル :: 11.6 データ型デフォルト値

厳密モードは、MySQL が INSERT や UPDATE などのデータ変更ステートメントで無効な値または欠落した値を処理する方法を制御します。値はいくつかの理由で無効になることがあります。たとえば、カラムに対して正しくないデータ型を持っていたり、範囲外であったりすることがあります。値の欠落が発生するのは、挿入される新しい行の非 NULL カラムに値が含まれておらず、そのカラムに明示的な DEFAULT 句が定義されていない場合です。(NULL カラムの場合、値が欠落しているときは NULL が挿入されます。)

厳密モードが有効でない場合、MySQL は無効または欠落した値に対して調整された値を挿入し、警告を生成します (セクション13.7.5.41「SHOW WARNINGS 構文」を参照してください)。厳密モードでは、INSERT IGNORE または UPDATE IGNORE を使用すると、この動作を実行できます。

データを変更しない SELECT などのステートメントの場合、厳密モードでは無効な値はエラーでなく警告を生成します。

厳密モードは、外部キー制約が検査されるかどうかに影響されません。foreign_key_checks を検査に使用できます。(セクション5.1.4「サーバーシステム変数」を参照してください。)

MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.1.7 サーバー SQL モード

2017-05-06

AWS の VPC(Virtual Private Network) についてメモ

※以下は個人的なメモです。最新の正確な情報はAWSの公式ドキュメントを参照してください。

VPC とは

Virtual Private Cloud (VPC) は、AWS アカウント専用の仮想ネットワーク。以下のコンポンーネントがある。


  • VPCに使うアドレスレンジ
    • VPCに設定するアドレスは既に使っている、もしくは使うであろうネットワークアドレスを避けるのがポイント
    • 推奨: 172.31.0.0/16 RFC1918レンジ、/16 (65,534アドレス)
    • 作成後変更はできないので注意が必要
    • VPCあたりのサブネット作成上限数はデフォルト200個
  • CIDRに/16 を設定した場合の各サブネット数と使えるIPアドレス数
サブネット
  • サブネットで利用できないIPアドレス
ホストアドレス用途
.0ネットワークアドレス
.1VPCルータ
.2Amazonが提供するDNSサービス
.3AWSで予約
.255ブロードキャストアドレス (VPCではブロードキャストはサポー トされていない)
アベイラビリティゾーン(AZ)
  • AZは1つ以上のデータセンターで構成される
  • 1リージョン内にAZが複数存在
  • AZはお互いに地理的・電源的・ネットワーク的に分離
  • 2つのAZを利用した冗長構成を容易に構築
  • リージョン内のAZ間は高速専用線で接続(リージョン間はインターネット経由)

ネットワークACL と セキュリティグループ
ネットワークACLセキュリティグループ
サブネットレベルで効果サーバレベルで効果
Allow/DenyをIN・OUTで指定可能 (ブラックリスト型)AllowのみをIN・OUTで指定可能 (ホワイトリスト型)
ステートレスなので、戻りのトラフィックも明示的に許可設定するステートフルなので、戻りのトラフィックを考慮しなくてよい
番号の順序通りに適用全てのルールを適用
サブネット内のすべてのインスタンスがACLの管理下に入るインスタンス管理者がセキュリティグループを適用すればその管理下になる

AWSクラウドとVPC
  • VPC内と外のどちらにリソースや エンドポイントが存在するかサービスによって異なる
  • VPCからAWSクラウドへのリソースはIGW経由の通信となる
    • プライベートサブネットからは→NATゲートウェイ
    • S3であればVPCエンドポイントの利用も可能
    • パブリックサブネットからは→自動割当てまたはEIPのパブリックIPから直接アクセス
  • S3へのアクセスはVPCエンドポイント利用 可能

VPCエンドポイント for S3
  • VPCエンドポイントをVPCに作成し、プライベートサブネットからAWSクラウド上のS3バケットにアクセス可能
  • VPCエンドポイントを作成すると、ルートテーブルの宛先にS3のプレフィックス、ターゲットにVPCエンドポイントが自動で設定されS3への通信がVPCエンドポイント経由となる
  • VPCエンドポイントポリシーでアクセス制御が可能
  • 追加費用なし(トラフィック課金もなし)

VPC Peering (VPCピア接続)
  • 2つのVPC間でトラフィックのルーティングが可能
  • 同一のAWSアカウントはもちろん、異なるAWSアカウント間(クロス アカウント)のVPC間をピア接続することも可能
  • 単一障害点や帯域幅のボトルネックは存在しない
  • 以下の点に注意
    • MTU (VPC Peering 1,500byte)
    • 直接PeeringしているVPCとのみ
    • 通信可能(2HOPは不可)
    • リージョンは跨げない

Amazon DNS サーバー
  • Amazonが提供するDNSサービス
  • 以下の2つのアドレスが利用可能
    • VPCのネットワーク範囲(CIDR)のアドレスに+2したIP(10.0.0.0/16の場合は10.0.0.2)
    • 169.254.169.253
  • VPC内のEC2インスタンスからのみ参照可能 (VPNや専用線経由では参照できない)
  • Enable DNS resolution
    • 基本はyesとする
    • NoにするとVPCのDNS機能が無効となる
  • Enable DNS hostname
    • TrueにするとDNS名が割り当てられる
    • “Enable DNS resolution”をtrueにしないと有効にならない

VPN接続構成
  • 1つのVPN接続は2つのIPsec トンネルで冗長化
  • ルーティングは以下が選択可能
    • 静的(スタティック)
    • 動的(ダイナミック:BGP)
  • カスタマゲートウェイの要件
機能RFC
Pre-shared キーを使用して、IKE セキュリティ接続を 確立するRFC2409
トンネルを論理インターフェイスに結合する (経路ベースのVPN)-
トンネルモードで、IPsec セキュリティ接続を確立するRFC4301
暗号化前に IP パケットをフラグメント化するRFC4459
AES 128 ビット暗号化または AES 256 ビットの暗号 化機能を使用するRFC3602
(オプション)BGP ピアを確立するRFC4271
SHA-1 または SHA-256 のハッシュ機能を使用するRFC2404
VPN トンネルに入る TCP パケットの最大セグメントサ イズを調整するRFC4459
Diffie-Hellman Perfect Forward Secrecy を使用しま す。以下のグループがサポートされます。
フェーズ 1 グループ: 2,14~18,22,23,24
フェーズ 2 グループ: 1,2,5,14~18,22,23,24
RFC2409
パケットの "フラグメント化しない" フラグをリセット するRFC791
IPsec Dead Peer Detection の利用RFC3706

専用線(Direct Connect)接続構成
  • AWSとお客様設備を専用線で ネットワーク接続
  • 相互接続ポイントへ専用線を敷設 し、AWSのルータと相互接続
  • 日本の相互接続ポイントは以下の2つ
    • 東京(Equinix TY2)
    • 大阪(Equinix OS1)
  • ルーティングはBGPのみ
  • 接続先は以下の2つ
    • VPC(プライベート接続)
    • AWSクラウド(パブリック接続)
  • VPNよりも一貫性がある
  • 帯域のパフォーマンスも向上
  • ネットワークコストも削減

VPCからオンプレミスへのルート設定
  • VPCからオンプレミスへの通信をするためには各サブネットのルートテーブルの設定が必要
    • 宛先: オンプレミスのIP
    • ターゲット:VGWのID
  • ルートテーブルで”ルート伝達 (プロパゲート)”を有効にするとVGWで受信したルート情報をルートテーブルに自動的に伝達(頻繁にオンプレのルートが更新 される場合はこちらを利用)

インターネットVPN vs 専用線
インターネットVPN専用線
コスト安価なベストエフォート回線も利用可能キャリアの専用線サービスの契約が必要
リードタイム即時~数週間~
帯域暗号化のオーバーヘッドにより制限あり~10Gbps
品質インターネットベースのため経路上のネットワーク状態の影響を受けるキャリアにより高い品質が保証されている
障害時の切り分けインターネットベースのため自社で保持している範囲以外での切り分けが難しいエンドツーエンドでどの経路を利用しているか把握できているため比較的容易

VPC Flow Logs
  • ネットワークトラフィックをキャプチャ し、CloudWatch LogsへPublishする機能
  • ネットワークインタフェースを送信元/ 送信先とするトラフィックが対象
  • セキュリティグループとネットワークACL のルールでaccepted/rejectされた トラフィックログを取得
  • キャプチャウインドウと言われる時間枠 (約10分間)で収集、プロセッシング、 保存
  • RDS, Redshift、ElasticCache WorkSpacesのネットワークインタフェーストラフィックも取得可能
  • 追加料金はなし(CloudWatch Logsの標準料金は課金)
  • Flow Log レコードの項目
フィールド説明
versionVPC flow logsのバージョン
account-idflow logを取得したAWSアカウント
interface-idログストリームが適用されているネットワークインタフェースのID
srcaddr送信元アドレス(※)
dsraddr送信先アドレス(※)
srcport送信元ポート
dsrport送信先ポート
protocolIANAで定義されたプロトコル番号
packetsキャプチャウインドウの中で取得したパケット数
bytesキャプチャウインドウの中で取得したバイト数
startキャプチャウインドウ開始時のUNIX時間
endキャプチャウインドウ終了時のUNIX時間
actionトラフィックのアクション(ACCEPT/REJECT)
log-statusログステータス(OK/NODATA/SKIPDATA)

IPv6対応
  • S3、CloudFront、WAF、Route53、VPC、ALBがIPv6対応

VPCにおけるIPv4とIPv6の特徴と制限
IPv4IPv6
アドレス体系32bit128bit
VPCでの利用デフォルト適用オプトイン(自動適用ではなく任意)
CIDRブロックサイズ16~28bitで選択 自分で任意のアドレスを設定可能56bit固定 かつ自動で56bit CIDRが アサインされる(選べない)
サブネットブロックサイズ16~28bitで選択64bit固定
パブリックIP/ プライベートIPそれぞれ存在 (NATを介してパブリックIPをプライマリプライベートIPにMAP) パブリックのみ (プライベートにするにはEgress-only Internet Gatewayを利用)
インスタンスタイプ全てのインスタンスタイプM3、G2を除く全ての現行世代の インスタンスタイプでサポート
アマゾン提供DNSプライベートIP、Elastic IPに対する それぞれのDNSホスト名を受信提供されるDNSホスト名はなし
閉域接続VPN、DirectConnectDirectConnectのみ

代表的なVPCのリミット
リソース
リージョン当たりの VPC の数5
VPC 当たりのサブネットの数200
AWS アカウント当たり、1 リージョン内の Elastic IP 数5
ルートテーブル当たりのルートの数100
VPCあたりのセキュリティグループの数500
セキュリティグループあたりのルール数(In/Out)50
ネットワークインタフェースあたりのセキュリティグループ5
VPC当たりのアクティブなVPCピア接続125
VPCあたり(仮想プライベートゲートウェイ)のVPN接続数10

VPCの作成方法
  • AWSマネジメントコンソール
  • AWS CLI/SDK
  • AWS CloudFormation
  • サードパーティツール(ANSIBLE)

用語


参考

2017-04-20

列指向データベースのページのデータ構造

行指向データベースは行単位でページ(Oracle Database でいうデータブロック)にデータを格納しているのに対して、列指向データベースは列ごとにページに格納している。クエリ実行時に結果セットを返す際に列別にバラバラのページに格納されているデータをどうやってタプル(レコード)に復元している*1のかと思ったがやはり行IDのようなものを持っているようだ。

行ID は C-Store では pid、MonetDB では BAT(Binary Association Tables) の oid と呼ばれている。

The Design and Implementation of Modern Column-Oriented Database Systems

f:id:yohei-a:20170420230742p:image:w640

  • NSM(N-ary Storage Model): 行方向でブロック(ページ)にデータを格納する方式
  • DSM(Decomposition Storage Model): 列方向でブロック(ページ)にデータを格納する方式

f:id:yohei-a:20170420233150p:image:w360

C-Store の pid や MonetDB の oid のような ID 以外に Join Index という手法もある。

具体的な実装は C-Store のソースコードで調べることができる。


さらに詳しくは諸橋さんの以下のエントリで紹介されている

VLDB 2009 Tutorial on Column-Stores *1 が表示されたとき、笑ってしまい「わたしの教科書です、教科書」と言ってしまった appengine ja night #21 *2。

Google BigQueryなどの仕組みを知りたいときの列指向データベースの説明に - wmo6hash::blog

この大作スライド参照。


https://www.cs.duke.edu/courses/fall01/cps216/lectures/10-physical.pdf もシンプルで良い資料。

NSM = N-ary Storage Model

DSM = Decomposition Storage Model


補足

C-Store はあのマイケル・ストーンブレーカー教授が産んだ列指向データベースで、商業的にも成功している Vertica(HP社) のルーツです。

ストーンブレーカー教授と一緒にこの論文を書いている Daniel Abadi さんは上の VLDB 2009 Tutorial on Column-Stores を書いているうちの一人でもあり、分かりやすい資料を書かれているので要チェックです。


MonetDB については以下参照


あと、カバリングインデックス(インデックスオンリースキャン)と違うのは以下の点だと思います。

  • カバリングインデックスは複数列のデータがページに格納されるが、C-Store のような列指向データベースでは列ごとにページに格納され、クエリ実行時に行IDのようなものでタプル(レコード)に復元される。
  • 列指向に最適化している
    • 列指向に最適化した統計
    • クエリーオプティマイザ
    • データ構造
    • SIMD


f:id:yohei-a:20170508155026p:image:w640f:id:yohei-a:20170508155025p:image:w160

We argue that the poor performance of

MySQL and the commercial RDBMS

“X” is related to the Volcano iterator pipelining model [6]. While the Volcano approach is elegant and efficient for I/O bound queries, in computation-intensive tasks, its tuple-at-a-time execution makes runtime interpretation overhead dominate execution. That is, the time spent by the RDBMS on actual computations is dwarfed by the time spent interpreting

the expressions in a query tree, and looking up the needed attribute values in pages storing tuples in the N-ary storage model (NSM). As a result, quite a high number of CPU instructions are needed for each simple computational operation occurring in a query. Additionally, the instructions per cycle (IPC) efficiency achieved tends to be low, because the tuple-at-a-time model hides from the CPU most parallel execution opportunities, namely those provided by performing computations for different tuples in an overlapping fashion.

MonetDB [2], developed at CWI 1, is an alternative approach to building a query execution system. Its MIL algebra [3] minimizes the interpretation overhead by providing execution primitives that process data in a column-at-a-time fashion. Since MonetDB uses vertically decomposed storage model (DSM) [5], where columns are simple arrays, and each primitive performs only one fixed operation on the input data, the primitive implementation boils down to a sequential loop over aligned input arrays. Modern compilers can apply loop pipelining to such code, allowing MIL primitives to achieve high IPC on super-scalar CPUs. However, the column-at-a-time execution model introduces the extra cost of intermediate result materialization, which is only sustainable inside main memory, thus limiting the scalability of the system.

Figure 1 presents the architecture of X100, a new execution engine for MonetDB that combines the benefits of low-overhead column-wise query execution with the absence of intermediate result materialization in the Volcano iterator model. One of its distinguishing features is vectorized execution: instead of single tuples, entire vectors of values are passed through the pipeline. Another is in-cache processing: all the execution is happening within the CPU cache, using main memory only as a buffer for I/O and large intermediate data structures. These techniques make X100 execute efficiently on modern CPUs and allow it to achieve raw performance comparable to C code.


ビッグデータ分析のデータベース Netezza と Matrix は兄弟?! そして、Amazon Redshiftも???

Matrix』と『Netezza』の開発者はアメリカ人のBarry Zane (バリー・ゼイン) 氏。アメリカトップクラスのカーネギーメロン大学を卒業後、Prime Computer社へ入社。1983年にApplix社に移り、CTOに就任、13年間在籍しました。(Applix社は2007年にCognos社により買収。)

その後、2000年にNetezza社を立ち上げ、PostgeSQLをベースに開発したデータベースアプライアンス製品である『Netezza』を開発しました。『Netezza』は、「エンタープライズ向けDWHアプライアンスとは」を再考して開発され、革新的なアーキテクチャ、サーバー、データベース、ストレージをひとつのマシンに統合することで、大量データの分析を可能にしました。

Barry Zane氏: Netezzaを作り, ParAccel MPP (Matrix)を作り, 今はグラフ分析エンジンを手がける ビッグデータ分析向けデータベースのスーパーアーキテクト | Insight Technology, Inc.

  • Amazon Redshift and the Case for Simpler Data Warehouses

6. Related Work

While Amazon Redshift, when launched, was the first widely available data warehouse-as-a-service, its core database technology (parser, optimizer, engine, storage organization, MPP architecture) was derived from technology licensed from ParAccel. ParAccel belongs to a group of column-oriented DBMS products that appeared from the middle through the end of the 2000s: Vertica, Ingres VectorWise, Infobright, Kickfire, and many others [1]. These systems had several similarities in their design philosophy and list of features, with many of them influenced by two pioneering modern column-store systems: CStore [8] and MonetDB/X100 [3].

Redshift’s compression techniques are similar to those used by Vertica, and their performance tradeoffs are well understood [2]. Redshift foregoes traditional indexes (or projections in CStore/Vertica) and instead focuses on sequential scan speed through compiled code execution and column-block skipping based on value-ranges stored in memory. Infobright’s Knowledge Grid and Netezza’s Zone Maps also rely on block skipping which as a technique was first discussed in [5]. Code compilation techniques in query execution have received renewed attention in academia [6][9] and are also used in other systems such as Microsoft’s Hekaton [4].

http://dl.acm.org/ft_gateway.cfm?ftid=1586891&id=2742795

参考

*1:別々のページに格納されているカラムのデータを結合してレコード(タプル)に何をキーに復元するのか?