大学院に進学することにした

今年の4月から明治大学大学院先端数理科学研究科ネットワークデザイン専攻の博士前期課程に進学します。

この記事は私の近況報告的な意味だけでなく、大学院に進学するか迷ってる人が進路を考えるための材料にもなればいいと思っています。

学部生時代の私

自己紹介がてらちょっとだけ学部時代(まだ学部生だけどね)の私について書きます。

私は典型的な、インターンのしすぎで学問が疎かになる学生で、 好きなように好きなコードを書いてきました。

といっても大してすごいことを成し遂げているわけではなく、今就職してチームにぶち込まれてもまあ足手まといにならないくらいにはコード書けるかなあってくらいのレベル感です。分からないところが分かる、って感じ。

周りの反応

大学4年生になって「進路どうするの?」と尋ねられた時に「大学院へ行きたい」と言うと少なくない数の人に止められました。

一番多かった意見が「君は研究より実務のほうが向いていると思うから早く社会経験を積め」というものでした。

この意見に関しては私としても真っ向から否定する気はなくて、確かに私は過去の活動から実務のほうが得意だと思っています。

この、私の適正(?)に関しては院試の面接でも突っ込まれたり、10年近い付き合いになる政治学科の後輩くんも「僕先輩が院行くと思ってなかったんですよね、なんか企業の技術職としてヌルっと良いとこ就職しそうなイメージ」(原文ママ)と言ってたりと、ずっと私に付きまとっています。

なぜ大学院に行こうと思ったのか

こんな、実務の方が向いてそうな私が大学院に行こうと思ったのにはいくつか理由があります。

  • (1)結局実務のためには学位が必要らしいことをアメリカで就職活動をしている中で感じた
  • (2)理系なのに学会発表なく卒業してしまうのは嫌だった
  • (3)今のうちに研究もやっておきたかった
  • (4)専門性を高めたい
  • (5)より少ないパイに身を置きたかった

(1)実務のためには学位が必要

少し前の記事に書きましたが、日本国外(特にUS)で開発者としての職を得ようと思ったら学位はあったほうがいいみたいですね。実際私も大学院を意識しだしたのはUS滞在中だったように記憶しています。

asmsuechan.hatenablog.com

Twitterで「学位」とかで調べると結構面白いツイートがヒットします。

実際、必要とされるのは学位だけではなく学位の先にある実務の経験だとは思いますが、雇用に関しては国や地域で事情が違うので下手に一般化出来る問題でもないですね。

(2)理系なのに学会発表なく卒業してしまうのは嫌だった

理系学生なのにまだ学会発表を1度もしたことがないというのは小さなコンプレックスだったりします。ですのでこのまま経験0の状態で卒業するのは嫌でした。

ちなみに学部生だからといって学会発表できないわけではなく、うちの研究室も1学年1-2人学会発表に行く人はいます。

(3)今のうちに研究もやっておきたかった

いろんな人に言われるように研究ではなく実務が得意な方の人なので、今のうちに研究もやっておきたかったです。

(4)専門性を高めたい

休学中の2017年秋頃のある日「俺が今書いているコード、誰でも書けるよなあ」ということに気づきました。どうせなら誰でもはできない事がしたくて、専門性を高めるために大学院を志望しました。

しかし開発者(志望)である以上は他の人が読んで分かるコードを書く必要があるので、この「誰でもはできないこと」をしたいという意見には自分事ながら少し考えさせられるものがありますね。

(5)より少ないパイに身を置きたかった

学部卒より修士卒の方が少ないのは明らかです。より少ないパイに身を置いて自分の希少性(?)を高めれば後々いいことが起こるかもしれないというぼんやりした期待があります。もっと数が少ないであろう博士は・・・ごめんなさい

将来のことはあまり深く考えないのですが、tagomorisさんのこちらのツイートがとても強く印象に残っています。自由に生きていきたいですよね。

大学院選び

大学院選びというよりは研究室選びなんですけどね。

修士へ進学しようと思ったときまずやったのが研究室選びです。この研究室選びに、私は2つの要素を条件にしました。

まず1つがコンピューターサイエンス(以下CS)絡みの問題が試験に出ること。これは私がCSの基礎を身につけたかったためです。

