気がつくと一年が終わりそうという事実に毎年驚愕しています。
今年はアドベントカレンダーに空きがあるようなので、仕事で使い始めてから2年は経過している
Datomicの軽めな話題から投入しようと思いこちらを執筆しました。
Datomicを使ってて嬉しい点
datalogが楽しい
初見だとエグい感じの見ためですが、慣れると脳汁ドバドバです。
個人的にはエンティティ間のjoinに頭を使わずに済む点が好きです。
select user.name, order.id from user inner join order on user.id = order.user_id;
[:find ?user-name ?order-id
:where
[?u :user/name ?user-name]
[?u :user/id ?user-id]
[?o :order/user-id ?user-id]
[?o :order/id ?order-id]]
Presto連携が強い
仕事ではmetabase->Presto->datomicの接続をセットアップしているおかげでダッシュボード的な機能を殆ど実装せずに済んでいます。
metabaseにクエリを足すだけ。
とある時点でのdb valueに対してクエリを行なうので一貫性を心配することが少ない。
datomicでクエリを行う操作はまずコネクションからdb valueを得るところから始まります。
このdb valueはどの時点かという属性が含まれており、内容が変わらないことが保証されています。
これは例えばとある条件にマッチするレコードの一覧(のページ)とカウントを別々のクエリーで取得してAPIのレスポンスで合体させて返すみたいな処理を実装する時に嬉しいです。
History api
端的に言うとデータの変更履歴が何もしなくても取得できる、ということです。
伝統的なデータベースを利用していて変更履歴的な機能を実装したい場合、履歴用のスキーマをデータとは別に用意して。。。という流れが選択肢になると思われますが
- 更新の際に履歴として保存するデータに漏れがある
- 履歴の保存を独自で実装することによって発生するバグ
といった問題と争わずに済むのは特にあたりまえにデータの変更履歴機能を求められる現職ではありがたい限りです。
更にdatomicではトランザクション自体もデータなので変更の原因、誰が変更したかといった情報をエンティティの表面に露出させずに済むのも強力です。
Datomicに頑張って欲しい点
クエリ結果のorder-byが提供されていない
僕の持っている情報が古い可能性はありますが、SQLで言う所のorder-by ...に相当する機能が無いためdatomicのapiレベルでソート済みの結果を得る方法が無いため、自前でソートを行なう必要があります。
適切にindexが指定できていれば伝統的なデータベースにおいてもパフォーマンス的な問題にはなりづらい認識[要出典]なので、datomicの方でも実装する気になればできるのでは？という気がしています。
フレーバーの乱立
プロダクション向けでdatomic-cloud/datomic on-prem,
開発用途でdatomic-pro/dev-local,
deprecateされた物にfree edition,
そしてon-premはコンポーネントの選択肢がdynamo dbだったりsqlデータベースだったりを選べます
こちらはアーキテクチャの自由度とのトレードオフなのでマイナスな感情では無いのですが、
ある機能が自分の利用しているフレーバーで使えないことがしばらくしてから分かったりするので意識する必要があるなぁーという感想です。
といった感じでdatomicは楽しいのでぜひ日本でも広まって欲しいなーという希望を込めて結びとさせていただきます!