データベース処理の高速化を図る。-Select編-

こんにちわ！
Inagora株式会社バックエンドエンジニアの福田です。

前回はデータベースのInsertの高速化について、書かせてもらったのですが、今回はデータの取得についての高速化について書いていきます。

Objective-Cでのアクセス制御

初めまして。Inagoraの平田です。

C言語や他の言語はたっぷり経験しているのですが、Objective-C歴は1週間です。
Objective-Cでのアクセス制御についてカルチャーショックを受けたので記事にしたいと思います。

大抵のオブジェクト指向言語はメソッド、インスタンス変数(≒プロパティ)に対して以下のアクセス制御を明示的に行うことができ、そのための宣言構文を持っています。

private	インスタンス外からはアクセス不可。クラス内からのみアクセス可能
protected	インスタンス外からはアクセス不可。クラス内、その子クラス内からのみアクセス可能
public	インスタンス外からアクセス可能

しかし、Objective-Cではそのような明示的な宣言がありません。
その代わりにヘッダファイルに記述する、しないで外部に公開するかどうかを決めます。
ヘッダファイル(*.h)に記述するのはpublic,ソースファイル(*.m)にのみ記述するのはprivateという感じです。簡単ですね。

Example.h

@interface Example:NSObject
@property boolean_t public_variable; //publicなプロパティ
- (void)public_method;               //publicなメソッド
@end

Example.m

#import "Example.h"

@implement

- (void)public_method {
  self.public_variable = true;
}

- (void)private_method {
  // privateなメソッド
}

@end

メソッドについては以上を理解していれば良いのですが、プロパティについてはもう一工夫が必要です。
プロパティを宣言するための@propertyは@interfaceの中にのみ記述でき、ソースファイルに記述される@implementの中には記述できないためです。
privateなプロパティを定義するためにはクラス拡張という機能を使います。
クラス拡張とは通常の@interfaceで宣言を記述したあとで、更に宣言を付け足す機能です。記述方法は"@implement クラス名()"と書きます。
これを用いて以下のようにソースファイル内で宣言を付け足すことでprivateなプロパティとすることができます。

Example.m

#import "Example.h"
    
@interface Example()

@property boolean_t private_variable; //プライベートなプロパティ

@end
    
@implement

- (void)public_method {
  self.public_variable = true;
  self.private_variable = true; // ヘッダファイルに書かれていないためこのソース外からは見えない。
}

@end

実はメソッドも同じように記述できるのですが、宣言なくても警告さえ出ないので私はやってません。

またprotected用のヘッダファイルを一つ追加し、それを自クラス、子クラスのソースファイルからのみインクルードする規約とすればprotectedも実現可能です。

MongoDBを利用する際の注意点

弊社では色々なDBを利用していますが、Mysqlの代替的にMongoDBを利用しています。利用していて不便な点がいくつかありますので、それをまとめてみました。

スキーマレスのため、ゴミのようなデータが入ってしまう

NOSQLなので当然なのですが、どんなデータでも書き込めてしまうというのがドキュメント志向DBの一番の特徴です。ここを許容できれば問題無いのですが、ゴミデータを許容できるシステムというのもそんなに無いと思うので、悩みどころになる点です。

AWSでMongoDBの専用サービスが無い

専用サービスが無いため必然的にEC2を利用することになり、Iaasの環境の場合はネックになります。AWS以外のIaasにもMongoの専用サービスというのは無さそうです。

基本的に3台でクラスタを組むため、台数が増える

Mongoの場合マスター＋スレーブ2台かマスター＋スレーブ＋コントローラの構成が基本になりますので、コストが増えます。

良さそうなGUIクライアントが無い

SequelProのようなサーバ側にインストール不要なGUIクライアントが無いため、基本的にコマンドラインの操作をするしかないケースが多いかと思います。MongoのGUIツールもあることはあるのですが、サーバ側にインストールしてWEBサーバを立ち上げてブラウザでアクセスするもの(phpMyAdminのようなもの)しかなく、ただでさえSQL文が使えないのに余計に不便です。

MongoDBは利用するメリットもかなり多いですが、根本的にRDBとは違うDBですので、そこを踏まえて利用するのがキーになります。

 

Google Analyticsのページ解析が機能しなかった件

こんにちは！ サーバーサイド担当の井上です！

