DBメモ

kt

DB設計

正規化

データの重複をなくし整合的にデータを取り扱えるようにデータベースを設計すること
DBの正規化で通常業務に使う範囲は第三正規化まで。

第一正規化：scalar 単一 1つのセルに1つの値しか含まない

関係従属性：

1つのセルに1つしか値を入れてはいけないのは、主キーが各列の値を一意に決定できないから。

第二正規化：

主キーの一部の列に対して従属する列がある場合、この関係を部分関数従属と呼ぶ。
主キーを構成するすべての列に従属性がある場合を、完全関数従属と呼ぶ。

・テーブル内で部分関数従属を解消
・完全関数従属のみのテーブルを作る

ER：entity relationship diagram

物理設計のステップ：

1.テーブル定義
2.インデックス定義
3.ハードウェアのサイジング
4.ストレージの冗長構成決定
5.ファイルの物理配置決定

サイジングはキャパシティとパフォーマンスの2つの観点から行う。

DBの性能問題の8割はディスクI/Oによって起こる

DBに格納するデータ量は、物理的なテーブル定義およびインデックス定義が終わらなければ算出できない
↓
論理設計の終了が前提条件となる

データは増加するので、どの程度増えるか見込まないとストレージの容量が足りなくなってしまう

・安全率を大きくとって、余裕を持たせたサイジングを行う
・後で容量が不足した場合に、簡単に記憶装置を追加できるような構成にしておく
　　スケーラビリティが高い構成

kt

view

selectにつけたあだ名の事。SELECT文。
元々あるテーブルから任意のデータを取り出したり組み合わせたりして作った仮想的なテーブル

Create view huge as select aa from bb

Drop view

ビューとテーブルの違い

実際のデータを保存しているか否か
実際にデータを保存する場合、保存する場所は一般的にHDD等の記憶装置となるが、
ビューの場合は、どこにも保存していない
ビューが保存しているのは、SELECT文そのもの

メリット

データを保存しない為、記憶装置の容量を節約できる
SELECT文を毎回かかなくて済む
削除したかのように振る舞うだけなので、すぐにデータの復元が実現可能
物理削除に比べても処理速度が速い

デメリット

where旬での絞り込み検索を行うときにフラッグの条件を追加する必要がある

ビューの制限

ビュー定義でORDER BY句は使えない

→行には順序がない為

ビューに対する更新

論理削除

実際にデータを削除せず、削除されたと見なすフラッグと呼ばれるカラムを設定すること。
ユーザーには削除しているかのように振る舞うことができることをさす。

多段ビューはNG

ビューへのアクセスは2段階で行われる。
オリジナルのテーブルへアクセス→ビューのテーブルへ反映。

つまり、多段ビューはパフォーマンスを大きく下げる

kt

データクレイジング

DB構築音時に業務で使用していたデータをDBに登録できる状態にすること
設計に先立って行う。

オリジナルのデータ(汚れている)
↓
データフォーマットの調査
↓
データクレイジング
↓
オリジナルのデータ(綺麗な状態)
↓
DB設計(論理/物理)
↓
DBへ登録

例：

・一意キーの特定
・名寄せ

名寄せとは、似通った名前を寄せ集めて統合すること。
名寄せコストを抑える為事前に統一された入力フォーマットを用意して、
最初から名寄せが発生しないデータを作る

名寄せの具体的な方法：

・別の情報と組み合わせて確度を高める
・情報の出現頻度から確認する

→これらはシステム化が可能

kt

パフォーマンスのサイジング

処理時間

何秒以内に終了するか

スループット

単位時間当たりにどれだけの処理をシステムがこなせるか

TPS　Transaction Per Second

性能要件の指標は2つ。
どれだけ速いか、どれだけ多いか。

・類似の稼働中システムのデータを流用する
・開発の初期段階でプロトタイプシステムを構築して、性能検証を実施する

DBが遅延する理由：

kt

ストレージの冗長構成

