They and I&#39;m going to try and explain to you why there are five types of databases and why you might use each.

One. So this came out of a discussion with colleagues. I had a colleague who categorized databases in ways I frankly still don&#39;t understand, and I said, but it's obvious there are five types, and he said, what?

So I think the types are relational, column, document, key-value and graph.

I&#39;m going to give you an example of how you might use these, and at least one open-source example of each of these.

Note that the examples I chose are not the only ones. Go out and do your own research. So, we&#39;re going to start with relational, um, for reasons that may become obvious in a moment.

So, here is a table. It&#39;s called books. It has three columns.

They are called ID, title, and author. Each column has a data type. We&#39;ve got an integer ID which we&#39;re using to distinguish the rows from each other.

And we have two string columns. One is the title of a book and the other is the name of the author.

Uh, I have not written any books. These books are made up. All books in this example are false.

Uh, don&#39;t go looking for books called this book and that book. Although I want books called that.

So relational databases come from um a paper by um Edgar Codd back in 1970 called a relational model of data for large shared data banks.

Large here is in the context of the time; we would regard these as relatively small, but this was people trying to do what were at the time large amounts of Data.

Uh, the trouble was that the existing ways of creating databases tended to require your program to know the structure of the database. So if you wanted to alter the data, um, you had to change your program.

Um, and also it was all a bit fiddly. He wanted to create a mathematical approach that was just simple enough and just abstract enough to represent just about anything.

And I think he succeeded beyond what would have been his wildest dreams because relational technology has taken over the world these days.

Um, and I have a note here to regard him as the granddaddy of relational databases and perhaps of databases altogether.

Uh, this paper is online in the notes; there’s a link to it.

Um, in his terminology, what he called a relation we now call a table. This actually took about 15 years to gain adoption. Uh, adoption on micro and mini computers, uh, fax machines and so on was quite quick, but IBM was very reluctant to abandon their older forms of database, and it wasn’t until the mid-1980s that IBM, who were very dominant in the big computing world at the time, adopted relational databases, and that became the dominant technology.

Now, our original table we’re all used to thinking of in tables, but if you start to increase what’s in your table data, it gets very complicated and you often end up with a lot of duplication.

So what we’re doing here is we’ve got a books table and an authors table.

Um, and we are using the author ID, which is in red. We can see that the two books in the Books tables have the same author.

We can look at that ID across in the authors' table. This has advantages when there for instance we have two John Smiths.

Well, we can specify which one we mean. If we were just using John Smith as the name in one table, it would all get very confusing.

This idea that you can link things in different tables by using shared IDs is fundamental to how relational databases work as well.

And if you think about it, I think of these as a bit like Python objects with references to other Python objects.

An important concept here is SQL, which is a domain-specific language for talking to relational databases.

It originated in the 70s. So again, very early on from when the original paper came. The original name was SQL, which was a pun probably on a related language called Quell from Ingres, which it was competing with.

It couldn’t stick with that name because there was a commercial product with the same name and they would get upset.

So it became SQL, but that’s why you’ll hear people talking about SQL.

That pronunciation has been around for a very long time. It was standardized in the 1980s, but the latest version was released in 2023.

So this is a language that’s still under active development.

Because it’s standardized, you’ll find that just about every relational database vendor has SQL bindings.

They’re not always quite the same as each other, but there’s a lot of commonality.

So to create those tables, these are the SQL statements we might use. Um, so we're creating a table called authors. We're defining an ID column, which is an integer.

We don't want the values to be null. We want them to have values. And we're saying this is the primary key.

This is the way we identify our records. And then it has a name, which is a text field, not null.

The details may differ between databases. And then we've got our books. Again, we've got an ID, which is an integer, the primary key.

It's not null. We've got a title, which mustn't be null.

And then we've got an author ID. This is an integer. And here we're saying that this references the ID in the authors table.

This means that when we add an author ID, the database can check that we are using an ID that already exists in the authors table.

So this keeps our data tidy. It helps stop us from making mistakes.

And to find the books written by this notional author, this Tibs, um I can select books.

title from books and I need to join together the author's ID in the authors table with the ID in the books table that match, and say I want those to match when I'm looking this up, but I want the author's name to be Tibs, and that will give me this book and that book back.

I should point out I've been struggling with writing SQL joins Since the 1980s, I always have to go and look up how to do this.

So don't be worried if you find SQL difficult.

SQL, however, is a really good language to learn because it’s a different kind of language than the procedural languages we’re all used to, like Python, where you tell the computer, do this, do that, do that.

In SQL, what you’re doing is finding out about this, give me this result.

Um, and it’s up to the SQL engine then to figure out how to do it for you.

So, relational databases, they have tables, they have rows, they have columns.

