集計関数の引数やNULLに関する取り扱いについての理解が曖昧だった
- 集計にNULLが含まれる場合の挙動は毎回不安になって調べてしまう
計算式をSELECTするという発想になじむのに時間がかかった、今はそういうものだと無理やり納得している
例えば「合計が～以上」という命令文を考えると、WHERE SUM(X) > 100みたいに書きたくなるかもしれない
結果表がデコボコになって、なんでエラーになるんだろう？　みたいな経験は何度かある。GROUP BYを使うときとか
- SQL学び始めの頃はよくハマっていた
MAX関数やMIN関数は文字列を指定しても使えることを少し前に知って驚いた
前章ではCOALESCEはISNULLで対応することの方が多そうという意見もあったが、たしかにCOALESCE関数だとISNULL関数よりも綺麗に記述できているような気もする

データをグループに分ける

業務内容によって、GROUP BYやHAVINGを使う機会が異なっている
「期間内のデータを、各ショップや会員が属する区分ごとに集計」という場面がすごく多いので、GROUP BYはおなじみ、というかこれなしではテストできない
GROUP BY内のカラムとSELECT内のカラムをそろえ忘れてエラーにしてしまうことが多かった
グループ集計の流れは今まで何となく理解していた状態だったのが今回、明確になった
HAVINGは使い慣れていなくてWHEREと混同してしまいがちなので覚えていきたい
- 集計前の条件がWHEREで、集計後の条件がHAVING
集計結果は処理の流れ的にWHEREでは絞り込めないため、HAVINGを使う必要がある
最初HAVING句を知らなくて苦労した記憶がある……

集計テーブルの活用

PostgreSQLではマテリアライズドビュー（マテビュー）という機能を使って集計テーブルを実現できる
- マテビューは実体を持たない通常のビューとは異なり、処理結果を保持しているため再検索なしで繰り返し参照できる。また、リフレッシュすることで最新の状態に更新が可能
最終的な結果を見るテストの立場ではあまり気にしたことがないかも……。とはいえ、知識としては持っておきたい
扱うデータの種類や規模によって、集計テーブルの更新頻度を調整するのが重要だと思った
- 頻度が高すぎると負荷がかかるし、低すぎると集計結果が古くなってしまうので難しそう
大規模な分析が必要なシステムだと複雑になったりしてメンテナンスが大変

まとめ

本章の内容はもちろん、前章で学んだ内容を振り返りつつ話し合いができたと思います。また今回もチームや業務内容が異なると、使用する関数等に違いがあることがわかりました。私自身SQLの学習を始めて1年ですが、未だにGROUP BYなどを使う際には混乱することが多いため、本章で学習した内容を活かして今後の業務を行っていきたいと思います。次回は第7章「副問い合わせ」です。

2023-06-09

「スッキリわかるSQL入門」読書会レポート vol. 4

読書会

株式会社リゾーム技術部システム開発第1グループの宮野です。
「スッキリわかるSQL入門」読書会　第4回のレポートです。

過去の記事はこちらです

「スッキリわかるSQL入門」読書会レポート vol.1 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol.2 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 3 - リゾームのテックブログ

今回の題材

引き続き、「スッキリわかるSQL入門」を使用しています。

今回から第Ⅱ部「SQLを使いこなそう」に入りました。
第5章「式と関数」を参加者で読み、感想などを話し合いました。

参加人数

今回は6人での読書会となりました。

参加者の感想・意見まとめ

5.1 式と演算子

式・演算子はよく使うというメンバーもいれば、普段の業務ではあまり使わないというメンバーもいました。また、以下のような声が挙がっていました。

別名は製品やDBMSによる。例えばSQLServerで列名を付けずに計算式のままにしておくと「(列名なし)」になる
テーブルの各行は一行ずつ順番に処理される。プログラマなら当然の発想だが、確かに初学者は戸惑うかも

5.2 さまざまな演算子

こちらも、使用頻度・よく使う演算子はメンバーそれぞれでした。
CASE演算子が紹介されていましたが、「使われているSQL文を見たことがあるくらい」という人もいれば「よく使う」という人もいたり……
また、 DBMSによって使用できる演算子が異なるケースについても多く発言がありました。

文字列連結は「||」とあるがSQL Serverだと「+」か CONCAT 関数、など

便利ですが、こういう注意点もあったり。

文字列連結の際には「+」をよく使うが、SQL Serverだと連結する対象がひとつでもNULLの場合、他に文字列があったとしても結果がNULLになってしまうため要注意（NULLはあらかじめISNULLで空文字などに置き換えておく）