RAID Redundant Array of Independent Disks

複数のディスクに書き込んで冗長化する、性能を向上させる

複数のHDDをひとつのドライブのように認識・表示させる技術
故障時に、データ復旧・アクセスを可能にする安全性の向上や、複数HDDへの分散書き込みによる
データ保存の高速化など、RAIDモード毎に特徴がある。

災害対策を目的とした、遠隔地へのデータの転送技術を
ディザスタリカバリーと呼ぶ。

RAID0：ストライピング

RAID1：ミラーリング信頼性は強固だがパフォーマンスが弱い

RAID5：パリティ分散

RAID10：RAID1+0 コストが高いが高性能

DBの物理配置：

・データファイル
・インデックスファイル
・システムファイル
・一時ファイル
・ログファイル

kt

バックアップ

バックアップ設計：

・フルバックアップ
・差分バックアップ
・増分バックアップ

フルバックアップの欠点：

・バックアップの時間が長い
・ハードウェアリソースへの負荷が高い
・サービス停止が必要

差分バックアップ：

例：1週間の経過で変更分のみバックアップする

増分バックアップ：

日々、変更分をバックアップする。ただし、リカバリには全てのデータが必要。時間もかかる。

kt

インデックス設計

基本はB-treeインデックス

長所：

・平均点の高さ
・均一性、持続性、処理汎用性、非等値性、親ソート性

作り方のポイント：

・データ量が少ないと効果が薄い
・カーディナリティ(特定の列の値がどのぐらいの種類の多さを持つかを表す概念) の高い列を選ぶ
・更新性能を劣化させるので注意
　　カーナビでいうと地図が急に古くなる状態

kt

parser(パーサー)

ソースコードや構造的な文字データを解析し、プログラムで扱えるデータ構造の集合体に変換するプログラムの事。

ビットマップインデックス

検索に用いられるカラムに対して、その値とレコードとのビットマップを使ってレコードを検索するインデックス。カーディナリティが低い場合に有効。

カーディナリティ

カラムに格納されているデータの種類がどのくらいあるかの値
(カラムの値の種類の絶対値)
OR検索でもインデックスが使用される

ハッシュインデックス

キー値からハッシュ関数で求めた値を使い、レコードの格納位置を決める

スカラ値の基準：分解不可能なもの

SQLのパーティション化：

テーブルの特定のカラムを分割キー(パーティション化キー)として、その値の種類により
テーブルを物理的に複数のセグメントに分割することで、クエリやメンテナンス作業のパフォーマンスを向上させる

kt

エラーが出て調べた事

テーブルの中身を削除
↓
truncate table テーブル名

テーブル定義で出たエラー

DB内の文字がおかしい...

原因：

文字コードがutf-8でない部分があった

テーブル定義の確認方法

show variables：

MySQLの設定値(変数を確認する)

https://teratail.com/questions/268253

文字コードの設定
character_set_client クライアントから送信する際の文字コード
character_set_connection クライアントから送信した文字コードの変換先
character_set_database データベースの文字コード
character_set_filesystem ファイルシステムの文字コード
character_set_results クライアントへの結果送信に使用する文字コード
character_set_server サーバの文字コード
character_set_system システムで使用する文字コード
character_sets_dir 文字コード設定が保存されているフォルダの場所

ログインで設定を変える方法：

mysql --default-character-set=utf8mb4

ログイン時、先頭に--default-character-setをつける

kt

トランザクション等のメモ

トランザクション

DBを更新する時、一連の処理をまとめて実行する仕組み

ロールバック

トランザクション処理が途中で失敗した時にSQLの実行をなかった事にして実行前に戻す

ACDI特性：アシッド

原始性：Atomicity すべて実行されるか、されないかのいずれかの状態
一貫性：トランザクションの前後でデータの整合性が矛盾しない
分離性：トランザクション実行中は、処理途中のデータは他のユーザーの処理からは見えないし、影響もない
永続性：トランザクションが完了したら、永続的に保存される

