最高に柔軟なデータベース！SurrealDB

2022/11/30 IT

最近の開発だと、RDB、KVS、ドキュメントDB。。。

データの形式や構造、使い方によりデータベースを使い分けることも少なくないですよね。

今回はそんな悩みを解決できそうな存在、SurrealDBに出会いましたので、

触ってみた感じをお伝えしたいと思います。

目次

1 SurrealDBとは
2 DB起動
3 クエリ使用例
4 まとめ
- 4.1 メリット
- 4.2 デメリット

SurrealDBとは

公式によれば

SurrealDB is the ultimate cloud database for tomorrow’s applications
SurrealDBは未来のアプリケーションのための究極なクラウドデータベース

というRust製のデータベース。

従来のRDBのようにスキーマ定義を使用したものや、

KVSのようなデータ、グラフ構造データなど、さまざまなデータを柔軟に扱えるのが強み。

また、独自にSurrealQLというsqlライクな言語があり、

比較的簡易に抽出が行えるよう工夫されている。

DB起動

docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start --user root --pass root

1	docker run --rm -p 8000:8000 surrealdb/surrealdb:latest start --user root --pass root

すでにコンテナイメージがあるので簡単に起動＆スピーディー
コンテナ起動以外にも各種OS用のバイナリが用意されている
起動後はユーザやDB作成、テーブルの作成が不要で、すぐにデータ登録や検索が行える

クエリ使用例

データ登録＆更新

CREATE person:tester SET name = "test"
UPDATE person:tester SET address = "home"

1 2	CREATE person:tester SET name = "test" UPDATE person:tester SET address = "home"

データにはidと呼ばれるレコードを一意にするものがあり、

上記例ではperson:testerが該当。

「person」がRDBでいうところのテーブル名にあたり、

「tester」がプライマリキーのイメージ。

この2つの組み合わせでレコードを特定する。

また、tester部を指定しない場合、ランダム文字列で作成される。

データ関連付け

CREATE person:tester SET name = "test", friends = [person:test1, person:test2]

1	CREATE person:tester SET name = "test", friends = [person:test1, person:test2]

上記のようにレコードのカラムとして、他のレコードとの関連を作成することができる。

RDBのように中間テーブルにID同士の関係をもつようなデータは不要。

RELATE person:tester->say->greet:hello CONTENT { time = time::now() }

1	RELATE person:tester->say->greet:hello CONTENT { time = time::now() }

上記例ではRELATEというコマンドにより、グラフDBでいうノードとエッジの関係を構築することができる。

この例では、エッジとしてsayというデータオブジェクトを介してpersonとgreetが紐付いている状態を作成することができる。

また、CONTENTとしてこの関係に対してのプロパティも追加可能。柔軟にデータをもたせることができる。

検索

データの検索

SELECT * FROM person WHERE name = "tester"
SELECT * FROM person:tester

1 2	SELECT * FROM person WHERE name = "tester" SELECT * FROM person:tester

personoのIDを指定しなければ、personの全件が対象となる。

関連性の検索

SELECT ->belong->attribute.name FROM person

1	SELECT ->belong->attribute.name FROM person

->で始まっているのは、FROMの部分を省略しているため。

実際は、

person->belong->attribute.name

1	person->belong->attribute.name

と同意。

この検索では、personがbelongというエッジを介して関連づいているattributeのnameを取得するといった抽出を行っている。

これは逆からの検索も可能で、

SELECT <-belong<-person[where name = 'hoge'].address FROM attribute

1	SELECT <-belong<-person[where name = 'hoge'].address FROM attribute

この場合だと、attributeにbelongというエッジを介して関連づいているpersonのうち、

nameがhogeであるもののaddressを抽出するということを行っている。

まとめ

触ってみて感じたのは、使い出すまでの簡単さと使いやすさ。

個人開発だったり、少人数開発なら現状でも全然使えるなと。

インメモリで起動しておいて、ちょっと退避する場所としてキャッシュ的に

使うとか夢が広がった感じでした。

メリット

・データが本当に柔軟に、かつ直感的に格納できる

・クエリもルールさえわかってしまえば、従来のjoinをsqlに書いたりは必要なく簡易

・起動や処理速度が速い

デメリット

・各言語のライブラリが開発中。まだまだ発展途上で、現状だとjavascriptやRust、

Goくらいしかない

（とはいえ、HTTP通信でクエリは発行できるので問題ないといえばない）

・GUIクライアントがないので、データが全体的に今どうなっているのか？を判別する

手段がない。これが整ってこないと多人数の開発には不向き。

データ構造をまとめる資料を作ったとしてもメンテされないとかで

結局実態が見えてこない状態になることが想像に難くない。

それでは！！！

にほんブログ村

人気ブログランキング

たーちゃん

20代前半までは東京で音楽をやりながら両手の指以上の業種でアルバイト生活をしていましたが、某大手プロバイダのテレアポのバイトでPCの知識の無さに愕然とし、コンピュータをもっと知りたい！と思ったことをきっかけに25歳の時にITの世界に未経験で飛び込みました。
紆余曲折を経て、現在は個人事業主としてお仕事させていただいており、10年ほどになります。
web制作から企業システム構築、ツール開発など、フロントエンドもバックエンドもサーバーもDBAも依頼があれば何でもやってきた雑食系エンジニアです。

今風にいうとフルスタックエンジニアということになるのかしら？？

→ 詳細プロフィールというか、生い立ちはこちら

→スキルシートをご覧になる場合はこちら

→お仕事のご依頼やお見積りなどお問い合わせはこちらから！

関連記事