5.3 さまざまな関数

こちらもメンバーによって使う機会・使う関数は様々…
そしてやはりDBMSによる違いが話題になりました。

検索して出てきた関数を使用できないということがたまにあった。難しいけど製品のドキュメントをなるべく見るように…
SQL Serverで使ってたあの関数と同じ関数がPostgreSQLに無いかな？無いわ…、みたいなことがあったりする

5.4 文字列にまつわる関数

こちらもメンバーによって（略）
よく使うというメンバーにとっては、この節に登場する関数はどれもおなじみですね…

コードとコードを連結するとか、郵便番号からハイフンを取り除くとか
（5.2で挙がっていた、文字列連結で「＋」を使う際はNULLの対処が必要ですが）CONCAT関数だとISNULL無しでも暗黙的に空文字に置き換わる

5.5 数値にまつわる関数

こちらもメ（略）
普段かかわる業務やDBMSによる差が話題になりました。

データ分析や金額計算をするアプリでは ROUND や TRUNC をよく使うのだろうか？
分析結果はたいてい何らかの四捨五入なのでROUNDにとてもお世話になる
SQLServerだとTRUNC関数は使えない。代わりにROUND関数
powerはべき乗の「べき」のことなのね。ﾊﾟﾜｰ!

5.6 日付にまつわる関数

こちらもメンバーによる使用頻度の違いはありましたが、特にSQL Serverユーザーによる「現在日時はだいたいGETDATE()」という声が多く聞かれました。

GETDATE()で日付取得してCONVERT関数やFORMAT関数で希望の書式に変形

5.7 変換にまつわる関数

この節で紹介されていた関数の中ではCASTをよく使うという声がありました。

数値型を文字列型に変換して連結する
演算子を使用する際、計算するデータ同士で型を合わせる　など

COALESCEはISNULLで対応することの方が多そう…とも。

全体を振り返って

関数はDBMSやバージョンによる差がやはり大きいようで、調べて出てきた関数や以前の業務で使っていた便利な関数が今使用しているDBMSにはない、といった経験が多く聞かれました。
また、現在携わっている製品・業務によって関数を使用する頻度、よく使う関数の種類が全く違うことも印象的でした。
普段見えない世界が見えるのも、チームをまたいだ読書会の面白さかもしれません。

2023-05-24

「スッキリわかるSQL入門」読書会レポート vol. 3

読書会

株式会社リゾーム技術部システム開発第3グループの岡部です。今回は「スッキリわかるSQL入門」読書会の第3回のレポートです。

過去のレポートはこちらからご覧いただけます。

書籍について

使用した書籍は「スッキリわかるSQL入門」です。

スッキリわかるSQL入門第3版 - IT入門書籍スッキリシリーズ (sukkiri.jp)

スッキリわかるSQL入門第3版ドリル256問付き！スッキリわかるシリーズ

作者:中山清喬,飯田理恵子
インプレス

Amazon

今回の学習範囲

今回読んだのは第4章「検索結果の加工」です。

参加者の意見・感想

今回は6名が参加し、お互いに意見や感想を共有しました。

検索結果の加工

検索結果の加工全般について、以下のような意見がありました。当たり前かもしれませんが、担当している製品や業務内容によって、使用するキーワードや頻度が異なってくるようです。

WHERE句の条件指定で済む場面が多いので、あまり使う機会が無い。重複の削除と並び替えをたまに使う程度。
テストでは、アプリ画面と同じ結果になるよう検索結果を加工することがある。
使ったことがない、あるいは初めて知ったキーワードもあった。

DISTINCT - 重複行を除外する

DISTINCTについては以下のような意見がありました。

時々使う機会がある。
会員の重複を取り除いたうえでデータをチェックしたり、会員数を集計することがある。
DISTINCTよりGROUP BYをよく使う。

ORDER BY - 結果を並び替える

ORDER BYについては以下のような意見がありました。今回学んだキーワードの中では最も使用頻度が高そうです。しかし、列番号による指定や順序保証に関して、新しい発見もありました。

