連番IDを使うと会社が潰れる。(訳: 連番とUUIDのベンチマークを取ってみた❤️）
大いなる流れには逆らえない あるAI研究者が言っていた、私の仕事もいつか AI に奪われるという言葉が非常に印象的だった。 私は一時期自分のキャリアに危機感を覚えAIに関する情報を集めていた。そのとき見つけたYoutube動画でこのようなことが語られていたのである。 ではなぜ彼らは研究を続けるのかと思うかもしれないが、個人や一団体がそれを放棄したところで世の中のイノベーションの流れを止めることは不可能だろう。 平和を望む国々も兵器開発をやめられないのと似たようなものだ。 私がこの記事のタイトルを思いついたとき、つい溜息が出た。あまり楽しくない思い出があるからだ。 ただ、思いついてしまった以上これを世に出さないわけにもいかず、血の涙を流しながらこの記事を書いている。 私というちっぽけな存在では、この大宇宙の大いなる流れには逆らえないのだ。 申し遅れました。私、YadaYadaKonnanYa
検索が爆速になるデータベース設計を公開します
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
Rails: データベースのパフォーマンスを損なう3つの書き方（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Common Rails Idioms that Kill Database Performance 原文公開日: 2017/01/03 著者: Starr Horne サイト: https://www.honeybadger.io/ 初版公開: 2018/01/11 訳文更新: 2021/06/24 2005年にRailsのActiveRecordを初めて見たときに、稲妻のような天啓を感じたことが忘れられません。当時はPHPアプリで生SQLクエリを書いていましたが、それまで面倒で退屈でたまらなかったデータベースの扱いが、そのときを境に突如として簡単で楽しいものに変身したのです。そう、楽しくなったのです。 ...やがて、ActiveRecordのパフォーマンスの問題に気づくようになりました。 ActiveRecordそのものが遅い
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
SQLのインデックスとそのチューニングについてのオンラインブック
開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQL、Oracle、SQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 Db2 (LUW)U
秒間100万クエリを受け付ける大規模ソーシャルゲームのバックエンドDBシステムの設計・運用ノウハウ
2016/08/26 CEDEC 2016
『アメーバピグにおけるDB構成&対応記』
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
MySQL Index勉強会外部公開用
12. © CROOZ,Inc. 12 １．INDEXとはなにか 何枚目がなにかを事前にメモっておけば良い！ スート ランク 位置 ハート Q 1 スペード 9 2 : : : ダイヤ 1 40 : : : スペード 6 45 なぜなら、要求は「カードを引く回数を最も少なく してスペード6を探すこと」 セコいとかおもうヒトはいるか もしれませんが何もセコいこ はしていないです。 前提条件など一切ないから このメモさえあれば位置を指定して1回引けば済む
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
平成 23 年度 研究レポート課題 ピグにおけるリアルタイムランキングの導入 システムディベロップメントグループ 松本 克彦 2011 年 8 月 31 日 概要 アメーバ・ピグに汎用リアルタイムラン��
平成 23 年度 研究レポート課題 ピグにおけるリアルタイムランキングの導入 システムディベロップメントグループ 松本 克彦 2011 年 8 月 31 日 概要 アメーバ・ピグに汎用リアルタイムランキングシステムを導入した際のレポートであ る。ピグの 70 万を超える DAU に耐えうるシステムを想定し、ハードウェア設計の段 階から容易に拡張スケールできる点と、容易にランキングを追加できる点を考慮して、 システムを実装した。それらの設計開発から実際のサービス導入後までの経緯を纏め た。ランキングシステム自体は、ピグに限定せずどのシステムからも利用できるよう に汎用的に設計した。本レポートが類似システム開発の参考になれば幸いである。 第１章 研究の背景 アメーバ・ピグでリアルタイムランキングを導入する案件が持ち上がった。ランキン グを導入すれば、ピグ内のゲームや投票における成績や順位をユ
リアルタイム・ランキングの実装例をRailsで書いてみた - Qiita
参考文献 http://labs.gree.jp/blog/2010/07/456/ リアルタイム・ランキングを考える http://www.cyberagent.co.jp/technology/pdf/2011_10.pdf 元ネタについては、GREEさんや、サイバーエージェントさんが同じような方式でした。 これを真似てRailsで実装してみました 動作環境 Ubuntu 12.04 Ruby 1.9.3 Rails 3.2.12 MySQL 5.5 データ構造 こんな感じの構造です(minとmaxはコードに埋め込んだら実は無くても良い) create_table "high_score_partitions", :force => true do |t| t.integer "min" t.integer "max" t.integer "user_count", :default
リアルタイム・ランキングを考える | GREE Engineering
はじめに こんにちは。プラットフォーム開発部のsp1rytusと申します。 先日、私もついに30歳のおっさんになってしまいました。加齢臭が出ないようにがんばります！ ランキングって？ ランキングは誰でもわかる、何らかの得点をソートして順位位置を決定する凄く簡単でシンプルなものです。しかし、ゲームを扱うコンテンツ・サービスにおいては、得点を通算/日別に順位付けされたものが直ぐに目に入るように、他人と自分を比較する非常に重要な役割を果たしています。そこで、この記事では次の３つ要件を満たすようなランキング・システムの難しさと、それを解決するための一例を簡単に説明させて頂きます。 順位付けはリアルタイムに行い、集計時間を必要としない。 100万件以上の得点データが扱える。 すべてのデータが正しい順位付けで取得できる(線形補完などで順位を概算しない）。 リアルタイムによる正確な順位付けは、データ件数
「コネクションプーリング都市伝説」はほんとに都市伝説?（その1) - 最速配信研究会(@yamaz)
「コネクションプーリング都市伝説」という単語がある.かいつまんでいうと 「コネクションプールって一般的に速いと言われているけど,クライアントが 多くなると接続維持のコストが大きくなるから今となっては速くないんじゃね?」 というものだ. WEB+DB PRESS vol.33でnipotanさんの中の人が書いてた記事が発端だと思われる. あとこんなエントリもあった. hori-uchi.com コネクションプーリング都市伝説は正しそう またちょっと古いねたですが、WEB+DB PRESS vol.33でnipotanさんが書いてたコネクションプーリング都市伝説を読んだ時、ほんとのところどっちが速いのかってのをabでベンチマークをとってみました。 (snip) これ以外にもいくつかパスを替えてベンチマークをとったところ、いずれも若干ですがプーリングしないほうが早かったので、現在はプーリングしな
DBの世界に起こる変革 | エンタープライズエンジニアの独り言
エンタープライズシステムのエンジニアをやって１０年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化（CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど）するのにディスク（ストレージ）が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて
第1回 大規模データではRDBMSのどこがボトルネックになるのか？ | gihyo.jp
RDBMSはオワコン？ 「右を向いても左を向いても“ビッグデータ”というキーワードが闊歩する時代に、いまさらRDBMSの話題？」 本連載のタイトルを見てそう思われたかもしれません。 「ディスクベースのRDBMSはオワコン、これからは○○（お好きなアーキテクチャを入れてください）の時代だ！」 とおっしゃる方もいるかと思います。 しかし、むしろ多くの企業がビッグデータに注目しているおかげで、RDBMS側でも大規模データを取り扱うニーズが増えています。 大規模データを取り扱う時にボトルネックとなる5つのポイント 数百ギガバイトといったレベルのRDBMSであれば、現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし、テラバイトを大きく超えたデータを扱う場合には、ボトルネックの傾向が変化するのはご存じでしょうか。 次の図は、RDBMSにまつわるボトルネックを示したものです。 図1 大規
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
ActiveRecordのコネクションプーリングをやめてみる - kaeruspoon
おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 関連 : RailsでMysqlスレーブ群をロードバランサ経由で使用できる、FreshConnectionを作り始めました RailsのActiveRecordは、DBとのコネクションがプールされます。 アクセスごとにコネクションをはりなおすよりは、オーバーヘッドがない分、理にかなっているようにも思えます。 ただ、比較的大きめなサイトになってくると、はりっぱなしのコネクションが多くなりすぎちゃって大変なことになってきます(1サーバ1万コネクションとかなりかねない)。リソースは食うし、たくさんのスレーブを抱えているときにActsAsReadonlyableなどでちまちまやっていたらとても運用できません。スレーブなんてLVS+keepalivedでバランシングしちゃいたいところ。でもコネクシ
MySQL innodb_flush_method = O_DIRECTの検討 - SH2の日記
MySQL InnoDBのパラメータでinnodb_flush_methodというものがあります。これはUNIX/Linuxにおいてデータファイル、ログファイルの読み書き方式を指定するためのもので、マニュアルの13.6.3. InnoDB Startup Options and System Variablesによると以下の3種類の設定が可能とされています。 無指定(fdatasync)：デフォルトの設定です。特別なフラグなしでファイルをオープンし、書き込み時にfsync()を行います。 O_DSYNC：データファイルについてはfdatasyncと同じです。ログファイルについてO_SYNCフラグをつけてファイルをオープンします。 O_DIRECT：データファイルについてO_DIRECTフラグをつけてファイルをオープンします。ログファイルについてはfdatasyncと同じです。 今回はこのパ
MySQL Conference & Expo 2007 - とあるはてな社員の日記
一昨日から今日まで3日間の日程で開催されていた、MySQL Conference & Expo 2007に行ってきました。日帰り圏内どころか、自転車圏内で、こういうカンファレンスがあるのは、素晴しいです。 詳細は、随時アップされるであろうプレゼン資料と、Planet MySQLに大量の報告があります(全部英語ですけど)。 個人的に注目していたのは、Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッションでした。あとは、http://www.mysqlperformaceblog.com/の人のセッションは、細かいTipsが多く、具体的にだいぶ役に立ちそうです。 というわけで、簡単に注目したセッションの内容を紹介してみます。ちなみに、内容の正確さは無保証です:P 気が向けば、もっといろいろ考察してみるかもしれません。 Technology at Di
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