次に、今の指導教員と同等もしくはより多くのものを自分が吸収できそうな研究室であること。これはどうせ外に出るのならば少なくとも現在の環境よりはいい場所に行きたかったためです。

この2つの条件から最終的に1つ研究室を見つけたので、ここに入るための勉強をはじめました。このとき2017年11月。試験の10ヶ月くらい前。結構勉強したつもりです。

ちなみに海外大学院も考えたのですがGPAが低すぎてかなり厳しそうだったので断念しました。

院試の話

夏に外部の大学院、冬に内部の大学院を受けました。夏は結局落ちましたが筆記試験は受かってたのでCSの基礎は身についたのかなと思います。結果は出なかったけど残るものはあったという感覚です。それでも、落ちた原因を内省するのならばそれは自分の勉強不足以外の何物でも無いと思っています。

大学院でやること

研究内容に関してはフラフラと迷走しましたが自立移動ロボット周りの研究を行うことにしました。

ロボット技術はこれから役に立ちそうな予感がしていますし、Web開発の経験があってロボットの研究をしている人は少ないみたいなので是非とも修士の2年間でロボット関連技術を身につけたいと思っています。

しかし所詮私大の修士であるので自分の行う研究の結果に関しては特に期待していません。研究に対して世のため人のためとかいう大義名分はなく言うなれば金と時間のかかる自己啓発といった気持ちです。要するに意義などはあまり深く考えず楽しくやれることをやっていくぞって事です。(もちろん必要な場面で求められる大義名分は引き出しますが)

そして大学院では国内外で学会発表できる事を期待します。これは自分の努力の次第に依るところが大きいかとは思いますが機会を逃さず発表経験を積んでいこうかと思っています。

将来の話

上で将来のことはあまり深く考えないと書いたのですが、浅くなら考えています。たぶん私は修士を卒業してからは世界のどこかで日本語だけじゃなく英語や中国語を話しながら開発者として活動すると思います。

私は先のことを早くから決断してしまうと視野狭窄になってダメになるタイプなのでこれくらいの塩梅がちょうどいいみたいです。とかいいつつ全然違うことやってたらそれはそれで面白いですよね。

2年間、時間とお金はかかりますがまあ私ならこの2年頑張れば15年後だかに元は取れるだろうな、という気持ちになったので最終的に自分へゴーサインを出しました。

終わりに

欲しい物リストです。よろしければ支援をよろしくおねがいします。 http://amzn.asia/gULRJ4O

本人の前では言いませんが、先日面談中に「うちの研究室でもoo大学(夏受けた大学院)に負けないくらいのいろんな機会を用意します」と言ってくださった指導教員の先生にはとても感謝しています。(ちなみに指導教員は夏受けた大学の卒業生)

これまで仲良くしてくださった方々、まだしばらく学生ですがこれからもよろしくおねがいします。

ドキッ!湯けむりだらけの開発合宿

