IEE-MySQLがインポート/エクスポートするファイルの形式はinfobright.cnfファイルのBH_DATAFORMATパラメーターで指定する事ができ、このパラメーターに指定する値により使用するローダーも変わります。

BH_DATAFORMATパラメーターには以下のいずれかの値を指定します。

・txt_variable 
・binary
・infobright
・mysql

txt_variableはテキスト形式のデータのインポート/エクスポートを行い、ロードにはInfobrightローダーが使用されます。

binaryはバイナリ形式のデータのインポート/エクスポートを行い、ロードにはInfobrightローダーが使用されます。

infobrightはDLPが生成する圧縮形式のデータのインポートを行い、ロードにはInfobrightローダーが使用されます。

mysqlは一般的なMySQLの形式のデータのインポート/エクスポートを行い、ロードにはMySQLローダーが使用されます。

txt_variableまたはbinaryを指定するとinfobrightエンジンが利用される為、より効果的にエクスポートを行う事ができます。MySQLを指定するとエクスポートにはMySQLエンジンが使用されます。

★Have a nice open source day★
KSK Analytics Infobright Team

IEEのバックアップとリストア

|
IEEのバックアップとリストアにはコマンドラインの操作は必要なく、ディレクトリの差し替えだけで行う事ができます。

バックアップの取得
1. IEEを停止します。
2. /Infobright/dataディレクトリをコピーし、安全な場所に保存します。
3. ナレッジグリッド(デフォルトでは/Infobright/data/BH_RSI_Repository)をコピーし、安全な場所に保存します。

バックアップのリストア
1. IEEを停止します。
2. 既存の/Infobright/dataディレクトリとバックアップで取得したdataディレクトリを差し替えます。
3. ナレッジグリッドの場所がデフォルトとは異なる場合はナレッジグリッドのディレクトリを差し替えます。
4. IEEを起動します。

dataディレクトリ内にはデータベースごとにディレクトリが存在しますが、ナレッジグリッドがどのデータがどのディレクトリに格納されているかという情報を管理しているので、バックアップを取得する際には必ずdataディレクトリ全体のコピーを取得するようにしてください。

また、手動でのデータベースディレクトリの編集はデータ破損の原因となるのでおやめください。

★Have a nice open source day★
KSK Analytics Infobright Team
先日Infobright社よりIEE 4.8.0がリリースされました。

IEE 4.8.0にはメモリ管理や関数の扱いなどの内部処理に対する改修が多く
含まれますが、目に見える大きな変更点としては以下の3点が挙げられます。

- Infobrightライセンス
これまで、IEEを利用するのにライセンスファイルは必要ありませんでしたが、
4.8.0からは契約時にInfobright社から提供されるライセンスファイルを登録
しないとご利用頂けなくなりました。

- ファイル、パラメーター、エンジンの名称
IEEが利用する多くのファイル名、パラメーター名、それらの設定箇所が変更されました。
また、これまでIEEは「brighthouse」という独自のエンジンを使用していましたが、
この名称は4.8.0より「infobright」へと変更されました。

- ログの強化
以前のバージョンでは、ログはbrighthouse.logとbh.errに出力されていましたが、
4.8.0からこれらのログはローテーション機能を持った「infobright.log」に出力
されるようになりました。
また、パフォーマンスの調査に有効なFET(Function Execution Time)ログも追加されました。

これらの変更に関する詳細はInfobright社から提供されているUser GuideとRelease Noteに
記載されています。弊社からもIEE 4.8.0の体験版と共に日本語化した各ドキュメントを
ご提供しておりますので、よろしければこちらからお申込みください。

★Have a nice open source day★
KSK Analytics Infobright Team

テーブルの変換方法

|
他のデータベースのデータをIEEへ移行する際には、IEEに新たにテーブルを作成する必要がありますが、旧データベースで使用していたデータ型がIEEでも利用できるとは限りません。
今回は代表的な3つのデータベースを例に、他のDBのDDLをIEEで利用可能なDDLへ変更する方法を紹介します。