We’re all quite used to that. We’ve been doing that with paper and pencil for generations. And of course we probably used spreadsheets as well.

So these tend to be a very natural way to think. Schema design, saying how the data is constructed, and what the data is like is upfront.

When you create your table, you have to say what you want your columns to be.

So my first example is PostgreSQL, which is um, the elephant is a very nice logo for PostgreSQL because it’s kind of this big, powerful um thing.

It’s had 35 years of active development, which takes us back to 1990. Um, I wrote that down so I’d remember.

Um, it’s always a good place to start. It’s one of my favorite databases.

Um, I have favorite databases. Okay. Um, it’s pronounced PostgreSQL, which I find, but you’re allowed to call it PostgreSQL because of history, and it derives from going back to the 80s.

There's a sequence of databases that lead up to PostgreSQL.

It's got rich data types, not just integers, text, and so on. You can store functions in the database, which means that you can have the database run code, which means that your client doesn't have to do it.

It's very extensible. You can write plugins and so on. But also, it's very easy to fork it, do things with it, and then, if you're nice, push the your extensions back into PostgreSQL.

A lot of companies have done that over the decades. It's got excellent documentation. So, it's very broad.

It talks about everything, but it also goes very deep, which makes me very happy because I often find that documentation talks about what I want and then stops too early.

And I recommend it as a good place to start if you need a relational database.

My second example though is SQLite. Now, the author says he pronounces this SQLite, but he also says he doesn't care how anyone says it.

So, I tend to say SQLite because that's easier. This is a library. And I love this second quote here: Small, fast, reliable.

Choose any three. So, it's a library. It's built into the Python standard library.

Import sqlite3 and you've got it. You can run it at the command line and when you Start it; it creates a temporary database.

It's everywhere. It's on your phones. So, it can legitimately claim to be the the database that has the most penetration in the world.

It's everywhere. It's single-user, which you'd expect because it's a library.

Um, it's slightly odd in some ways, and actually the schema is optional, and how the types work is a bit odd, and the documentation recommends using it as a file format rather than JSON, YAML, or TOML for local storage.

In fact, they claim that it's sometimes faster than actually creating a text file.

Um, it can be faster than fopen to access. Um, and it can be quite portable.

There are extensions to create zip files that you can send around. So when should we use a relational database?

Well, it's almost always a good place to start. The technology has been around a long time and is very mature.

So if your data fits, which it probably does, um, and whatever you need to do, there's probably a relational database that can do it, and it's probably going to be fast enough.

So, column databases. So this looks like a relational database except I split the columns apart. I apologize for the name of that first column for reasons that become evident later.

Um, the timestamp was too long, so this is just DT. So we've got a timestamp, we've got an ID, we've got a book name, we've got a price, we've got how many books we sold, and we've got a customer ID who bought that book.

Um, someone named 923 bought this book twice at the same time. Maybe they were giving it away.

What we've done here is just split the columns up. Very simple idea. So, column databases are in many ways an optimization of relational databases.

They're saying sometimes you don't want to access data as rows. You want to access data as columns.

Maybe I've got 100 rows, but I typically use two or three of the columns. So, if I have to go away and retrieve all the rows and then extract just the columns I want, that's both wasteful and slow.

But if I know I'm going to do that, if I've got the columns stored in the database, I can just get the columns I need.

So, storing data as columns can already give you a win there. But because we know the data type of the columns, we can compress that data, um, giving more efficient data storage.

So, we take up less space, which also means data is faster to retrieve.

So, this tends to be good for data that doesn't change a lot because, um, working with data that's compressed is a pain.

So here's a view of that same table, but I've shown where we've compressed repeated values.

Um, so the yellow items are things where that data is repeated in the next rows.

Um, because it's a column, you can imagine our storage. You need to get a A little bit clever about indexing helps us actually figure out where we want to be in the compressed data to retrieve things.

This is stuff we've been doing in computer science for decades. So it's faster at adding new rows. Um, and then the compression will happen in the background over time.

If there's compression, it's faster at adding new columns, which is interesting.

In a relational database, adding a new column means adding it to all the rows. It's a slow operation.

It's fast at querying a few columns out of many. It's going to be slow at changing or deleting rows because you've got to unpick all your columns and then put them back together again.

So it suits log data, sensor data, um, pressure, time, humidity, or tons of information you might be collecting, time series data in general, and actually any sort of data where you're going to store it for historical purposes.

You're not going to change it, but you want to use it for analytical purposes.

So you'll see column databases used as data warehouses. And my example here is ClickHouse. Now, this is quite a common model.