トランザクション分離レベル

処理の実行中、アクセスを待ってもらうための度合い

①READ UNCOMMITTED　ダーティリードの可能性あり
②READ COMMITTED　ダーティリード解消、ノンリピータブルリードの可能性あり
③REPETABLE READ　ノンリピータブルリード解消、ファントムリードの可能性あり
④SERIALIZABLE　あまり使われない

ロック

データにアクセスしている間に他のユーザーが読み書きできないようにする事

1つのSQL文の実行単位で自動的に設定されるが、一瞬だけなので明示的にロックをかける必要がある

デッドロック

さんすくみの状態
発生した場合、両方とも失敗させることで解決する

DBのパフォーマンスアップや利便性を上げる仕組み

①インデックス：検索を早くする
②ビュー：仮想的なテーブル
③ストアドプロシージャ：命令をまとめて実行する仕組み
④トリガー：特定の動作に連動して処理をする仕組み

ステアドプロシージャ

ユーザー定義関数。複数のSQL文を組み合わせて登録しておける仕組み。

トランザクションとの違い

トランザクション→まとめて実行を保証
ストアドプロシージャ→まとめて名前をつけているだけ

性質上、トランザクションと組み合わせて使用されるケースも多い

トリガー

特定の動作が起きた時にストアドプロシージャを実行する機能

レコードの追記・削除・上書き

kt

インデックス

データにおおよそのあたりをつけて、検索を高速化する仕組みの事

インデックスを設定すると、
設定した列と主キーやインデックス番号を組み合わせた「インデックス」というテーブルが作られる
レコードを見つけやすいように並べ替えたり、似ているものを近くに置く
検索した場合インデックスを探すが、並べ替えられてることでおおよそ何番目くらいの場所にあるかは特定できるため、ありそうなゾーンを調べる。(B tree)
主キーや外部キーの列に自動的にインデックスが作られる
ディスク容量を消費してDB更新時はインデックスも更新するため、パフォーマンスが若干低下する

kt

スキーマ

DBの構造の事

外部スキーマ

プログラムと関わる部分の設計。ユーザーから見たスキーマ。
データのビューや出力データ

概念スキーマ

DBの論理部分の設計
開発者から見たスキーマ。

内部スキーマ

ハードウェアやRDBMSに関わる部分の設計
HDD、メモリ、運用、システム構成など。

kt

クライアントサーバーシステム

クライアントサーバーシステム

サーバーにシステムを置き、クライアントからサーバにアクセスして使う仕組み。
システムすべてを1つのPCに入れて使う事をスタンドアロン型という。

3階層のクラサバ型システム

クライアントアプリサーバ DBサーバ

PG サーバ側PG DB、DBMS

Webサーバの定義：

ApacheやnginxなどのWebサーバソフトをインストールしたサーバの事。
Webブラウザからの接続を待ち受け、接続があるとその要求に対するコンテンツを返す。

サーバの段階ではHTMLと、画像や動画は別々に保存される。
ブラウザからの要求に対し、サーバ側は該当するコンテンツをバラバラのまま返し、
ブラウザがそれらを組み立てて表示する。

kt

SQL文メモ

CONCAT：

文字列を連結します．
なお，||演算子はMySQLでは論理和(OR)として解釈されるため，文字列連結の用途には使用できない．

SELECT CONCAT(‘文字列1’ || ‘文字列2’・・・)

like：曖昧検索

前方一致：~~%

後方一致：%~~

部分一致：%~~%

Like検索

SQLで部分一致検索を行う場合は%（ワイルドカード）を使用する。

kt

リストア・リカバリ・ロールフォワードのまとめ

リストア

保存していたデータが失われた際に、フルバックアップのファイルをDBに戻す作業の事
バックアップを戻す一覧の作業を指す。

mysql -u ◯◯ -p -D ◯◯ < ◯◯.sql

リカバリ

いわゆるデータ復旧の事