OracleからInfobrightへ変換:

・ MEDIUMTEXTをVARCHAR (N)へ変換。'N'には必要なサイズを入力。
・ LONGTEXTをVARCHAR (N)へ変換。'N'には必要なサイズを入力。
・ DOUBLE(A,B)をDECIMAL(A,B)へ変換。
・ INTEGERをBIGINTへ変換。
・ VARCHAR2/CHAR2をVARCHAR/CHARへ変換。


SQL ServerからInfobrightへ変換:

・ MEDIUMTEXTをVARCHAR (N)へ変換。'N'には必要なサイズを入力。
・ LONGTEXTをVARCHAR (N)へ変換。'N'には必要なサイズを入力。
・ DOUBLE(A,B)をDECIMAL(A,B)へ変換。
・ MONEYをDECIMAL(18,4)へ変換。
・ SMALLMONEYをDECIMAL(6,4)へ変換。
・ INTEGERをBIGINTへ変換。
・ NCHAR/NVARCHARをCHAR/VARCHARへ変換。
・ NUMBERをINTEGERへ変換。
・ NUMBER(A,B)をDECIMAL(A,B)へ変換。


MySQL (MyISAM)からInfobrightへ変換:

・ MEDIUMTEXTをVARCHAR (N)へ変換。'N'には必要なサイズを入力。
・ LONGTEXTをVARCHAR (N)へ変換。'N'には必要なサイズを入力。
・ DOUBLE(A,B)をDECIMAL(A,B)へ変換。


★Have a nice open source day★
KSK Analytics Infobright Team
InfobrightエンタープライズエディションではCHARカラム、VARCHARカラムに対してlookupという修飾子を設定する事ができ、lookupカラムを定義する事でカラムの圧縮率、クエリパフォーマンスが向上します。

lookupカラムは値を整数に置き換えて圧縮せずにメモリで保持するので、多くのユニークな値を保持するカラムにlookupを設定すると大量にRAMを消費してしまいます。(ユニークレコード全件をRAMにロードするので、例えば100万件の100文字のユニークなレコードは100MBのRAMを消費します。)

lookupは以下のようなカラムに設定する事が推奨されています。:

・ カラムのユニークな値は10,000件以下

・ 重複した値とユニークな値の行数の比率が10:1以上のカラム (以下の2つのクエリの結果を比較)

   - SELECT COUNT(<COLUMN>) FROM...  
   - SELECT COUNT (DISTINCT <COLUMN>) FROM...

・ よく使用するカラム(使用頻度の低いカラムに設定しても無駄にRAMを消費するだけ)

カラムにlookupを設定するには以下のようにcommentに'lookup'を追加します。

   mysql> create table ...
   (...
   <<column name>> <<column type>> ... comment 'lookup' ...
   ...)
   engine=brighthouse;

まとめると、メモリを十分確保できる環境では、使用頻度が高く、ユニークな値が10,000件以下、
重複とユニークレコードの比率が10:1以上のCHAR, VARCHARカラムに対するlookupの設定が
パフォーマンスの向上に有効だと言えます。

★Have a nice open source day★
KSK Analytics Infobright Team
今日は冬に戻ったかのような寒い雨の朝ですが、とても暖かかった一昨日4月6日(月)にInfobright無料体験ハンズオンセミナーを実施しました。

Infobrightのインストール、DB作成、データロード、検索を実際のオペレーションを行って体験頂きますが、質問時間にはここでは書けないいろいろなお話しをさせて頂くことができますので対面のよさを感じます。
040.png
参加者様のコメントをご紹介します。
"InfoBrightの長所、利点をお聞き出来て大変参考になりました。また講義だけでなく、ハンズオンで実際に触れてみることによりイメージが湧きやすく、大変良かったと思います。"

次回開催は決まり次第掲載しますが待ちきれない方は個別対応のご相談も承りますので、こちらからお問い合わせ下さい。