私達のチームでは業務中はslackで情報共有していますが、緊急時の連絡はLineで来ます。 サーバー側の人間としてはLineで会社のメンバーから連絡が来ると、また何か起こったかと緊張が走ります。 今回は表題の件を解決して無事リリースしたと思ったら帰宅途中にチームのグループにLineの連絡が来たお話。。。

エンジニアさんだって怖くない! Sketch3を使ってみよう②

 こんにちは！！！！！うおおっ！

期間が空きすぎて全然違う内容を書こうとしていた

デザイナーの吉田ことヨッシーです。

今回は「エンジニアさんだって怖くない!　Sketch3を使ってみよう②」ということで、

テンプレートを使って実際にUIをつくってみましょう。

ーーーー前回の記事はこちらーーーー

エンジニアさんだって怖くない! Sketch3を使ってみよう① - Inagora Tech. Blog

ーーーーーーーーーーーーーーーーー

今日の目標は、弊社アプリ

WONDERFULL

の「設定」画面です。

 こんな感じ

 ではやっていきましょう！

①さてアートボードをおいたら、、

②テンプレートを開きます。

File　＞　New From Template  ＞　iOS UI Design をクリック

　

 ばばーーーーーん

とこんな感じにUIのパーツがはじめから入っています。

さらに、自分でテンプレートを作成して定義しておけば

いつでもパーツを引き出すこともできます。

やっべ　便利

また、テンプレートとして登録したパーツは

編集すると複製したパーツにもすべて

編集した内容が適用されちゃいます。

ではでは必要なパーツをコピーして

もとのアートボードに貼り付けましょう！！

5秒くらいでリストが完成しました！（コピペだけだし）

右端の矢印も素材を探したり、制作したりする手間も省けて

とても便利です。

次回は配置したパーツを編集したり、

独自のパーツをテンプレート化してもっと便利にしていきましょう！

あでゅー！

データベース処理の高速化を図る。-Insert編-

皆さん、お久しぶりです。

サーバーサイドエンジニアの福田です。

前回のブログは第一回のマーケティング、ファンネルに関して書かせて頂いたので、今回は技術的なお話を書きたいと思います。

さて、弊社の運用するサービス、WonderfullはECアプリであり、アプリ内で商品の購入を行うことが出来ます。

こちらのサービスの根底となるのがECオープンプラットフォームであるEC-CUBEであり、弊社Wonderfullアプリもサーバー側はEC-CUBEを用いて開発がされています。

縁の下の力持ちであるEC-CUBEですが、ECサービスを提供する為、非常にデータベースとの関連性が深いです。

アプリ上で掲載する商品情報の管理。受注情報の管理。各サプライヤーさんの情報管理。商品はカテゴリー分けされてるからカテゴリーの管理。。。などなど、多くデータの管理を必要とする為、データベースの扱い一つ変えるだけでサービスの向上、または低下などを招いてしまうことになります。

普段は気づきにくいですが、よくお聞きするAmazonや楽天、Wonderfullのサービスのように、皆さんの生活の中でもデータベースが深く根付いております。

今回、データベースを扱う上で一番処理が重いとされる、Insert処理。データを追加する処理を高速化するにはどうしたらよいか考えてみましょう。

まず、Insertの処理方式を次の3つで考えてみましょう。

①1件ずつのInsert

②1回の発行で複数行のデータをインサート（マルチプルインサート）

③バルクロード（大量のデータを一括ロード）

各インサート処理に関して、例として、「データ長約200bytes、100万件（約200Mbytes）のデータ」を投入した場合の比較を行っていきましょう。

インサート処理	1インサートの行数	MySQL 5.0.79(Innodb)
1件ずつのInsert ※	-	25459（単位：秒）
マルチプルインサート	1000行	78.86
バルクロード	-	31.99

※ 遅すぎたので1000件分を計測し×1000で算出

上記の結果のようにインサートの形式により、処理にかかる時間が大幅に変わっていきます。

今回の結果は100万件という非常に膨大なデータを扱っていますが、インサート処理の方法一つとっても、処理能力に差があるため、その場その場で適した方法を選択する必要があります。

参考：インサート（insert）の処理方式別のパフォーマンスを検証 | 株式会社インターオフィス

エンタープライズJavaについて

皆様はじめまして。

サーバーエンジニアのウィリアムです。数年前まではエンタープライズJava開発に従事していましたが、最近私たちWONDERFULLのサーバーサイドはPHPで開発していますので、エンタープライズJava開発について復習したいと思います。