ClickHouse has an open-source version which is the GitHub repository linked there and um a commercial venture that will give you enterprise editions that do more stuff, and the commercial version claims it's the fastest and most resource-efficient real-time data warehouse and open-source database.

ClickHouse is blindingly fast for queries, nicely because it's essentially still a relational idea. It's still SQL, so Everything you've learned about using SQL still works.

It's got extra functions and utilities to make it easy to do columnar stuff, but it's very familiar.

Explaining the 5 types of database and how to choose between them — Tibs

The official YouTube Channel of the EuroPython conferences. Current edition: EuroPython 2023.

EuroPython is the official European conference for the Python programming language.

Copyright © 2004-2023, EuroPython Speakers, EuroPython Society, Sweden and the Local Organisers of the EuroPython conferences. "EuroPython" is a trademark of the EuroPython Society.


EuroPython Conference

관계형, 컬럼, 문서, 키-값, 그래프의 5가지 데이터베이스 유형은 각각 다른 목적과 데이터 구조에 최적화되어 있으므로, 데이터의 특성과 필요한 기능에 따라 적절한 유형을 선택하는 것이 중요합니다.

데이터베이스 선택 시 초기에는 관계형 데이터베이스(예: PostgreSQL)가 좋은 출발점이지만, 프로젝트 요구사항 변화에 유연하게 대응하고 다양한 유형의 데이터베이스(예: 분석을 위한 ClickHouse, 캐싱을 위한 Valkyrie, 비정형 데이터 검색을 위한 OpenSearch, 네트워크 데이터 분석을 위한 Neo4j) 간의 통합 전략을 고려해야 합니다.

단일 프로젝트에서 여러 유형의 데이터베이스를 사용할 경우, Kafka와 같은 메시징 시스템을 통해 데이터 스트림을 구축하여 데이터베이스 간의 의존성을 줄이고 효율적인 데이터 흐름을 관리하는 것이 권장됩니다.

다섯 가지 데이터베이스 유형 소개

이번 강연에서는 **데이터베이스가 다섯 가지 유형으로 나뉘는 이유와 각 유형을 언제 사용해야 하는지**에 대해 설명합니다. 이는 동료와의 논의에서 시작되었는데, 그는 데이터베이스 분류에 대해 다른 견해를 가지고 있었고, 연사는 관계형, 컬럼, 문서, 키-값, 그래프의 다섯 가지 유형이 명확하다고 주장했습니다.

각 유형에 대해 **어떻게 사용할 수 있는지에 대한 예시와 최소 하나 이상의 오픈 소스 예시**가 제공될 예정입니다. 제시된 예시들은 유일한 선택지가 아니므로, 개인적인 조사를 통해 더 많은 정보를 얻을 수 있습니다. 관계형 데이터베이스부터 시작하는 것은 그 이유가 곧 분명해질 것이기 때문입니다.

관계형 데이터베이스: 기본 스키마와 SQL

관계형 데이터베이스는 **1970년 에드가 코드의 논문 '대규모 공유 데이터 뱅크를 위한 데이터의 관계형 모델'에서 시작**되었습니다. 당시의 '대규모' 데이터 처리 요구를 해결하기 위해, 기존 데이터베이스 방식의 복잡성과 프로그램 변경의 필요성을 극복하고자 했습니다. 코드는 충분히 간단하고 추상적인 수학적 접근 방식을 만들어 거의 모든 것을 나타낼 수 있도록 했으며, 이는 오늘날 관계형 기술이 전 세계를 지배하게 된 성공의 기반이 되었습니다.

코드가 '관계'라고 불렀던 것은 현재 '테이블'로 통용되며, 이 기술이 널리 채택되기까지 약 15년이 걸렸습니다. IBM이 1980년대 중반에 관계형 데이터베이스를 채택하면서 **지배적인 기술로 자리매김**했습니다.

원래 테이블은 우리가 익숙한 방식이지만, 데이터가 복잡해지면 중복이 많이 발생할 수 있습니다. 이를 해결하기 위해 책 테이블과 저자 테이블을 분리하여 **공유 ID를 통해 서로 다른 테이블의 항목을 연결**하는 방식이 관계형 데이터베이스의 기본 원리입니다. 이는 마치 파이썬 객체가 다른 파이썬 객체에 대한 참조를 가지는 것과 유사합니다.

관계형 데이터베이스와 통신하기 위한 **핵심 도메인별 언어는 SQL**입니다. 1970년대 초반에 개발되었으며, 초기에는 'SEQUEL'로 불리다가 상업적 제품과의 이름 충돌을 피하기 위해 'SQL'이 되었습니다. 1980년대에 표준화되었고 2023년에 최신 버전이 출시될 정도로 현재도 활발히 개발 중인 언어입니다. 표준화 덕분에 거의 모든 관계형 데이터베이스 공급업체에서 SQL 바인딩을 제공하며, 공통점이 많습니다.

