Name: 7 データベース・パラダイム (7 Database Paradigms)
Uploaded: 2024-12-06T06:35:02.000Z
Duration: 9 min 53 s

My dad used to tell me, use the right tool for the job, and not vice versa.

父によく言われたのは、仕事に適した道具を使え、その逆はするな、ということだった。

When it comes to app development, choosing the right database is one of the single most important decisions that you'll ever make.

アプリ開発において、適切なデータベースを選択することは、最も重要な決断のひとつです。

様態の副詞

In today's video, we'll look at seven different database paradigms, along with some databases you've probably heard of, and some others that you haven't.

今日のビデオでは、7つの異なるデータベース・パラダイムについて、おそらく聞いたことのあるデータベースと、聞いたことのないデータベースについて見ていこう。

We'll look at how they work from a technical perspective, but most importantly, we'll try to understand what they're best used for, because my dad also used to tell me, don't bring a knife to a gunfight.

技術的な観点からどのように機能するのかを見ていくが、最も重要なのは、どのような用途に使うのが最適なのかを理解することだ。

If you're new here, like and subscribe, and also check out my new top 7 playlist for more videos like this.

また、私の新しいトップ7プレイリストで、このようなビデオをもっとチェックしてください。

Our list will start from the most simple type of database, and gradually become more complex as we get to number 7.

このリストでは、最も単純なタイプのデータベースから始め、7番まで徐々に複雑になっていく。

And that brings us to our first paradigm, the Key-Value Database.

そして、最初のパラダイムであるKey-Valueデータベースにたどり着く。

Popular databases in this space include Redis, Memcached, and Etcd.

この分野で人気のあるデータベースには、Redis、Memcached、Etcdなどがある。

The database itself is structured almost like a JavaScript object or Python dictionary.

データベース自体は、JavaScriptのオブジェクトやPythonの辞書のような構造になっている。

You have a set of keys, where every key is unique, and points to some value.

キーの集合があり、どのキーも一意で、ある値を指す。

In Redis, for example, we can read and write data using commands.

例えばRedisでは、コマンドを使ってデータを読み書きできる。

We use the set command, followed by a key and a value to write data, then the git command to retrieve that data in the future.

データを書き込むにはsetコマンドを使い、その後にキーと値を指定し、将来そのデータを取り出すにはgitコマンドを使う。

In the case of Redis and Memcached, all of the data is held in the machine's memory, as opposed to most other databases that keep all their data on the disk.

RedisとMemcachedの場合、すべてのデータはマシンのメモリに保持される。他のほとんどのデータベースがすべてのデータをディスクに保持するのとは対照的だ。

This limits the amount of data you can store, however it makes the database extremely fast, because it doesn't require a round trip to the disk for every operation.

このため、保存できるデータ量は制限されるが、操作のたびにディスクを往復する必要がないため、データベースは非常に高速になる。

In addition, it doesn't perform queries, joins, or anything like that, so your data modeling options are very limited, but again it's extremely fast, like sub-millisecond fast.

加えて、クエリーや結合などは実行されないので、データモデリングの選択肢は非常に限られるが、やはり非常に高速で、ミリ秒以下の速さだ。

You wouldn't want to use a key-value store for your main app data.

メイン・アプリのデータにキー・ヴァリュー・ストアを使いたくはないだろう。

Most often, they're used as a cache to reduce data latency.

多くの場合、データのレイテンシーを減らすためのキャッシュとして使われる。

Apps like Twitter, GitHub, and Snapchat all use Redis for real-time delivery of their data.

Twitter、GitHub、Snapchatなどのアプリはすべて、データのリアルタイム配信にRedisを使っている。

There are other use cases beyond caching, like message queues, PubSub, and gaming leaderboards, but more often than not, key-value databases are used as a cache on top of some other persistent data layer.

メッセージキュー、PubSub、ゲームのリーダーボードなど、キャッシュ以外の使用例もあるが、多くの場合、キーバリュー・データベースは、他の永続的なデータレイヤーの上にキャッシュとして使用される。

Now a database that only supports key-value pairs is obviously pretty limited, and that brings us to the wide-column database.

キーと値のペアしかサポートしないデータベースは、明らかにかなり限定的である。

Popular options in this family include Cassandra and HBase.

A wide-column database is like you took a key-value database and added a second dimension to it.

ワイド・カラム・データベースは、キー・バリュー・データベースに2つ目の次元を追加したようなものだ。

At the outer layer, you have a keyspace, which holds one or more column families, and each column family holds a set of ordered rows.