データをある状態に戻したい時、
差分バックアップしていたトランザクションログを適用する。
障害などでデータの保存に支障が生じた、データ自体が異常状態になってしまった際に
復旧させるのがリカバリに当たる。

ロールフォワード

ある時点(チェックポイント)で複製したバックアップデータを書き戻し、
その後の更新データ(ジャーナル)を反映して障害発生直前の状態に戻す事。
DBに障害が起こった場合の回復手法の一つ

ロールバックとロールフォワードの違い

トランザクション処理中に問題があった時に巻き戻すか、
障害があった際バックアップデータに入れ替えるかの違い

ロールバック：トランザクション処理の異常時に行う巻き戻し対応。後退復帰。頻度高。

ロールフォワード：障害発生時にバックアップファイルを適用して復旧させる。前身復帰。頻度低。

※どちらもジャーナルファイルを用いて復旧を行う

kt

データの暗号化について

AES_DECRYPT

AESを使用して復号化する

AES_DECRYPT(‘復号化する文字列', '任意のキー')

AES：Advanced Encryption Standard (高度暗号化標準)

アメリカ政府が策定した暗号化規格のこと。

AES

UNHEX

数値の 16 進数表現を含む文字列を返す

HEXとは?

16進数の事

DBの暗号化について

kt

レプリケーション

DBのコピーをとり、複数台のDBサーバーで構成すること。
複数台で運用することで、1つのサーバーへの負担を減らす。

シングルマスタ

1台のマスタとそれ以外のスレーブ(読み込みのみ)

マルチマスタ

すべてのサーバが読み書きできる。

kt

クラスタシステム

複数のサーバシステムと連携して1つのシステムとして運用するシステム。
1つのサーバで障害が発生しても、別のサーバで業務を継続できる。

HAクラスタ

High Availability　冗長化構成

共有ディスク型(大規模、DBサーバー)、データミラー型(Web/APサーバ)

エンティティ

データを属性という形で保持する

DBの冗長化(アクティブ-スタンバイ)

クラスタソフトウェアを用いる
→システムの切り替えを実現するプログラムの事。

クラスタソフトウェアが登録されたサービスについて、正常に動作しているかどうかを確認
↓
ハードビートを用いる
↓
スプリットブレイン(ハードビートの状態が確認できず、フェイルオーバーの判断がつかない事)

アクティブ-アクティブ

・シェアードエブリシング型
・シェアードナッシング型

kt

table space

table space (表領域)

DBMSがデータを保管するためにストレージ上に確保した領域
データの物理的な記録場所で、システムごとに内部形式が異なる。

複数の表領域を高速な装置と低速な装置に分けて使い分けたり、
一つの表領域を複数の装置にまたがって作成し、並列に読み書きを行なって高速化することができる

資料：https://e-words.jp/w/表領域.html

kt

サブクエリ

使い捨てのビュー(select文)

SELECT文終了後には消えてなくなる
階層数には原則制限ないので、サブクエリの中のFROM句にサブリクエリ..といった多段構造が可能

kt

DELETE、TRUNCATE、DROP文の違い

DELETE

データを削除 (FROMで指定)
COMMITしていなければロールバック可能

TRUNCATE

テーブルのデータを削除 (TABLEで指定)
テーブルごと削除してから再作成
DELETE文より高速
ロールバック不可

DROP

テーブルのデータを削除(TABLEで指定)
完全に削除するのでロールバック不可
表構造も残らない

資料：https://www.earthlink.co.jp/engineerblog/intra-mart-engineerblog/2680/

kt

Auto_incrementの設定を変更する

設定値の確認

show table statusで確認

設定値の更新

ALTER TABLE テーブル名 AUTO_INCREMENT=次に採番される値

資料：https://www.tweeeety.blog/entry/2015/04/28/201956

kt

UNSIGNED NULL

オプション (非標準) 属性の事

すべての整数型には、オプション (非標準) 属性 UNSIGNED を指定できます。符号なしの型は、カラムで負ではない数値しか許可しないとき、またはカラムの上限の数値範囲を大きくする必要があるときに使用できます。たとえば、INT カラムが UNSIGNED である場合、カラム範囲のサイズは同じですが、その終点は -2147483648 と 2147483647 から、0 と 4294967295 に変化します。

浮動小数点と固定小数点も UNSIGNED になり得ます。整数型と同じように、この属性は負の値がカラムに格納されるのを防ぎます。整数型とは異なり、カラム値の上限範囲は変わりません。

数値カラムに対して ZEROFILL を指定すると、MySQL は自動的にそのカラムに UNSIGNED 属性を追加します

資料：https://dev.mysql.com/doc/refman/5.6/ja/numeric-type-attributes.html

kt

DBの権限確認、付与

権限の確認

SHOW GRANTS for ユーザー名

権限の付与

GRANT ALL On *.* TO ユーザー名;　-- グローバル
GRANT ALL On db名.* ユーザー名;　-- データベース
GRANT ALL On db名.テーブル名 TO ユーザー名;　-- テーブル
GRANT ALL(col1) On db名.テーブル名 TO ユーザー名;　-- カラム

kt

SQLでデータの中身だけ(insert文のみ DML)抽出する方法

mysqldump -u user -t DB名 > dump.sql

参考：https://qiita.com/katsukii/items/c7709fc501c1eb11603f

kt

mysqlの接続時にToo many connectionsと出てきた時

max connectionsの確認

show variables like "%max_connections%";

現在のコネクション数の確認

show processlist;

max connectionsを広げる

set global max_connections = XXXX;

どのような設定にするのが良いか?

A.

単にコネクション数が増えただけでは、DBサーバの負荷はそこまで増えない見込み

↓　理由

MySQLはスレッドモデルで実装されている
アイドル状態(sleep)のコネクションは、あまりDBサーバのCPUやIOリソース使用量に関係しない
メモリは多少必要

影響するのは、アクティブなコネクション数と、スレッドで実行されるSQL

SHOW GLOBAL STATUS LIKE 'Threads_%';

アクティブなコネクション数：Threads_running

現在のコネクション数：Threads_connected

注意点：

DBの負荷はコネクション数以外の変数の影響が大きく、
コネクション数だけではコントロールできない

↓
コネクション制限で過負荷を回避するのは困難
↓
Thread Poolという機能が役に立つようだ

引用資料：https://mita2db.hateblo.jp/entry/2020/05/31/175523

kt

SQLモードについて

サーバー SQL モードは、MySQL でサポートされる SQL 構文、および実行されるデータ妥当性チェックの種類を定義します。これにより、MySQL をさまざまな環境で使用したり、MySQL をほかのデータベースサーバーと一緒に使用したりすることが、さらに容易になります。

NO_ENGINE_SUBSTITUTION

CREATE TABLE または ALTER TABLE などのステートメントが無効またはコンパイルされていないストレージエンジンを指定したとき、デフォルトのストレージエンジンの自動置換を制御します。

解説記事：

kt

mysqlのストアドファンクションインポート時にエラー

エラー内容：

ERROR 1418 (HY000) at line 2810: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

解決方法：

log_bin_trust_function_creatorsを有効にする

状況：

ストアドファンクション入りのDDLを対象データベースにdumpしようとしたが、
以下のエラーが発生。

エラー内容：

ERROR 1418: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)