SQL을 사용하여 테이블을 생성할 때는 `CREATE TABLE` 문을 사용하며, **각 열의 데이터 유형, null 허용 여부, 기본 키 지정** 등을 정의합니다. 예를 들어, `authors` 테이블과 `books` 테이블을 만들고 `author ID`를 통해 두 테이블을 연결하여 데이터의 무결성을 유지할 수 있습니다. `JOIN` 문을 사용하면 여러 테이블의 데이터를 결합하여 원하는 정보를 조회할 수 있습니다.

SQL은 파이썬과 같은 절차적 언어와 달리, **'무엇'을 원하는지 명시하고 '어떻게' 수행할지는 SQL 엔진에 맡기는 선언적 언어**입니다. 관계형 데이터베이스는 테이블, 행, 열로 구성되며, 스키마 설계와 데이터 구성 방식을 미리 정의하는 것이 특징입니다. 이는 종이나 스프레드시트 사용 방식과 유사하여 매우 자연스러운 사고방식입니다.

첫 번째 관계형 데이터베이스 예시는 **PostgreSQL**입니다. 35년간 활발히 개발되어 온 강력한 데이터베이스로, 다양한 데이터 유형, 함수 저장, 높은 확장성, 쉬운 포크 및 기여 기능이 특징입니다. 매우 광범위하고 깊이 있는 문서화도 잘 되어 있어 관계형 데이터베이스를 사용해야 할 때 **시작하기에 훌륭한 선택지**입니다.

두 번째 예시는 **SQLite**입니다. 작고 빠르며 안정적인 라이브러리로, 파이썬 표준 라이브러리에 내장되어 있어 `sqlite3`을 임포트하는 것만으로 사용할 수 있습니다. 휴대폰 등 **세상에서 가장 많이 사용되는 데이터베이스**라는 주장을 할 만큼 널리 퍼져 있습니다. 라이브러리이기 때문에 단일 사용자 환경에 적합하며, 스키마가 선택 사항이라는 점과 파일 형식으로 로컬 스토리지를 위해 JSON, YAML, TOML 대신 사용하는 것을 권장한다는 점이 독특합니다.

관계형 데이터베이스는 **거의 항상 시작하기에 좋은 곳**입니다. 기술이 매우 성숙하여 대부분의 데이터에 적합하며, 어떤 요구사항이든 충분히 빠르게 처리할 수 있습니다. 하지만 다른 유형의 데이터베이스가 더 효율적인 경우도 있습니다.

컬럼 데이터베이스: 효율적인 분석을 위한 최적화

컬럼 데이터베이스는 관계형 데이터베이스와 유사하지만, **데이터를 행이 아닌 열 단위로 저장하고 액세스하도록 최적화**되어 있습니다. 이는 특정 열만 자주 조회하는 경우에 특히 유용합니다. 예를 들어, 100개의 열 중 2~3개의 열만 필요한 경우, 전체 행을 가져오는 대신 필요한 열만 가져와 효율성을 높일 수 있습니다.

열 단위 저장 방식은 데이터 압축에도 유리하여 **더 효율적인 스토리지와 빠른 검색 속도를 제공**합니다. 열의 데이터 유형을 알기 때문에 데이터 압축이 가능하며, 이는 공간을 절약하고 검색 성능을 향상시킵니다. 데이터가 많이 변경되지 않는 로그 데이터, 센서 데이터, 시계열 데이터 등 기록 목적으로 저장하고 분석하려는 데이터에 특히 적합합니다.

컬럼 데이터베이스의 예시는 **ClickHouse**입니다. 이는 데이터 웨어하우스로 많이 사용되며, 쿼리에 있어 매우 빠릅니다. 기본적으로 관계형 아이디어를 유지하므로 SQL 사용에 익숙한 사용자에게 친숙하며, 열 작업을 위한 추가 기능과 유틸리티를 제공합니다. 레코드에 고유한 기본 키가 없어도 작동할 수 있지만, 있는 것이 도움이 됩니다.

ClickHouse는 **새 행을 더 빨리 추가할 수 있으며, 압축은 백그라운드에서 발생**합니다. 또한, 관계형 데이터베이스와 달리 새 열을 추가하는 것이 더 빠릅니다. 그러나 행을 변경하거나 삭제하는 데는 느릴 수 있습니다. 따라서 많은 열 중에서 몇 개의 열을 쿼리하고 싶을 때, 특히 데이터가 자주 변경되지 않는 경우에 컬럼 데이터베이스를 사용합니다.

문서 데이터베이스: 비정형 데이터와 풍부한 쿼리