外層には、1つ以上の列ファミリーを保持するキースペースがあり、各列ファミリーは順序付けられた行のセットを保持する。

This makes it possible to group related data together, but unlike a relational database, it doesn't have a schema, so it can handle unstructured data.

そのため、関連するデータをグループ化することが可能だが、リレーショナル・データベースとは異なり、スキーマを持たないため、非構造化データを扱うことができる。

This is nice for developers, because you get a query language called CQL that's very similar to SQL, although much more limited and you can't do joins.

CQLというSQLによく似たクエリ言語が使えるからだ。

However, it's much easier to scale up and replicate data across multiple nodes.

しかし、スケールアップして複数のノードにデータをレプリケートするのははるかに簡単だ。

Unlike an SQL database, it's decentralized and can scale horizontally.

SQLデータベースとは異なり、分散型であり、水平方向に拡張できる。

A popular use case is for scaling a large amount of time series data, like records from an IoT device, weather sensors, or in the case of Netflix, a history of the different shows you've watched.

一般的なユースケースは、IoTデバイスからの記録、気象センサー、あるいはNetflixの場合、視聴したさまざまな番組の履歴など、大量の時系列データをスケーリングすることだ。

It's often used in situations where you have frequent writes, but infrequent updates and reads.

書き込みは頻繁に行われるが、更新や読み込みは頻繁に行われないような状況でよく使われる。

It's not going to be your primary app database.

アプリの主要なデータベースにはならない。

For that, you'll need something more general purpose, like a document-oriented database.

そのためには、ドキュメント指向データベースのような、より汎用的なものが必要だ。

Popular options in the Firestore, DynamoDB, CouchDB, and a few others.

Firestore、DynamoDB、CouchDB、その他いくつかの人気のあるオプション。

In this paradigm, you have documents, where each document is a container for key-value pairs.

このパラダイムでは、ドキュメントがあり、各ドキュメントはキーと値のペアのコンテナである。

They're unstructured and don't require a schema.

構造化されておらず、スキーマを必要としない。

Then the documents are grouped together in collections.

そして、ドキュメントはコレクションにまとめられる。

Fields within a collection can be indexed, and collections can be organized into a logical hierarchy, allowing you to model and retrieve relational data to a pretty significant degree.

コレクション内のフィールドにはインデックスを付けることができ、コレクションは論理的な階層に編成することができる。

They don't support joins, so instead of normalizing your data into a bunch of small parts, you're encouraged to embed the document.

結合をサポートしていないので、データを小さなパーツの束に正規化する代わりに、ドキュメントを埋め込むことが推奨される。

This creates a tradeoff where reads from a friend and application are much faster, however writing or updating data tends to be more complex.

このため、友人やアプリケーションからの読み込みは非常に速くなるが、データの書き込みや更新はより複雑になりがちというトレードオフが生じる。

Document databases are far more general purpose than the other options we've looked at so far.

文書データベースは、これまで見てきた他の選択肢よりもはるかに汎用的だ。

From a developer perspective, they're very easy to use.

開発者の観点からは、非常に使いやすい。

They're often suitable for mobile games, IoT, content management, and many other use cases.

モバイルゲーム、IoT、コンテンツ管理、その他多くのユースケースに適していることが多い。

If you're not exactly sure how your data is structured at this point, a document database is probably the best place to start.

この時点でデータがどのような構造になっているのかよくわからない場合は、ドキュメント・データベースから始めるのが一番だろう。

Where they generally fall short is when you have a lot of disconnected but related data that is updated often, like a social app that has many users who have many friends who have many comments who have many likes, and you want to see all the comments that your friends like.

ソーシャルアプリのように、たくさんのユーザーがいて、たくさんの友達がいて、たくさんの友達がたくさんのコメントをしていて、たくさんの友達が「いいね！」を押していて、友達が「いいね！」を押しているすべてのコメントを見たい場合などだ。

Data like this needs to be joined, and it's not easily done in a document database at scale.

このようなデータは結合される必要があるが、文書データベースで大規模に行うのは容易ではない。

Luckily, we have this thing that's been around forever called the relational database.

幸いなことに、私たちにはリレーショナル・データベースという昔からあるものがある。

You're likely familiar with this type of database with flavors like MySQL, Postgres, SQL Server, and many others.

この種のデータベースには、MySQL、Postgres、SQL Server、その他多くの種類がある。

They've been around for nearly 50 years and continue to be one of the most popular types of databases in today's world.