★Have a nice seminar day★
KSK Analytics Infobright Team
Infobright Community Edition(ICE)は無償でダウンロードし無期限で利用できるInfobrightです。
弊社にお問い合わせを頂き、ご訪問すると既に本番業務で使われているお客様も時々いらっしゃいます。
infobright.org-logo.jpg
データが1/10-1/50程度に圧縮され、高速レスポンスが得られることに満足されているようです。

ただ、やはりいざという時はサポートが必要になり、弊社にお問い合わせを頂くようになります。

残念ながらICEのサポートは弊社ではお受けできませんが、IEE(Infobright Enterprise Edition)への移行はスムースです。

ただ一度無償版を入れてしまうと、社内で追加コストの稟議を通すことが困難になるケースもあるかと思いますので、初めからIEEをご利用頂くことをお奨めします。
IEEの体験版もご利用頂けますので、こちらのフォームからご依頼下さい。

ICEとIEEの機能の違いはこちらに記述があります。

★Have a nice big data solution★
KSK Analytics Infobright Team

================================================================
株式会社KSKアナリティクス
Infobrightに接続するクライアント(BIツールや検索ツール、ユーザーアプリケーションなど)がどんなSQLを投げてきたかを確認する方法をご紹介します。

Infobrightをインストールしたフォルダ(ディレクトリ)にある my-ib.iniにある以下のオプションを有効にし、サーバーを再起動することで指定したファイルにSQLが書き込まれます。
#general_log=1
#general_log_file=/infobright_query.log

#がついているとコメント扱いになりますので、#を削除してファイル名を記述します。
Windows環境の場合は C:/infobright_query.logのように記述します。

ログファイルの内容は以下のようになります。
showquery.jpg

たとえばエンドユーザー(システム利用者、業務ユーザー)からレスポンスが悪いという問い合わせがあった場合、DB管理者はこのスイッチをオンにしてサーバーサイドで同じSQLを実行し原因がDBサーバーなのかネットワークかクライアント側の問題なのかを切り分けることが可能となります。

設定を有効にするには、Infobrightの再起動が必要です。
また、テストが終わったら忘れずに元にもどしましょう。

ご参考になれば幸いです。
★Have a nice research process★
KSK Analytics Infobright Team
Infobright Enterprise Edition 4.7.1がリリースされました。

今回のリリースには以下のような修正と改良が含まれます。

  • パフォーマンスの向上: ジョインやソートにおける並列処理の割合の増加、より効率的なアルゴリズム、異なる方法で構築されたクエリー間の一貫性を向上、クエリーの同時実行の改良
  • メモリー管理の改良: メモリーの利用効率を向上、メモリーリークに対処、処理に必要なメモリー容量の削減。
  • クエリー精度、構文、ファンクション: クエリーが誤った結果を返す問題を解決、IEE の結果フォーマットと MySQL/Postgre の結果フォーマットの一貫性の向上、IEE でサポートされるクエリー/関数の増加。(処理がネイティブエンジン(MySQL や Postgres)に切り替わる頻度が少なくなります)
  • インポート/エクスポート、DLP: DLP のインポートにおけるエラーや誤ったファイルが作成される問題を解決、テーブルスキーマの変更を管理する方法を改良
  • 異常終了に対処: 異常終了を引き起こす可能性のあるコーナーケースを修正
  • インストールと設定: インストール、設定における改良

また、これまでのIEEはMySQLベース(IEE MySQL Edition)のみのリリースでしたが、PostgreSQLベース(IEE Postgres Edition)が追加され、PostgreSQLユーザーにもご利用頂き易い製品となっています。
現バージョンのIEE Postgres Editionはバージョンアップに対応していない為、実用的ではないかもしれませんが、今後のリリースではバージョンアップにも対応予定なので、IEE Postgres Editionの使用をお考えの方は4.7.1でご評価頂き、バージョンアップ対応後に実際の運用にご使用頂くのが良いかもしれません。