あのStrutsはどうなってますか？

　エンタープライズJava開発に従事している方であれば、一度はStruts を扱ったことがあるでしょう。筆者自身が業界に入ったのは2004年のこと。最初に参加したプロジェクトがStruts 1を使った企業システムの構築だったことをよく覚えています。

　当時にStruts 1で作られたシステムの多くは、今でも現役で稼働しています。しかし、2013年にサポート終了を迎えたため、今後Struts 1を使い続けることは大きなリスクになりますね。

　なお、Struts 1からの移行先として、ApacheではStruts 2を勧めています。しかし、以下の点から他のフレームワークに比べてStruts 2を採用するメリットが少ないと判断しました。

・Struts 1とStruts 2の間にソースコードの互換性はないこと
・Struts 2にも重大な脆弱性が何度か発見されていること

では、Struts 1終了後。新規のエンタープライズJava開発、どうしてますか？

大成功を収めた Spring

　Spring FrameworkはJava製のOSSフレームワークです。軽量かつ開発のしやすさから人気を得ています。特徴は、DIとAOP（アスペクト指向）を中核とした豊富な機能です。ドキュメントも豊富で、多数の採用実績があり、Javaに関するもので最も成功しているオープンソースプロジェクトと言ってよいでしょう。

Springのアーキテクチャは以下のようなイメージです。

　View層では、「Thymeleaf」というテンプレートライブラリで作ったHTMLを使用します。Viewの入力値は、Controller層のコントローラーで受け取ります。入力値にはフォームの他、JSONやXMLも使用できます。コントローラーは、Model層のサービスを呼び出し、その結果に応じてViewとデータを設定します。Viewの代わりにJSONやXMLなど任意のデータを出力することも可能です。

　Model層内のサービスは、Java EEのサービスと同じ役割を担っており、トランザクションの起点として機能します。リポジトリは、Spring Data JPAが提供するデータ操作用のオブジェクトです。リポジトリとエンティティを使用してデータベースを永続化します。

　各オブジェクトの生成や依存性注入、トランザクション制御は、SpringのDI機能が実現します。

「Dependency Injection（DI）」を直訳すると「依存性の注入」となります。まずは「DIとは何か」というところから理解するために、この言葉を詳しく説明していきます。

　DIという言葉のうち「Dependency（依存性）」という単語は、「オブジェクトが成立するために必要な要件」という意味を持っています。この要件とは、オブジェクトの持つ属性や関連するオブジェクトなどです。

　次の単語である「注入（Injection）」とは「外部からの設定（Configuration）」を意味しています。設定ファイルやWebアプリケーションのデプロイメントディスクリプタ（web.xmlなど）での設定を「注入」と呼んでいるのです。

　これらのことから「DI」という言葉を言い表すと「オブジェクトの成立要件に必要な情報を外部設定すること」となります。情報を外部に切り出すことで、たとえオブジェクトを利用する状況が変わったとしても、設定を変更するだけでそのオブジェクトを利用することができるようになります。つまり再利用性の高い「部品」としてオブジェクトを実装しやすくなるのです。このような再利用性の高いソフトウェア部品のことを「コンポーネント」と呼びます。

　DIでは、「設定を利用から分離する（the principle of separating configuration from use）」という考え方をコンポーネント設計のための1つの原則としています。コンポーネントの集合としてプログラムを設計することは「再利用」というメリットだけではなくソフトウェア開発に対してさまざまな恩恵を与えます。

　DIの主目的の1つはアプリケーションのコンポーネント化を促進することです。アプリケーションをコンポーネント化することで以下のようなメリットが得られます。

・コンポーネント単位で機能を強化・改訂することができる
・バグや故障を局所化できる
・ベンダ提供のコンポーネント等と付け替えることができる
・テストが容易になる

　DIは、オブジェクトを構成するために必要なほかのオブジェクトとの関係を外部設定に分離することで、アプリケーションをコンポーネントの集合として組み立てるためのデザインパターンです。そして、DIフレームワークを利用することで容易にアプリケーションのコンポーネント化を促進することができ、コンポーネント化によって開発中や開発後の仕様変更やデバッグにも強いアーキテクチャを構築することができます。

　Spring以外にも、Play Frameworkなど軽量のフレームワークがありますが、Spring Frameworkは、現在Javaのオープンソースソフトウエアの中で最も普及したプロダクト群であるため、しっかりと覚えてみてはいかがでしょうか。