プロダクトでもテストでも、大変お世話になっている。
列番号で並び替えの基準を指定できるのは知らなかった。
- しかし書籍にも書いてあるように、列の順番に依存してしまうので、できるだけ使わない方がよさそう。
- 主キーが連番かつ1列目にあるテーブルのデータを目視で確認するとき、SELECT * FROM table ORDER BY 1 DESC のように書くことはある。プロダクトでは使わない。
- UNIONなどの集合演算子を使う場合、単純に列名指定できない制約があるため、その際に利用することはある。
ORDER BY句を付けないと順序保証されない件は注意が必要。
- 大抵は主キーでソートされてしまうので、SQLの実行結果だけ見て安心してしまいがち。しかし実質的にはランダムであり、DBMSの実装に依存しているので、順番が重要な場面では必ずORDER BYを付けよう。
書籍には書いていないが、照合順序や型の関係で、思わぬ順番になることがあるので注意が必要。

OFFSET/FETCH - 行数を限定して取得する

OFFSET/FETCH句について、使ったことがない、あるいは知らなかったという方が多かったものの、各DBMS独自のキーワードを使って同様の処理を行うことは少なくなさそうです。

データ抽出の際は全件取得で問題ないことが多く、あまり使ったことがない。
LIMITを使ったことがある。
- PostgreSQLやMySQL等で利用できる。
TOPはよく使う。
- SQL Serverで利用できる。
- 逆に、SQL Server以外で使えないのを知らなかった。これが無いと不便に感じてしまう…。
- SELECT TOP (n) PERCENT * FROM table のように書くことで、上位n%を取得することもできる。

集合演算子

UNION（和集合）やEXCEPT（差集合）、INTERSECT（積集合）といった集合演算子について以下のような意見がありました。これらの中では、主にUNIONを使うことが多そうです。

集合演算子は全く使ったことがなかった。
UNIONを使った処理自体は時々見かけるが、自分で書いたことはあまりない。
UNIONしか知らなかった。EXCEPTとINTERSECTは使ったことがなかった。
EXCEPTは順番に注意。毎回ちょっと混乱する…。

まとめ

今回はSELECTで抽出した検索結果を加工し、目的に合わせて整形する方法を学びました。今まで使う機会があまり無かったキーワードはもちろん、ORDER BYのようによく使うキーワードに関しても、改めて体系的な知識を得ることができたと思います。

次回は第5章「式と関数」で、第II部に入ります。式や関数を用いて計算を行う方法を学びます。

2023-05-18

「スッキリわかるSQL入門」読書会レポート vol.2

読書会

株式会社リゾーム技術部システム開発第3グループの土井です。「スッキリわかるSQL入門」読書会の第2回レポートです。第1回目のレポートはこちらです。 tech.rhizome-e.com

読書会の題材

前回に引き続きスッキリわかるSQL入門を題材としています。

2回目レポート

2回目は第2章「基本文法と4大命令」と第3章「操作する行の絞り込み」のレポートになります。参加者は6名でした。

それぞれの感想・意見交換

基本文法と４大命令

SQLの基本ルール

SELECT, FROM, WHEREで行を分けて書いている
予約語は大文字で書いている
自分の中での予約語のルールとしては、予約語ではないものと判別しやすいように必ず大文字で書くようにしている
- 予約語には大文字小文字の区別はないけどチーム内でそろえたほうがいいだろう
Transact-SQL (SQL Server) だとセミコロンの使用が推奨されている
Transact-SQL ステートメントの終端記号。セミコロンは、このバージョンの SQL Server のほとんどのステートメントでは必須ではありませんが、将来のバージョンでは必須になる予定です。

引用元:Transact-SQL 構文表記規則 (Transact-SQL) - SQL Server | Microsoft Learn
- セミコロンが必須になれば既存のコードが動かなくなるから推奨のままなのでは？
複数のSQLを続けて書くときは後から読みやすくするためにも末尾にセミコロンを付けたほうが良さそう
文頭がかならずSELECTとかDELETEとかなので、セミコロンがなくても文末は判別できるからかあんまりつける意味を感じない。つけた方が処理が早かったりするのかしら？
- エディターが色を分けてくれるからセミコロンが無くてもだいたいわかる
所属チームではコメントは基本ハイフン2つで書いているイメージ
- ストアドには作成者とか作成・更新日くらいで、処理の補足説明等があまり書かれていないため毎回読むのにかなり時間がかかっている（ストアド仕様書と照らし合わせている…）

データ型とリテラル

