Posts for: #Database

mongodb のトランザクションの考え方

1時に寝て8時に起きた。3時頃に気分悪くて起きて少し吐いてそれからまた寝た。丸1日機能拡張とリファクタリングのために go のコードを書いていた。

mongodb のトランザクション管理

2つの web api から同じコレクションの異なるフィールドを更新したい。mongodb で厳密なトランザクションを管理するようなアプリケーションではないけど、なるべく整合性を維持できるように努めることはやっておきたい。mongodb でトランザクションに近いことを実現する方法として次の記事が参考になった。

この記事では findOneAndUpdate() という api を使って、更新時に必ず変更されるフィールドを含めることで find したときのそのフィールドの値が変わっていればエラーになってくれることでトランザクション相当の機能が提供されると書いてある。必ず変更されるフィールドとして ObjectId を使えば他の更新処理を検出するのに役立つだろうとある。いま私が開発しているアプリケーションでは同じフィールドを複数の web api から更新するわけではないのでここまで厳密なトランザクション管理は必要にない。

既存の処理が Replace を使って実装されていたのを Update を使うように変更する。Replace と Update の違いはドキュメント全体を更新するのか、一部のフィールドのみを更新するのかの違いになる。具体的には go のドライバーにおいて次のメソッドの使い分けになる。

これらのメソッドを使うことで find と replace/update の操作を1回の処理でできるから効率もよいらしい。

後世に残せるものを書く

0時に寝て4時に起きて6時半に起きた。今日は3つのイベントに参加して疲れた。そのうちの2つを紹介する。

データ指向アプリケーションデザインの紹介イベント

Data Engineering Study #18「データ指向アプリケーションデザイン」 に参加した。監訳者のさいとうさんのブログの 2022年を振り返って を読んだときにたまたまみつけて登録していた。

14:00 - 16:30 というちょっと変わった時間帯に設定されているのはさいとうさんが米国在住で時差によるものだと推測する。さいとうさんのいる場所では21時ぐらいと話されていたような気がする。2時間半分のお仕事を休んでもこのイベントは聞きたいなと思ったので取引先に連絡した上でその時間帯はイベントを聞いていた。

この本は人類の叡智といってよいと私は思う。 さいとうさんによると、2007-2017年の過去10年間の分散データシステムの教科書と紹介されていた。私はそれ以前の研究を知っているわけではないので、私のような初学者にとってはもっと長い期間のデータベース研究の歴史を学べるように感じた。 著者はこの本を書くのに4年を費やしたという。本を1冊書くのに4年とか、著者の偉大さが伺える年月でもある。

著者はデータベースの研究者であろうけれど、すべての研究を自分で行ったわけではないだろう。 他者の研究を調査した上でこういった書籍にまとめるというお仕事も非常に価値のあることだと本書を読んで実感した。私も課題管理の分野でそういうことができればいいなと思う。

さいとうさんの講演のタイトルは「30分でわかる〜」という接頭辞がついているものの、さいとうさんと同レベルの人にしかわかるわけはなくて、このイベントに参加しても本に書いてある全体像がわかるだけで、本の内容がわかることはほぼないと言える。私はこの本を精読したのでさいとうさんの話しを聞きながら、あの辺の書いてあった話しの紹介だなと記憶を辿りながら聞いていた。

コワーキングのオンラインイベント

月例のカフーツさんのオンラインイベントに参加した。先月の所感はここ 。今日の話題は 間借りコワーキング だった。実際にカフーツさんで間借りコワーキングを実践された方をゲストにお招きしてその体験談を話してもらってみんなで議論したりしていた。ここで言う間借りとは、コワーキングスペースの運営をメンバーにも体験してもらってそこから新たな価値を模索しようといったもの。インターンシップのようなものとも言えるし価値創造のための施策とも受け取れる。ただのアルバイトではないという意図で「間借り」という名前を付けている。最初に説明を聞いていて、あまり私にはピンと来なかった。それは it 業界は勉強会を個々に開くのが当たり前過ぎて、そんなのはわざわざコワーキングスペースの運営者にならなくてもすぐにできることのように思えたから。おそらくここは it 業界が先進的過ぎて、普通の組織や会社に勤めている人は、気軽に知人や不特定多数の人たちを呼んで勉強会 (イベント) をしたりしないのだと推測する。

それからコミュニティの話題で、強い紐帯と弱い紐帯の話しが出てきて、リンダ・グラットン 氏の著書に書いてあった言葉として「境界接続者」という用語を紹介されていた。私が軽くググってみてもその用語は出てこないのでおそらくは次の研究者の研究を紹介されている一節だったのではないかと推測する。

 アメリカの社会学者M・グラノヴェッターの「弱い紐帯の強さ」という有名な説をご存じの方は多いと思う。「紐帯(ちゅうたい)」とは文字どおり紐(ひも)や帯(おび)のことではあるが、転じて「二つのものをかたく結びつけるもの」また「 血縁・地縁・利害関係など、社会を形づくる結びつき」という意味がある。(「デジタル大辞泉」より)「弱い紐帯の強さ」とは『価値ある情報の伝達やイノベーションの伝播においては、家族や親友、同じ職場の仲間のような強いネットワーク(強い紐帯)よりも、「ちょっとした知り合い」や「知人の知人」のような弱いネットワーク(弱い紐帯)が重要である』という社会ネットワーク理論である。もう40年前に発表されたが、SNSが世の中を席巻するようになり再び注目をあびている。

会社内の「弱い紐帯(ちゅうたい)」

なにかの英語の言葉の訳語として「境界接続者」という用語をあてているのだと推測する。ここでいう境界とは、コミュニティとコミュニティをつなぐ役割をする人のことでそういった人がコミュニティにおいて大きな価値を提供しているというのが、弱い紐帯の強さで提案されている価値に相当するらしい。それを体験もしくは実践する機会として間借りコワーキングはうまく作用するのではないかという企画につながってくる。そこまで聞いて、単なるインターンシップではないことは理解できた。

私はどちらかと言うと弱い紐帯よりも強い紐帯のコミュニティの価値を認める方だと言える。その真逆の考え方は懸念もいくつかあるものの、普段は考えないことを考える機会としておもしろかったと言える。社会で生きていく上でどちらの要素もあることなので一方に固執しなくてもよいというのも正しいと思う。

flyway を触ってみた

0時に寝て4時に起きてタイムライン眺めながらだらだらして6時半に起き上がった。

データベースの移行処理

半年前から導入したいという話しは聞いていたものの、先送りになっていたライブラリに flyway がある。データベースの移行処理のためのスクリプト (sql) を管理するツールでどの移行スクリプトを実行したかを記録したり、未適用の処理を自動で適用してくれたりする。spring boot だとすぐ組み込める状態になっていて Community Plugins and Integrations: Spring Boot をみながら設定したらすぐに動いた。flyway 自体の設定も Common Application Properties を参考に spring boot の設定ファイルで行える。

例えば、こんな感じ。

spring:
  flyway:
    enabled: true
    schemas: public
    locations: classpath:db/migration
    baseline-version: 0
    baseline-on-migrate: true

移行処理の履歴情報は flyway_schema_history テーブルに保持される。既存のテーブルが存在して flyway の履歴データがない場合 (初回起動時) に移行処理を実行するかどうかを baseline-on-migrate で決める。実行するなら baseline-version でどのバージョンをベースラインとするかも設定できる。ゼロにすることで V1 からの sql ファイルを適用してくれる。ベースラインの考え方は実際に何度かデータベースの初期状態を変えて実行しないとわかりにくいかもしれない。