256bitの殺人メニュー

インフラエンジニアだったソリューションアーキテクトなくわののブログ。こちらのBlogは個人の意見となっていて会社とは全く関係ありません。お約束です。[twitter:@kuwa_tw]めんどくさがりが重い腰を上げて何かをアウトプットすることにどれほどの意味があるのかを試してみたいブログでもある。

2023年の振り返り

年の瀬ですね!(そうですね!)

今年は職を変わるという大分転機な1年だったので振り返りをざっと書いていこうと思います。

転職をした

AWSでやってたことも整理

新しい会社の前にAWSでやってたことも整理しておくと、以下の通り今までAWSでやってきた事はこんな感じで、

  • お客様とお話するいわゆるソリューションアーキテクト
  • Amazon DocumentDB を専門にするスペシャリストソリューションアーキテクト

をやってきた。 前者を6年くらいやってきて、そこからキャリアをどうしようかという試行錯誤の一つでAmazon DocumentDBのスペシャリストソリューションアーキテクトになった。というのが流れだと思う。どちらも非常に興味深いし面白い事ができたので良かった。

まず、ソリューションアーキテクトとして、お客様と、ある技術テーマにおいて効率よくAWSを使っていただくためにどうすればいいかをディスカッションするのはとてもエキサイティングだったけど、キャリアとして広げるためにやることかえてみっぺ。がスペシャリストソリューションアーキテクトという結果だったわけだと思う。

やはり、サービスを主体とするスペシャリストソリューションアーキテクトはソリューションアーキテクトとは動き方も目指すゴールも違っていて、ただ、やらないとわからないことも多いので、多分やってよかったと思っている。スペシャリストソリューションアーキテクトもそれはそれで楽しかった。

加えてレポートラインがシアトルの方だったり、シンガポールの方だったりというのを経験できたのも良かった。ぼくは力及ばずという所だったけど、英語をやらなければ、、、というモチベーションにもなったし、開発の人ととても近い位置で仕事ができたのでより本当のAWSを感じることができたんじゃないかなと思っている。

転職を考える

てか今年のはじめの時点では自分が転職してるなんて夢にも思ってなかった。完全にAWSでバリバリやってると思ってた。

それくらいAWSでの仕事は魅力的だったし楽しかったと思っている。

ただ中頃から挑戦したいなと思うようになったのも事実で、理由として2015年にAWSにはいった時のアーリーな感じをもう一回やってみたくなったというのが大きい気がする。今のAWSが悪いって思っているわけではないけど、あの頃の状況を繰り返すことはAWSにいるだけだとできないんじゃないかなと思った。*1

後は何をやるか、で、ソリューションアーキテクトをもう一回やってみたくなったのもある、お客様とお話して課題解決を行うというのがやはり自分は好きだったのを思い出したからだ。

なので、ちょっとアーリーな会社でソリューションアーキテクトができる所を探して話をきいてみたりしていた、何社かお話を聞かせていただいていたけど、その中の一社がDatabricks だった。

そして前のエントリにもちょっと書いたけど、自分が納得できるプロダクトがある所という条件もあり、Databricksはまさにステージもそうだし、プロダクトも興味がある、そうかーじゃあ楽しいかもしれないねってなったのが大きかった。

転職

あれよあれよとプロセスは進んで、オファーいただくことができた。

英語の面接もあったけど、Zoomのおかげもあってw なんとか話することができた。ただ多分今の上司が外国の方じゃなかったら今頃このレベル(マジでたいしたレベルではないけど😓)では会話できてないよな、、、って思うといろんなものは無駄じゃなくてつながってるんだろうなって思った。*2

で、その間にお休みいただいてゆっくりやすんだりTwitterではっちゃけたりしてる*3間に入社日になったというわけですw

この後どう転がるかはわからないけどこういうものは後で答え合わせしないとあのときの選択がどうだったかなんてわからないので、自分は自分がなにかを選択したことを評価したいと思う。

2ヶ月たってオンボーディングも終わりかけ、2024年からはいろいろやれることを増やしていける感じになりつつあるので来年からお話する機会や、勉強会、それ以外でも活動増やしていければと思うのでよろしくお願いします!!!!

*1:実際の所そういう場所もあるのかもしれないけど

*2:ゆっくりしゃべる人なんで大丈夫ですよって言われて面接入ったら全然早口だったのだけはマジで忘れないとおもうw