このデータベースは50年近くの歴史があり、今日の世界で最も人気のあるデータベースのひとつであり続けている。

They were originally conceived by a computer scientist named Ted Codd.

もともとは、テッド・コッドというコンピューター科学者によって考案された。

He worked for IBM and spent years working out his theories on relational data modeling.

彼はIBMに勤務し、リレーショナル・データ・モデリングに関する理論を何年もかけて確立した。

You can read his original paper online, and most of it goes way over my head, but you can appreciate the amount of math and science that went into the development of relational databases, and that's very likely why they remain so popular today.

しかし、リレーショナル・データベースの開発に費やされた数学と科学の量を理解することができる。

A few years later, this would inspire the development of SQL, or Structured Query Language, or SQL if you prefer.

数年後、これがSQL（Structured Query Language、構造化クエリー言語）の開発のきっかけとなった。

It's a special type of programming language called a query language that allows you to access and write data in the database.

これはクエリー言語と呼ばれる特殊なプログラミング言語で、データベースのデータにアクセスしたり書き込んだりすることができる。

Okay, but what do we actually mean when we say relational database?

では、リレーショナル・データベースとはどういう意味なのだろうか？

Well, imagine you have a facility that builds airplanes.

飛行機を製造する工場があるとしよう。

The facility is your database, and on that database you might have different warehouses that hold different parts, like engines, wheels, and so on.

施設はデータベースであり、そのデータベースには、エンジンやホイールなど、さまざまな部品を保管する倉庫があるかもしれない。

Each warehouse is like a database table for holding a certain type of part.

各倉庫は、ある種の部品を保管するデータベースのテーブルのようなものだ。

Each individual part has a serial number to uniquely identify it, and you can think of an individual part as a row in a table.

個々の部品は、それを一意に識別するためのシリアル番号を持っており、個々の部品をテーブルの行と考えることができる。

So now that we have all these parts separated into different warehouses, how do we build an airplane?

では、これらの部品を倉庫ごとに分けて、どうやって飛行機を作るのか？

そこで登場するのが人間関係だ。

We can build an airplane by referencing the unique ID of the different parts that go into it.

私たちは、飛行機を構成するさまざまな部品の固有のIDを参照することで、飛行機を作ることができる。

Notice how each part has its own unique ID.

各パーツがそれぞれ固有のIDを持っていることに注目してほしい。

This is known as its primary key, then it defines its various parts by referencing their IDs.

これを主キーと呼び、そのIDを参照することでさまざまなパーツを定義する。

These are known as foreign keys because they reference data in a different table.

これらは別のテーブルのデータを参照するため、外部キーとして知られている。

Now if we want to join all this data together, we can run a query to do that.

これらのデータを結合したい場合は、クエリーを実行すればよい。

So the main takeaway here is that an SQL database organizes data in its smallest normal form.

つまり、SQLデータベースはデータを最小の正規形で整理するということだ。

However, a potential drawback here is that it requires a schema.

しかし、スキーマが必要なのが難点だ。

If you don't know the right data shape up front, they can be a little harder to work with.

適切なデータ形状を前もって知っておかないと、作業が少し難しくなる。

SQL databases are also ACID compliant, which means whenever there's a transaction in the database, data validity is guaranteed even if there are network or hardware failures.

SQLデータベースはACIDにも準拠しており、データベース内でトランザクションが発生するたびに、ネットワークやハードウェアに障害が発生してもデータの有効性が保証される。

That's essential for things like banks and financial institutions, but it makes this type of database inherently more difficult to scale.

これは銀行や金融機関などには不可欠だが、この種のデータベースは本質的に拡張が難しくなる。

However, it's worth noting that there are modern SQL databases like Cockroach that are specifically designed to operate at scale.

しかし、Cockroachのような大規模運用に特化した最新のSQLデータベースがあることは注目に値する。

In any case, relational databases remain the most popular type of database in production today.

いずれにせよ、リレーショナル・データベースは、今日の生産現場で最もよく使われるタイプのデータベースであることに変わりはない。

But what if instead of modeling a relationship in a schema, we just treated the relationship itself as data?

しかし、スキーマでリレーションシップをモデル化する代わりに、リレーションシップそのものをデータとして扱うとしたらどうだろう？

Enter the graph database, where your data is represented as nodes and the relationships between them as edges.

グラフ・データベースは、データをノード、データ間の関係をエッジとして表現する。

Popular options in this space include Neo4j and dgraph.

この分野で人気のあるオプションには、Neo4jとdgraphがある。

Let's imagine we want to set up a many-to-many relationship in an SQL database.

