不揮発性メモリでのデータベース処理最適化 〜 ヤフーにおけるデータベース技術の研究開発
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ ヤフーでデータベースエンジニアをしている松浦です。 インターネットサービスを作る上で、そのデータの保持・管理を担うデータベースは重要なソフトウエアコンポーネントですが、今回のTech Blogでは、ヤフーにおけるデータベース技術の研究開発についてのお話をします。 ヤフー社内では、さまざまなデータベースを運用していますが、そのデータベースを最新のハードウエアに対応させる研究開発を行っています。 具体的には、不揮発性メモリを有効に活用するMySQLのストレージエンジン「Leo」の開発に取り組んでいます。 本日は、Leoについて簡単にご紹介をします。 不揮発性メモリとは？ まず、前段として、Leoのお話をする前に、不揮発性
Cloud Spanner のロックについて
この記事では Cloud Spanner の並行性制御が何であるのか、結果として何を実現しているのかを見てから具体的なロックの実際の挙動について追っていく。 なお分散システムとしての話はあまりないので期待しないように。 この記事では実際の挙動を確認しながら書いているつもりだが、 2021年3月現在の挙動がサイレントに変わることもあることには注意してほしい。 TL;DR Cloud Spanner はロックフリーな Read-Only Transction と、堅実にロックを行う Read-Write Transaction の2つのアクセスパスを持ち、 ROMV と呼ばれる方式に最も近い。 その他技術との組み合わせの結果として分散システムでありながら Serializability と Linearizability を兼ね揃えた理論上最も強い一貫性を実現しており、 Google はそれを
ダーティリード、リピータブルリード、ファントムリードをちゃんと理解してからトランザクション分離レベルを理解しよう - Qiita
ダーティリード、リピータブルリード、ファントムリードをちゃんと理解してからトランザクション分離レベルを理解しようDatabase はじめに トランザクション分離レベルとは2つ以上のトランザクションの間同士でのお互いの操作の影響度合いを定義したものです。 具体的にトランザクション分離レベルが何なのかを理解するためには、リード現象(Read phenomena)である「ダーティリード(Dirty reads)」「ノンリピータブルリード(Non-repeatable reads)」「ファントムリード(Phantom reads)」の3種類の違いを理解する必要があります。 本記事ではこの3種のリード現象を例を用いて解説し、トランザクション分離レベルの定義を記載しています。 3種のリード現象 説明に利用する例 以下のArticles(記事)テーブルという擬似的なテーブルを例に進めます。 Id Tit
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現 Googleは、クラウド上で高度なスケーラビリティを実現する、ミッションクリティカルな業務に対応したリレーショナルデータベースサービス「Google Cloud Spanner」を発表しました。 Google Cloud Spannerは、地球規模の大規模分散処理データベースとして、NoSQL並の非常に高いスケーラビリティと高い可用性、そして高速な処理を実現しつつ、SQLに対応。強い一貫性を持つトランザクション処理も実現。企業のミッションクリティカルな業務にも使えると説明されています。 地球規模に分散したリレーショナルデータベース 一般に、ミッションクリティカルな業務に対応したリレーショナルデ
オラクルが大口顧客アマゾンを批判、エリソン会長の焦り | 日経 xTECH（クロステック）
米アマゾン・ドット・コム（Amazon.com）と米オラクル（Oracle）の間で、データベース（DB）を巡る舌戦が加熱している。焦点は、アマゾンが進める基幹系システムの「脱Oracle DB」だ。それによってシステム障害が起こったとオラクルが吹聴すれば、アマゾンも「2018年末までに脱Oracle DBを88％完了させる」とやり返した。 米アマゾン・ウェブ・サービス（Amazon Web Services、AWS）のアンディー・ジャシーCEO（最高経営責任者）は2018年11月9日、同社のeコマース事業を支える基幹系システムで利用するOracle DBを、自社製のDBクラウドである「Amazon Aurora」や「Amazon Redshift」に移行する作業が順調に進んでいることを明らかにした。 ジャシー氏は同日に「Twitter」で、「アマゾンの消費者事業（eコマース部門）がOrac
スロークエリの分析 | Let's POSTGRES
NTT オープンソースソフトウェアセンタ 板垣 貴裕 スロークエリ (時間のかかるSQL) を発見するまでの手順を解説します。スロークエリ分析と改善は以下の流れで行うことになります。この記事では主に 1. のスロークエリの特定方法について解説します。2.については『スロークエリの改善』を参考にしてください。 どのSQLが遅いのかを見つける。 そのSQLがなぜ時間がかかるのかを判断する。 設定パラメータ、SQL、スキーマなどを改善する。 着目したSQLの性能を再測定し、2. から繰り返す。 着目したSQLのチューニングが完了したら、他のボトルネックを探すため 1. から繰り返す。 スロークエリの見つけ方 スロークエリを見つけるには、大きく分けて統計情報ビューを使う方法と、サーバログを使う方法の2つがあります。統計情報ビューを使う方法は PostgreSQL 8.4 以降でしか利用できませんが
mita2 DB メモ: MySQLのデッドロックについて
MySQL (InnoDB) はデッドロック状態になった場合、片方のトランザクションを強制ロールバックし、もう片方のトランザクションに必要な ロックを獲得させ、処理を進める。その際、強制ロールバックされたクエリは以下のエラーが発生する。 mysql> UPDATE t1 SET col1 = 'session2' WHERE pk = 1; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction デッドロックの対処方法 1. リトライ 根本的な対応ではないが、良くとられる解決策。 タイミング悪く更新が重なったときに起こる程度であれば、リトライで十分。 2. クエリを修正し、ロックを獲得する順番を揃える 上記の例でいうと、片方のトランザクションがt1→t2 という順でロックし
ドキュメント指向データベースと列指向データベース
ドキュメント指向データベースの概要 リレーショナルデータベースでは、データを表形式で保存します。そのため、表にしやすいデータであれば、効率よく管理することができます。 しかし、世の中全てのデータを表にできるかと言えば、そうではありません。そのようなデータをリレーショナルデータベースで管理しようとすると、どうしても無理が生じてしまいます。その結果、プログラムを組むのが難しくなったり、処理に時間がかかるようになったりしてしまいます。 このような中で、柔軟な構造でデータを扱えるようなデータベースとして、「ドキュメント指向データベース」と呼ばれるデータベースが出てきました。 ドキュメント指向データベースでは、1件分のデータを「ドキュメント」と呼びます。また、個々のドキュメントのデータ構造は自由で、データを追加する都度変えることができます（図1）。リレーショナルデータベースとは違って、事前にテーブル
A new App Engine datastore API
This post is primarily intended for App Engine users (and of those, only Python users :-). Over the past months I've been working on a new design for the Python datastore API, under the code name Datastore Plus. The new design is very ambitious, and changes a lot of things: New, cleaner implementations of Key, Model, Property and Query classesHigh-level asynchronous API using Python generators as
今まで見たもっともクソなテーブル設計 - 何か着ていればいいよ
あれは、僕がデータベースを扱ううち最初から３件目のプロジェクトだった。 C++のソースが難解で火を吹いているという話で、自分は低スキルの若造。火にくべるには丁度良い程度のやる気と責任感をもっていた。折悪く別のプロジェクトが終了した直後だったもので投入されたのでした。 現場で『DBからデータを吸い出すツールかSQLを作ってくれ』といわれ話をきくと他社が作ったDB定義がすこぶる使いづらいという。 ER図やDB定義を見せてくださいと言ったのだけど、そんなものは無いという返事。 今ならもうここら辺で逃げ出すところですが、当時は『ふーん。』てなもんでそういうこともあるのかくらいの軽い気持ちで考えていました。 で、プロジェクトの資料をあさりまくって何とかDB定義のようなものも見つけDBのデータを調査し始めたのですが何かがおかしい。 機能の数に比して異様にテーブル数が少ないのです。 ふと周りを見ると、皆
SQLに依存することの危険性 ー 単体DBサーバでは終わらない時代の考え方 | 独り言v6
ベンチャー社長で技術者で:ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！. というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。 L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出
DBの世界に起こる変革 | エンタープライズエンジニアの独り言
エンタープライズシステムのエンジニアをやって１０年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化（CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど）するのにディスク（ストレージ）が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて
インフラエンジニアのためのcassandra入門
@marqsさんと@muranetさんと一緒にhbstudy#11で発表させていただきました。 これを機にとか言うとでかすぎる気がしますがCassandraが国内でも盛り上がるといいなーと思います。 懇親会でも結構使おうとしている方がいたりしてうちもうかうかしてられないですねｗ 資料をあげましたのでこちらよろしかったらどうぞ！ インフラエンジニアのためのcassandra入門 View more presentations from Akihiro Kuwano. これだけはかかないと！ 素晴らしい会を開いて下さっているハートビーツの方々や、スピーカーの方々、来ていただいた方々に感謝しております 非常に楽しかったです！ ただいま二日酔いですw
データベーストランザクションの管理 — Django v1.0 documentation
デフォルトのトランザクション処理¶ Django のデフォルトの挙動では、組み込みのデータ変更に関わるモデル関数を呼び 出したときにはいつでも自動的に commit を行います。例えば、 model.save() や model.delete() を呼び出すと、変更は即座にコミットされます。 これはほとんどのデータベースにおける自動コミット設定とほとんど同じ挙動です。 すなわち、ユーザがデータベースへの書き込みを必要とするような操作を行うと、 Django はすぐに INSERT/UPDATE/DELETE 文を実行し、次いで COMMIT を実行します。暗黙のロールバックは行いません。 HTTP リクエストとトランザクションを結び付ける¶ TransactionMiddleware を介してリクエストとレスポンスのフェイズにトラン ザクションを結び付けるというものです。 このトランザクシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why You Shouldn’t Invest In Vector Databases?
GitHub - baidu/tera: An Internet-Scale Database.
GitHub - baidu/BaikalDB: BaikalDB, an Enhanced Structured Database.
O/Rマッパーによるトラブルを未然に防ぐ
)
Pooling in the Microsoft Data Access Components
IBM Developer