型は知っていたが文字列の固定長、可変長それぞれの違いについて曖昧だった
どのデータ型を使えばいいのか？という部分がそもそもどういった型があるかも含めて調べながら進めている
データ型はいまだに戸惑いがち。クエリ実行してエラーになってはじめて気づくとかよくある。テスト業務では既存のテーブルを検索したり加工したりしかしないからよいが、作る立場だとデータ型はすごく気を使いそう…
「ダブルクオーテーションはSQLの文字列リテラルとして用いることは出来ません」
- 最初の頃は結構混乱していた覚えがある
文字列型はvarcharかnvarcharしか使ったことがない(SQL Server)
CHARとVARCHARが入り混じってる時はめちゃ混乱する…
- つい最近も連携されるCSVデータの項目にCHARとVARCHARが入り混じってた
最近だとCHAR型からVARCHAR型に変換する際に、後ろの空白をすべて取り除く必要があり記述が大変だった
- char varchar が混ざると半角スペースで埋まってたり、埋まってなかったりで後処理が大変だった

SQLの命令体系 /SELECT文 - データの検索/UPDATE文-データの更新/DELETE文-データの削除/INSERT文-データの追加

SELECT以外の他の3つはUPDATE SET, DELETE FROM, INSERT INTOみたいに固有の部分とセットで覚えていた
テキストの体系図が分かりやすかった。
ASはデータ抽出する際に項目名をそのままエクセルの表のヘッダーとかにするためよく使う
アスタリスクを使うとASで列に別名をつけれないのであまり使ってない
「SELECT * FROM」はデータベースの設計変更の影響を受ける危険性あって注意が必要
WHERE句忘れは油断しているとやりがち。UPDATEやDELETEを使うときは、あらかじめトランザクションを開始しておき、その中で動作確認するようにしている。そうじゃないと事故る…
UPDATE/DELETE時のWHERE句の付け忘れはマジで注意…（身に覚えあり）
- 前回も話に出ていたが、まずはWHERE句付けた状態でSELECTしてみて、更新/削除対象のレコードだけがSELECTされることを確認してから命令部を書き換えるのを徹底している（当然トランザクションもかける）
UPDATEとDELETEはそこだけ書き換えたら動くし要注意
- トランザクションかけたり、先にFROM～WHERE～を記述しておいたりすれば防ぐことが出来る
普段の業務では、他のテーブルを参照してデータを生成することが多いので、INSERT～VALUES～よりINSERT～SELECT～のほうがよく使うかも
FROMを先に書くとインテリジェンスが効く

4大命令をスッキリ学ぶコツ

検索系、更新系で覚えていたから既存系と新規系の分類方法は知らなかった
テキストが推奨する記述順には違和感があった
SQL、というかプログラミングはとにかく手を動かして覚えるのが一番早い

操作する行の絞り込み

WHERE句による絞り込み

SQL文を作成する際にWHERE句は欠かせない存在
取得したいデータの項目を並べたとしても絞り込みの条件をWHERE句で指定しないと意味のないデータになってしまう

条件式

対象となるデータを指定するためにWHERE句を使う
WHERE句は条件を指定
- 行を指定するのも本質的には条件
- テキスト内のINSERTで使えないのというのはWHERE句なしで列を指定しているからでは？
例である数値の足し算は書くとしたらSELECTになる

様々な比較演算子

比較演算子は数値か日付で使う
IS NOT NULLをよく使う。boolean型だったらIS TRUEとか
NULLの判定で、IS NULL/NOT IS NULL演算子を使うのはSQLの特徴。最初の頃は＝を使ってしまい期待とは違い挙動によくなったりした
NULLを比較演算子で判定できないのはなんとなく知っていたが、理由は初めて知った。
- 比較演算子は値同士を比較するもの。NULLは値ではないので、比較すると結果がUNKNOWN (TRUEでもFALSEでもない！)になってしまう
「条件式の結果はTRUE,FALSE,UNKNOWNの3つの結果がある」
- てっきりNULLもFALSEとして判定されてるとばかり思ってたが、厳密には違うっぽい
最初のころ「=NULL」と書いてしまった経験はある。「値ですらない」と今回読んで納得した
NULLの扱いは難しいし、出てきたら気を付けるようにしている
- そもそもNULLでいいのかとか
直近の業務で、NULLの場合と空文字の場合の両方を考慮しなければならない部分がありかなり混乱した…
LIKE演算子はあまり使わない(使う機会がない)
LIKE演算子はストアドでよく見かける（それこそ部分一致検索で）
- パターン文字にアンダースコアを使う場面はあまり見かけることが無いため忘れてしまっていた
BETWEENとINはよく使うが、ANYは一度も使ったことが無い気がする
BETWEEN演算子もあまり使わないが日付やIDの範囲指定とかで使うときはある
IN演算子はカラムの値が限られている（決まっている）時に使うことがある。例だと都道府県、業種など
ANY, ALL演算子は使ったことがない
- というか知らなかった
- いつもOR演算子で分けてた
「>」「<」と「=」の順番が分からなくなったときは頭の中で読み上げるようにしている
結構な頻度で「<>」を「!=」と書いてしまいがち
- これは確かにやってしまう
- Excelでも「<>」が使われている

