カレンダー

2020/06
 
78910111213
14151617181920
21222324252627
282930    
       

広告

Twitter

記事検索

ランダムボタン

1クリック3分待ち

by 唐草 [2020/05/18]



 MongoDBは、保存できるデータの柔軟性の高いデータベースと言われている。事前にどんなデータをどんな形式で保存するかを考える必要がないと大胆な主張をする人さえいる。異なる形式のデータが混在しても許してくれる仕様をおおらかさと捉えることもできるだろう。ユーザデータ保存のために多くのWebサービスの裏側で動いているらしい。
 「らしい」というような伝聞系の語尾が続いたのには訳がある。ドキュメントからは柔軟性を感じられるのだが、実装された現場を覗く限り柔軟性が仇になっているように思えてならないからだ。
 ぼくに言わせてもらえば、MongoDBなんてものはぼくの胃に穴を開けるためにこの世に存在するとしか思えないソフトウェアである。
 これまでに職場で動いているMongoDBに何度も振り回されてきた。起動できなくなったこともあれば、逆に勝手に終了してしまうこともあった。バックアップが使えず全データが消えたこともあった。そのたびに睡眠時間や食事時間を削って身も心も毎度満身創痍になりながら、どうにか復旧を行ってきた。
 こんなことを繰り返しているうちに、いつの間にかぼくがMongoDBエキスパートだと周囲から誤解されるようになってしまった。その結果、面倒がドンドンぼくの方へと転がり込むようになってしまった。完全に負のスパイラルである。
 今日も厄介な話が舞い込んできた。どうやら1万件を超えるデータの中に破損データが数個紛れ込んでいるらしい。それを見つけて対処して欲しいと軽々しく言うではないか。それが砂場から針を探すような依頼だと分かっていやしないのだろう。コマンドを使いこなせれば1行で済むかも知れないが、ぼくは何も分からない。だから、GUIツールでポチポチクリックしながら問題点を探していくより他になかった。
 誰にでもできる簡単な仕事なのだが、またしてもぼくの心を膝蹴りでへし折るような問題が発生した。アプリがやたらと重いのだ。1回クリックすると、ひどいときには3分ぐらい待たされる。何をするにも待たされるのは、Windows 95の頃が思い出される。当時はそれが普通だったのでなにも感じなかったが、OSの起動すら10秒の時代に3分待ちなんてもはや拷問である。
 こうして今日もMongoDBは、力強くぼくの胃に穴を開けるのであった。