MariaDB

MariaDB

Library

MariaDB とはデータベース倉庫を管理するためのApp。C言語製。倉庫にあるデータを高速に参照/更新/計算したりできる。アプリは基本的にこのデータベース倉庫と連携しながら動くので SQL には十分に精通しておく必要がある。

当然ながら、MariaDB の公式の説明書 や 公式チュートリアル は一通り読んでおく。

クイックメモ

• MySQLリファレンス
• DB設計ポリシー
• MySQLチューニング

セットアップ

1. 設定ファイル etc/my.cnf のモード、所有者、システム変数を確認
2. /var/lib/mysqlディレクトリの所有者を mysql に変更
3. ローカル利用ならリモート接続を禁止
4. 日本語入力のズレを解消

$ mysqladmin -u root -p status
$ ss -tan

SHOW VARIABLES LIKE 'char%';
$ vi /etc/my.cnf

[mysqld]
skip-networking
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

• character_set_system は MariaDB の内部システム用の設定 だから、utf8mb3 のままでOK

セキュリティ

DELETE FROM mysql.user WHERE User='root' AND Host NOT IN ('localhost');

リモートから root で MariaDB にログインできると危険なので削除。

rootのパスワードリセット

一旦MariaDBのプロセスを落としてからセーフモードで起動、パスワードを設定してMariaDBのプロセスを再度起動させてやるだけ。

# systemctl stop mariadb
# mysqld_safe --skip-grant-tables &
alter user 'root'@'localhost' identified by 'new_passwd';
# systemctl stop mariadb
# systemctl start mariadb

以上。できなかったら「flush privileges」してから。

設計ポリシー

要点リスト

Database normalization。データベースを正常な状態にしておく。

• そのテーブルの主人公は誰（なに）なのかを主キーで明確にする
• そのテーブルはどのような「状態」の述語なのかを明確にする
• 実世界において２つの事柄を同時に認識することはできない
• ゆえに認識の鏡であるテーブルにも２つの概念を混ぜてはいけない
• ２つの概念が混じっているように感じるならテーブルを分けるべき
• テーブルを分けた時は外部キーを利用して両テーブルの整合性を保証
• １つの変更が多数箇所の修正に結びつく場合もテーブルを分けられるかも
• カラムに定義する属性は実世界の「状態」を適切に表現しているべき
• 例えば、id と cat_no は違う。id は各要素のID、cat_no はカテゴリ番号
• でも外部キーを追加するには一意性制約があるので上記２つをまとめても良い
• 命名はすべて短くて適切で本質的な表現であるべき
• １つの「状態」を２度も記述するような冗長なカラム設計は避けるべき
• NULL を許すと世界が 3VL になってしまいアプリ設計が非常に複雑になる
• NULL を許すとそのテーブルはオプティマイザとの相性が悪くなる
• NULL を許すとそのテーブルはインデックスとも相性が悪くなる
• NULL が入る余地があるということは DB設計に問題があるかも
• NULL 発生を引き起こす「ありえないデータ」は将来、悩みのタネになるかも
• SQL にはそもそも順序という概念がないので手続き型ロジックの実装は高負荷
• ゆえに、手続き型のロジックに頼るのは最後の手段にする
• 空間や時系列を表現したいのであれば RDB はやめる

データベースの本質

データベースの本質は「実世界のデータ構造」のパラレルワールドをマシンの中に創造すること。ゆえに、データベースとは人間の認識を反映する鏡だと言える。

実世界（やその状態）を「パラレルワールド」としてマシンの中に複製すると、遠隔マシンにバックアップしたり、自作アプリと連携させたり、AIと抱き合わせて情報分析したりと、色々なことができるようになる。

RDB の場合、主にリレーション（テーブル相互の関係性）という表現手法に沿って実世界（やその状態）を整理しつつパラレルワールド化していくことになる。ちなみに、他の表現手法には NoSQL や DIT などがある。

データベースの設計

データベース設計においては特に、以下２点を強く意識すべき。

1. マシンパワーの活用を大前提としたデータベース設計
2. 目的から逆算した実世界データ構造のパラレルワールド化

マシンパワーが大前提

データを管理するだけであれば別に紙やノートを使っても良いはず。わざわざマシンにデータ管理を任せるのだから「マシンにしかできない何か」を強く期待しているはず。つまり、マシンパワーの活用と目的の実現とのバランスをしっかり前提とした上でテーブル設計やチューニングすることが大切。

実世界の「本質」を適切に表現

データベースの活用とはつまり実世界データ構造のパラレルワールド化。ゆえに、実世界を適切に認識し、その本質的な状態を適切にデータベースにアップロードしていく必要がある。

しかし、実世界の本質的な状態とは流動的で常に変化していくもの。この性質をしっかりと踏まえ、将来を見越したデータベース設計をする必要がある。

ゆえに、データ構造パラレルワールド化の際には以下３点が特に大切。

1. 実世界の状態や本質を適切に認識する能力
2. 目的から逆算してデータを整理する能力
3. その状態を適切に表現する能力

以上３点があれば、その人は適切にデータベースを設計できる。そのような人は自分の部屋と同様にデータたちのお部屋も綺麗に整理することができるはず。