*3:転職のタイミングでTwitterをちゃんと再開したけど大分世界が変わっていて難しいw

僕の理解するデータレイクハウスとはなにか?

こちらの記事はDatabricks Advent Calendar 2023の23日目の記事です!

何年ぶりにかくねん、、、8年ぶり!!!!!????
嘘やろ、、、、😨

という衝撃はおいておいて、8年ぶりともなると色々変わっているわけで、一番大きいのは僕は会社をAmazon Web Services JapanからDatabricks Japanに変わりました。
転職の理由というのはポジティブな理由もネガティブな理由もあると思いますが、そういう細かいことはおいておいて(おくんかい)決め手になったのはこれです。

「Databricksというサービスに技術的なアドバンテージを感じたから」

SAとしていえばこういえるかもしれません、

「SAとして働いてる自分を想像して、Databricksをお客さまにオススメするときのイメージが付いたから」

でもあります。 とにもかくにもDatabricksというサービスが気になった、というのが転職理由の大きな理由の一つなわけです。 そこでみなさんはこう思うと思うんですよね「Databricksの何がいいの?」と。

今日はそれを(僕の理解の中の)めちゃくちゃザックリな説明をしていくというDatabricksってなに?という人向けの記事にしていきたいと思います。

それでは、行ってみましょう! 絵が下手すぎて全くイメージ伝わらない、、、気がしてきた、、、けど考えるな感じろでお願いしますw

Databricksって何だ?

まずDatabricksってなんなんでしょう、、、?
よく言われるのはマネージドApache Sparkだとか、ですがそれはDatabricksの一つの側面にしか過ぎないと思うんですよね?
Databricksはこう言ってます、データレイクハウスと、、、何やそれ、という方に最初からお話していきましょう、、、。

データウェアハウスの誕生

データ分析をするにあたって、みんなは思いました

「メチャクチャなデータ量のデータに対してもちゃんと応答できるデータベースをつくればいいじゃない」

それをみんなはデータウェアハウス(DWH)と呼ぶことにしました。

DWHは非常に重宝されましたが、そのうち問題が出てきました。

「構造化データはデータベースに入れやすいけど、動画や、音声などの非構造化データはどうやって分析する?」
「データの管理場所がバラバラになって管理しづらいよ」
「データを入れたらめちゃくちゃお金かかるよ」

みんなは困ってしまいます。

データレイクへ

そこでみんなは考えました。

「そうだ!データを統一したいれる場所を作ってそこから使いたいときは引っぱり出してくればいいんだよ」
「データの泉、、、データレイクだ!」

みんなはデータレイクにいろんなデータをとにかくドンドン入れていくようになりました。 データレイクは非常に安く、データレイクに入ったデータをみんなは、データの分析や、機械学習に使っていきます。

あれあれ、、、でもそのうちにまた誰かが困っているようです。

「とにかく入れまくっていたからデータレイクがぐちゃぐちゃだよ」
「このデータって正しいデータなのかな、、、?」
「データレイクからデータとってくるのちょっと遅くない?」

これでは泉ではなくて沼です。やっぱり困ってしまいました。*1

そしてデータレイクハウスへ

そのうちまた誰かが言いました。

「データレイクの中でデータウェアハウスがうごかせれば全部解決するんじゃないの?」
「それだそれだ!」
「でもどうやって?」
「データレイクの上でトランザクションや、スキーマを設計することができればそのまま動かせるよ」
「いいね!やってみよう!」
「でも名前がないと分かりづらいな、、、データレイクとデータウェアハウスを合わせてデータレイクハウスって呼ぼう」

こうしてデータレイクハウスという概念が生まれました。 データレイクハウスは低コストなクラウドストレージの上にオープンファイルフォーマットと言われる特別なフォーマット*2で、トランザクションスキーマの強制、パフォーマンスの強化を実現しました。 それによってデータウェアハウスの課題であった、データの分断やコスト、データレイクでの課題であった課題(データ品質、パフォーマンスなど)も解決することとなりました。

要するに、 ”データレイクと、データウェアハウスのいいところどり、データの格納場所はデータレイクなので、安価かつオープン。構造化データも非構造化データも取り扱える。しかもデータガバナンスが効かせられ、処理も高速。データ分析にも、機械学習にもオールインワンで活用可能” というのがデータレイクハウスの良さになるわけです。

Databricksの何がいいの?の第一歩がレイクハウス!