複数の条件式を組み合わせる

AND, OR演算子も使うことは多い
データ抽出は条件が一つということはあまりないので多くの場合、ANDやORが含まれている
論理演算子の優先度に注意
- ()を使って明示的にしたほうがリスクが減りそう
AND、OR等の優先度を意識したことはあまりなく、括弧を使用して調整することが多い

主キーとその必要性

Railsだとテーブルを作成する際にIDの項目が自動的に作られる
- そのため、主キーよりも外部キー制約とかを意識することが多い
主キーが連番になっているデータはよく見るが、代替キー (サロゲートキー) といった呼び名はあまり意識したことがなかった。
人口キーや代替キーといった呼び方は知らなかった

まとめ

今回の読書会では文法に関する内容だったので業務での経験を交えながら意見交換を行えました。所属するグループによってはあまり使わない条件の演算子があるといった違いもありましたが、全員「UPDATEとDELETE」へはかなり注意をしているという部分では話が盛り上がりました。

次回は第4章「検索結果の加工」になります。次章で第1部が完了となります。

2023-05-09

「スッキリわかるSQL入門」読書会レポート vol.1

読書会

株式会社リゾーム技術部システム開発第4グループの平松です。「Linux標準教科書」読書会が終わり少し間が空きましたが今回も社内で有志を募り読書会を始めました。その内容をレポートにしていきたいと思います。

読書会の題材

題材として選んだのは、スッキリわかるSQL入門第3版ドリル256問付き！スッキリわかるシリーズです。

スッキリわかるSQL入門第3版ドリル256問付き！スッキリわかるシリーズ

作者:中山清喬,飯田理恵子
インプレス

Amazon

SQLの基礎からDB設計までを体系的に学べることができるかと思い、この本を選びました。

読書会の進め方

読書会の進め方はリゾームのテックブログで投稿している他の読書会記事と同じです。

読書会当日までに指定の章を事前に読んでおく
感想や疑問点をまとめて、Yammerにアウトプットする
当日、感想をそれぞれ発表して意見交換を行う

他の読書会記事はこちら

「現場で役立つシステム設計の原則」読書会レポート vol.1 - リゾームのテックブログ
 「入門監視」読書会レポート vol.1 - リゾームのテックブログ
 「Linux標準教科書」読書会レポート vol.1 - リゾームのテックブログ

1回目レポート

初回は第1章「はじめてのSQL」のレポートになります。参加者は7名でした。

それぞれの感想・意見交換

データベースとは

リゾームでは使用しているRDBMSとしてPostgreSQL, MySQL, SQLite, SQL Serverがある
担当製品で使用しているRDBMS以外は画面を見たことすらない
SQLが何の略かを書いていないのはなぜだろう？
- 現在、ISOの規格ではSQLを何かの略語として扱っていないらしい
列のことはカラムと呼ぶが行のことをロウって呼ぶ人は全然いない
どのDBMS製品でも基本は同じと書いてあるが、どの製品も色々と拡張しているイメージの方が強い

はじめてのSQL

SQLで何かするときはSELECTを使うことがほとんど
- INSERT, UPDATE, DELETEはあまり使ったことがない
テストデータの作成でINSERT, UPDATEを使用することがある
動作している環境に対して更新系のSQLを実行したことはない
- アプリケーションの制約の手の届かないところでデータを変更してしまうとデータの整合性が取れなくなってしまう場合があるため
PaaSのHerokuにはDataClipsというSQLを実行できる環境があるため、データ抽出する際はそこから操作している
テストチームで最初に渡されたクエリが「SELECT * FROM テーブル名 WHERE なんとかかんとか」だった
dokoQL はおもしろい。環境用意しなくてもSQLを試せるのはいい
- いつでも初期状態に戻せるので、安心してUPDATEやらDELETEやらできそう
テーブルやカラムの名前をつけるのは割と難しい
- テーブル名が英語の場合は複数形にするか単数形にするかという問題がある
- ローマ字表記の場合はヘボン式で統一するのも大事
SQLを書くとき、フォーマットどうするの？という問題もある
- 一般的なプログラミング言語だと自動フォーマットがかなり普及しているけど、SQLは人によって書き方がバラバラな印象
  - カンマの位置とかインデントとか