対応：

設定の確認

SHOW VARIABLES LIKE 'log_bin_trust_function_creators';

log_bin_trust_function_creators	OFF

rootユーザーに、権限を付与して再度dump

mysql>SET GLOBAL log_bin_trust_function_creators = 1;

参考記事

kt

DBにSSH接続しようとすると怒られる

こちらの対応で解決

具体例：

SSHのホストキーが変化した事によるSSH接続エラー
対応はknown_hostsファイルからホスト鍵を削除すればOK
手順に沿って行えば比較的簡単で、
$HOME/.ssh/known_hosts をcat等で表示する(.sshディレクトリがHOMEにあるとした場合)
例：

.ssh % cat known_hosts
github.com,~~~ ssh-rsa 
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
[example.com]:××××,[...]:××××

対象のホストを入れて以下のコマンドを打鍵

ssh-keygen -R '[example.com]:××××'

kt

バックアップしたDBをリストアしようとするとGTIDエラーが出てしまう

@@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

GTIDとは

グローバルトランザクション識別子の事

発生元のサーバ(マスター)で作成され、コミットされたトランザクションに関連づけられる一意識別子。
サーバはもちろん、特定のレプリケーションセットアップ内のすべてのサーバに一意となっている。

公式：https://dev.mysql.com/doc/refman/5.6/ja/replication-gtids-concepts.html#:~:text=グローバルトランザクション識別子 (GTID) は,のサーバーに一意です。