これがDatabricksがよくお話するデータレイクハウスのザックリとしたお話でした。なんか夢があっていいですよね。でもこれは現実です😆

データレイクハウスを最初に始めたというだけではなく、それをドンドン進化させ続けているのがDatabricksというプロダクトというわけです。

閑話休題:Databricksってどんな会社?

ここでちょっとDatabricksという会社についてお話しようと思います。
まだ入って二ヶ月ですが、まず言えるのが非常にみなさんスキルフルという点、技術が好きな方が多くて、技術ディスカッションなどになると白熱していることもあって楽しいです。
なおかつ、非常に研修なども豊富ですごい大変ですが、ためになるコンテンツがたくさん揃っています。
アットホームで楽しく仕事をできる*3環境もあるので是非Databricksにもっと深く触ってみたい!という方はお声がけください!採用強化中です!w

Databricksのお気に入りのサービス

ほら、、、AWSでもよく好きなサービスっていってたから、、、😅
DatabricksでいうとUnity Catalogが大好きです!!!
データカタログのサービスではありますが、単なるデータカタログというだけではなく、統一した権限管理/アクセスコントロール、監査ログ、データの依存管理(データリネージュ)、機械学習のモデルレジストリなど様々な機能を持ったサービスとなっており、Unity CatalogがあることでDatabricksはより統一されたガバナンスを効かせることができます。
最近の新しい機能にもUnity Catalogは深く結びついていて、ただのマネージドhive metastoreでしょ?と思っているとぜんぜん違うのできっとビビります!

まとめ

そんなこんなでとりあえず最初に面白そうと思ってもらえる記事を目指して書いてみましたがいかがでしょうか? Databricks自体は聞いたことあるけどどんなものかよくわかってないという方はまだまだいる気がしているのでこういう記事もまた書いていきたいと思います!

*1:ちゃんと運用されてるまさにデータレイク、というものもあるので絶対にこうなる、というわけではないですが課題の一例としてお聞きください

*2:Databricks で使われているのはDelta Lakeといいます

*3:メタファーの奴じゃないですw

子供と一緒にカレーが食べたい

