【Part1】KVDB,RDB作ってみる

## 背景
- 普段からRDBやNoSQLなどを利用するが、見切り発車で個人開発などを進めていくことが多く、途中で考慮漏れが見つかった時に、DBの変更にめっちゃ手間がかかってしまう
- 社内の人に質問したところ、DB作ってみたらとおすすめの本を教えていただけたので、まずはDB作ってみようと思う

## 進め方

https://build-your-own.org/database/

主にこのサイトを参考にして、DBの概念について読み進めながらまとめつつ作成していく。
3000行程度と相当にミニマルなDBであるので、ほとんど初めてのGoではあるが、おそらくいけると思う。

## はじめに

### トランザクションとは
理解しているつもりであったが、うまく文脈上で言い換えられなかったので調べ直した
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/1553d64e-df74-4082-996e-863d0ddf16e4.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/a4490be9-5193-4123-95d1-a8066dfbfb15.png)

一番しっくりしたのは、最後の`関連する複数の処理を一つの処理として実行・管理する仕組み`（[参考](https://swri.jp/glossary/%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3#:~:text=%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%EF%BC%88transaction%EF%BC%89%E3%81%A8%E3%81%AF%E3%80%81,%E3%80%8C%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E5%87%A6%E7%90%86%E3%80%8D%E3%81%A8%E5%91%BC%E3%81%B6%E3%80%82)）だった。

### 耐久性
![スクリーンショット 2025-04-03 20.20.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/634570e2-bdcc-4b2d-a84c-6214f90378b9.png)

耐久性については納得である。電源が切れたりしても、データを正しく壊さずに持つ機能であるという理解。確かにこれができないとDBとは呼べない。

### 原子性
![スクリーンショット 2025-04-03 20.25.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/c3a6bf7c-991e-4f43-97cb-4e8a7b89b40e.png)

少し日本語がおかしいので、Geminiに同様に翻訳してもらった
>**`fsync` システムコール**
>
>`fsync` は、それまでに書き込まれたすべてのデータを永続化（確実にディスクに保存）するファイルシステム操作です。これは永続性を要求し、確認するために使用されます。データベースは `fsync` が完了した後でのみ、クライアントに成功応答を返します。
>
>しかし、データベースが `fsync` の前や実行中にクラッシュした場合はどうなるでしょうか？ 最新のデータは失われる可能性がありますが、データが部分的に失われ、部分的に永続化されるような中途半端な状態になってはいけません。この「すべてか、無か」という性質は原子性（アトミシティ）と呼ばれます。
>
>データベースはクラッシュから「合理的な状態」に回復しなければならず、これは単に `fsync` を使うことよりも難しい課題です。

原子性について、過去に基本情報などで学んだ気がするが曖昧なのでもう少し掘り下げてみる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/f9b9c8b6-cc00-4f57-938c-074c92e30ea8.png)
（参考：https://blog.trocco.io/glossary/acid）

つまり、行うべき操作が必ずすべてが正常に終了した状態か、全く何もしないかのどちらかになるということと理解した。

普段ここら辺を意識しないと、忘れてしまいますね、、、

### 他の特性
特に、元の参考元には説明がなかったが、ACID特性の残りの２つもここではみたい。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/9da50e14-d59a-43d3-a537-2d36895a77fe.png)
（参考：https://blog.trocco.io/glossary/acid）

独立性は、そのままなのでわかりやすい。

Consistencyに関しては、DBにつけるデータ制約として理解した。

##  データ構造のインデックス作成
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/7c99876b-fd94-47fe-99df-7ce237278962.png)

この章は結構語っているが少しわからない部分があったので、調べながら対応する

### 余談：OLAP/OLTPとは

**OLAP：**
とりあえず、Amazonの記事が見つかった

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/058b97b5-3d85-4a7b-8832-f36160e086df.png)
（参考：https://aws.amazon.com/jp/what-is/olap/）

大量のデータを収集して分析する処理っぽい

説明を見てオンラインに違和感があったので調べたところ`リアルタイム`といった意味であった。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/a87292c8-efed-4106-9700-6fd470c026c2.png)
（参考：https://it-trend.jp/bi/article/27-0067）

つまり、`リアルタイムに大量のデータを分析する処理`とのこと

**OLTP:**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/799fdd4e-d041-420b-9e3a-8440284a7434.png)
（参考：https://data.wingarc.com/what-is-oltp-2-13329）
ということで、分析手法と比べると少し毛色が違うようにおもう

AWSのこれを見ると、やはり分析手法と保存等の方法となっているのでそのようだ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/3c33b307-bff9-49ae-8f29-b8538d70b98f.png)
（参考：https://aws.amazon.com/jp/compare/the-difference-between-olap-and-oltp/）

### DBの向き不向き
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/71723fce-6b02-43cf-a1f7-f0d261034297.png)

要は従来型のRDBは、OLAP（大量のデータ分析）には向いていないため、新しく色々な専用のDBが作成されたとのこと。

### メモリ内データ構造とディスク上データ構造

ディスク上に作成する関係上次の問題が発生してしまうようだ

1.RAMとディスクでは、1000倍以上速度差がついてしまう
2.データベースとは、本質的にはディスク上に構築されたデータ構造です。そのため、データ構造の知識は前提となります。（知らないと厳しいかもとのこと。あまり詳しくないので調べつつAIにも聞きつつやっていきたい）
3.ディスク式だと、待ち時間が長くなりすぎるので同時制御が必要になるとのこと。

### KVストア上のリレーショナルDB

>SQL はデータベースとほぼ同義です。しかし、SQL は単なるユーザー インターフェイスであり、DB の基本ではありません。重要なのは、 その下にある機能です。

SQLよりも下のレイヤーがあるとのこと。
そのレイヤーが、KVインターフェースである

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3125890/4a0fb983-dfed-40f6-8282-accc49eaf126.png)

画像にあるように、KV DBを作るが、それがNoSQLを指すわけではなく、KVを下層レイヤーとしたRDBを構築していくようだ


## まとめ
次回から実際にGoを利用して作っていく。
結構前置きが長くなってしまったので、ここでいったん区切ろうと思う