pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
23. 社内ISUCON w/ yosuke_furukawa | fukabori.fm
話したネタ Write Code Every Day ISUCONとは？ エンジニア5000名が参加するISUCONとは何か ISUCONに参加するまでの流れ ISUCON問題作問する側のインフラ担当は大変 ISUCARI ISUCON9予選の出題と外部サービス・ベンチマーカーについて - catatsuy - Medium R-ISUCONは優勝者が作問側へ ISUCON参加側のyosuke_furukawaの役割は？ テディベアプログラミング なぜ社内ISUCONをリクルートテクノロジーズで開催しているのか？ ISUCONの技術力を高める、リクルートのパフォーマンス課題を共通で解く 社内ISUCON開催に向けて、何か社内を説得 or 進めていくコツは？ スモールスタートで始めつつ、偉い人を巻き込む R-ISUCON PortalにVM再起動ボタン ベンチ動きっぱなしISUCON NTT
なぜRDBからCSV + COBOLに変更する事でコスト削減と高速化を同時に実現出来たかの考察 - ブログなんだよもん
そもそも既存はどんなロジック？ RDBなんだからWhere句使ったら？ なぜファイルにすると速くなるのか？ 並列化と分散処理による高速化の可能性 COBOL使う必要あったの？ Javaとかじゃダメだったの？ まとめ TLを見てると以下の記事が少し話題になってました。 tech.nikkeibp.co.jp tech.nikkeibp.co.jp 対象の記事は有料会員じゃないと見れないのだけど事例としては以下みたい。 リソース - ユーザー事例 - COBOL製品 ユーザー事例 : マイクロフォーカス さて、この記事の驚きポイントは「１億レコードくらいのDB処理をRDBからCOBOL + CSVに変更してUnixサーバからWindowsサーバに変える事で性能を維持しつつコストを1/5くらいにした」という事でしょう。 「せっかく7割もあったSQLを全部COBOLに変えるとか時代に逆行しすぎ！」
DBアクセスで遅くなったテストの実行時間を Docker で 40% 削減した方法 - Qiita
DBのレイヤーを含むエンドツーエンドテストやDBに依存したコンポーネントの自動テストがたくさんあると、全てのテストが終わるまでに長い時間がかかるようになってしまうことがあります。DBのクエリ実行はネットワークIOやディスクIOなどを含んだ高コストな処理だからです。 Docker を少し工夫して使うと、お手軽にテスト中のDBのクエリ実行にかかる時間を削減できます。自動テストが完了するまでの待ち時間を短縮し、開発のフィードバックサイクルをより早く回せるようになります！ MariaDB を用いたプロジェクトの実績では、DBアクセスを伴うテストケースが 153件 ありましたが、この方法によりそのテストスイートのローカル環境での実行時間を約 43% 削減できました（約 145.7s → 約 83.3s）。 どうやって？ Docker で tmpfs を使います。 tmpfs tmpfs とは、ディス
我々はいかにして技術選択を間違えたのか？ 2016 - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！アプリケーション基盤チームの横田(@yokotaso)です！ kintoneなどで利用していたJavaフレームワークのSeasarのEOLに伴い、S2Daoからの脱却を試みたのですが、パフォーマンス問題や障害を発生させてしまうなど問題を多々発生させてしまいました。 同じ過ちを繰り返さないという強い決意のもと、今回の失敗をブログで公開いたします。 失敗をあえて公開する点で斬新かつ濃いブログ記事となっております！ 失敗体験の公開は恥だが役に立つ！ 移行先の選定の失敗 移行先として選定したプロダクトは Hibernate*1です。 Hibernateを選んだ理由としては Spring Framework を選定した Spring Frameworkで Interface + アノテーションでプログラミングするならSpring Data JPA が有力 JPAに準拠したのORMの中でも、H
ISUCON 8 予選の Go 初期実装に見る初心者コード - methaneのブログ
会社のBlogにも書いたのですが、ISUCON 8 予選で負けてきました。 さて、 ISUCON の初期実装の定番として、初心者が書いたようなSQLやコードになっている点が挙げられます。 今回の Go の初期実装もその定番にもれず、初心者がやりがちな、Goの良さを殺してしまうコードがありました。 今回負けた反省点の一つとして、アプリの書き換えを二人でやっていたのでコンフリクトを恐れてそのリファクタリングを怠ったというのもあります。 Goで本戦に参加されるチームの方にはぜひこれを克服してもらいたいと思います。 アンチパターン: 長い無名関数 例: https://github.com/isucon/isucon8-qualify/blob/9d7890f5433bdaf2cec75b4cdf1ebd0d9a531281/webapp/go/src/torb/app.go#L404-L492
MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？ - Quora
回答 (3件中の1件目) ハイプサイクルという概念をGartnerグループが提唱してまして、様々な流行りスタリのサイクルを分析する標準的な方法となっています。 ハイプとは過度な期待や熱狂を意味する言葉です。一発屋芸人の人気のカーブみたいなもので、テツandトモみたいに安定する場合と、消えていくものがあります。芸人ではありませんがDA PUMPは一茶の人間性もありまして、次は厳しいけど定着すると思っています。 なんだかのトリガーで評価が上がり始め、ピークを迎える。その後評価が下がっていき、底を打つと少し上がって定着するという経過をたどるとしています。これと同じモデルで、流行りのハイテク...
[翻訳] たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか （How a single PostgreSQL config change improved slow query performance by 50x）
先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 How a single PostgreSQL config change improved slow query performance by 50x https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0 How a single PostgreSQL config change improved sl
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ - エンジニアHub｜Webエンジニアのキャリアを考える！
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
MySQL のサブクエリって、ほんとに遅いの？ | DevelopersIO
こんにちは、みかみです。 今日のクラスメソッドのAWSおみくじ、RDS（t1.micro）でしたー！（昨日は Aurora！＠＠ｖ はじめに 前職＠アプリ開発時、MySQL のクエリチューニングをさせていただく機会がありました。 ユーザー入力のキーワードで全文検索 → 見つかったレコードを返すのですが、所要時間、約3分。。 Apache タイムアウトして画面真っ白。。。（泣きそうでした＞＜。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリの
Apache Spark 2.0正式版がリリース。ANSI SQL標準サポート、10倍以上の高速化など
Apache Spark 2.0正式版がリリース。ANSI SQL標準サポート、10倍以上の高速化など 分散処理フレームワークの「Apache Spark 2.0」正式版のリリースが、開発元のDatabricksから発表されました。これまでApache Sparkはバージョン1.x（直前の最新版は1.6）でしたので、メジャーバージョンアップとなります。 Spark 2.0で最大の新機能は、新しいSQLパーサーを採用したことによるANSI SQL（SQL 2003）への対応です。ビッグデータのベンチマークの1つであるTPC-DSの99種類のクエリがそのまま実行可能と説明されており、プログラマが慣れ親しんだ一般的なSQL文はすべて実行可能になります。 また、DataFrameとDatasetは統合されたAPIとなりました。 こうしたAPIの変更や改善が行われた一方で、Spark 2.0ではパフ
Rebuild: 145: Benchmarking Placebo (naoya)
Naoya Ito さんをゲストに迎えて、SSD, GeForce GTX 1080, WWDC, App Store, Data Engineering, デザインなどについて話しました。 Show Notes Fusion-io How our SSD result in cost savings for customers | Fastly GeForce GTX 1080がついに発売開始、恒例の深夜販売も入荷数は少なめ SLI | GeForce 199ドルでVR対応なGPU Radeon RX480をAMDが発表 APP STORE 2.0 What to Expect at WWDC 2016 Apple’s ‘macOS’ – OS X name update seemingly confirmed 9: Data Engineer, not Data Scientist -
ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
SQL実践入門──高速でわかりやすいクエリの書き方 - kagamihogeの日記
俺は実務経験をある程度こなしたあと、RDBの知識不足を認識したクチである。改めてRDBを勉強し始めて困ったことの一つは、実行計画の読み方がよくわからないことだった。もちろん、ぐぐればNESTED LOOP JOINが何かとかは出てくるし、公式のマニュアルも参考になる。ただ、webの文献は体系だって解説があるとは限らないし、個人のブログなどは粒度がバラバラで、まとまった量の知識を得るには向いていない。マニュアルも膨大な量があるので慣れていないと目的の文書が書いてあるかどうかすら分からないし、あったとしても必要なレベルの解説があるかどうは分からない。 そこで本書の出番である。既存の書籍にもSQLとパフォーマンスを論じたものはあるにはあるのだが、それに特化した本の存在は、少なくとも俺は知らない。一冊だけ、データベースパフォーマンスアップの教科書 基本原理編 - kagamihogeの日記という極
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
N+1問題におけるORMの重たさについて - Atsuo Ishimoto's blog