★Have a nice open source day★
KSK Analytics Infobright Team

ビックデータ分析において、列指向DBエンジンとナレッジグリッドを持つInfobrightエンタープライズ版(IEE)は大変有効に機能します。IEEの性能は他のカラム型製品と同様に標準的な行指向のDBと比較して圧倒的です。
programming-code-data.png

MySQL,Oracle,SQLServer等のような従来のデータベース技術を利用する場合、データベース管理者と設計者が最適なDBモデルを定義するために協業します。
これらのソリューションでは多くの場合スタースキーマ又はスノーフレークスキーマを適応するでしょう。この構造により冗長性の削減ができ、参照整合性と最適なキー設定を意識しつつパフォーマンスの最適化を図れます。従来型DBではこれらの設計が安定的基盤として最適ですが、IEEの場合、多少異なる場合があります。

IEEでは、よりフラットな設計が最適となる場合が多くの事例で見受けられます。
IEEが持つ圧縮性能やデータの冗長性と列の増加がディスク容量に影響を与えにくい特性を考慮すると、よりフラットなDB設計にしても他のDB製品に比較して大幅に少ない総物理ストレージ容量で収まるからです。
またIEEのナレッジグリッドアーキテクチャによって、すべてのカラム(列)が多くのクエリに最適化されたインメモリ構造に配置されます。

行ベースのDB製品または他の列ベースのDB製品からIEEへの移行を検討されている場合、以下の3つのよくある質問をご確認下さい。

1)データはSQLのupdate文で更新されますか?
  分析系システムの場合、多くの場合、静かに変化する次元
  (SCD:Slowly Changing Dimensions)にたいする考慮が必要です。
  例えば顧客の引っ越しにともなう地域の変更などです。これらへの配慮が必要な場合はファクトテーブルにすべてを集めるのでなく、ディメンジョンテーブルを持つ設計となります。
2)スタースキーマを推奨するキューブやBIツールを利用予定ですか?
  ある種のBIツールはスタースキーマを必須要件としています。
  Pentahoのようなツールでは設定によりよりフラットな設計でもキューブやアドホックな検索の実装が可能になっており、IEEの設計が柔軟になります。
3)データの特性として1つの行にすべての項目を入れることができますか?
  MySQLをベースとするInfobrightの場合、各行の最大は64kバイトです。
  多くの場合問題ありませんが、フラット化する場合に念頭に入れて下さい。


ファクトテーブルと2つのディメンジョンテーブルの例

 Database.fact_skinny (  Date datetime,  Id int,  Browser varchar(30),  Customer_id int,  Response varchar(10)  ) ENGINE=BRIGHTHOUSE   Database.dim_date (  Date datetime,  DayOfWeek int,  DayOfMonth int,  DayOfYear int,  HourOfDay int,  MinOfHour int,  SecOfMin int  ) ENGINE=BRIGHTHOUSE   Database.dim_customers (  Customer_ID int,  Fname varchar(20),  Lname varchar(20),  Address varchar(30),  SSN int  ) ENGINE=BRIGHTHOUSE  
T

フラット化する例:
このモデルではdim_dateの更新はないことが前提です。
(データロード後はupdate文は使用しない。dim_customersも同様です)

 Database.fact_wide (  Date datetime,  Id int,  Browser varchar(30),  Customer_id int,  Response varchar(10),  DayOfWeek int,  DayOfMonth int,  DayOfYear int,  HourOfDay int,  MinOfHour int,  SecOfMin int,  SSN int  ) ENGINE=BRIGHTHOUSE   Database.dim_customers (  Customer_ID int,  Fname varchar(20),  Lname varchar(20),  Address varchar(30)  ) ENGINE=BRIGHTHOUSE

フラット化した構造のメリットはパフォーマンスの大幅向上です。
BIツールや検索系フロントシステムがDB構造に柔軟であれば、ぜひ比較検討下さい。