RDBのトラブルの現場を追え！ ~ 様々な現場を見る ~ / rdb-troubleshooting2builderscon2019の登壇資料です https://builderscon.io/builderscon/tokyo/2019/timetable?date=2019-08-31 # 参考資料 - https://speakerdeck.com/soudai/rdb-troubleshooting - https://soudai.hatenablog.com/entry/2018/05/01/204442
RDBのトラブルの現場を追え！ / rdb-Troubleshooting
そーだいなる DBRE Nightでの登壇資料です https://connpass.com/event/138437/ # 紹介資料 - https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua - https://www.youtube.com/channel/UCeenIljXnSwrwYEU-YBE2qA/feed - https://speakerdeck.com/soudai/postgresql-architecture-and-performance-monitoring - https://gihyo.jp/dev/feature/01/dex_postgresql/0002 - https://lets.postgresql.jp/documents/technical/query_analysis/1 - http
AWS、SQL互換の新問い合わせ言語「PartiQL」をオープンソースで公開。RDB、KVS、JSON、CSVなどをまとめて検索可能
Amazon Web Services（以下AWS）は、SQL互換の新しい問い合わせ言語およびそのリファレンス実装である「PartiQL」をオープンソースとして公開したことを発表しました。 PartiQLはSQL互換の構文に最小限の拡張を施すことで、リレーショナル形式のデータベースだけでなく、KVSやJSONなどを含むNoSQLデータベースやCSVファイルなど、さまざまなデータソースに対して横断的に検索できる問い合わせ言語およびそのリファレンス実装です。 下記はPartiQLを発表したブログからの引用です。 Today we are happy to announce PartiQL, a SQL-compatible query language that makes it easy to efficiently query data, regardless of where or in
AWS、利用時のみ自動起動し負荷に応じてインスタンスが増減するマネージドRDB「Aurora Serverless」、正式版に
AWS、利用時のみ自動起動し負荷に応じてインスタンスが増減するマネージドRDB「Aurora Serverless」、正式版に 一般にOracleやMySQLなどのデータベースを利用するためには、あらかじめインスタンスを起動しておく必要があります。クライアントはこのインスタンスに対して接続し、クエリを送信して結果を受け取ることになります。 新しく正式版となったAmazon Web Services（AWS）の新サービス「Aurora Serverless MySQL」は、このインスタンスの起動をオンデマンドで行うことで、クライアントから呼び出されるときだけ起動し、負荷に応じてスケールするRDBです。 従来のAmazon Auroraと同様にバックアップやパッチの適用などはクラウド側で行われるマネージドサービスで提供されるため運用の手間が不要であるのに加え、データベースのプロビジョニングやイ
YAPC::Kansai で RDBアンチパターン その2 について話してベストトーカー賞を取ってきた #yapcjapan - そーだいなるらくがき帳
YAPC::Kansaiでトークしてきました。 yapcjapan.org RDBアンチパターンの話してきました。 去年、PHPカンファレンスでRDBアンチパターンの話をして盛り上がったのでそれの第二弾です。 b.hatena.ne.jp speakerdeck.com 僕が伝えたい事はたったひとつ。 このブログを読んだらすぐ自分たちのサービスのバックアップとリストア手段確認してください！ お兄さんとの約束だぞ！！ このトーク応募したらGitLab.comが大事故起こしたり、S3が落ちたり世の中では大変そうでした。 www.publickey1.jp ヒューマンエラーとかあるんですよほんと。 僕もいっぱい見てきたし、やったし（ぉぃ なので本当にもうこれだけは絶対確認してほしいって思います。 実際に「バックアップ無いDBをバグで飛ばしたんですけどどうすればいいですか？」とか相談来ます。 ほん
リレーショナルデータベースの仕組み (1/3) | POSTD
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
MySQL・PostgreSQLユーザーグループ（MyNA・JPUG）合同DB勉強会で発表した資料を公開しました。「データモデルについて知っておくべき7つのこと 〜NoSQLに手を出す前に〜」
表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPerに知ってほしいRDBな事