문서 데이터베이스는 **JSON과 같은 문서를 저장하는 데 매우 유사**합니다. 텍스트 기반의 많은 데이터를 입력하고 조작하거나 쿼리하려는 경우에 적합합니다. 문서는 JSON 형식을 띠는 경향이 있으며, 인덱스를 통해 검색 시 일치 정도에 따른 관련 점수와 함께 데이터를 반환합니다. 비교적 구조화되지 않은 데이터를 처리하면서도 인덱스와 풍부한 쿼리 기능을 원하는 경우에 유용하며, 업데이트보다는 저장하고 쿼리하는 용도로 더 많이 사용됩니다.

예시로 **OpenSearch**가 있습니다. 이는 오픈 소스 엔터프라이즈급 검색 및 관찰 기능 모음으로, 대규모 비정형 데이터에 질서를 부여하는 데 중점을 둡니다. Apache Lucene 프로젝트를 기반으로 하며, 대량의 텍스트 조작, 토큰화, 검색 등을 처리합니다. 쿼리는 JSON으로 작성되며, 스키마 디자인은 선택 사항이지만 시맨틱 벡터를 저장할 경우 권장됩니다.

OpenSearch는 내장된 시각화 도구인 대시보드를 제공하여 데이터를 실시간으로 보여줄 수 있습니다. 또한, SQL 쿼리 인터페이스도 지원합니다. OpenSearch는 **인덱싱 가능한 JSON 문서를 저장하고 싶을 때, 빠르고 확장 가능한 전체 텍스트 검색을 원할 때, 데이터 스키마를 미리 결정하고 싶지 않을 때, 정교한 분석 및 시각화를 위해** 사용됩니다.

키-값 데이터베이스: 빠른 액세스와 캐싱

키-값 데이터베이스는 **빠른 액세스를 목표로 하는 간단한 구조**를 가집니다. 파이썬 사전처럼 키와 값으로 구성되며, 정교한 값 데이터 유형을 가질 수 있습니다. 예시로 **Redis**가 있습니다. Redis는 고성능 키-값 저장소로, 키는 이진 시퀀스이고 값은 문자열, 리스트, 해시 등이 될 수 있습니다. 값에 1단계 사전을 가질 수 있지만, 사전의 사전을 가질 수는 없습니다. 지리 공간 인덱스, 하이퍼로그로그, 블룸 필터와 같은 독특한 기능도 제공합니다.

Redis는 CLI 프로토콜과 CLI를 통해 쉽게 상호작용할 수 있습니다. `EX60`과 같은 명령어를 사용하여 **값의 만료 시간을 지정**할 수 있어 캐싱에 매우 유용합니다. 메모리에 데이터를 저장하지만 디스크에도 보존되어 빠르면서도 안정성을 확보합니다. 캐싱 외에도, 일반적으로 데이터베이스 용도로는 예상치 못했지만 **pub/sub 메시징 및 메시지 큐**에도 매우 잘 작동합니다. 스트리밍 지원도 있어 Kafka와 유사하게 스트림에 로그를 추가하고 읽을 수 있습니다.

키-값 데이터베이스는 **데이터가 키-값 ID에 적합할 때, 특히 캐싱, 데이터 만료, pub/sub 메시징, 메시지 큐**에 사용됩니다. 흥미로운 데이터 유형 덕분에 고양이 추적과 같은 독특한 용도로도 활용될 수 있습니다.

그래프 데이터베이스: 연결된 데이터의 탐색

그래프 데이터베이스는 **객체 간의 복잡한 연결 관계를 모델링**하는 데 사용됩니다. 1980년대와 1990년대에는 관계형 데이터베이스가 디지털 매핑 분야에서 필요한 대량의 좌표 데이터를 저장하고 빠르게 처리할 수 없었기 때문에 객체 지향 그래프 데이터베이스를 직접 개발하는 사례도 있었습니다. 이는 XY 데이터 그래프가 아니라 **지식 그래프**로서, 사물을 연결하는 방향 그래프입니다.

그래프 데이터베이스는 **노드, 관계(엣지) 및 속성**을 가집니다. 명명법에 대한 표준화는 없지만, 객체/참조/속성 또는 노드/엣지/값 등으로 불릴 수 있습니다. 스키마는 암시적, 점진적 또는 사전에 설계될 수 있으며, 최근에는 데이터 탐색에 많이 사용되어 데이터를 만들면서 스키마를 확장하는 것이 일반적입니다. 노드는 유형을 가지며 속성을 포함할 수 있고, 관계에 따라 연결됩니다. 관계는 노드 간의 링크이며, 일대일, 일대다, 다대일 등 다양한 형태를 가질 수 있습니다.