※このエントリは個人の見解であり、所属する組織の公式見解ではありません 今年も何故か完全にすっぽかしてしまうというアレをしてしまうアレ(´;ω;`)

このエントリは、カレー Advent Calendar 2016 19日目のエントリです。 19日目、、、。

またや、、、また人権が失われました。

悲しいですね。人は繰り返してしまう生き物。

子供と一緒にカレーが食べたい

子供と一緒に御飯を食べていますが、まだ本格的なカレーは食べられないわけです。 ただ一緒に食べたいという気持ちはあるわけです。 じゃあどんなものがあるのか、それですね。

とりあえずなんでも食べてくれてた時代

離乳食の頃にはだいたいなんでも食べてくれていてありがたかったです。

とか

を食べてくれてましたね。「カレェ」

いわゆるカレーの王子さまもたべてくれました。

大きくなってきて通用しなくなる時代

いわゆるイヤイヤ期にはいると、大人と同じものが食べたくなってきます。そうするとこうなるわけです。 「カレーない!(コレじゃない!これは色がお父さんが食べてるやつと違う!)」

そう、、、なんか色が薄いんすわ。自分が見ても「まあ違うものに見えるわな」となりますものね、、、。

というところで色々見ていった結果アンパンマンカレーが一番色が濃いし1歳から食べられるのでベスト。結構美味しい。ということがわかりました。

息子もニッコリですわ。

というわけで。

子供と一緒にカレーライフ楽しみましょう!!!

ちな

最近食べたので一番美味しかったのは「ボーイズカレー」の生姜焼き定食(カレー付き)で、こんなに美味しい生姜焼きはこの世にないです、、、アレ、、、? カレーもありますっす!

f:id:akuwano:20161223014043j:plain

可愛い見た目のSlack入門 [ChatOpsによるチーム開発の効率化]中身も可愛い奴だぜ

※このエントリは個人の見解であり、所属する組織の公式見解ではありません

前職からのお付き合いの @ さんに

Slack入門を頂きました!ありがとうございます!

f:id:akuwano:20160623000443j:plain

ちゅーわけで早速読んでみたりします。 一言で言えばSlackの使い方についてまとめた本、なんですが、そこはそれ、いわゆる本屋さんにあるHow to本(で○るシリーズとか)ではないわけです。 チームの作り方、アカウントの作り方、それを既に使っている方々は知りたいですか!? あ、、、いやもちろんそれもありますw もちろんSlackの使い方は細かい所、そんな使い方あったんだ、、、と言うところまでかいてあるんですが実際に開発の現場でSlackの使っている人が知りたい

  • SlackのAPI活用方法
  • SlackでChatOpsを実践するための方法や実例
    • Hubotの細かい仕組みや構築方法、実践方法
  • GithubやCircleCIとの連携方法

といったやり方が具体的に載っている本なわけです。 おもしろBotが作りたい方、開発にもっとSlackを活用したい方、無料枠で使ってるみたけどホントにSlackって便利なのかな、、、Skypeで良くね、、、俺、、、ミーハーなのかな、、、鬱だ氏のうって内心おもってる方は一度読んでみるとSlackである必要性、というのがわかるかもしれません!

最近我が家の家庭のやり取りもLINEからSlackになりつつある今日このごろですがこれを期にもっとSlack活用したいと思います!

Slack入門 [ChatOpsによるチーム開発の効率化]

Slack入門 [ChatOpsによるチーム開発の効率化]

目黒のカレー屋さん&家カレーを長く楽しむ方法

※このエントリは個人の見解であり、所属する組織の公式見解ではありません

このエントリは、カレー Advent Calendar 2015 17日目のエントリです。
17日、、、です、、、。


どうもどうも乙カレー様です。桑野です。
3日ほど過ぎてしまいましたが、、、カレーアドベントカレーンダーを更新したいと思っております。

更新しないと、


とか

ついには、

と罵られるのです。カレーの世界は怖い。

というわけで震えながらはじめましょう。人権を得るための旅の始まり。

目黒のカレー屋さん

まずは目黒のカレー屋さんについて簡単に。

タダカリー

まずはこれ、タダカリーさんです。ここの豆の入ったキーマカレーがとても好きなのです。
おしゃれな店員さんの作るおしゃれな店内で盛り付けが目にも美味しいおしゃれなカレーを食べることができます。それは僥倖。

ルソイ

次はルソイ、ここはガッチガチのインド料理屋さんといった雰囲気のカレー屋さんです。
チキンカレーも美味しいし、ナンも美味しいです。
ここは夜に来てタンドリーチキンを肴にインドビールなんか飲んじゃうのも良いお店です。

辛くすると半端無く辛いらしい。という噂なので、辛いのが好きな人には僥倖。

シャプラ

Devsumiの聖地からおそらく一番近いカレー屋さん。
ここはテイクアウトのランチが、カレー+サラダ+ナン+ライスで750円という破格なところ。
正直シャプラという店名はよく知らなくて、パルマさんのカレー」の所のカレーと言う認識しかありませんでした。。


店員のおっちゃん(パルマさん?)による挨拶の勢いがすごいのでたまに気後れしますw
でも結構美味しいのオススメ。コスパ最強伝説。僥倖。

とりあえず現状ではこんな感じですね。今後もあったら追加していきたいとおもう、僥倖。(写真撮り忘れた。。。)

家カレーをなるべく長く楽しみたい。

次に、家カレーをなるべく長く健康に楽しみたい人について。
家カレーは市販のルーを使ったカレーということです。

1日目、2日目以降でまとめていきましょう。

1日目

1日目は家カレーそのものの味を楽しみたい。日本のカレーは美味しい。そういう気持ちで頑張っていきたい。
ただ、なるべく健康に楽しみたい。

そんなあなたに、プライムジャワカレー。これは油分が少ない。
今は粉末タイプになっているんですが、これは若干改悪感はあって、前は粉末タイプではなくて通常のルーになっていたのでもっと美味しかったと思う。



市販のカレーとはいえ適当につくらず、ちょっと気をつけると更に美味しい。こんな感じ。

  • 野菜を炒める前に、オリーブオイルをスライスにんにくで香りづけする。
  • 肉(ぼくは豚バラが好きです)を投入する前に塩コショウで下味を付ける(塩少なめ、胡椒多めが好み)
  • ル・クルーゼとか圧力鍋でしっかり柔らかく煮詰める

これをやるだけでも大分違う。
あー美味しかった。よっぽど大食いじゃなければきっとまだ余ってるでしょう。次の日もっと楽しみましょう。

2日目以降

2日目のカレーはもっと美味しい。これは定説ですが、実際真実ですね。
ただ、もっと楽しみたい。楽しみましょう。


これを使います。(テレレレッテレー)GABANの純カレー


ギャバン 純カレーパウダー丸缶

ギャバン 純カレーパウダー丸缶


純カレーをつかうことで更にカレーが復活しますお。
お湯を100CC〜200CC投入して、純カレーを更に投入する。
しばらく煮込んで味見して完成。

元のカレーはtheおうちカレーって味だったのが、純カレーを入れることでシャープな味になります。
プライムジャワカレーがそもそもそんなに好きじゃない場合には1日目にもう入れてちゃいましょう。

さらに、おこのみで、食べる時に醤油を入れればちょっと和風になりますし、とろけるチーズをいれてもいいです。じゃがいもスライスを耐熱皿に敷き詰めてカレーのルーを流し込んで上にとろけるチーズを敷いて、粉チーズをまぶすとカレーグラタンにもなります。何度でも楽しめる。
具も少なくなっていると思うので、コロッケなり、唐揚げなりを追加してもOK。無限の可能性です。まさに銀河。

ああ、、、いつまでも楽しんでいたい、、、そんな気分です。

以上です。

正月三が日、おせちにあきたらカレーもね!
で、カレーを食べる方はいらっしゃるのではないでしょうか。スパイスから作るのも美味しいのですが、手軽に市販の物の楽しみ方を模索してみるのも良いかもしません。

ではでは!(∩´∀`)∩


