[2023年1月号] Software Design(技術評論社) サマリー+個人メモ

Software Design の2023年1月号について、

ざっくり内容紹介
個人的に気になった記事やポイント

をまとめている記事です。

サマリー記事の一覧はこちら。

特集①：アルゴリズムを使いこなしたい
特集②：PostgreSQL 15の最新機能解説
Development
そのほか
Software Design 2023年1月号

特集①：アルゴリズムを使いこなしたい

探索とソートで学ぶ計算量
- 計算量という言葉
  - 時間計算量と空間計算量（記憶容量をどれだけ必要とするか）というのがある、というのをなるほど言われて思い出した
  - 普通は時間計算量を指すのは周知のとおり
- 線形探索
  - 「1」なら一番はやいね
- 二分探索
  - 普段の平均は線形探索よりいいけどソートされてないといけないし「1」なら負けるね
- オーダー記法
  - O(1)
    - 定数時間
    - 絶対1回だよ！
  - O(log n)
    - 対数時間
    - ２をステップ数に乗じた定数倍のもの、二分探索がいい例（logの底は2）
  - O(n)
    - 線形時間
    - 計算回数がデータ量に比例するもの、線形探索がそのまま例
  - O(n log n)
    - 線形探索＋二分探索みたいな感じなので式もちょうどそうなる
    - クイックソート、マージソートなどはこれ
  - O(n^2)
    - 2乗時間
    - バブルソートとか
  - ソートの中身忘れてますね！使わないもんな…
しくみから理解するデータ構造
- 下記４つのアクションに対してさらに下記３つの基本的なデータ構造でどういう計算量になるかの表があった
  - 1番目の値にアクセスする
  - 挿入
  - 削除
  - 検索（存在チェック）
  - 配列
  - 連結リスト
  - ハッシュ
- 一応ハッシュテーブルがもっともすべて平均して優秀（全部 O(1)）
再帰呼び出しと分割統治法
- 再帰呼び出し
  - 難しい問題を簡単な問題にわける
  - 1段階だけ解いて再帰する（自明で簡単なときはやらない）
  - 例はいつもの階乗のやつ
  - …かと思ったら迷路問題の解決方法が載っていた！
- 分割統治法
  - 問題を分割したあとにそれぞれの小さな問題をすべて解決したらもとの問題も解決してるよね、の考え方
  - 再帰呼び出しのときと同じように、段階的に簡単にしていって「自明な段階」になったら１つの枝が終了、全部やったら解決！みたいな感じ
  - マージソート、クイックソート、二分探索などで使われている
動的計画法
- 小さな問題を解決したらその答えを覚えておいて、別の大きな問題を分解したときに同じ部品が出てきたら再利用しよう！の考え方
- フィボナッチですね
- トップダウン法とボトムアップ法というのがある

特集②：PostgreSQL 15の最新機能解説

多用途にフィットする現在のPostgreSQL
- OLTP（OnLine Transaction Processing、索引を用いた軽量なオンライン処理、だろう）にもアナリティクス（テーブルパーティショニング機能の活用）にも、軽量操作から大規模ヘビー検索にも、用途が広い
  - OLTPという方がいわゆる一般的なDB利用のニーズに近いものと思われる
  - OLTPでは、ミリ秒単位でレスポンスをちゃんと返せるようにするために「実行計画」というものがつくられる
    - 最近のPostgreSQLはここの着実な性能向上がいいんだとか
- アナリティクスのほうは、大量データの全件検索や全件ジョインなどのこと。「個々5年間のPostgreSQLの進化はここにある」らしい
  - パラレルクエリ
  - テーブルパーティショニング
  - 大量I/O時のメモリ利用効率化
- 電力、ガス、通信、金融などの重要なミッション分野でもPostgreSQLは積極的に採用されるようになっている（というかOSSのRDBMSが、なのかな）
  - ここで必ず使われるのが「ストリーミングレプリケーション」の高可用性（従来）
  - 新しい話には「論理レプリケーション」がある
    - いままでのようにDB全体をレプリケーションするのではなく、スポット的にできたり、もしくは「操作内容」という論理的な部分だけを伝えて受信側は受信側で勝手にそれをやる、みたいな概念
開発者向けのSQLの機能拡充
- PostgreSQL 10以降のSQL関連の機能強化整理
  - …全部書こうと思ったけど無理！
- 15
  - MERGE文
    - UPSERT に DELETE も足したようなやつっぽい
    - いままでにもあった INSERT ON CONFLICT も似てるように思うが、こちらはinsertが主目的だけどMERGEは色々条件に応じて選べる的な違いがある
  - ロールとスキーマについての概念図がありとてもよさそう
    - スキーマをちゃんと使いこなせている人なんているんだろうかといつも思いながら謎の設計をやってきたりしていたが、やっぱり権限分離などで使うのが正解のもののよう
      - 「現実における業務やシステムを論理的に区分けしオブジェクトを配置する」という考え方に基づくものらしい
    - でもこういう段階構造のものを見ると毎回思うんだけど、「だったらDBをもう一個作るのと本質的な違いはなに？」となる。「面倒が減る」とかそういうことではなく、本質的な差がないと思ってしまう。階層を１つずらせばほぼ同じことが実現できるものはいつもうまく扱えなくて困る。
PostgreSQL 15 の新機能
- JSONサーバーログというのは気になった
  - この章の書き出しに何の前触れもなくいきなり「にゃーん。」と書いてあったんだけどこれは一体なんだ…？
  - 「実は誰も本文なんて読んでないのでは」に対する実験とかだったら面白い

Development

オンラインホワイトボード「Miro」徹底活用術
- プレゼン機能、、、使うのか、、、
- さっき思ったけど仕様書の作図するとき draw.io じゃなくて Miro でもいけるかな。よく使う形状の図はあったっけ？

そのほか

ITエンジニア必須の最新用語解説「モジュラモノリス」
- 地味にほぼ毎月ちゃんと扱っている数少ないコーナーかも
- 大規模なソフトウェア開発で扱われるアーキテクチャのこと
- いままででいうモノリシックアーキテクチャ（モノリス）とマイクロサービスアーキテクチャの２つを兼ね備えるもの、もしくは両者の間を埋めるもの
  - だとしたらもうちょっと名前はなんとかならなかったのかと思ったけど、モジュラーという言葉は「共通規格の既存部品を組み合わせて作る作り方」みたいな意味があるので（モジュラージャックとかこれかな）、まあわからんでもない
  - モノクロアーキテクチャとかにしたら色の話？みたいになるもんな
- システム全体はモノリシックな雰囲気で動くが、内部を複数の小さなモジュールにするとのこと
  - かなりふわふわしててなんの線引きにもなっていないと感じるが、一応「ランタイムは共通」「各モジュールはAPIベースで結合」などあるらしい
    - でもランタイム共通ならだいぶモノリシック寄りに引っ張られるな