예시로 **Neo4j**가 있습니다. 이는 세계에서 가장 사랑받는 그래프 데이터베이스로, 시장 침투율이 가장 높습니다. Neo4j에서 노드는 레이블을 사용하여 유형을 나타내고 키-값 속성을 가지며 인덱싱됩니다. 관계는 이름, 유형, 시작 노드, 끝 노드를 가져야 하며, 방향이 있고 속성을 가질 수 있습니다.

Neo4j는 **Cypher라는 자체 쿼리 언어**를 사용하며, 영화 데이터베이스에서 '케빈 베이컨 거리'를 찾는 것과 같은 복잡한 관계 쿼리를 쉽게 수행할 수 있습니다. 시각화 도구가 내장되어 있어 그래프 구조와 관계를 직관적으로 이해할 수 있습니다. 그래프 데이터베이스는 **지식 그래프 형태의 퍼즐이 있을 때, 네트워크 분석이 필요할 때, 스키마가 암시적이거나 점진적으로 구축되어야 할 때** 사용됩니다. 또한, 커뮤니티 지원을 통해 학습 및 활용에 도움을 받을 수 있습니다.

데이터베이스 유형 간의 공통점과 선택의 지혜

다섯 가지 데이터베이스 유형은 모두 데이터를 저장하며, **모두 어떤 형태로든 JSON을 지원**합니다. 예를 들어, ClickHouse는 컬럼 데이터베이스임에도 JSON 분석 속도를 높이는 혁신적인 기술을 선보였습니다. 또한, 머신 러닝을 위해 **모두 어떤 종류의 벡터 임베딩을 지원**하며, SQLite에는 확장 기능이 있고, 모든 데이터베이스는 어떤 방식으로든 확장 가능합니다.

데이터베이스를 선택할 때는 **초기에 최선의 추측을 하고 나중에 생각을 바꿀 준비를 하는 것이 중요**합니다. 디지털 매핑 프로젝트처럼 관계형 데이터베이스가 특정 문제에 적합하지 않다는 것을 깨닫고 자체 솔루션을 개발해야 했던 경험도 있습니다. 관리형 솔루션을 선택할 때는 **데이터를 쉽게 가져오고 내보낼 수 있는지 확인**하는 것이 중요합니다. 이는 잘못된 데이터베이스나 공급업체를 선택했을 때 유연하게 대응할 수 있는 핵심적인 장점입니다.

단일 프로젝트에서 여러 유형의 데이터베이스를 사용할 경우, **데이터 스트림을 활용하여 데이터베이스 간의 연결을 분리**하는 것이 좋습니다. 예를 들어 Kafka와 같은 메시지 큐 시스템을 데이터 백본으로 사용하여 PostgreSQL, ClickHouse, Redis 등이 각자의 스트림에서 필요한 데이터를 읽도록 구성하면, 서로의 종속성을 줄이고 엉킨 네트워크가 형성되는 것을 방지할 수 있습니다. 이는 각 데이터베이스가 독립적으로 작동하며, 소비자는 원하는 메시지를 선택하여 읽을 수 있도록 합니다.

발표자가 언급한 다섯 가지 데이터베이스 유형은 무엇이며, 각 유형은 어떤 용도로 사용하기에 적합하다고 설명했나요?

관계형 데이터베이스의 역사적 배경과 SQL의 중요성, 그리고 관계형 데이터베이스가 오늘날까지 지배적인 기술이 된 이유는 무엇인가요?

컬럼 데이터베이스가 관계형 데이터베이스와 비교했을 때 가지는 주요 장점과 단점은 무엇이며, 어떤 종류의 데이터에 가장 적합하다고 설명했나요?

문서 데이터베이스와 키-값 데이터베이스는 각각 어떤 특징을 가지며, 언제 사용을 고려해야 한다고 언급했나요?

그래프 데이터베이스는 어떤 구조를 가지며, 발표자가 언급한 사용 사례 외에 어떤 경우에 특히 유용하다고 생각하시나요?

그래서 저는 여러분에게 왜 데이터베이스에 다섯 가지 유형이 있는지, 그리고 왜 각각을 사용해야 하는지 설명하려고 합니다.

이것은 동료와의 논의에서 나온 것입니다. 저에게는 솔직히 아직도 이해가 안 되는 방식으로 데이터베이스를 분류하는 동료가 있었는데, 제가 '데이터베이스에는 다섯 가지 유형이 있는 게 당연하잖아요'라고 말했더니 그가 '뭐라고요?'라고 했습니다.

그래서 저는 유형을 관계형, 컬럼, 문서, 키-값, 그래프라고 생각합니다.

이것들을 어떻게 사용할 수 있는지에 대한 예와 이러한 각 예에 대한 최소 하나의 오픈 소스 예를 제공할 것입니다.

