検索が爆速になるデータベース設計を公開します
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
フロントエンドパフォーマンスのチェックリスト2021年版（PDF、Apple Pages、MS Word）-前編 | POSTD
クイックサマリー：2021年のWebパフォーマンスを高速化しましょう。 毎年恒例のフロントエンドパフォーマンスのチェックリスト（PDF、Apple Pages、MS Wordに対応）は、指標やツールからフロントエンドのテクニックに至るまで、現代のWebで高速なユーザ体験を生み出すために知る必要があるすべてを提供します。 このチェックリストは2016年から更新を続けてきました。 メールのニュースレターでも、フロントエンドに関する便利な情報をご確認いただけます。 このガイドは、LogRocketに勤務する筆者の友人の厚意によるサポートを受けています。 LogRocketは、フロントエンドパフォーマンスのモニタリング、セッションリプレイ、製品分析を組み合わせ、顧客体験の向上に貢献するサービスです。 また、DOM完了時間、サーバ初期応答時間（TTFB）、初回入力までの遅延時間（FID）、クライアン
PHPとPythonとRubyの連想配列のデータ構造が同時期に同じ方針で性能改善されてた話 - hnwの日記
PHPとPythonとRubyの連想配列のデータ構造がそれぞれ4〜5年ほど前に見直され、ベンチマークテストによっては倍以上速くなったということがありました。具体的には以下のバージョンで実装の大変更がありました。 PHP 7.0.0 HashTable高速化 (2015/11) Python 3.6.0 dictobject高速化 (2016/12) Ruby 2.4.0 st_table高速化 (2016/12) これらのデータ構造はユーザーの利用する連想配列だけでなく言語のコアでも利用されているので、言語全体の性能改善に貢献しています1。 スクリプト言語3つが同時期に同じデータ構造の改善に取り組んだだけでも面白い現象ですが、さらに面白いことに各実装の方針は非常に似ています。独立に改善に取り組んだのに同じ結論に至ったとすれば興味深い偶然と言えるでしょう2。 本稿では3言語の連想配列の従来実
Big Sky :: golang でスライスの先頭に追加する append がなぜ遅いのか
Go - ISUCON5予選でスコア34000を出す方法 - Qiita Goで下記のようなsliceの先頭にひたすらオブジェクトを追加する処理を書く際は、不必要に長いsliceにならないよう注意しましょう。負荷が非常に高い処理になります。 hoge := []int{} for _, comment := range comments { hoge = append([]int{comment.ID}, hoge...) } http://qiita.com/y_matsuwitter/items/771020ebb68c07053548 append は第一引数のスライスに第二引数以降の可変個アイテムを追加する関数です。なるべく呼ばれない実装が良いです。どうしても多いアイテムを扱う場合は出来れば以下の様に書くのが良いです。 参考: https://blog.golang.org/sli
Go言語でのString・Int間の変換速度について - Qiita
※ 追記 reflectの使い方が間違っていたので訂正しました。切腹...m(__)m いくつか書き方があるようなので、簡単な比較をしてみました。 ベンチに使ったコードは下記にあります 文字列から数値（String to Int） 文字列から数値に変換する方法 strconv.Atoi(string) int, error // 引数は 変換対称の文字列, 基数, ビット数 strconv.ParseInt(string, int, int) int64, error // 小さな数値文字列で計測 (n = 35) BenchmarkAtoi 50000000 28.6 ns/op 0 B/op 0 allocs/op BenchmarkAtoiParseInt 50000000 27.0 ns/op 0 B/op 0 allocs/op // とても大きな数値文字列で計測 (n = 99
Go のスライスの内部実装 - Block Rockin’ Codes
History 14/05/09: Merge2 を修正しました。http://twitter.com/jbking/status/464659353945911297 Intro Go のスライスは、いわゆる LL 系の言語が持つ可変長配列の実装と似ています。 よって LL のような手軽な扱いをすることもできますが、その内部実装を知ることでより効率の良いメモリハンドリングができ、パフォーマンスを改善や、メモリーリークの防止などに繋がる可能性があります。 この辺は SWrap というライブラリを作りながら勉強したので、今回は、この Go のスライスの内部実装を解説します。 Go の配列 スライスを知るためには、まず配列について知っておく必要があります。 Go の配列は固定長のため、以下のように長さを指定して宣言します。 var arr [4]int func main() { arr =
Go 言語で標準入力から読み込む競技プログラミングのアレ --- 改訂第二版 - Qiita
大幅に加筆して改訂第二版としました 2015-01-11 まえがき Go が競技プログラミングに向いているかどうかの議論は別として． はじめに 競技プログラミングでは，標準入力からスペースまたは改行で区切られた大量の数値や文字列を読み込むことがよくあります(たとえば，AtCoder Begineer Contest #002 の入力 など)．C++ など競技プログラミングのメジャー言語の場合は，ノウハウが蓄積されていて，Google 先生に聞けばいくらでも教えてもらえるのですが（例），Go となるとそうはいきません．そもそも，例に挙げた AtCoder でも Go 使えないですし（初版 2014年6月14日現在; 2015年1月11日再確認）． そこで，godoc を見ながら使えそうなものを探してみました．想定としては C++ の cin >> とか Java の java.util.Sc
シェル芸処理速度向上のヒント - 日々之迷歩
先日のシェル芸勉強会ではWebサーバのログを扱った。ファイルサイズは約356MB、約350万行程度のそれなりに大きなテキストデータだった。このくらい大きなデータになると処理速度が気になってくるところ。 ではどんなところに気をつけるといいのか？下記の2点に注目して試してみることにした。 マルチコアの恩恵を受ける 一つのコマンドで頑張るより、パイプで刻んで複数のコマンドで処理した方が早くなる場合がある。何でもかんでも早くなるわけでは無い。パイプの流れが途中で止まら無いことが重要。 例えばsort処理は一度データを全てメモリに取り込む必要があるため、流れを止めてしまう。またパイプの最初で処理速度が遅いと、後ろのコマンドが手持ち無沙汰で遊んでしまうので遅くなる。 高速なコマンドで先にデータを絞り込む パイプの流れを途中で止めないためには、先に高速に処理できるコマンドを持ってくる。ここでは高速処理出
Swiftでパフォーマンスが向上したことについての私感 - Qiita
今年の6月のWWDCでSwiftが発表された時のアピールポイントの1つとしてパフォーマンス向上がありました。 とはいえ、Objective-Cはメッセージパッシング部分などで多少ボトルネックなどがあるとはいえそこそこ速いし、一般的なGCではなく参照カウンタ形式のメモリ管理なので定期的にもっさりするような挙動もほぼ起こらないので、元々そこをネックに感じていた人は少なかったのではないかと思います。 でも速いに越したことはないですし、実際どのくらい差があるのか気になりますよね。 Swiftの処理速度 いくつか見た中で、良い感じにまとまっているのはこれですかね(8月の記事なので現バージョンでは少し差があるかもですが)。 Apples to apples, Part II · Jesse Squires 以下、要点 + 意見です。 Swiftは、Optimization LevelをNone [-O
Python の新しいプロファイラ vmprof が面白い - methaneのブログ
PyPy 2.6 と同時に、 vmprof という CPython/PyPy 用のプロファイラが登場しました。 私はまだ PyPy では使っていませんが、CPythonのプロジェクトをこれでプロファイル取ってみたらなかなか面白かったので紹介します。 概要 Python にはもともと標準ライブラリとしてプロファイラ (cProfile) が付いてきていますが、これは関数の呼び出しと戻りでコールバック関数を呼び出しつつ実行時間を計測するタイプのプロファイラで、短時間でも正確なプロファイルが取れる反面、オーバーヘッドが大きく、小さい関数をたくさん呼び出す部分がオーバーヘッドでより大きく見えてしまうなどの問題がありました。 これと別の種類のプロファイラとして、定期的にサンプリングして、サンプルが多いところが実行時間も多いハズ、というプロファイラもあります。こちらはある程度の量のサンプルを集めないと
あなたのPythonを爆速にする７つの方法
最近プロコン（プログラミング・コンテスト）をはじめました。 基本的にはアルゴリズム勝負なのですが、とにかく速度を競うプロコンです。 小手先の速度チューニングもバカにできません。 何が速くて何が遅いのかはっきりさせるため、ボトルネックになりそうな操作のベンチマークを取りました。 実行環境は下記のとおりです。 python2.7.5 OS: MacOSX 11 CPU: Core i7 2GHz (4core) MEM: 16GB その1. 配列の初期化を高速化する まずはプロコンの基本中の基本、配列の初期化です。 下記７つの初期化方法を比較してみます。 空配列へappendして配列をつくる for内包表記で配列をつくる サイズ1(None)の配列を乗算してから値を代入する サイズ1(None)の配列を乗算する サイズ1(ゼロ)の配列を乗算する すべてゼロのarrayをつくる 0〜nのarra
Ruby の高速化の道。 - だいありー
pwd が何の略か？ ということを聞かれた。確かに答えられない。 http://www.abbreviations.com/pwd の中で working directory を含むものをピックアップすると、 Print Working Directory Present Working Directory Path of Working Directory の３説が見つかる。 man を見ても、あんまりしっくりこない。なんで cwd （current working directory）にしなかったんだろう？ system call は getcwd(2) なのに。 昨日の続き。 早速中田さんが r49614 を入れてくれて、こういう a, b = x, y の時には、 push x # stack: x push y # stack: x y newarray 2 # stack: [
プログラムを高速化する話
KMCの例会講座で用いたスライドを一部編集したものです。 ビット演算を組み合わせたトリッキーな方法で様々な操作を高速に行う方法を紹介します。
Goサーバのモニタリング - Qiita
5日目担当の@cubicdaiyaです。先月末のGoConではGoのカンファレンスなのにほぼnginxをビルドする話しかしてなかったので今日はちゃんとGoの話をします。 Goで書くサーバプログラム Goではサーバプログラムを書くためのユーティリティが豊富に揃ってる上に、ゴルーチンやチャネルを利用することで高いパフォーマンスが要求される環境でも十分な性能を発揮することができます。いつだったか「あれはHTTPサーバ書くための言語ですよ」なんて話をとあるエンジニアから聞いたことがあるくらいです。 例えば「Hello, World!」を返すだけのHTTPサーバであれば標準ライブラリのnet/httpを利用することで以下のように書くことが出来ます。 package main import ( "fmt" "net/http" ) func handler(w http.ResponseWriter,
海の向こうにあるZabbixサーバの表示をWebサーバのチューニングだけで高速化する - Qiita
海外で展開しているサービスがある関係上各サーバの監視に利用しているZabbixサーバも海外にあるのですが、ほとんどチューニングされておらず、ZabbixのWebUIの画面をロードするのが遅くて遅くてしょうがないので頑張ってチューニングしてみた時の話です。 また、チューニング前後でダッシュボードのロードにかかった時間を計測してみました。 準備 まず、Google ChromeのDeveloper Toolsでキャッシュを無効にします。 チューニング前の状態 ZabbixはよくあるApache+mod_phpによる構成です。この状態でZabbixのダッシュボード(dashboard.php)にHTTPSでアクセスするとブラウザ左下のステータスバーにページのロードにかかった時間が表示されます。 2.7秒かかっています。すごく遅いです。体感でわかるくらい遅いです。 Zabbixが定期的にポーリング
とあるサイトの高速化についてフロントエンドでやったことまとめ。 - Toro_Unit
業務で携わっている案件なのですが、アクセス数の急増が見込まれるイベントがありまして。準備期間も少なく、バックエンド側でできることがほぼないという状況でサイトを落とさないようにがんばる！というお仕事でした。レガシーソースてんこ盛り。CSSプリプロセッサとか何それ状態。 そこで実施した対策のまとめです。サーバー・アプリケーション・サイトの構成によって、効果の大小はありますが、比較的効果があったと思われるものをつらつらと。 リクエストの削減とファイルサイズの最適化 まず一番最初に考えなければいけないのがリクエスト数です。すごいおおざっぱに言うと、WEBサーバー（ApacheとかNginxとか）への負荷は、PV数×リクエスト数です。PVがそんなに無くてもそのページのリクエストがめちゃくちゃ多いとそれだけでかなりの負荷になります。リクエストを半分にできれば2倍の人数がさばけるってことに、すげーおおざ
Collection Data Types In Swift: Detailed Test Results ← Designated Nerd
I wrote a piece for RayWenderlich.com about Collection Data Structures in Swift, and I did a whole lot of performance testing around it that didn’t have room to make it into that piece. I’m going to be going into waaaaay more detail and burying you in charts in this blog post if you want to dive deeper. The short version is included in that piece: Creating collection data structures in Swift is a
Core Data パフォーマンスチューニング
Core Data (store type は、SQLite) のパフォーマンスチューニングについての覚書。 改善したいのは検索速度。インデックスを使っているつもりが、本当にインデックスが効いているか？ということを如何に調べるかがポイント。 まず、遅い部分のクエリが実際はどのようなSQL文かを調べる。 具体的には次のようにする。 Xcode プロジェクトの実行可能ファイルの該当ファイルをダブルクリックする。"引数"ダブの、"起動時に渡される引数"に、"-com.apple.CoreData.SQLDebug 1" と書く(Core Data Programming Guide: Core Data Performance 参照)。すると、コンソールにSQL 文が出力されるようになる。SQL 文中の、'?' はプレースホルダーで、実際は、何かの値が入る。 ここでは、調べたSQL 文をコピーし
A-Liaison BLOG: Core Data のパフォーマンスをちょっとだけ調べてみた
ちょっと仕事で触ってみて分かった範囲のことを書きます。断りがない限り、 iPhone 3GS で Wifi 接続環境下においてテストしました。 ■キャッシュ無し vs キャッシュ有り executeFetchRequest:error: メソッドを用いて、 Entityのプロパティで一件だけ絞り込んで返すようなクエリは大変遅いということが分かりました。Indexを付けて実行してもほとんど速くなりません。どうやらそもそもバックエンドに使っているSqliteが大変遅い、特にコネクションを生成したり破棄したりするのが遅い感じがするので、ループで一件ずつ取得するなどのときはたくさんのSQLが実行されないようにする必要があります。 objectWithID: メソッドは試していないのでちょっと不明です。 回避策として、アプリが起動したタイミングで当該エンティティの全オブジェクトをあらかじめ取ってきて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Collection Data Structures in Swift