サイトアイコン たーちゃんの「ゼロよりはいくらかましな」

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

たーちゃん

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

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

 

 

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

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

 

 

 

 

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

 

クエリ使用例

データ登録＆更新

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]

 

上記のようにレコードのカラムとして、他のレコードとの関連を作成することができる。
RDBのように中間テーブルにID同士の関係をもつようなデータは不要。
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

 

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

関連性の検索

SELECT ->belong->attribute.name FROM person
->で始まっているのは、FROMの部分を省略しているため。
実際は、
person->belong->attribute.name

 

と同意。
この検索では、personがbelongというエッジを介して関連づいているattributeのnameを取得するといった抽出を行っている。
これは逆からの検索も可能で、
SELECT <-belong<-person[where name = 'hoge'].address FROM attribute
この場合だと、attributeにbelongというエッジを介して関連づいているpersonのうち、
nameがhogeであるもののaddressを抽出するということを行っている。

 

まとめ

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

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

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

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

 

メリット

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

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

・起動や処理速度が速い

 

デメリット

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

Goくらいしかない

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

 

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

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

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

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

 

 

それでは！！！

 

 


にほんブログ村


人気ブログランキング

モバイルバージョンを終了