DEXでもうMongoDB職人は要らなくなるの巻

※このエントリは個人の見解であり、所属する組織の公式見解ではありません

このエントリは、MongoDB Advent Calendar 2015 18日目のエントリです。

どうもどうも乙カレー様です。桑野です。
MongoDB on AWS的ななにかを書こうとしたのですが、その前にこれ紹介したことなかったなーと思いDEXの紹介しようと思います。

DEXとは

あのMongoDBならこの人達のMongolabさんの作った、MongoDBのSlowlogなどから適切なINDEX設定をRecommendしてくれるプロダクトになります。
神様仏様Mongolab様。

インストール

pipで簡単。

$ pip install dex

コマンドライン手順

基本的には、MongoDBのURLと、Logのパスを指定していきましょう。

$ dex -f /var/log/mongodb/mongodb.log  mongodb://localhost
{
    'runStats': {
        'linesRecommended': 0,
        'linesProcessed': 1,
        'linesPassed': 149
    },
    'results': []
}

ほいできました。

データベース例

データベースはこの前 作ったデータベースにデータを足して作ってみましょう。
適当に1000万レコードほど追加しました。

$ mongo d1
(snip)
> db.t1.find().count()
10110005


そこでもう一回DEXを実行してみますが、まだクエリを実行していないので当然何も出ません。

$ dex -f /var/log/mongodb/mongodb.log  mongodb://localhost
{
    'runStats': {
        'linesRecommended': 0,
        'linesProcessed': 1,
        'linesPassed': 149
    },
    'results': []
}

では、Indexのきいていないクエリを打ってみましょう
どれも10秒以上かかります。重い。

$ mongo d1
# クエリ1つ目
> db.t1.find( { "nosql" : "mongodb"} )
{ "_id" : ObjectId("567365cf760961552b000001"), "created_at" : ISODate("2015-12-16T13:04:10Z"), "name" : "kuwa_tw", "nosql" : "mongodb", "price" : 10 }
# クエリ2つ目
> db.t1.find( { "name" : "saeoshi"} )
{ "_id" : ObjectId("567365cf760961552b000005"), "created_at" : ISODate("2015-12-16T13:04:38Z"), "name" : "saeoshi", "nosql" : "voldemote", "price" : 2000 }
# クエリ3つ目
> db.t1.find( { "price" : { $gt: 9000 } } )
(いっぱい出たのでsnip)
>
# クエリ4つ目:複合条件
> db.t1.find( { "name" : "kakerukaeru" , "price" : { $gt: 10 } } )
>


そうしたらそこでもう一回DEXを実行してみましょう。
そうすると、重かったクエリをピックアップして、どのようなインデックスをはればいいのかRecommendしてくれます。これは素晴らし。