2019/01/12から2019/01/14の2泊3日五十沢温泉ゆもとかん(http://www.ikazawaonsen.com/)に宿泊して開発合宿をしました。

mokumoku-onsen.connpass.com

私は大学生で、スポンサーされる枠で申し込んでスポンサーしていただきました・・・!

1日目

到着まで

旅館がある六日町駅には東京駅から上越新幹線上越線を乗り継いで行くつもりでした。

しかし授業の都合で集合時間に間に合わなかった私は不幸にも黒塗りの高級車に追突してしまう・・・

旅館到着

無事に22:10くらいに旅館でラストサムライかましてしまった私はそのまま流れるようにフードファイトへ。

f:id:asmsuechan:20190115214352j:plain

とてもおいしくて20分くらいで食べ終わりました。魚が・・・魚が・・・とてもおいしかった・・・!

1日目夜

命の水の吸引力に勝てなかった我々はノールックで開封してしまう。

f:id:asmsuechan:20190115215533j:plain

自分がいた部屋はそのまま0時くらいには就寝しました。他の部屋ではスマブラやってたみたいです。

2日目

2日目の朝、部屋の窓を開けるとこんな景色が広がっていました。白い。

f:id:asmsuechan:20190115214705j:plain

そういえば隣の宴会場にいる若いパパママwithキッズがカラオケ大会で盛り上がっていたのがガン聞こえでいいコンテンツになりました。普通に上手くてよかったです。

この日は結構マジメに作業をしたおかげかちょっとだけ進捗が出ました。よかった。

開発開始

1日目を大きく遅刻してきた私は2日目の午前中より開発を開始しました。コードを書く以外のタスクがあまりにも多かったのでそれを3連休のうちに片付けようとセコセコと頑張っていました。

が、しかしやはり日本酒の吸引力には・・・・勝てなかった・・・・・(ここで手記は途切れている)

3日目

さて最終日。

朝はとても軽快な音楽が流れる食堂でバイキング形式の食事です。明太子がおいしかったです。

f:id:asmsuechan:20190115222703j:plain

午前中は温泉に入りアイスを食べ睡眠をとりました!進捗ですね。

ゴハン他人丼さんでした。おいしくいただきました。 f:id:asmsuechan:20190115220930j:plain

合宿でやろうと思っていたこと

  • 卒論バリバリ書く
  • 発表資料作成
  • 期末テストの勉強(2教科)
  • phpunit.xmlとの戦い

合宿で実際にやったこと

  • 期末テストの勉強(1教科)
  • 発表資料作成(半分)
  • phpunit.xmlとの戦い
  • アニメを見る
  • 寝る
  • 温泉
  • 日本酒

あはーーーん。やはり計画通りにはいかないものですね。卒論はファイルを開くことすらしなかった・・・

しかし半分くらいはやったので良しとしたいです。

まとめ

楽しかったです!!!!!ありがとうございました!!!!!

私もカッコいい大人になっていきたいと思います(東京都/23歳/学生)

写真を取り忘れたのですが、甘酒がめちゃくちゃおいしかったです。

その他

そういえば玄関には熊がいました。 f:id:asmsuechan:20190115213213j:plain

電話がなんかエモい f:id:asmsuechan:20190115220530j:plain

合わせて読みたい judeee-blog.hatenablog.com

takanakahiko.hatenablog.com

apolloオプション内でパスパラメーターを取得する

variables()prefetchの両方でparamsに関する処理を書かなければ動かない。これは自分のNuxtやapolloに対する不理解が原因でもあると思うが、違和感がハンパない。

<template>
  <themecontent :research-theme="researchTheme" />
</template>

<script>
import ThemeContent from '@/components/atoms/ThemeContent'
import gql from 'graphql-tag'

export default {
  components: {
    'themecontent': ThemeContent
  },
  data() {
    return {
      researchTheme: {}
    }
  },
  apollo: {
    researchTheme: {
      prefetch: ({ route }) => {
        return {
          name: route.params.name
        }
      },
      variables() {
        return {
          name: this.$route.params.name
        }
      },
      query: gql`
        query researchTheme($name: String!) {
          researchTheme(name: $name) {
            name
            content
            thumbnail_url
            title
          }
        }
      `
    }
  },
  methods: {}
}
</script>

Vue.jsのいい感じなctagを生成する

定義場所に直接ジャンプできる便利なctagをVue.jsで使うときにちょっと困りました。

Vue.jsのコンポーネント名のctagが自動では生成されない

ctagを生成するときはctags -R --extra=+fqってやるとファイル名のctagを生成してくれて便利なのですが、このタグには拡張子が付いています。

生成されるctagは例えば

App.vue  src/App.vue 1;" F

って感じです。これだとコード中にAppがあってもジャンプできません。

App  src/App.vue 1;" F

ですので拡張子.vueを含めない上のような形式にして欲しいのです。

しかしctagsコマンド単体では拡張子無しのタグを生成する方法が見つからなかったので、vimの保存時にsedでtagsファイルを置換するようにしました

" ~/.vimrc
function! _updateCtags()
  let tagsFile = getcwd() . '/tags'
  exec ":silent ! ctags -R --extra=+fq && sed -i -e 's/^\\([a-zA-Z0-9]*\\)\\.vue/\\1/' " . tagsFile
  " *.vueファイルの.vueの部分をsedで取り除く
endfunction
command! UpdateCtags call _updateCtags()
autocmd BufWritePost * :UpdateCtags

こんなコードを.vimrcに置けばvimの保存時にファイル名から生成したVueコンポーネントの名前のタグを自動生成できます。

(コンポーネントのnameオプションで別の名前を指定されると無理。また別の正規表現で抜き出す必要がある)

~/.ctagsこれをちょっといじって使っています。

クラウドワークスで1年くらい開発インターンしてた話

この記事はex-crowdworks Advent Calendar 2018の23日目です。

2016年から2017年にかけて1年ほどクラウドワークスで開発インターンをしていた思い出話です。これから開発インターンする人にも参考になると思います。

きっかけ

このミートアップの懇親会で社員さん捕まえて「ここで働かせてください!!!!!」って言ったら「勢いのある若者がいる」と認識されてインターンすることになりました。

そういえばインターン始まって最初にメンターさんと1on1した時、「東京タワーよりジャンプする方法って知ってる?」って聞かれて「ん???」ってなってたら「東京タワーはジャンプできないでしょ?」って返されて微妙な空気になったのが面白かったです。

やったこと

クラウドワークスの開発インターンは結構しっかりしていて、「新卒0年目」みたいな扱いでちゃんと(?)仕事を振ってくれて普通にレビューもしてくれてかなり力がついたと思います。

  • メッセージ周りに機能をちょっと追加
  • ServiceWorkerによるwebPushの実装
  • サポートチームからの要望による改修
  • webPush周りのリファクタリング
  • その他

最初はメッセージ改修チーム(メンバー1人+俺)に在籍して簡単なバグ修正や機能追加などメッセージ改修のお手伝いを少ししていました。

夏頃突然メンターさんに「メッセージが来た時にMessangerみたいな通知きたら嬉しいよね、やってみようよ!」みたいな感じの軽いノリで言われてからChromeで動くプッシュ通知の実装が始まりました。

「やってみようよ!」とは言われたもののメンターさんにはメンターさんの仕事があった(これとか)ので自分中心に分からないところは他の社員さん達に聞いて頑張って進めた結果、メンターさん曰く「気付いたらできてた」そうです。ドキュメントは頑張って残したつもりなんですがいやこれこの後誰がメンテすんねんって感じです。今誰がメンテしてくれてるんだろう・・・

クラウドワークスのwebPushは今も動いていて、来るたびちょっと嬉しいです。

バグらせた

開発にはバグが付きものです、と教わりました。私も一年の間にそこそこバグを生み出してしまいました。

  • メッセージ周りのデータ構造壊してデータ不整合
  • ServiceWorkerをインストールする際のハンドリングの凡ミスでIEで一晩動かなかった
  • ↑の再発防止としてエラートラッキングツールを内製しようとしたがGoogle Chromeのシークレットモードだけで動かない

特に一晩動かなかった時は、書いた報告書の損害額が結構デカくて一日めちゃくちゃヘコんでました。。。

障害の次の日、あまりにもヘコんでいたのを見かねた社員さんたちが私の机の上にスッとお菓子を置いていってくれたりコーヒーご馳走してくれたりめちゃくちゃ励ましてくれて「めっちゃいい人たちだ・・・・」って思ったのを覚えています。

気になったこと

当時の会社全体の雰囲気は謎のバッチサーバーさんのエントリを読めばなんとなく分かりそうですが、まあ良く言えば体育会系のノリが結構強いところでした。

例えば、開発じゃない他のチームのインターン生が社員さんに激詰めされてる声が頻繁に聞こえてくるなど。辞める際にマネージャーさんには話したのですが結構声デカくてうるさかったし自分のメンターさんがあれだったらすぐ辞めただろうなって感想です。

総括

とても楽しい時間を過ごさせてもらいました。クラウドワークスでインターンしたことは今の開発者としての自分にかなり大きな影響を与えていて、当時関わった方々にとても感謝しています。

当時お世話になった人たちとは今もまだ交流があって、Twitterで話したりたまに飲みに行ったりしててみんな仲良くていい雰囲気でとても楽しいです。これからもよろしくお願いします。

Vue.jsで使うGraphQLクライアントライブラリ

Vue.jsでGraphQL使ってみようかと思った時、GraphQLクライアントが結構ゴチャついててどのライブラリを組み合わせて使えばいいのか分かりにくかったのでまとめました

結論

コンポーネント内でリクエストの送信をするなら vue-apollo
Vuexのアクションでリクエストを送信するなら apollo-client
AWS Amplify + AppSyncの組み合わせなら aws-amplify

vue-apollo

コンポーネントに組み込むタイプのやつです。コンポーネントapolloオプション生やしてそこで指定されたリクエストはmountedで呼ばれます。

apolloオプション、ちょっと邪悪感が否めませんが、小さなアプリケーションを使うときはこいつで十分です。コンポーネントのテストにはvue-test-utilsなんかを使えば良いのではないでしょうか。

Vuexのライフサイクルとは合わないのでVuexのアクションでGraphQLエンドポイントにリクエスト投げる使い方をしたい人には向きません。

サンプルソース

<template>
  <div><span>{{ getTodo }}</span></div>
</template>

<script>
import Query from '@/apollo/query.gql'

export default {
  data() {
    return {
      getTodo: {}
    }
  },
  apollo: {
    getTodo: {
      variables: {
        id: 1
      },
      prefetch: true,
      query: Query,
    }
  },
  methods: {
  },
  async mounted () {
    this.$apollo.queries.getTodo.refetch().then(data => console.log(data))
  }
}
</script>

apollo-module

Nuxtでvue-apolloを使うためにvue-apolloをラップしたライブラリです。役割はvue-apolloと同じなので省略。

apollo-client

vue-apolloaws-appsync-sdkの大元になるライブラリです。ドキュメントの最初の方に書いてある通り、ビューレイヤーに組み込むことでキャッシュなどの機能を十分発揮してくれます。

こんな感じで簡単に書くことができます。

import ApolloClient from 'apollo-boost';
import gql from 'graphql-tag';

const client = new ApolloClient({
  uri: 'https://graphql.example.com'
});

client.query({
  query: gql`
    query TodoApp {
      todos {
        id
        text
        completed
      }
    }
  `,
})
  .then(data => console.log(data))
  .catch(error => console.error(error));

apollo-link

ただ単純にGraphQLのリクエストのみを送りたいときはこいつです。query/mutationを送りたいときはapollo-link-httpを使います。

こいつはexecutemakePromiseを組み合わせてよく便利に使っています。

import { execute, makePromise } from 'apollo-link'
import { HttpLink } from 'apollo-link-http'
import gql from 'graphql-tag'
import query from './query.gql'

const operation = {
  query: gql`${query}`
}
const uri = 'http://localhost:4000/graphql/'
const headers = {}
const link = new HttpLink({ uri, headers })

makePromise(execute(link, operation))
  .then(data => {
    if (this.debug) console.log(`received data ${JSON.stringify(data, null, 2)}`)
    return data
  })
  .catch(error => {
    if (this.debug) console.log(`received error :${error}\n${this.baseURL}: ${query}`)
    return { error: error }
  })

aws-amplify

AmplifyでAppSync立てたならこいつを使うのが一番使い勝手良さそうです。というかCognitoのトークン取ってくる機能もAppSyncにリクエスト投げるのもこいつだけで完結できます。

ライブラリとしてすごく便利でいろんなことをやってくれるのですが「お前なんで勝手にそんなことしてるんだよ・・・」みたいな何でも詰め込んだ感じではなく適度に薄く使いやすいやつです。

※vue-apolloのようにコンポーネントに組み込んでよしなに勝手にやってくれるようなことはしません

ドキュメントからのコピペですがこんな感じのコードです。

import Amplify, { API, graphqlOperation } from "aws-amplify";
import * as queries from './graphql/queries';

// Simple query
const allTodos = await API.graphql(graphqlOperation(queries.listTodos));
console.log(allTodos);

// Query using a parameter
const oneTodo = await API.graphql(graphqlOperation(queries.getTodo, { id: 'some id' }));
console.log(oneTodo);

aws-appsync-sdk

apollo-clientをラップしたライブラリで、query/mutationはapollo-clientとほとんど変わらなくてsubscriptionやofflineを使うには少し便利そうです。

コンポーネントに組み込まずに使う方法ありそうですが使ってないので不明です。サンプルではコンポーネントに組み込んでthis.$apolloで参照する使い方しか書かれていません。

感想

apolloさん関係のライブラリを使おうとする度に「俺はただいい感じにGraphQLのエンドポイントへfetch投げてくれるだけで満足するんだ・・・ただそれだけでいいんだ・・・」って気持ちになります。

Main Memory Database Systems: An Overview

読んだ論文

  1. Garcia-Molina, et al., Main Memory Database Systems: An Overview, in IEEE Trans. on Knowl. and Data Eng., 1992

この論文をざっくりまとめます。

要約

インメモリデータベース(MMDB)はデータをメインメモリに保存するデータベースのことである。MMDBは従来のデータベース(DRDB)と比べて高速に処理を行うことができるが(本当か?)、(xxxという欠点がある) この論文では、MMDBが動く仕組みと実際に開発されてきたMMDBの紹介を説明している。

1. INTRODUCTION

メインメモリデータベース(MMDB)はメインメモリにデータを保存するデータベースで、従来のデータベース(DRDB)はディスクにデータを保存するものである。 しかし、MMDBはバックアップとしてデータをディスクに保存し、DRDBはキャッシュとしてメインメモリにデータを保存する。このようにMMDBもDRDBもメインメモリとディスクの両方を使う

MMDBは近年(つっても1992年当時のこと)の半導体メモリチップの低価格化と集積度の向上により実用化されたもので、デッドライン時間が決まっているリアルタイムシステムにおいて効果的に使うことができる。

この論文ではMMDBにおいてメインメモリと磁気ディスクの差による影響に関して論じた。

以下の3つの質問と答えは、MMDBに関してよくある疑問である。

(1) データベースの全体ががメインメモリに収まると考えるのは合理的なことなのですか?

Yes

でも、衛星の画像データみたいな大きなデータだとメインメモリに格納しきれなくなってしまうだろうから、大きなデータと小さなデータは分けて管理する。

データにはよく使われるHotなデータとあまり使われないColdなデータがあって、Hotなデータをメインメモリに格納するようにしてColdなデータをディスクに格納するようにする。この時、MMDBとDRDBの2種類でデータが管理される。

(2) MMDBとめっちゃ大きなキャッシュをメインメモリに持つDRDBはどう違うのですか?

asmsuechan: これは私も真っ先に感じた疑問だからここに答えがあってよかった

まずインデックス構造が問題で、DRDBにおいてメインメモリの中に全てのデータがあったとしてもディスク用の設計が使われてしまう。さらに、データを使用するアプリケーションはデータがディスクに存在するかのようにバッファマネージャーを使うのでこうなるとあまりメリットはなくなる。

でも、良いDBMSはデータがメインメモリに保存されているかのように振る舞うようになるはずなので、将来的にはMMDBとDRDBの違いはなくなると思う。

(3) メインメモリは何か特別なハードウェアによって不揮発で信頼できるものになるのか?

これにはyesともnoとも答えられなくて、MMDBの設計によるとしか答えられない。なぜなら無停電装置を導入したりエラー検出をしっかりしたり冗長性を高めたりしても、それはメインメモリが落ちる確率を下げるだけでどんなに頑張っても0%にはならないから。だからバックアップは必ず必要になる。

2. メモリ常駐データの衝撃

この章ではDBMSにおいて重要ないくつかのコンポーネントにおいてメモリ常駐に関する事柄を説明する。

A. 並行実行の制御

DBの、トランザクションを並行実行する場合におけるデータのロックを制御する仕組みについて。

まず、データがメモリに常駐していてデータの競合が小さいならばロックの粒度を小さくしてもこの利点はないので、ロックの粒度をフィールドやレコードなどの小さい単位からリレーションなどの大きな単位にして良い。

最悪DB全体で1つの単位としてもよくて、実際これの研究も行われていた。これはトランザクション直列実行されることになる。 この場合ロック処理において、セット/リリースやデッドロックへの対処などの制御処理をほぼ無視できるのでトランザクションの直列実行は望ましい。

なお、実際のロック処理(排他ロック)は、2ビットでオブジェクトがロックされているかの情報をそのオブジェクトにトランザクション待ちが発生しているかどうかを表して実現する。

asmsuechan: このセクション、プロセスの並列処理周りの知識がないとちょっと難しい

B. コミット処理

処理の失敗に備えるために、トランザクションのログを取る必要がある。このログはディスクに保存しなければならないので、この保存処理がボトルネックになってスループットを下げてしまうことがある。

ディスクを使うDBでも同じ問題は起きるけど、MMDBではここが唯一ディスクを操作する操作だからよりシビアになってしまう。

今まで研究されてきている、この問題を解決するいくつかの手法を紹介する。

  1. stable メインメモリにログを保存する
    特別なプロセスやプロセッサを使ってstable メインメモリからディスクにデータを保存するようにする。いわゆるキューイングかな。
  2. precommitするようにする
  3. group commitという手法を使う。
    これはページがいっぱいになるまでログを溜めた後にまとめてディスクに保存する手法のことである。

C. アクセス手法

MMDBに置いて、B-Treeはあまり有用ではない。それはB-Treeのハッシュの仕組みが領域を大きく消費するからだ。

メインメモリにあるデータへアクセスするには、B-Treeのようにデータをインデックスに保存する必要がない。これは、メインメモリはディスクに比べてアクセス速度が速くポインタでも十分なスピードでデータを見つけることができるからだ。

このことより、インデックス中の可変長のフィールドに関する問題を解決したり、ポインターのサイズがデータより小さい場合は容量を削減したりできる。

D. データ表現

リレーションはデータのポインターのタプルとして表現される。ポインタによりスペースの効率利用が可能で、さらに可変長データの表現が容易になる。

E. クエリ処理

上でも述べたように、データのポインターでリレーションが表現できるなら、リレーション関連の処理が効率よく実行できる。

ここで一番重要なのは、「データがメモリにあるからクエリの速度を上げることができるようなコンパクトなデータ構造が可能である」ということである。

F. リカバリ

揮発性のメモリから不揮発性のメモリにデータをバックアップすることは必須である。

バックアップからデータをリカバリすることで大事なのは、(1) バックアップを最新に保つ処理と(2) 失敗から復旧する処理である。

以前Commitの部分で述べたように、DBに何か問題があったとき、ログからデータを復旧する。

チェックポインティングはなるべくトランザクションの処理を邪魔してはいけないが、どうしてもロックなどの処理が発生する。その代償として動機を行わないfuzzy dumpingが知られている。

G. パフォーマンス

メインメモリデータベースのパフォーマンスはだいたい処理時間に依存する。

H. APIと保護

DRDBに置いて、DBMSとアプリケーションのデータの受け渡しはプライベートバッファを会して行われている。これに対してMMDBではオブジェクトが直接メモリアドレスで参照される。

プライベートバッファをなくしてトランザクション時にオブジェクトに直接アクセスするようにすると、トランザクションがシンプルな場合にはトランザクションにかかる時間のほとんどがビット(?)をメモリからバッファにコピーする時間に費やされることになる。

しかしデータに直接アクセスするときには、DBMSが認知していないデータを変更できてしまうためにこの変更をDBMSが検知できずにログに書かれないという問題がある。

I. データクラスタリングマイグレーション

DRDBではデータオブジェクトはまとまって保存されたりクラスタ化されたりする。

asmsuechan: 空間的局所性やな

MMDBのデータはDRDBのデータと違って分散しているので、このデータをディスクに移すときどのように、またどこに保存するかという問題が発生する。

この解決方法には様々あって、ユーザーがデータの移動(migration)時にどうクラスタリングするかを手動で設定する方法から、アクセスパターンから自動でクラスタを決定する方法まである。

ここで私たちが言いたいのは、データの移動と動的クラスタリングはMMDBの要素であるということである。

3. システム事例

この章では、今まで理論の設計や実装がされてきたインメモリデータベース に関して述べる

A. OBE

OBEはIBMとOffice-By-Exampleの合同チームが開発したプロジェクトであり、IBM 370アーキテクチャの上で実行される。このDBはアドホッククエリの処理に重点が置かれている。

データ表現としてOBEではポインタが多用されていて、リレーションはタプルのリンク付きリストとして’保存される。

ジョインはネストされたループ(nested-loop)で実行され、インデックスはジョインの実行時にその場で作られる。

B-G

下書き保存し忘れて消えた、後ほど復旧。

結論

5分より短い間隔でアクセスされるデータはメモリに置くべきであるという調査がある。これは、データへのアクセスにかかる金銭的なコストから計算したものである。しかし一番大事なのは、メモリの値段が下がるにつれてこの時間も長くなるということだ。

まとめ

この論文はインメモリデータベースの基礎中の基礎を分かりやすく説明してくれているので、かなりしっかり読んでしっかり訳しました。

でも具体例のところは話が古くて正直あまりピンと来なかったところが結構あったのでもっと勉強せねばって気持ちです・・・