제가 선택한 예가 유일한 예는 아닙니다. 직접 조사해 보세요. 자, 관계형부터 시작할 건데, 그 이유는 잠시 후에 분명해질 겁니다.

자, 여기 테이블이 있습니다. 이름은 books이고 세 개의 열이 있습니다.

이름은 ID, 제목, 작성자입니다. 각 열에는 데이터 유형이 있습니다. 행을 서로 구별하는 데 사용하는 정수 ID가 있습니다.

그리고 두 개의 문자열 열이 있습니다. 하나는 책 제목이고 다른 하나는 저자 이름입니다.

어, 저는 책을 쓴 적이 없습니다. 이 책들은 지어낸 것입니다. 이 예에 나오는 모든 책은 가짜입니다.

어, '이 책'과 '저 책'이라는 책을 찾지 마세요. '저 책'이라는 책을 원하지만요.

관계형 데이터베이스는 1970년 에드가 코드의 '대규모 공유 데이터 뱅크를 위한 데이터의 관계형 모델'이라는 논문에서 나왔습니다.

여기서 large는 당시의 맥락에서 볼 때 비교적 작은 것으로 간주되지만, 당시에는 많은 양의 데이터를 처리하려는 사람들이 있었습니다.

어, 문제는 기존의 데이터베이스 생성 방식은 프로그램이 데이터베이스의 구조를 알아야 하는 경향이 있다는 것입니다. 따라서 데이터를 변경하려면 프로그램을 변경해야 했습니다.

음, 그리고 그것은 모두 약간 까다로웠습니다. 그는 거의 모든 것을 나타낼 수 있을 만큼 충분히 간단하고 충분히 추상적인 수학적 접근 방식을 만들고 싶었습니다.

그리고 저는 그가 관계형 기술이 오늘날 세계를 장악했기 때문에 그의 가장 엉뚱한 꿈을 넘어 성공했다고 생각합니다.

음, 그리고 여기에 그를 관계형 데이터베이스의 대부이자 아마도 모든 데이터베이스의 대부로 간주해야 한다는 메모가 있습니다.

어, 이 논문은 온라인 노트에 있고, 링크가 있습니다.

음, 그의 용어에서 그가 관계라고 부르는 것을 우리는 지금 테이블이라고 부릅니다. 이것은 실제로 채택되는 데 약 15년이 걸렸습니다. 어, 마이크로 및 미니 컴퓨터, 팩스 기기 등에서의 채택은 매우 빨랐지만 IBM은 구형 데이터베이스 형식을 포기하는 것을 매우 꺼렸고, 당시 대형 컴퓨팅 세계에서 매우 지배적이었던 IBM이 관계형 데이터베이스를 채택한 것은 1980년대 중반이 되어서였고, 그것이 지배적인 기술이 되었습니다.

이제, 원래 테이블은 우리 모두 테이블에서 생각하는 데 익숙하지만 테이블 데이터에 있는 내용을 늘리기 시작하면 매우 복잡해지고 종종 많은 중복이 발생합니다.

그래서 여기서 우리가 하는 것은 책 테이블과 저자 테이블을 가지고 있다는 것입니다.

음, 빨간색으로 표시된 저자 ID를 사용하고 있습니다. Books 테이블의 두 책이 동일한 저자를 가지고 있음을 알 수 있습니다.

저자 테이블에서 해당 ID를 살펴볼 수 있습니다. 예를 들어 John Smith가 두 명인 경우에 이것이 유리합니다.

음, 우리는 어떤 것을 의미하는지 지정할 수 있습니다. John Smith를 하나의 테이블에서 이름으로만 사용했다면 모든 것이 매우 혼란스러워질 것입니다.

공유 ID를 사용하여 서로 다른 테이블의 항목을 연결할 수 있다는 이 아이디어는 관계형 데이터베이스가 작동하는 방식의 기본입니다.

그리고 생각해 보면, 저는 이것들을 다른 Python 객체에 대한 참조가 있는 Python 객체와 약간 비슷하다고 생각합니다.

여기서 중요한 개념은 관계형 데이터베이스와 통신하기 위한 도메인별 언어인 SQL입니다.

그것은 70년대에 시작되었습니다. 따라서 원래 논문이 나왔을 때부터 매우 초기에 나왔습니다. 원래 이름은 SQL이었는데, 이는 아마도 경쟁하고 있던 Ingres의 Quell이라는 관련 언어에 대한 말장난이었을 것입니다.

동일한 이름을 가진 상업 제품이 있었기 때문에 그 이름을 고수할 수 없었고, 그들은 화를 낼 것입니다.