- 使ったことないけど、SQLFluffというlinterがあるみたい
初めて触った時はエクセルとか表計算ソフトみたいだなと感じた
同じDBMSでもバージョンで挙動が違う事が多いため検索などする際は注意
UPDATE、DELETE等で既存のレコードを変更する際には、WHERE句の指定が合っているかチェックするためにまずSELECTで対象を確認してから流すようにしている
業務を通してSQLを学んだので改めて書籍で体系だった知識を身につけたい
RailsだとActiveRecord経由でデータの操作をするため、直接SQLを書くことは少ない

まとめ

SQL自体の説明からSQLでどのようなことができるかなど基礎的な説明がほとんどでしたが、それぞれの担当製品で使用しているRDMBSについての話やどのような場面でSQLを使用することがあるかなど業務内容に沿った話を多くすることができたと思います。次章は「基本文法と4大命令」で、文法の内容に入っていきます。ここでも業務や経験と絡めた感想を共有していきたいと思います。

2023-03-01

「Linux標準教科書」読書会レポート vol.11

読書会

株式会社リゾーム技術部システム開発第2グループの土井です。「Linux標準教科書」読書会の第11回レポートです。第10回目のレポートはこちらです。 tech.rhizome-e.com

読書会の題材

前回に引き続きLinux標準教科書を題材としています。

11回目レポート

今回は「第12章ファイル管理」で、参加者は6人でした。

それぞれの意見交換

Linux のファイル管理

ルートディレクトリ直下の各ディレクトリがそれぞれ何用のディレクトリなのか曖昧なまま使っていた
業務でよく使うディレクトリはhome, 設定の変更のetcとログ調査目的のvar
昔のサーバはetcではなく、optに設定ファイルを置いている事があり、どこに設定ファイルがあるか分からない事があった
改めて考えると、ディレクトリで階層構造でファイルを保管できるというのは便利
大学時代研究でラズパイを操作するにあたって設定やログが/usr/etcや/var/logにあるのは調べたことがあったがFHSで定められているということは知らなかった
FHS(File Hierarchy Standard)
- 設定ファイルがetcディレクトリ、一般ユーザー用プログラムはbinディレクトリにあるのは理解していたが、そういった決まりがあるのは知らなかった

ディスクのパーティション

パーティションの作成等はしたことがない
パーティション分割したことはない
パーティションについてはそもそも知識がなかった
- 実際に構成だったりを考える部分が特に難しそう
GPTという管理方式だとパーティションが4つまでの制約とかもないみたい
- 拡張、論理があるのはMBRという管理方式
- GPTに対応しているコマンドもある。gdiskコマンド
既に利用しているハードディスクのパーティション操作等、注意すべき点がいくつかあるため覚えておく
業務でハードディスクを増設したり、パーティションを作成したり、というのはあまりないかなあ
パーティションの一覧の見方(fdisk -l)とかは、覚えておくとトラブル時に役に立つかもしれない
MBR・GPTの両方に対応した、パーティション操作のコマンドとして、partedというのもある
意識してパーティション分けたことなかった
パーティション分けるとアクセス速度が上昇するのは、検索スコープが分かれるからなのかな

ファイルシステム

ファイルシステムを作成したことがない
df -Tでファイルシステムも表示される
dfコマンドはディスクの使用状況を確認する時によく使う
dfコマンドはディレクトリを指定することもできる
ファイルシステムごとのディスクの使用量は、df -h でよく確認する
ubuntuのファイルシステムを確認するとext4だった
ext3もしくはext4が多く利用されている
Windowsで利用できるファイルシステムについてはいくつか聞き覚えがあった
普段意識していない部分の話で特にジャーナリング機能の部分はなるほどとなった
ジャーナリング機能というのは初耳
- 読んでもよくわからなかったけど、これで実行コマンドを記録指定あるから、途中で強制的に終了されてもコマンドを見て書き込みを終了できる(書き込み中のファイルをなかったことにできる)ってことかな

マウント