対応策：https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0025
詳しい解説：https://hiroi10.hatenablog.com/entry/20130308/1362765495

マルチAZのRDS mysqldump注意点：

kt

binlogについて

Server層が出力するログ

binlogは、レコードの更新内容を保存します。誤って削除したデータを復元する場合、binlogを利用します。データベースのバックアップをベースに、バックアップ時点から指定時点の間のbinlogを適用することで、指定時点のデータを復元できます。

引用資料：https://www.ipride.co.jp/blog/3660

kt

Where旬とHaving旬の違い

Where句はselect句の結果からwhere句で指定した抽出条件を実行する
Having句はGroupBy句でグルーピングした結果からHaving句で指定した抽出条件を実行する

SQLが実行される順序は以下のようになっており

FROM → WHERE → GROUPBY → HAVING → SELECT → ORDERBY

GroupByでグルーピングする前に抽出するのがWhere句で、
 GroupByでグルーピングした後に抽出するのがHaving句

引用資料：

kt

DBのトランザクション分離レベルに関して色々

トランザクションの分離

トランザクション(SQLをひとまとめにした処理)は全て直列に処理される訳ではなく、
同時にリクエストが飛んでくる場合、並列に処理されることも
↓
競合状態が発生する可能性がある
↓
DBでは、並列処理されたにも関わらず直列に処理した場合と同じ結果が得られるように実装を工夫
↓
トランザクションの分離性

分離性を上げれば上げるほどパフォーマンスは下がる

MySQLのストレージエンジン、InnoDBでは以下
下にいくにつれて分離レベルが上がる

READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE

REPEATABLE(再現性)
SERIALIZABLE(シリアル化可能)

デフォルト = REPEATABLE READ

ネクストキーロック（ギャップロック）

ファントムを回避するためのロックの仕組み
REPEATABLE READ分離レベルでは、上記カウントクエリの場合
「指定値~無限大」までをロックすることによりファントム問題を防ぐ
これがネクストキーロック

デッド解決方法

分解レベルを下げる
READ COMMITTED分離レベルの場合ギャップロックが掛からない

トランザクション分離レベルの性質で発生する問題

ダーティーリードDirty Read

トランザクションBでコミットされていないデータをトランザクションAで読み取ってしまう問題

ファジーリード・ノンリピータブルリードFuzzy Read/Non-Repeatable Read

トランザクションAでデータを複数回読み取っている途中で、トランザクションBでデータを更新して
コミットした場合、トランザクションAで違う結果のデータを読み取ってしまう問題
(非再現性リード)

ファントムリードPhantom Read

トランザクションAで一定の範囲のレコードに対して処理を行っている途中で、
トランザクションBでデータを追加・削除してコミットした場合、
トランザクションAで幻影のようにデータが反映される為、
処理の結果が変わってしまう問題

トランザクション分離の種類

分離レベルダーティリードファジーリードファントムリード
READ UNCOMMITTED ○ ○ ○
READ COMMITTED 　　× ○ ○
REPEATABLE READ　　 × × ○
SERIALIZABLE 　　× × ×