$ dex -f /var/log/mongodb/mongodb.log  mongodb://localhost
{
    'runStats': {
        'linesRecommended': 7,
        'linesProcessed': 7,
        'linesPassed': 201
    },
    'results': [
        {
            'queryMask': '{"$query":{"name":"<val>","price":{"$gt":"<val>"}}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"name": 1, "price": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"name": 1, "price": 1}, {"background": true})'
            },
            'details': {
                'count': 3,
                'totalTimeMillis': 52289,
                'avgTimeMillis': 17429
            }
        },
        {
            'queryMask': '{"$query":{"name":"<val>"}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"name": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"name": 1}, {"background": true})'
            },
            'details': {
                'count': 2,
                'totalTimeMillis': 35758,
                'avgTimeMillis': 17879
            }
        },
        {
            'queryMask': '{"$query":{"nosql":"<val>"}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"nosql": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"nosql": 1}, {"background": true})'
            },
            'details': {
                'count': 1,
                'totalTimeMillis': 17983,
                'avgTimeMillis': 17983
            }
        },
        {
            'queryMask': '{"$query":{"price":{"$gt":"<val>"}}}',
            'namespace': 'd1.t1',
            'recommendation': {
                'index': '{"price": 1}',
                'namespace': 'd1.t1',
                'shellCommand': 'db["t1"].ensureIndex({"price": 1}, {"background": true})'
            },
            'details': {
                'count': 1,
                'totalTimeMillis': 17488,
                'avgTimeMillis': 17488
            }
        }
    ]
}


ついでにexplainもしてみましょう。

> db.t1.find( { "name" : "kakerukaeru" , "price" : { $gt: 10 } } ).explain()
{
        "cursor" : "BasicCursor",
        "isMultiKey" : false,
        "n" : 0,
        "nscannedObjects" : 10110005,
        "nscanned" : 10110005,
        "nscannedObjectsAllPlans" : 10110005,
        "nscannedAllPlans" : 10110005,
        "scanAndOrder" : false,
        "indexOnly" : false,
        "nYields" : 18,
        "nChunkSkips" : 0,
        "millis" : 17893,
        "indexBounds" : {

        },
        "server" : "ip-172-31-20-34:27017"
}

当たり前ながらIndexが無いので当然BasicCursorです。


ではRecommendにしたがってIndexを貼ってみましょう

> db["t1"].ensureIndex({"name": 1, "price": 1}, {"background": true})
> db["t1"].getIndexes()
[
        {
                "v" : 1,
                "key" : {
                        "_id" : 1
                },
                "ns" : "d1.t1",
                "name" : "_id_"
        },
        {
                "v" : 1,
                "key" : {
                        "name" : 1,
                        "price" : 1
                },
                "ns" : "d1.t1",
                "name" : "name_1_price_1",
                "background" : true
        }
]

はいIndexれましたね。
ではもう一回explainしてみましょ。
爆速!!!

> db.t1.find( { "name" : "kakerukaeru" , "price" : { $gt: 10 } } ).explain()
{
        "cursor" : "BtreeCursor name_1_price_1",
        "isMultiKey" : false,
        "n" : 0,
        "nscannedObjects" : 0,
        "nscanned" : 0,
        "nscannedObjectsAllPlans" : 0,
        "nscannedAllPlans" : 0,
        "scanAndOrder" : false,
        "indexOnly" : false,
        "nYields" : 0,
        "nChunkSkips" : 0,
        "millis" : 0,
        "indexBounds" : {
                "name" : [
                        [
                                "kakerukaeru",
                                "kakerukaeru"
                        ]
                ],
                "price" : [
                        [
                                10,
                                1.7976931348623157e+308
                        ]
                ]
        },
        "server" : "ip-172-31-20-34:27017"
}


BtreeCursorになってIndex[name_1_price_1]が使われているのがわかると思います。
というわけで、Indexはメモリを食うので一概に貼りまくったらええというわけではないんですが、定期的にDEXを流すことでIndexが使われていないクエリが流れていないかを確認することができます。
簡単に使えるので使っていくと幸せになりますよ。


MongoDB使ってる時点で幸せなのかよくわかりませんがね。。。(怪談的な終わり方)


MongoDB in Action

MongoDB in Action

  • 作者: Kyle Banker,Peter Bakkum,Shaun Verch,Douglas Garrett,Tim Hawkins
  • 出版社/メーカー: Manning Pubns Co
  • 発売日: 2016/04/15
  • メディア: ペーパーバック
  • この商品を含むブログを見る