0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【Part1】KVDB,RDB作ってみる

Posted at

背景

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

進め方

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

はじめに

トランザクションとは

理解しているつもりであったが、うまく文脈上で言い換えられなかったので調べ直した
image.png

image.png

一番しっくりしたのは、最後の関連する複数の処理を一つの処理として実行・管理する仕組み参考)だった。

耐久性

スクリーンショット 2025-04-03 20.20.36.png

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

原子性

スクリーンショット 2025-04-03 20.25.33.png

少し日本語がおかしいので、Geminiに同様に翻訳してもらった

fsync システムコール

fsync は、それまでに書き込まれたすべてのデータを永続化(確実にディスクに保存)するファイルシステム操作です。これは永続性を要求し、確認するために使用されます。データベースは fsync が完了した後でのみ、クライアントに成功応答を返します。

しかし、データベースが fsync の前や実行中にクラッシュした場合はどうなるでしょうか? 最新のデータは失われる可能性がありますが、データが部分的に失われ、部分的に永続化されるような中途半端な状態になってはいけません。この「すべてか、無か」という性質は原子性(アトミシティ)と呼ばれます。

データベースはクラッシュから「合理的な状態」に回復しなければならず、これは単に fsync を使うことよりも難しい課題です。

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

image.png
(参考:https://blog.trocco.io/glossary/acid)

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

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

他の特性

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

image.png
(参考:https://blog.trocco.io/glossary/acid)

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

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

データ構造のインデックス作成

image.png

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

余談:OLAP/OLTPとは

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

image.png
(参考:https://aws.amazon.com/jp/what-is/olap/)

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

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

image.png
(参考:https://it-trend.jp/bi/article/27-0067)

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

OLTP:

image.png
(参考:https://data.wingarc.com/what-is-oltp-2-13329)
ということで、分析手法と比べると少し毛色が違うようにおもう

AWSのこれを見ると、やはり分析手法と保存等の方法となっているのでそのようだ
image.png
(参考:https://aws.amazon.com/jp/compare/the-difference-between-olap-and-oltp/)

DBの向き不向き

image.png

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

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

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

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

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

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

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

image.png

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

まとめ

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?