引用資料：

kt

create userでユーザーの作成

# ユーザー作成
create user #### identified by '####';
grant all privileges on ####.* to ####'%';

identified by の後に設定したいパスワードを入力する

メモ

権限のメモ：

kt

DBの構造化・非構造化について

構造化データ

データストレージに配置される前に要件定義される
ある定められた構造となるように整形されたデータのこと

例：リレーショナルDB

メリット：

ビジネスユーザーが簡単に利用可能
多くのツールを利用する機会が増加

デメリット：

目的を事前定義することによる利用の制限柔軟性、ユースケースが制限される
データウェアハウスに保存されるが、要件に変更があると全ての構造化データの更新が必要となる

非構造化データ

ネイティブな形式のまま保存され、使用時まで処理されないデータ

例：
メール、ソーシャルメディアの投稿、プレゼン、チャット、衛星画像など

メリット：

データの用途を柔軟に変更できる
データを事前定義する必要がないため素早く収集できる
データレイクに保存されるのでコストダウン

デメリット：

データの準備、分析にデータサイエンスの専門知識が必要となる
専門ツールも必要

引用資料

kt

強整合性と結果整合性について

強整合性

変更中のデータが完了するまで他の人は古いデータが参照できない
↓
データは一貫性（整合性）が保たれている、最新のものである

結果整合性

変更中のデータが完了していない間も他の人は古いデータを参照できる
↓
参照しているデータが古い可能性がある

強整合性と結果整合性の違い

データのコピーに関して強整合性の場合

1つのコピーが変更されると、全てのコピーが変更されてから読み取り可能になる

結果整合性の場合

データが更新されると、1つのコピーが変更された後、その他のコピーは非同期で変更される

結果整合性を使用するとデータの書き込み処理は早くなるが、
データを読み取る時に古いデータを取得する可能性がある

NoSQLデータベース = 結果整合性

DNSも結果整合性　必ずしも最新の値を反映しているとは限らない

引用記事：

kt

DDL,DML,DCLの整理

DDL

Data Definition Language

create,drop,truncate table,alter table
テーブルを作る、削除する、変更する

DML

Data Manipulation Language

select,insert,update,delete
selectしたりインサート、アップデート、デリート

DCL

Data Control Language

begin,commit,rollbackなど
トランザクション制御系

deleteはDML
dropやtruncateはDDL

引用資料：

kt

mysqldumpslowについて

参考記事：

kt

QPS

Queries Per Second　クエリ毎秒
検索システムやデータベースなどが、1秒間に外部からの問い合わせを処理する件数

類似語：

RPS：Request Per Second
リクエスト毎秒

TPS：Transactions Per Second
トランザクション毎秒

引用資料：
https://e-words.jp/w/QPS.html

kt

MySQLのEXPLANについて

クエリがどのように実行されるかを確認する
DBのパフォーマンスが悪い時のクエリ調査に使える

kt

MVCCについて

記事：

kt

DEFINER関連

DBユーザーを削除した時に障害となっていた原因

公式での関連記事

kt

MySQL5.7から追加されたセキュリティー機能

DBユーザーアカウントロック等で参考にした

公式

kt

ソルト付きハッシュのソルト保存について

徳丸さんの記事整理：

登場用語整理

ハッシュ値
↓
あるデータを特定の計算手順（ハッシュ関数）を用いて固定長の文字列や数値に変換したもの

特徴：

一貫性 (同じ入力から常に同じハッシュ値が生成される)
固定長出力ハッシュ関数の出力は固定長
高速計算
衝突耐性

ユースケース：

ユーザーログインでの認証
↓
入力されたパスワードをハッシュ関数で変換し、DBに保存されているハッシュ値と一致
するか確認。一致すればログインが許可される。

ソルト：

