投稿元:
レビューを見る
http://tsucchi.github.io/db/2019/03/17/rdb-the-right-way に書きました
投稿元:
レビューを見る
Bill KarwinのSQLアンチパターンの読了後に読みました。
本書はSQLアンチパターンよりも広く、現場で起こりそうなRDBMSにまつわるトラブルに向けた事例集といった趣。
投稿元:
レビューを見る
普段あんまりRDBを設計する機会が少ないので、なかなかピンとこないものも多かったけど、フラグとかソートとかインデックスに関する章は知識として「こういったデメリットにもつながる」ということを知れたので良かった。
投稿元:
レビューを見る
アンチパターンとその解決法を書いた書籍。易しく書かれていて読みやすい。
また、さらに知りたい人のために、おすすめ書籍やWebが紹介されてあり、その点は良いと思った。
前半は設計レベルの話が多く、馴染み深い内容。
後半は運用よりの話で、この先役に立つかもという視点で、参考のために読んだ。
投稿元:
レビューを見る
RDBを利用しているエンジニアには必要な知識。他のデータベース入門書では記載されていないところを、わかりやすく書いてあり、中級者になるには必須の知識と思う。
一体、どれぐらいのエンジニアがこの知識を持っているのだろう。。本書を読んで、システム開発には、RDBに詳しいデータベース管理者は必要だなと感じたが、軽視され、知識の中途半端なアプリケーションエンジニアが兼任している例が多いだろうなぁ。
メモしたいところ;
・やり過ぎたJOIN:JOINのアルゴリズム理解してる?
「WHERE狙いのキー、ORDER BY狙いのキー」
・効かないインデックス:インデックス設定しても効かないことがあるのわかってる?
・ビューとサマリーテーブルの違いわかってる?
・バックアップの種類:論理バックアップ、物理バックアップ、ポイントインタイムリカバリの違いわかる?
・ロックといっても、レベルと粒度を整理しよう
レベル(排他ロックor共有ロック)、粒度(表ロック、行ロック)
・トランザクション分離レベルを理解しよう
覚えておきたい用語:
・マテリアライズド・ビュー
・サマリーテーブル
・遅延レプリケーション
・Varnish :HTTPアクセラレータ
・Redis:RDBMSの苦手なところをカバー
・EAV(エンティティ・アトリビュート・バリュー):複数の目的に使われるカラムを用意する設計
・Polymorphic Associations:子テーブルが複数の親テーブルを持つ設計
・トリガー
・ギャップロック、ネクストキーロック:MySQLの特徴的なロック
投稿元:
レビューを見る
各章の見出しにユーモアとインパクトがあり、またアンチパターンの解説、そしてアンチパターンを生まないためにはどうすればよかったのかをセットで教えてくれるので、なぜ悪い設計のRDBが出来上がるのか、どんな設計をするべきなのかがわかりやすかった。
アンチパターンが引き起こされる事のはじまりは特におもしろく、例えば営業とエンジニアの齟齬からうまれる、
営業「普通追加ボタンがあったら削除ボタンもあるでしょ」
エンジニア「いや追加ボタン一個だけって言ってたじゃん……」
(一章「データベースの迷宮」)
のようなやりとりや、
IDに意味を持たせる設計により、DBの検索がしづらくなる(七章「隠された状態」)など、親しみやすい例が挙げられていた。
データベースのロックやコンフィグ、キャッシュなどはまだわからない部分もあったが、今後もお世話になる本だと思う。初心者におすすめの本。
投稿元:
レビューを見る
DBやSQLに関するアンチパターンが数多くかかれており、自分の認識の甘さを改めて感じることができた。
ベーシックな内容ですが1つ1つがとても大事だと思います。
投稿元:
レビューを見る
実務でもよく見かける例えば「効果の薄いIndex」「多すぎるJoin」「とりあえず削除フラグ」などを例にアンチパターンとその解消方法が紹介されていてとても良かった。
読みながら自分のアプリケーションで場合を考えなら読み進められた。
以下、自分がいいと思った箇所のメモを記載。
### 2章 失われた事実
- 履歴が保存されていることは重要。トラブル対応時に欲しい情報が失われていないか、の観点で履歴の保存は行う
- 例えば、購入した時点の消費税率を、別テーブルで参照しているとき、消費税が変わると、過去にかった金額の消費税率がわからなくなり、返品を行った際に不整合が起きたりする。
- 例えば、配送状態を上書きする仕様にしている場合、過去に配送中だったのか、配送済みになったのか、キャンセルがあったかなどの事実がわからなくなってしまう。
### 3章 やりすぎたJoin
- Joinを多く行うと、テーブルスキャンをする量が指数関数的に多くなり、DBへの負荷も増大する
- 例えば10,000行と10,000行のテーブルのJoinでは100,000,000行のテーブルスキャンがされてしまう。(Indexが貼られていたらその限りではない)
- なのでJoinするテーブルは小さくしてからJoinすることが大事
- Joinには3種類ある
- Nested Loop Join(NLJ):1行ずつループして処理する
- Hash Join:1度に全件読み込んで処理する(MySQLではサポートされていない)
- Sort Merge Join:全件をソートして上から順に比較する(MySQLではサポートされていない
### 4章 効かないIndex
- Indexが効かない(使われない)ケース
- 検索結果が多い、全体の件数が少ない
- 10,000件のうち9,999件取り出す場合など、Indexの意味がない
- 検索結果が全体の20%未満のとき、総レコード数が数万レコード以上あるときに有効
- 条件にその列を使っていない
- where age + 10 > 20)では無理。 where age > 20 -10 ならできる
- カーディナリティの低い列に対する検索
- Men / Womenしかない場合などIndexは意味ない
- あいまな検索
- where like %keyword% はIndexが効かない。先頭文字がないのでIndexは無理
### 5章 フラグの闇
- とりあえず削除フラグとかは危険。テーブルに「状態」を持たせずに済むならそのほうがいい
- ユニーク制約が使えなくなる(emailをユニークにしたいが、退会済みユーザーとemailがかぶるなど)
- カーディナリティが低いが、検索時には状態を含めて検索する必要が出てきてクエリが遅くなる
- もしテーブルに状態をもたせるならば、、、
- 対象のテーブルが小さく、Indexが不要なこと
- そのテーブルが関連するテーブルの親になることがなく、データ取得の際に頻繁にJoinの対象にならないこと
- Unique制約が不要で、外部キーでデータの整合性を担保する必要がない
### 6章 ソートの依存
RDBMSのエグゼキュータの評価順
1. FROM
2. ON
3. JOIN
4. WHERE
5. GROUP BY
6. HAVING
7. SELECT
8. DISTINCT
9. ORDER BY
10. LIMIT
- ページネーションでOffset100,000とかにすると結局100,000件のデータを見ている。where id > 100000 and みたいにするほうがい
### 9章 強すぎる制約
- 強すぎる制約をかけてそれを変更したくなったとき、Alter文での変更などになるがロックがかかりデータ量によっては結構な時間になるので、メンテナンスの時間を設ける必要もでてくる
- ビジネスロジックに伴う制約は変更される可能性があるので、アプリケーション側でのバリデーションにしたほうがいい
### 10章 ころんだあとのバックアップ
- 毎日バックアップをとっているが、いざ必要になったときにリストアしてみたらリストアできなかったみたいなこともある。バックアップが動いていること、バックアップでリストアできることなどもテストしておくといい。
### 11章 見られないエラーログ
- エラーログが出ていない、エラーが定常的にあって、重要なエラーが何か分からず放置されていることもよくある
投稿元:
レビューを見る
# 現場のミスから学べる、実務的なRDBアンチパターン集
## 面白かったところ
* 歴代の偉大な先輩方が経験された失敗談とその対策がたんまり書いてあり、とても実用的
* 特に `Where狙いのキー、order by狙いのキー` の話は目から鱗だった
* この一冊を買うことによって、守られるプロダクトの平和があると強く感じた
## 感想
インフラ層のミスや失敗談はあるっちゃあるけどなかなか共有されない・知ることが難しいトピック。
可能な限りわかりやすく、時にはデータベースの仕様を織り交ぜながら傾向と対策を謳っている当書にはとても感銘を受けた。
技術的な経験値の有無に関わらず、ITプロダクトに関わる人は一読してもシンはしないだろう。
久々に5つ星をつけたい書籍。
投稿元:
レビューを見る
データベースの設計におけるアンチパターンについて、様々な視点で書かれた本。
単純に、データベース設計といってもいろいろ考えなきゃいけないことが多いのだろうなと思った。
『SQLアンチパターン』という本に影響をうけているそうで、あちこちで紹介されてあった。この本も読んでみたい。
著者によると、RDBの寿命はアプリケーションよりも長いとのこと。確かに、アプリケーションを作り直すことはあっても、データベースまで作り直すってことはそうそうないからね。そう考えると、よく考えた設計が必要というのもうなずける。
削除フラグをもつテーブルってよく見るけど、アンチパターンなのか。まあ、確かにSQL書くとき面倒だよね。削除したテーブルを別に用意するのがいいらしい。
インデックスについても、もっとちゃんと意識するようにしたほうがいいのだろうな。SQLについては知っていても、インデックスというのはあまり学んでこなかったし、このへんももうちょっと勉強したほうがよさそう(それこそこの本は、インデックスは知っている前提で書かれてあるし)。
個人的に、管理者と一般ユーザは別のテーブルでもったほうがいいという話に驚いた。普通にやってしまってるなぁ。分けたらログイン時にUNION使わなきゃいけないし。まあ、分ける理由としては、管理者にしか必要のないカラムがある場合、一般ユーザは絶対にNULLになるからということだから、そういう項目がなかったら別にいいのかな。NULLが多くなる設計というのはやめたほうがよさそう。
SQLのLATERAL句というのは初めて知った。他のサブクエリの結果をサブクエリの中から参照できるらしい。いい使い方が思いつかないけど、覚えておきたい。
ログ関連の設定は全く意識したことがなかったけど、やっぱりそれじゃダメだよなとこの本を読んで思った。アプリケーション側でのSQL呼び出しのエラー時のログはとるけど、やっぱDB側でもとっておいたほうがいいんだろうか。デフォルトでどうなってるのかもよく分からないし、もうちょっと調べてみよう。
後は、監視ももっと自動化したほうがいいのだろうなと思った。なんかいいツールがないか、もう少し調べてみようと思う。
投稿元:
レビューを見る
SQLアンチパターンを読んだ後に読むと良いと思う。
この2冊は基礎知識としてしっかりと身に着けたい。
投稿元:
レビューを見る
山崎先生より推薦図書
本書は知識を入れるというより、ケーススタディ的な内容となっている。
0から知識をいれていくというより、実践的な場面での使い方や、失敗事例から学べることなどが書かれているためプロダクトを作っていく段階で参考となる。
MySQLやPostgreSQLを使ったシステム・サービスを設計・運用していて,原因のわからない障害によく出くわす人,そしてそれを改善したい人に向けてのものなので、常に実装をしていくG’sACADEMY生には、良い書籍となるのではないかと思う。
投稿元:
レビューを見る
この本は、データベース設計の失敗例とその解決策を具体的に解説しています。アンチパターンの説明から、それがなぜ問題なのか、そしてどのように解決できるのかまで、一貫して深く掘り下げています。スマートカラム、EAV、削除フラグなど、耳が痛いトピックも避けずに取り上げ、それぞれに対する具体的な解決策を示しています。これにより、読者は自身のデータベース設計を見直し、改善するための具体的なアイデアを得ることができます。また、具体例から始まるため、非常に読みやすく、実践的な知識を身につけることができます。この本は、データベース設計をより深く理解し、自身のスキルを向上させたいと考えているすべての人におすすめです。
投稿元:
レビューを見る
MySQLとPostgresSQLの違いも踏まえて解説してくれるのと例も分かりやすくて読みやすかった
投稿元:
レビューを見る
導入部分もあり、説明がわかりやすい。RDBMSによってロックの特徴があることや、デフォルトのトランザクション分離レベルが違う点は、勉強になった。
「フラグの闇」は今まで関わってきたシステムでも使われており、書かれてる苦しみは確かに感じてきたな〜と。
今回は図書館で借りたが、手元にも持っておきたいと思える一冊だった。