不揮発性メモリでのデータベース処理最適化 〜 ヤフーにおけるデータベース技術の研究開発
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ ヤフーでデータベースエンジニアをしている松浦です。 インターネットサービスを作る上で、そのデータの保持・管理を担うデータベースは重要なソフトウエアコンポーネントですが、今回のTech Blogでは、ヤフーにおけるデータベース技術の研究開発についてのお話をします。 ヤフー社内では、さまざまなデータベースを運用していますが、そのデータベースを最新のハードウエアに対応させる研究開発を行っています。 具体的には、不揮発性メモリを有効に活用するMySQLのストレージエンジン「Leo」の開発に取り組んでいます。 本日は、Leoについて簡単にご紹介をします。 不揮発性メモリとは？ まず、前段として、Leoのお話をする前に、不揮発性
Database Lounge Tokyo #1 (2016/07/27 19:30〜)
Database Lounge Tokyo とは？ 「Databaseの幅広い話題を語れる場が欲しい！」ということで企画した勉強会＆交流会＆飲み会(?)です。仕事帰りにお酒を飲みながらDBについてゆる～く語る場にしたいと考えています。ぜひ Database Lounge Tokyo のグループページもご確認ください。 http://database-lounge-tokyo.connpass.com/ 第１回について とはいえ、最初からゆる～くやり過ぎてもあまり良い会にならなそうということで、第１回は下記の皆様に、ガチなお話をおねがいしました。 Mikiya Okuno (@nippondanji) KaiGai Kohei (@kkaigai) Hiroki Kumazaki (@kumagi) 講演内容は録画させて頂く予定です。後日YouTubeで公開します。 ビアバッシュについて 会
how innodb lost its advantage
For years it was very easy to defend InnoDB’s advantage over competition – covering index reads were saving I/O operations and CPU everywhere, table space and I/O management allowed to focus on database and not on file systems or virtual memory behaviors, and for past few years InnoDB compression was the way to have highly efficient OLTP (or in our case – SGTP – Social Graph Transaction Processing
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応
YouTubeがMySQLをスケールアウトする「Vitess」をオープンソースで公開。Kubernetesに対応 Google Cloud Platformのブログに投稿された記事「Scaling MySQL in the cloud with Vitess and Kubernetes」で、Vitessは次のように説明されています。 At YouTube, we went on that journey as we scaled our MySQL deployment, which today handles the metadata for billions of daily video views and 300 hours of new video uploads per minute. To do this, we developed the Vitess platform,
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる
RailsがMySQLのcollationをサーバー側のデフォルトのutf8_general_ciからutf8_unicode_ciにわざわざ変えてるのどうせ大した理由じゃないだろと思って掘ってみたらやっぱり大した理由じゃなかった… https://t.co/6NeetGhTF0— Ryuta Kamizono (@kamipo) April 18, 2014 Railsでcollationとしてutf8_unicode_ci(RailsのDEFAULT_COLLATION)が採用されるのはcharsetが未指定もしくはutf8(RailsのDEFAULT_CHARSET)のときだけで、utf8mb4にすることとかは全く考慮されてない。— Ryuta Kamizono (@kamipo) April 19, 2014 @frsyuki MySQLのcharset utf8のときのデフォルト
MySQL/MariaDBとTransactdのInnoDBロック制御詳細 その1 - BizStationブログ
今回から数回にわたり、TransactdのオペレーションとInnoDBにおけるロックについて解説します。 ロックについてはあまり良くわからなくてもとりあえずそれなりに動くアプリケーションは作れてしまいます。ですが、マルチユーザー環境でミッションクリティカルなアプリケーションを書くには、ロックの理解が不可欠です。ロックをうまく使って、矛盾や間違いのない読み書きをしつつ同時実行性も高いアプリケーションにしましょう。 その1では、Transactdを実装する上でMySQLのソースやドキュメントから得た知見を基に、InnoDBのロックの種類と分離レベルに応じてそれをどのように使うかをまとめてみます。 Index MySQLのトランザクション関連用語 MySQLのREPEATABLE-READ InnoDBのロック 行ロック (row-level locking) GAPロック GAPロック単体 ネ
［速報］Amazon Aurora発表。MySQL互換で性能5倍、商用リレーショナルデータベースと同等の機能を提供するマネージドなデータベースサービス。AWS re:Invent 2014
［速報］Amazon Aurora発表。MySQL互換で性能5倍、商用リレーショナルデータベースと同等の機能を提供するマネージドなデータベースサービス。AWS re:Invent 2014 Amazonクラウドを提供するAmazon Web Servicesは、同社の年次イベント「AWS re:Invent」を米ラスベガスで開催しています。 初日の基調講演では、クラウドがエンタープライズITにおけるニューノーマル（新しい普通）であることを強調。新サービスとして、MySQL互換でありつつ商用リレーショナルデータベース並の性能と機能を実現したという「Amazon Aurora」を発表しました。 MySQLとフル互換でありながら5倍の性能 Amazon Web Servicesシニアバイスプレジデント Andy Jassy氏。 既存のリレーショナルデータベースというのは高価で、プロプライエタリで
SH2先生のRDB比較, ぶっ壊れ編
SH2 @sh2nd 個人的にそうなんだろうなあと思っていたことが書いてあって、とても腑に落ちた記事 / how oracle prevent "partial write" | Oracle Community https://t.co/nHcmvh5ZSA 2014-05-18 13:21:43 SH2 @sh2nd MySQLのinnodb_doublewrite、PostgreSQLのfull_page_writesのような、データブロックが半分しか書かれていない事態を想定した処理は、Oracle DatabaseはALTER TABLESPACE BEGIN BACKUPのときにのみ行う 2014-05-18 13:26:55 SH2 @sh2nd なのでサーバクラッシュ時にデータブロックが壊れていて、REDOを適用しただけでは直せないことがある。ただその場合Oracle Dat
MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
RailsでMySQLを使う際のcollation周りの問題について - Journal InTime(2014-01-14)
_ RailsでMySQLを使う際のcollation周りの問題について RailsでMySQLを使う時のcollation周りの注意点のメモ。 デフォルトのcollation設定 Railsでrake db:create:allとかすると、デフォルトではcollationがutf8_unicode_ciになるが、大文字小文字や半角全角を区別しないだけならまだしも「パ」と「バ」の区別もされない。たぶん、欧米の人にはutf8_unicode_ciの方が都合がいいんだろうけど。 以下のページの手順でutf8_general_ciやutf8_binに変更しておくとよい。 ActiveRecordでデフォルトの照合順序を変更する validates_uniqueness_ofのcase_sensitiveオプション 以下のページで指摘されているように、validates_uniqueness_of
MySQL Performance: over 1M QPS with InnoDB Memcached Plugin in MySQL 5.7 - DimitriK's (dim) Weblog : November 2013
MySQL Performance: over 1M QPS with InnoDB Memcached Plugin in MySQL 5.7 Last week, during Tomas' keynote at MySQL Percona Live Conference in London we announced as one of "previews" of the following MySQL 5.7 release(s) -- an over 1,000,000 Query/sec result obtained with InnoDB Memcached plugin on a Read-Only workload. This article here is just to confirm the announced results without going too m
Tungsten Replicatorを使って、非RDS→RDSのMySQLレプリケーションを行う | DevelopersIO
都元です。AWS上に構築するシステムAにおいて、非AWS上で稼働する別システムBで利用しているマスタデータを使いたい、という状況ってありえますよね。既にシステムBは非AWS環境で動いていて、そこで使っているマスタデータを、AWS上に新規構築するシステムBでも使いたい。そして、システムA上でマスタ更新が掛かったら、システムBのマスタも更新されて欲しい、というわけです。 システムA,B共にAWS上にあれば、理想的な解決方法もあるでしょう。逆に、システムBがRDSでさえなければ、MySQL標準のレプリケーション機能を使うこともできるでしょう。しかし、RDSを使う場合は、標準のレプリケーション機能を利用することはできません *1。 というわけで、今回のような非RDSをmasterとするRDSへのレプリケーションでは、サードパーティ製プロダクトのお世話になる必要がありそうです。今回はTungsten
MySQL5.6関連情報まとめ
社内向けに説明した資料です 会社の技術ブログにChefの記事投下しました。http://devlab.isao.co.jp/chef-solo_vagrant_install/
実践ハイパフォーマンスMySQL 第3版
新しい情報を盛り込み、信頼性や正確さといった目標を重視するという前版からの方針に加えて、第3版では、MySQLの動作の仕組みに関する事実だけでなく、MySQLがそのように動作する原理を伝えたいと考えて執筆されている。そうした原理の実質的な効果を示す、より具体的なストーリーやケーススタディを盛り込んで、それらをベースとして、「MySQLの内部のアーキテクチャや処理がそうなっているとしたら、実際の使用状況で実質的にどのような効果が得られるのか」、「そうした効果はなぜ重要なのか」、「結果として、MySQLは特定のニーズにどのように適しているか、あるいは適していないか」という質問に答えている。MySQL管理者やアプリケーション開発者が求める必須の知識や手法を掘り下げて、問題や課題に対して実践的な考え方と解決の手法を示す。読者のMySQLについての理解と技術を一段高いレベルに引き上げる。改訂第3版。
Facebookが何千台ものMySQLを人手を使わず自律管理する仕組み「MySQL Pool Scanner（MPS）」
おそらく世界でもっとも大規模にMySQLのクラスタを展開し、運用しているのがFacebookでしょう。複数のデータセンターにまたがり何千台ものMySQLサーバを運用するために、自動化の仕組みは欠かせません。 その自動化がどのような仕組みになっているのか。FacebookのデータベースエンジニアであるShlomo Priymak氏が、Under the hood: MySQL Pool Scanner (MPS)という記事をFacebookで公開しています。 かなり長い記事なので、ここではそのポイントをまとめて解説してみました。詳細はぜひ原文をあたってみてください。 MPSのおもな3つの機能 Facebookで稼働しているMySQLは、つねに1つのマスターとそこからレプリケーションされた複数のスレーブによるレプリカセットを構成しています。このレプリカセットの構造を維持し続けることで、可用性と
Making full table scan 10x faster in InnoDB
At MySQL Connect 2013, I talked about how we used MySQL 5.6 at Facebook, and explained some of new features we added to our Facebook MySQL 5.6 source tree. In this post, I'm going to talk about how we made full table scan faster in InnoDB. Faster full table scan in InnoDB In general, almost all queries from applications are using indexes, and reading very few rows (0..1 on primary key lookups and
第10回 [実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（3） | gihyo.jp
隔週連載groonga 第10回[実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（3） こんにちは、株式会社リブセンスの吉田健太郎です。第8回に続いて、私が体験したTritonnからmroongaのシステム移行プロジェクトを舞台裏からお届けします。 これまでのあらすじ 将来的な技術負債を残さない、そしてInnoDBの性能向上等の恩恵を受けるため、もはやレガシーとなったMySQL 5.0を捨てて、MySQL 5.6への移行を行いたい。しかしSolrへ乗り換えるほどでもなく、引き続きシンプルにSQLを用いた、リレーショナルな日本語対応の全文検索を使いたい。この構想を実現するため、groongaのMySQLバインディング版である「mroonga」を用いた、MySQL 5.6への移行プロジェクトが始動しました。 これまでの記事と、主なトピックは次の通り
![第10回 [実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（3） | gihyo.jp](https://cdn-ak-scissors.b.st-hatena.com/image/square/05b0af51bb41516773d6954ec69cb62b4b24568e/height=288;version=1;width=512/https%3A%2F%2Fgihyo.jp%2Fassets%2Fimages%2FICON%2F2013%2F1099_groonga.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PacemakerのMaster/Slave構成の基本と事例紹介(DRBD、PostgreSQLレプリケーション) @Open Source Conference 2014
Real-time replication from MySQL to PostgreSQL using open source Tungsten
Google Code Archive - Long-term storage for Google Code Project Hosting.