mount,unmountコマンドは使ったことがない
マウントの単語自体はDockerとかでも出てくる
EC2にS3のマウントする時に使ったかな、他はDockerでホストのディレクトリをマウントするとかで出てくる
マウントするために利用するディレクトリをマウントポイントと呼ぶことを初めて知った
AWSのハンズオンでマウントを行った記憶がある(復習しようと思った)
OS起動時にマウントするには、/etc/fstabファイルを編集する
WindowsだとSSDとかHDDがC:とかD:とかE:とかにマウントされて使えるようになるよね
マウントを意識したことないからこれもLinuxならではって感じなんだろうか

スワップ領域の作成

パーティションをスワップ領域として使うのにスワップファイルシステムを作る必要があることを初めて知った
スワップ領域の有効・無効化用のコマンドがあるのはわかりやすい
メモリのメトリクス監視でスワップ領域が表示されるが、どういう仕組みかは分かっていなかった(利用していないメモリ上のデータを一時退避する場所)
メモリサイズと同じサイズでハードディスクのパーティション領域を作る
スワップファイルシステムをパーティションに作成し、スワップ領域として利用する
パーティション領域は mkswap コマンドで作り swapon コマンドで有効にし swapoff コマンドで無効にできる
スワップについてイマイチわかっていなかったため勉強になった
実際に作成したことはこれまでなかった
- スワップ領域は作成した後に swapon コマンドを実行しなければ有効化されないという部分は意識しておきたい

自動マウント

/etc/fstab ファイルに記述しておけば自動マウントされるのは知らなかった
mount コマンドで /etc/fstab の設定で自動マウントする
fstabはfile systems tableの略
/etc/fstab にある設定ファイルに自動マウントの設定を書ける
S3を自動マウントする時にfstabを設定した記憶がある
やや記述が面倒な印象を持った
自動でできることを知っていないと、この設定を書き換えようとはならないため今後覚えておきたい

CD/DVD/USB メモリ (リムーバブルメディア) の利用

リムーバブルメディアを使う場合はマウントする必要がある
mount コマンドでディレクトリを指定して手動でマウントする必要がある
メディアを取り出す前に umount でアンマウントする必要がある
Windowsだと、自動的に○○ドライブに割り当てられるが、Linuxだと手動でマウントする必要がある
- だが、LinuxでCDやUSBメモリを利用する機会はあまりない
Windowsでは意識しない部分だったため、なるほどと思った
ラズパイでリムーバブルメディアを接続するときそういえばマウントって単語が出てきた気がする

i ノード

ファイルやディレクトリごとにiノード番号を割り振られる
- そのためiノードの容量が足りなくなると新規にファイルを作成できなくなる
- ディスクに空きがあっても、iノード領域に空きが必要
- ファイルを作成する際はデータ領域の空き容量だけではなく、iノード領域の大きさも意識する必要がある
ファイルシステムにファイルを作成する際にiノード領域が足りないと作成できないことは注意していきたい
ファイルシステムを作成した時にiノード領域が確保される
ファイルシステムには、データ領域の他にファイルごとの場所やアクセス権限などを管理するiノードと呼ばれる領域がある
df -i で確認可能
df -i でファイルシステムの情報を参照できる
手元の環境で確認すると、gunzipコマンド・gzipコマンド・zcatコマンドのiノード番号は異なっていた
- ディストリビューションによって異なるのだろうか

ハードリンクとシンボリックリンク

直接参照しているか、パスで参照しているか
postgresql関連のエラーでさわった記憶がある
シンボリックリンクはよく使うが、ハードリンクという仕組みがあることを知った
ln コマンドでリンクを作成する
- -s オプションをつけるとシンボリックリンク、つけなければハードリンクを作成する
ハードリンク、シンボリックリンク共に初めて聞いた
ショートカットはファイル（.lnk）として扱うためエディタに直接貼り付けると開けないが、シンボリックリンクではそれが可能
ハードリンクは使ったことがあったがシンボリックリンクはそもそも知らなかった
ハードリンク
- 元ファイルを削除してもハードリンクが残っていれば消えないのか
- ファイルの実体(iノード番号)を共有する
- iノード番号で同じファイルの実態を参照する必要があるので、同一のパーティション内である必要がある
- 通常のファイルの新規作成はハードリンクを１つ作るのと同義
- 元ファイルが削除されてもハードリンクされたファイルが実行できる
- フォルダのリンクは作成不可
シンボリックリンク
- 元ファイルが保管されている位置を示す擬似的なファイルを作成する
- Windowsのショートカットファイルのような感じ
- 元ファイルが削除されるとシンボリックリンクされたファイルは実行できない
- Windowsでいう、ショートカットみたいなもの
- フォルダのリンクを作成可能

