検索が爆速になるデータベース設計を公開します
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
CPUの脆弱性、Linux関係者らの見方や対応
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 編集部 2018-01-05 14:57 Linuxは、プロセッサの脆弱性「Meltdown」「Spectre」の影響を緩和することはできるものの、Linux開発者たちがこの一件について不満を抱いていないわけではないだろう。Linuxカーネルの生みの親であるLinus Torvalds氏もLinuxカーネルのメーリングリスト（LKML）で以下のように述べている。 私は、Intel社内の人物が時間をかけて、自社CPUを厳しい目で精査する必要があると考えている。そして、すべてが設計通りに動作しているといった広報用の文章を作文するのではなく、問題があるという事実を実際に認める必要があるとも考えている。..またこのことは、問題を軽減するためのこれらパッチが「すべてのCPUがガラクタというわ
Rails: PostgreSQLのマイグレーション速度を改善する（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Better Database Migrations in Postgres 公開日: 2017/09/10 著者: Craig Kerstiens サイト: http://www.craigkerstiens.com/ データベースが成長してスケールするに連れ、気を遣わなければならない点が当初とは変わってきます。アプリをdev環境で動かしているうちは気にもかけていなかった操作コストを、production環境でがっつりと支払うはめになったりします。私たちの多くがやらかしてしまうのが、たとえばマイグレーションです。production環境でマイグレーションの起動に5分、それから15分間動き続けたまではよかったのですが、突然トラフィックに問題が生じたりします。 こういう事態を引き起こしがちな操作は2つありますが、どちらについてもダウ
Advanced Postgres Performance Tips
You’ve added the INDEXes, both partial and covering. You’ve VACCUUM ANALYZEd. You JOINed and INNER JOINed everything to a single query. And yet, your report is still taking too long. What do you do when the low-hanging fruit has been harvested? It’s time to get down and dirty with some of the lesser known SQL constructs in Rails land. EXPLAIN what’s happening If you’ve gotten this far, you’re prob
目的別ガイド：チューニング編 — Let's Postgres
この記事では PostgreSQL のチューニングの概要を紹介します。まずは PostgreSQL のチューニングの勘所を掴んでください。各項目についての詳細はリンク先の記事で紹介していますので、そちらをご覧下さい。 チューニングの流れ PostgreSQLのチューニングとして必要な作業には何があるのでしょうか？ システムの開発状況やボトルネックによって必要な作業は変わってきますが、およそ以下の事項が挙げられます。 1. 情報収集と分析 チューニングを総当りで試すのは得策ではありません。まずは「ログ」や「稼動統計情報」を収集し、パフォーマンスのボトルネックを見つけることが先決です。特に良くあるトラブルは「トラブルシュートとチューニング」にも対処方法があります。 2. チューニングの実施 最も影響の大きなボトルネックから順にチューニングしていきます。 ボトルネックが解消されるまで、それ以外の
スロークエリの分析 — Let's Postgres
NTT オープンソースソフトウェアセンタ 板垣 貴裕 スロークエリ (時間のかかるSQL) を発見するまでの手順を解説します。スロークエリ分析と改善は以下の流れで行うことになります。この記事では主に 1. のスロークエリの特定方法について解説します。2.については『スロークエリの改善』を参考にしてください。 どのSQLが遅いのかを見つける。 そのSQLがなぜ時間がかかるのかを判断する。 設定パラメータ、SQL、スキーマなどを改善する。 着目したSQLの性能を再測定し、2. から繰り返す。 着目したSQLのチューニングが完了したら、他のボトルネックを探すため 1. から繰り返す。 スロークエリの見つけ方 スロークエリを見つけるには、大きく分けて統計情報ビューを使う方法と、サーバログを使う方法の2つがあります。統計情報ビューを使う方法は PostgreSQL 8.4 以降でしか利用できませんが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQL Performance Monitoring
