Tips on fixing database performance problems and a few war stories from fixing performance at Cookpad
![Database Performance for Rails Applications - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/42acaed0156a234d19bf7f45c6dbe221d3e94d1a/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F35adae704afb48db8575f29e838ca875%2Fslide_0.jpg%3F9679074)
Data / ML, EngineeringHerb: Multi-DC Replication Engine for Uber’s Schemaless DatastoreJuly 25, 2018 / Global Schemaless, Uber’s fault-tolerant and scalable datastore, supports the 600-plus cities where we operate and the 15 million rides per day that occur on our platform, not to mention Uber Eats, Uber Freight, and other business lines. Since 2014, we have deployed more than 50 Schemaless instan
It’s time for us to admit what we have all known is true for a long time: NoSQL is the wrong tool for many of the modern application use cases, and it’s time that we move on. NoSQL came into existence because the databases at the time couldn’t handle the scale required. The rise of this new generation of data services solved many of the problems of web scale and rapidly growing data sets when it w
大分たってしまったけど、ようやく時間が空いたので、db tech showcase Tokyo 2016 http://enterprisezine.jp/dbonline/detail/8466 で話した内容を記録的に書いておく。あとはSILOの解説を特に自分用に論文の4章を中心に整理しておく。あとはついでに自分の思うところも記す。 ・SILO 元論文はこちら、執筆陣はMITのLiskov一派とEddie Kohler 現在のDB研究の第一線のメンバー。 http://people.csail.mit.edu/stephentu/papers/silo.pdf SILO以降、大きくDBベースのアーキテクチャの考え方は変わりました。ほとんど全ての分散系OLTPはSILOを程度の大小はあるとはいえ、意識していると言っても過言ではないでしょう。前世代ではほぼ「空想か?」ぐらいの扱いだった分散t
Speedy Transactions in Multicore In-Memory Databases読んだ。 2013年にSOSPで発表された論文。 ↓論文リンク Speedy transactions in multicore in-memory databases 下手をするとただの論文の和訳になりかねないので、できるだけ要点に絞って書くようにする。 一方で、提案手法のアーキテクチャ・動作原理に関しては僕の理解も含めて詳細に書く。 (と言いつつ、結局全訳感が拭えないものになってしまった) ※ この記事内の[n]は論文中のrefer番号をそのまま使ってその論文へのリンクとしています。 概要 Siloは近年のマルチコア化した環境でscalabilityを持つ、非常にパフォーマンスの高いインメモリDB Siloはメモリを有効活用するために、トランザクションIDを含む競合となりえるポイント
More than a billion people now use Facebook Messenger to instantly share text, photos, video, and more. As we have evolved the product and added new functionality, the underlying technologies that power Messenger have changed substantially. When Messenger was originally designed, it was primarily intended to be a direct messaging product similar to email, with messages waiting in your inbox the ne
Dr. Richard Hipp, creator of SQLite, presents "How SQL Database Engines Work" at OpenSQLCamp 2008. The description: To many programmers, SQL RDBMSes are a magical black box. A talk can help clear up a lot of the mystery. SQL users tend to make better use of the language once they have a rough idea of what is going on beneath the covers.
EngineeringMySQL High Availability at GitHubGitHub uses MySQL as its main datastore for all things non-git, and its availability is critical to GitHub's operation. The site itself, GitHub's API, authentication and more, all require database… GitHub uses MySQL as its main datastore for all things non-git, and its availability is critical to GitHub’s operation. The site itself, GitHub’s API, authent
This course is a comprehensive study of the internals of modern database management systems. It will cover the core concepts and fundamentals of the components that are used in both high-performance transaction processing systems (OLTP) and large-scale analytical systems (OLAP). The class will stress both efficiency and correctness of the implementation of these ideas. All class projects will be i
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
数日前、Uberのブログで「Why Uber Engineering Switched from Postgres to MySQL」というエントリが公開されました。 Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog https://eng.uber.com/mysql-migration/ それに対して、PostgreSQLコミュニティ界隈でもいろいろなブログエントリが公開されました。 Robert Haas: Uber's move away from PostgreSQL http://rhaas.blogspot.jp/2016/08/ubers-move-away-from-postgresql.html On Uber’s Choice of Databases http:/
最近、久しぶりにPostgreSQLのクエリチューニングをしていたのですが、その過程で「この本はぜひもっと多くの人に読んでもらいたい」と改めて思い出した一冊がありました。 それは、「SQLパフォーマンス詳解(原題:SQL Performance Explained)」という本です。 SQLパフォーマンス詳解 http://sql-performance-explained.jp/ パフォーマンスチューニング、特にクエリチューニングについて説明する場合、その前提となる知識は広範なものになります。 そのため、自分が頑張って説明するよりも、優れたエキスパートのまとめたコンテンツを活用させてもらう方が、質・量ともに優れたインプットにしていただけるのではないか、と思うのです。 また、この「SQLパフォーマンス詳解」は非常に良い本であるにも関わらず、一般の出版社から出ているわけではないため、それほど積
最近 Graph database が盛り上がってるように感じる。 さて ArangoDB という DB を知っているだろうか。 MySQL とか MongoDB とかと比べると知名度は低いものの、NoSQL、とりわけ Graph database 界隈では名が知られている。Graph database 界隈と書いたが、さしずめこの領域では Neo4j が幅を利かせている。Neo4j なら聞いたことあるって人はたくさんいると思う。 Graph databases ・Neo4j Neo4j の強みとしては、そのクエリ言語である Cypher の読みやすさが一つ挙げられる。Cypher の紹介ページ に書かれている最初のサンプルを引用すると、こうだ。 MATCH(:Person{ name:"Ann"})-[:MARRIED_TO]->(spouse) このクエリは「name が "Ann"
以前のエントリで「次回は履歴を保存する方法について解説します」と書いたのですが、その前に気になるテーマを見つけたので、今回は予定を変更してそちらの解説を行いたいと思います。 その気になるテーマというのは、表題の通り、関係データベース (RDB) における配列の取り扱いについて。 そもそも、リレーションモデルでは、原則的に単一のカラムはスカラを表すため、これを用いてベクタである配列を直接表現することはできません。 (参考: リレーションの正規化#第一正規形 - Wikipedia) しかしながら、実際には配列というデータ構造を用いずにシステムを設計・開発することは現実的に不可能です。 結論から言えば、関係データベース上で配列を表現するためのごく簡単なテクニック (というほど大げさなものでもない) があるのですが、少なくとも私が観察した範囲では、その手法にはこれと言った名前が付けられておらず、
Go Conference 2018 Spring
N+1, solvedEdgeDB solves the problems that ORMs exist to workaround. A comparison that speaks for itself: SELECT movie.title, ( SELECT avg(rating) FROM reviews WHERE movie_id = movie.id ) AS avg_rating, (SELECT array_agg(q.v) FROM (SELECT person.name AS v FROM actors INNER JOIN persons AS person ON (actors.person_id = person.id) WHERE actors.movie_id = movie.id ) AS q WHERE q.v IS NOT NULL ) AS ac
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く