SQLデータベースで多対多のリレーションシップを設定したいとしよう。

We do that by setting up a join table with the that define the relationship.

そのためには、リレーションシップを定義する結合テーブルを設定する。

In a graph database, we don't need this middleman table.

グラフ・データベースでは、この中間テーブルは必要ない。

We just define an edge and connect it to the other record.

エッジを定義し、それを他のレコードに接続するだけだ。

We can now query this data with a statement that's much more concise and readable.

これで、より簡潔で読みやすいステートメントでこのデータを照会できる。

In addition, we can achieve much better performance, especially on larger datasets.

さらに、特に大規模なデータセットでは、はるかに優れたパフォーマンスを達成できる。

Graph databases can be a great alternative to SQL, especially if you're running a lot of joins and performance is taking a hit because of that.

グラフ・データベースはSQLの素晴らしい代替となる。

They're often used for fraud detection in finance, for building internal knowledge graphs within companies, and to power engines like the one used by Airbnb.

金融における不正検知や、企業内のナレッジグラフの構築、Airbnbが使用しているようなエンジンの動力源としてよく使われている。

Now let's imagine you want to build something like Google.

では、グーグルのようなものを作りたいと想像してみよう。

A user provides a small amount of text, then your database needs to return the most relevant results ranked in the proper order from a huge amount of data.

ユーザーが少量のテキストを提供すると、データベースは膨大なデータから適切な順序でランク付けされた最も関連性の高い結果を返す必要がある。

For that, you're going to want a full-text search engine.

そのためには、全文検索エンジンが必要だ。

Most of the databases in this space are based on top of the Apache Lucene project, which has been around since 1999, like Solr and Elasticsearch.

この分野のデータベースのほとんどは、SolrやElasticsearchのように、1999年から存在するApache Luceneプロジェクトに基づいている。

In addition, we have cloud-based like Algolia, and my new personal favorite, MeleSearch, a Rust-based full-text search engine.

さらに、Algoliaのようなクラウドベースや、個人的に最近気に入っているMeleSearchというRustベースの全文検索エンジンもある。

If you want to check it out, I have a full tutorial on Fireship.io for pro members.

Fireship.ioのチュートリアルをご覧になりたい方は、Fireship.ioのチュートリアルをご覧ください。

From a developer perspective, they work very similar to a document-oriented database.

開発者の視点からは、ドキュメント指向のデータベースとよく似た働きをする。

You start with an index, then you add a bunch of data objects to it.

まずインデックスを作り、そこにたくさんのデータ・オブジェクトを追加する。

The difference is that under the hood, the search database will analyze all of the text in the document and create an index of the searchable terms.

その違いは、検索データベースが文書内のすべてのテキストを分析し、検索可能な用語のインデックスを作成することである。

So essentially, it works just like the index that you would find in the textbook.

つまり、基本的には教科書に載っている索引と同じように機能する。

When a user performs a search, it only has to scan the index as opposed to every document in the database, and that makes it very fast even on large datasets.

ユーザーが検索を実行する際、データベース内のすべてのドキュメントをスキャンするのではなく、インデックスをスキャンするだけでよい。

The database can also run a variety of different algorithms to rank those results, filter out irrelevant hits, handle typos, and so on.

データベースはまた、これらの結果をランク付けしたり、無関係なヒットをフィルタリングしたり、タイプミスを処理したりするために、さまざまな異なるアルゴリズムを実行することができる。

This does add a lot of overhead, and they can be expensive to run at scale, but at the same time, they can add a ton of value to the user experience if you're building something like a type-ahead search box.

しかし同時に、タイプ・アヘッド検索ボックスのようなものを構築する場合、ユーザー・エクスペリエンスに大きな付加価値を与えることができる。

And with that, we've reached number seven, the multi-model database, which in my opinion is the most exciting paradigm on this list.

これで、私たちは7番目のマルチモデルデータベースに到達した。

There are a few different options out there, but the database I want to focus on here is FaunaDB, which is very different than anything else we've looked at so far.

しかし、ここで注目したいのはFaunaDBというデータベースで、これまで見てきた他のデータベースとは全く異なるものだ。

If you're a front-end developer, all you really care about is the data that you consume in the front-end application.

もしあなたがフロントエンド開発者なら、本当に気にするのはフロントエンド・アプリケーションで消費するデータだけだろう。

You don't want to have to think about data modeling, schemas, replication, shards, or anything like that.

データモデリング、スキーマ、レプリケーション、シャード、そういったことを考える必要はない。