ディスクを管理するコマンド

アンマウントした状態でfsckコマンドを実行するほうが安全
fsckはfile system check, file system consistency checkの略
fsck デバイス名のコマンドでそのデバイスのファイルシステムのチェックと修復ができる
- ジャーナリング機能をもつファイルシステムだと、修復作業が素早く行える
fsckコマンドで修正する場合、修正対象のパーティションはマウント解除してから行う
fsckコマンドを使う場面はおそらく焦っていると思うので、問題を増やさないためにもチェックするパーティションがアンマウントされている状態であるかのチェックを行うようにしたい
duはdisk usedの略
duコマンドで細かいディレクトリ使用量が見える。df -h で全体を調べて深堀りする時に使えそう
df コマンドでハードディスク全体、du コマンドでフォルダの使用量やファイルのサイズを確認できる
df -hでファイルシステムごとの空き容量を確認して、du -sh /* で各ディレクトリのファイルサイズを確認したりするのはよくやる

まとめ

「第12章ファイル管理」の内容は知識として知らない部分も非常に多く勉強になりました。気を付けないといけないポイント(スワップ領域は作成した後に swapon コマンドを実行しなければ有効化されない、ファイルシステムにファイルを作成する際にiノード領域が足りないと作成できないetc)は実際にLinx系のシステムを取り扱う際には気を付けていきたいと思います。

「Linux標準教科書」読書会は今回で終了となりましたが、今後の読書会にも参加していきたいと思います。

2023-02-14

「Linux標準教科書」読書会レポート vol.10

読書会

株式会社リゾーム技術部システム開発第4グループの平松です。「Linux標準教科書」読書会の第10回レポートです。第9回目のレポートはこちらになります。

tech.rhizome-e.com

読書会の題材

前回に引き続き Linux標準教科書を題材としています。

10回目レポート

今回は11章「プロセス管理」で、参加者は4名でした。

それぞれの感想・意見交換

プロセスとは

プロセスはkillコマンドで終了させるときに確認するぐらいでプロセスの親子関係や流れを意識したことはなかった

スケジューリング

ラウンドロビン、FIFOはよく出て来るので覚えておくといいかも
プロセスの優先度のパラメータの1つにNice値がある
- psコマンドでプロセスの確認をすることがあるので、その出力に表示されていたか調べたが、-O nice を付けないと表示されないらしい
プロセスの優先度を変更できるnice,reniceコマンドは初めて知った
Nice値は知らなかった
Nice値は優先度を示す値
- 初見では19が最も優先度が高そうに見えたけど、-20が一番高い
- 他プロセスに処理を譲るほどNiceであるということ…？

フォアグランドジョブとバックグラウンドジョブ

ジョブをバックグラウンドとフォアグランドに切り替えることができるのは知らなかった
コマンドをバックグラウンドで起動する際に&をつけるのはやったことがある気がするが具体的に何で使ったかは覚えていない
コマンドでバックグラウンドとフォアグランドを切り替えるのは新鮮だった

プロセスID

自身のPIDの取得は、溜まったプロセスを定期的にkillするスクリプトを書いた時に使った
psコマンドは強制終了させたいプロセスを調べるのに使うぐらい

シグナル

ctrl + C はSIGINTを送信してたのか。知らない内に使っていた
プロセスを強制終了させるために使っていたため、9以外のシグナル番号は知らなかった
killコマンドで強制終了と終了のシグナルを送信するぐらいしか使ったことがない
killコマンドしか使ったことがない
プロセスの終了は、15番を基本使ってそれで終了しなかった場合に9番で強制終了させた方が安全にプロセスの終了が行える

topコマンドとpstreeコマンド

CPUやメモリ使用率が高いプロセスを特定したい時にtopコマンドを使う
topコマンドはあまり使ったことがない
topコマンドはリアルタイム故に違うidと読み間違えるのを気を付けたほうがいいらしくなるほどなと思った
pstreeコマンドはプロセスの親子関係が図として表示されるので直感的に理解しやすい

プロセス間通信

パイプ、シグナルをよく使っているかな
セマフォなんかはよく聞く

まとめ

普段、使っていて意識することがなかったプロセスやジョブなどの内部構造について学ぶことができました。プロセスIDやシグナルの項目は使う場面もあると思うのでこの読書会で知ることができてよかったです。次回は、「第12章ファイル管理」です。