그래서 SQL이 되었지만, 그래서 사람들이 SQL에 대해 이야기하는 것을 듣게 될 것입니다.

그 발음은 오랫동안 사용되었습니다. 1980년대에 표준화되었지만 최신 버전은 2023년에 출시되었습니다.

따라서 이것은 여전히 활발히 개발 중인 언어입니다.

표준화되었기 때문에 거의 모든 관계형 데이터베이스 공급업체에 SQL 바인딩이 있음을 알 수 있습니다.

서로 완전히 똑같지는 않지만 공통점이 많습니다.

이러한 테이블을 만들려면 다음과 같은 SQL 문을 사용할 수 있습니다. 음, authors라는 테이블을 만들고 있습니다. ID 열을 정수로 정의하고 있습니다.

값이 null이 되는 것을 원하지 않습니다. 값이 있어야 합니다. 그리고 이것이 기본 키라고 말하고 있습니다.

이것이 레코드를 식별하는 방법입니다. 그리고 이름이 있는데, null이 아닌 텍스트 필드입니다.

세부 사항은 데이터베이스마다 다를 수 있습니다. 그리고 책이 있습니다. 다시 말하지만, ID가 있고, 정수이고, 기본 키입니다.

null이 아닙니다. 제목이 있는데, null이 아니어야 합니다.

그리고 author ID가 있습니다. 이것은 정수입니다. 그리고 여기서 authors 테이블의 ID를 참조한다고 말하고 있습니다.

이것은 author ID를 추가할 때 데이터베이스가 authors 테이블에 이미 존재하는 ID를 사용하고 있는지 확인할 수 있음을 의미합니다.

따라서 데이터가 깔끔하게 유지되고 실수를 방지하는 데 도움이 됩니다.

그리고 이 유명한 작가 Tibs가 쓴 책을 찾으려면 책을 선택할 수 있습니다.

책에서 제목을 선택하고 authors 테이블의 author ID와 일치하는 책 테이블의 ID를 함께 조인해야 합니다. 그리고 조회할 때 일치시키고 싶다고 말하고 author의 이름이 Tibs이기를 원하면 이 책과 저 책을 다시 얻을 수 있습니다.

1980년대부터 SQL 조인 작성에 어려움을 겪고 있다는 점을 지적해야 합니다. 항상 방법을 찾아봐야 합니다.

따라서 SQL이 어렵다고 생각하더라도 걱정하지 마세요.

그러나 SQL은 Python과 같이 우리 모두가 익숙한 절차적 언어와는 다른 종류의 언어이기 때문에 배우기에 정말 좋은 언어입니다. Python에서는 컴퓨터에게 이렇게, 저렇게, 저렇게 하라고 지시합니다.

SQL에서는 이것에 대해 알아내고 이 결과를 제공하는 것입니다.

음, 그런 다음 SQL 엔진이 어떻게 해야 할지 알아내는 것은 SQL 엔진에 달려 있습니다.

따라서 관계형 데이터베이스에는 테이블, 행, 열이 있습니다.

우리 모두 꽤 익숙합니다. 우리는 여러 세대에 걸쳐 종이와 연필로 그렇게 해왔습니다. 그리고 물론 스프레드시트도 사용했을 것입니다.

그래서 이런 것들은 매우 자연스러운 사고방식인 경향이 있습니다. 스키마 설계, 데이터 구성 방식과 데이터가 어떤 모습인지 미리 알려주는 것이죠.

테이블을 만들 때 컬럼을 어떻게 만들지 미리 알려줘야 합니다.

첫 번째 예시는 PostgreSQL인데, 코끼리가 PostgreSQL의 아주 멋진 로고입니다. 왜냐하면 크고 강력한 무언가이기 때문이죠.

35년간 활발하게 개발되어 왔는데, 이는 1990년으로 거슬러 올라갑니다. 음, 기억하려고 적어놨어요.

음, 항상 시작하기에 좋은 곳입니다. 제가 가장 좋아하는 데이터베이스 중 하나입니다.

음, 제가 좋아하는 데이터베이스가 있습니다. 좋아요. 음, PostgreSQL이라고 발음하는데, 역사 때문에 PostgreSQL이라고 불러도 된다고 생각합니다. 80년대로 거슬러 올라가면 됩니다.

PostgreSQL로 이어지는 데이터베이스의 순서가 있습니다.

정수, 텍스트 등 뿐만 아니라 다양한 데이터 유형을 가지고 있습니다. 데이터베이스에 함수를 저장할 수 있습니다. 즉, 데이터베이스에서 코드를 실행할 수 있으므로 클라이언트가 코드를 실행할 필요가 없습니다.

Explaining the 5 types of database and how to choose between them — Tibs

스크립트