単純なハッシュ関数を使用すると攻撃手法(辞書攻撃、レインボーテーブル等)で特定される恐れがある
↓
パスワードにランダムなデータ (salt)を追加してからDBに保存
↓
saltを使用することで同じパスワードであってもユーザーごとに異なるハッシュ値が生成される
↓
攻撃に対する防御性を高められる

平文でなくハッシュ値で保存する理由

漏洩時のパスワード利用を遅らせる
管理者への秘匿化
暗号鍵も盗まれる前提

復号可能で暗号鍵管理が必要な暗号化ではなく、ハッシュ値での保存をする
レインボーテーブル対策に見かけのパスワード長を長くする

ソルトの保管場所

ハッシュ値と共にデータベースに保存する
Modular Crypt Format(MCF)を用いて保存する

ハッシュ値とソルト、ハッシュの方式はセットでファイル内の1行にまとめて保存する
これらの情報はパスワードの照合に必要なので、セットで保存されている

MCFは元々はUnix/Linuxのパスワード保存ように考案されたもの
現在ではウェブアプリケーションでパスワードを保存する場合でも標準的に用いられている

流失後のリスク

時間をたっぷり掛ければ破られるのが、ハッシュ関数は一方向なので、ハッシュ値とソルトから、数式などで平文パスワードが算出できるわけではなく、辞書攻撃や総当たり攻撃が必要となる

kt

NoSQLの選定について

以下のユースケースにマッチする

スケールしても運用が変わらない
低レイテンシー・高スループット
スケールするWebセッション
PubSubモデル
イベント処理
JSONなどの複雑なデータ格納
ビッグデータ処理
ソーシャル、グラフ、BOMツリーの検索

参考記事：
chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://d1.awsstatic.com/events/jp/2018/summit/tokyo/aws/59.pdf

DB設計

view

ビューとテーブルの違い

メリット

デメリット

ビューの制限

論理削除

多段ビューはNG

データクレイジング

パフォーマンスのサイジング

ストレージの冗長構成

バックアップ

インデックス設計

parser(パーサー)

エラーが出て調べた事

DB内の文字がおかしい...

トランザクション等のメモ

DBのパフォーマンスアップや利便性を上げる仕組み

インデックス

スキーマ

クライアントサーバーシステム

SQL文メモ

リストア・リカバリ・ロールフォワードのまとめ

ロールバックとロールフォワードの違い

データの暗号化について

レプリケーション

クラスタシステム

DBの冗長化(アクティブ-スタンバイ)

table space

サブクエリ

DELETE、TRUNCATE、DROP文の違い

DELETE

TRUNCATE

DROP

Auto_incrementの設定を変更する

UNSIGNED NULL

DBの権限確認、付与

SQLでデータの中身だけ(insert文のみ DML)抽出する方法

mysqlの接続時にToo many connectionsと出てきた時

どのような設定にするのが良いか?

SQLモードについて

mysqlのストアドファンクション インポート時にエラー

DBにSSH接続しようとすると怒られる

バックアップしたDBをリストアしようとするとGTIDエラーが出てしまう

GTIDとは

binlogについて

Where旬とHaving旬の違い

DBのトランザクション分離レベルに関して色々

トランザクションの分離

ネクストキーロック（ギャップロック）

デッド解決方法

トランザクション分離レベルの性質で発生する問題

トランザクション分離の種類

create userでユーザーの作成

DBの構造化・非構造化について

構造化データ

非構造化データ

強整合性と結果整合性について

強整合性

結果整合性

強整合性と結果整合性の違い

DDL,DML,DCLの整理

mysqldumpslowについて

QPS

MySQLのEXPLANについて

MVCCについて

DEFINER関連

MySQL5.7から追加されたセキュリティー機能

ソルト付きハッシュのソルト 保存について

登場用語整理

平文でなくハッシュ値で保存する理由

ソルトの保管場所

流失後のリスク

NoSQLの選定について

mysqlのストアドファンクションインポート時にエラー

ソルト付きハッシュのソルト保存について