RDBMSとMongoDB

丁度、MongoDBのことが社内で色々と話題になっている時に、タイムリーにこの記事がでてきて、自分的に凄くささったのでメモ。
Open database life: ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift

データベース設計ができない/できなかった/する時間が取れない、といった人たちや、Shardingのためのロジックを書くのがめんどくさい、といった人たちを中心に好まれるデータベースです。Facebookでも、子会社の中にMongoDBを使っているところがあります。
　MongoDBを使うか、RDBMSを使うかという議論は、よく「先に楽をして後で苦労するか、先に苦労して後で楽をするか」という表現にたとえられます。「技術的負債」を語る上で良いモデルケースと言えるでしょう。
　稼働までなら、MongoDBの方が、正規化が必須なRDBMSより楽です。その一方で、設計を放棄したツケは、後々になってデータ整合性問題、(重複値の多発による)データ量増加、それによるコスト増といった様々な負債となって現れます。裏の実装はMyISAMと大して変わらないので、データ量がメモリに乗らないくらいの規模になってくると、InnoDBよりも急激なペースで参照・更新性能とも悪化します。典型的な「技術的負債」のパターンと言えるのではないでしょうか。

英訳 (by Gengo)

The debate about whether to use MongoDB or RDBMS is often described as being analogous to the expression, “To play now and work later, or work now and play later”. I believe that the situation we find here is a suitable model for talking about “technical debt”.
If we were only to consider the matter up to the point of operation, then MongoDB is the easier option because it does not require normalization like RDBMS does. On the other hand, the cost of abandoning design will surface later on in the form of various burdens such as the problem of data consistency, and (due to the frequent occurrence of duplicates) rises in data quantity and cost. The underlying implementation is not much different from MyISAM, so if data cannot fit into memory, both the referencing and updating performances will decline at a pace more rapid than InnoDB. It can be said that this is a classic pattern of “technical debt”.

MongoDBの売りとして、"スキーマレス"によるイニシャルコストの低さという所がフォーカスされているようですが、一方でNoSQL系の誕生の背景としては、Webシステムの拡大に伴う、ストレージの"スケールアウト"の必要性という所があったはずで、自分は後者の印象のほうが強かったので、ユースケースが真逆でチグハグだな〜と感じました。

• スキーマレス
  • テーブル定義しなくてもデータを格納できる。
    • サービスをさくっと始める所にフォーカス
• スケールアウト
  • スケーラビリティを維持するためACIDからBASEへ (下に参考スライド有り)
    • サービスがでっかくなった時に必要な概念
    • 一貫性を犠牲にしてもスケーラビリティを手に入れたい時

しかも、スケールアウトという、後で楽するための所に強いプロダクトなのに、スキーマレスの設計によるツケで、後で苦労するプロダクトとされているのも聞いてて残念な感じ。

ただ、一方で、例えば、世界的に使われててボクも大好きなfoursquareはMongoDBを使っていたり、アメーバもMongoの採用事例で色々とスライドを見かけるので、MongoDBがフィットするユースケース/使い方というのも確実に存在していて、そういうユースケースがもうちょっと抽象度を挙げてキャッチーな言葉でまとめられるようになると、違う見え方がするのかな〜と思ったり。
Mongo on Hadoop | Foursquare Engineering Blog
AmebaのMongoDB活用事例

あと、これは自分で色々想像してて気になった所で、スキーマレスでさくっと始められるというのは長所として挙げられますが、運用して2,3年経った時にどんな感じになってるのかな〜？と。スキーマ定義のドキュメントが無いとかはまあよくある話だと思いますが、RDBMSであれば、DDL引っ張ってくれば、最低限の情報とその定義に基づくレコードが格納されているという状態は保証されますが、スキーマレスだと、DDL無いし、Modelクラスがコードに定義されていたとしても、そのModelクラス自体が変遷したりしているわけで、運用の仕方によっては、むかーしの予期しないレコードでバグが出るとか、migrationが超大変とかありそうだな〜と勝手に想像しました。この辺は使ってる人に、どうやってるのか話を聞いてみたい。

ACID, BASE, CAP定理に関しては、この資料が凄くまとまってて勉強になりました。

NoSQLに関するまとめ from Gosuke Miyashita

これ絡みで最近読んだ本

データベースの限界性能を引き出す技術　?NoSQLに飛びつく前に知っておきたい原理と最新テクニック

Software Design (ソフトウェア デザイン) 2014年 03月号 [雑誌]

iPhone5s を買った #docomo #mnp

前に携帯を買ってから丁度２年。
digno(ISW11K)を買った - seikoudoku2000のブログ
auにMNP発行の電話をしたら、「auで端末を選んでいただければ30000ポイント差し上げることもできます」みたいな話をされたけど、それでもやっぱりMNPのほうが割安なのは否めないので、そのまま手続きを進めた。
今回はdocomoに出戻り。iPhone5sの32GB。MNP一括で9800円。

端末選びにあたっては、特にapple信者という訳でもなく、どっちかというとandroidにしたかったけど、端末性能と価格とを比べるとどうみても一番お買い得かなと。android端末は実質0円はあったけど、一括0円はほとんど無かった。rebuild.fmで5sが絶賛されていたのも頭に残ってた。
Rebuild: 20: iPhone 5s (Kenn Ejima, Hakuro Matsuda)
日本はiOSのシェアが世界的に見ると異常に高いという記事やらを見たりするけど、一番安くて性能いいんだから、そりゃそうだよな〜と。
emobileのNexus5も気になったけど、emobile + softbankの電波ってのがどんなもんか分からないので、無難なdocomoをチョイス。try wimaxならぬ、try emobileみたいのがあったらいいな〜と思った。

２年前と比べると、全体的にキャッシュバックは少なくなった印象(３台以上で契約すれば、、みたいのは結構あった)だけど、iPhoneは月々サポートが大きいので結局ほぼトントンな感じ。というか、のりかえ割なるものを考えると、今回のほうがお得かも！？

前回 (au ISW11K)

端末: 0円
キャッシュバック: -45,000円
月々割り: -1050円 * 24ヶ月 = -25,200円
⇒ -70,200円

今回 (docomo iPhone5s)

端末: 9,800円
月々サポート -2,940円 * 24ヶ月 = -70,560円
のりかえ割 -780円 * 24ヶ月 = -18,240円
⇒ -79,000円

マシンの大幅なスペックアップもあり、満足感は相当高いです。すげーさくさく動くし、LTEなためか回線状態もau時代よりいいし、カメラが超いい感じww。色々使っていきたいと思います。

２年前に書いたエントリーを今回の乗り換えの時に読み返してみると、意外に役立った&当時の状況を結構鮮明に思い出せて役立ったので、今回のも書いてみた。
２年後のMNP事情はどうなっているんだろうな〜。今の競争の形は健全ではないと散々言われているて自分もそう思うし、ケータイ買いたいだけなのに訳の分からんコンテンツにとりあえず登録させられて速攻で解約してと、せっかく新しい端末を買っているのに買い物していて気持ちよくないし、、と前回同様、再び残念な気持ちを味わうことになったので、いい方向に変わっているといいな〜。

JAWS DAYS 2014に行ってきた #jawsdays

去年に引き続き、JAWS DAYSに参加。
JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug - seikoudoku2000のブログ

Gengo session

前回はほんとただただ圧倒されてスゲースゲー言ってただけな思い出がありますが、今は仕事でもバリバリと使ってたり、会社で横に座ってる人が発表したり(自分もspeakerに名前があるけど、資料手伝っただけw)と、１年で色々と変わったな〜と少ししみじみ。

Gengo session!! #jawsdays pic.twitter.com/VBSFksxsNr

— Yosuke Tomita (@seikoudoku2000) 2014, 3月 15

発表のほうは自社のサーバ構成の変化を赤裸々に語った内容で、皆に興味持ってもらえるかな〜とちょっとドキドキでしたが、好意的なフィードバックを見付けてほっと一安心。(資料は後日アップされるはず。)
包括的に自分たちのシステムの変化を振り返るというのは中々無いことなので、自分たち的にも良い機会だったな〜と。来年の今頃はどんな感じの構成になってるかな〜。

Gengo Jaws Days Tokyo 2014 Presentation from Derek Szydlowski

Gengo の話よかった。ボトルネックをひとつずつ解消することによって、今日のスケーラビリティが得られているとのことだった。 すごく現実的。 #jawsdays

— ゆうりゅう@カーバンクル(FF14) (@Yuryu) 2014, 3月 15

gengo イケてるよなー。仕組みが。

— Takumi Sakamoto (@takus) 2014, 3月 15

http://t.co/Jy2gG8kZWYの事例はAWS利用の典型的な例で、ベンチャーが初期投資コストを抑えて資金を順調に回す際に、AWSが非常に柔軟で活用しやすいということを意味している。また、多種多様なサービスがあり、組み合わせやすいという点も魅力だろう。#JAWSDAYS

— Junya Terazono 寺薗淳也 (@terakinizers) 2014, 3月 15

Immutable Infrastructure

全体としては、やはり今が旬のImutable Infrastructureの話が面白かったです。
Chef=冪等性というイメージですが、あるレシピがまっさらなサーバに対してはキレイに動くけど、既存のサーバに流し直すとエラーになることがちょいちょい（設定ファイル名変えたり、cookbookのバージョン上げたりした時とか）あって、冪等性とは？と思い悩んだり、自分たちがChefを上手く使えていないのかな〜とモヤモヤしていた所が、少しすっきりしました。ビバ、Immutable!!
ただ、blue-green deploymentはお洒落だし挑戦したい所ではあるけど、一日何回/何十回もデプロイしているような所がそれやると、サーバ準備してる間に次の来ちゃうよな〜とか、インスタンス代ほぼ倍払ってんのかな？みたいな所がちょっと気になりました。今度バリバリやってる人と話す機会があったら聞いて見たい所です。
Immutable Infrastructure #jawsdays // Speaker Deck
SpecInfra at JAWS DAYS 2014 // Speaker Deck

others

あと、目から鱗感でいくとこの発表が一番だったかなと。
What makes AWS invincible? from JAWS Days 2014
AWSの設定変更時のテストは無意識のうちにマニュアルでやってたし、CLI使いこなせるようもっと勉強しないとな〜くらいは思ってた自分からすると、完全に一段も二段の上の視点からの問題提起で刺激的でした。プレゼンのストーリーや資料も凄い良くて勉強になりました。
Miles Wardさんのその場での回答によると、AWSの設定変更のテストにはこれが使えるそうです。
AWS-Compatible Private Cloud | Compatibility Features | Eucalyptus
全然知らなかったツールなので今度調べてみねば。

関係者の皆様お疲れ様でした&ありがとうございました！
今から来年が楽しみ！！

"How Google Tests Software"を読んでる

まだ読み途中だけど、本の中の↓の言葉で、何か自分の中でつながった感じがあったのでメモ。

"quality in not important until the software is important"

レガシーコード問題

どの現場にもレガシーコード問題だったり、何でこうやって作っちゃったの？みたいな話は転がっている気がして、トータルのコストを考えれば絶対にキレイに作るべきと考えてたけど、それは自分が担当したことのあるソフトウェアが新たに開発者を必要とするくらい世に必要とされたからで、そもそも品質なんて気にされることも無く、消えていったソフトウェアやサービスもいっぱいあるんだよな〜と。
冷静に考えてみると当たり前だけど、何か目から鱗の感じがあった。

20%ルール

Googleで有名になった20%ルールってのは、エンジニアのモチベーションアップのためのちょっとお洒落な取り組くらいに思ってたけど、実はとても合理的なモノじゃないかなと感じた。
20%ルール無しで(有象無象の色んな会議を経て、、)、ほんとのプロジェクトばかりになってしまうと、テストや運用の工数を含めてかっちりと決めねばならずやることが増えるけど、そもそもそのソフトウェアが重要かどうかってのが判断がつく前に、そこまで突っ込むこと自体がリスクだし、打てる数が少なくなってしまう。
20%ルールでソフトウェアの多産多死の状態を作りつつ、重要になったソフトウェアに対してはクオリティを保証するためのテストの準備やデプロイの自動化等をきっちりと行ってソフトウェアのデリバリーのスピードを早める。この両輪が大事なのかなと思った。

CIとかInfrastructure as Codeとか、内側のループの話は最近旬で、自分もどっちかというとそういう方面の話のほうが好きだけど、テストが無かろうがコードが汚かろうがスケーラビリティが無かろうが、外側のループを懸命にまわしながら、ユーザに必要とされるサービスやソフトウェアを作り上げたこと自体に敬意を払いながら、仕事に取り組んでいくべきと思ったのでした。

"quality in not important until the software is important"

大事な言葉なので２回書いておいた。

How Google Tests Software

テストから見えてくるグーグルのソフトウェア開発

macの開発環境整備 その２ (pythonまわり)

前回の続き。
macの開発環境整備 その１ - seikoudoku2000のブログ
今回はpython周りの所を中心に。python始めたてですが。

• pyenv
  • yyuu/pyenv · GitHub
  • Readme が充実していて読み応えがある。
  • 前はpythonbrewなるものを入れた覚えがあったけど、deprecatedって書いてて、pyenvを使ってくださいと書いていた。
    • utahta/pythonbrew · GitHub

• pyenv-virtualenv
  • yyuu/pyenv-virtualenv · GitHub

• pyenv + pyenv-virtualenvの分かりやすい説明
  • Python - pyenvとvirtualenvのインストールと使い方 - Qiita [キータ]

• Sublime Text2
  • package controlを入れる
    • Sublime Text: 初期設定など（ST2 / ST3） :: log.chocolateboard
  • python周りは何があると開発が捗るか探り探りな感じなので、とりあえず見つけた↓を真似した。
    • Sublime Text 2でPythonの開発環境を整える - Qiita [キータ]
    • dreadatour/Pep8Lint · GitHub
    • SublimeRope Documentation — SublimeRope documentation
  • SublimeLinterも追加で入れた
    • [SublimeText2]SublimeLinterでSublimeTextをIDE化 | DevAchieve
    • SublimeLinter/SublimeLinter · GitHub
  • Command+b で起動するpythonのパス指定
    • Sublime Text 2 と環境変数 | cockscomb.info
    • pyenvとの組み合わせはどうやるのが良いか？ このプロジェクトは2.7 で、このプロジェクトは3.2みたいな時。ターミナル併用するほうが早そうだが。
  • コマンドでファイル開けるように設定
    • OS X Command Line - Sublime Text 2 Documentation

ln -s "/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl" /usr/local/bin/subl

macの開発環境整備 その１

先日、新端末を購入したので、諸々インストール&設定中。
15インチのMacbook Pro Retinaディスプレイ(整備済製品)を買った - seikoudoku2000のブログ
新しいマシンで何かやるたびにこの辺のことをググり直している気がするのでまとめておく。

• homebrew(パッケージマネージャ)とrvm
  • 前にまとめてた。 Rubyの写経時の環境 - seikoudoku2000のブログ
  • 後述のchef solo + vagrantインストールの時にrvmあると良い気がする。

• Google Chrome
  • Chrome ブラウザ

• XtraFinder

XtraFinder adds Tabs and features to Mac Finder.

• Sublime Text2
  • Sublime Text: The text editor you'll fall in love with

• iTerm2
  • iTerm2 - Mac OS Terminal Replacement

• tree

brew install tree

• 辞書で英英辞典を使えるようにする。
  • Macの辞書.appで英英辞典、英類義語辞典を使う方法 / Inforati
  • ショートカットは command + control + D

• vagrantとchef-soloのインストール
  • 流行りだし、何かと面白そう・便利そうなので！
  • rvmの環境が整った状態であれば、↓の書籍に書いてある通りやるといけますが、注意点として VirtualBox 4.2.14 だとvargantのインストールでこけてしまいました。
    • virtualization - "vagrant up" fails with "NS_ERROR_CALL_FAILED" error - Server Fault
    • 書籍では4.2.12 が使われています。 Download_Old_Builds_4_2 – Oracle VM VirtualBox
    • 7/15時点で4.2.16になっているので解消しているか？

入門Chef Solo - Infrastructure as Code

WEB+DB PRESS Vol.75

• その他の関連書籍
  • 先頭のやつを半分くらい読んだだけですが、naoyaさんの本はあくまでchefの本で、chefを試すためのsandboxとしてvagrantが出てくる感じですが、こっちの本では開発環境としてvagrantを使うことによる様々なメリット、そのためにvagrantに用意されている機能が説明されていて面白いです。
  • chef → 本番サーバの管理、 vagrant → 開発環境の統一 に使う感じっぽい。

Vagrant: Up and Running

Test-Driven Infrastructure with Chef

Chef: The Definitive Guide

15インチのMacbook Pro Retinaディスプレイ(整備済製品)を買った

３週間ほど前になるけど、５年ぶりにノートPCを買い替えた。
今のPC(白いMacbook)も動いてはいるけど、OSはsnow leopardを最後にバージョンアップ対象から外されてしまったし、仕事で最新型のMacbook Proが支給されて以降、家での操作がだんだん辛くなってきたし、DMM英会話やってるとなぜかディスクがうねりだし、１レッスン中に１回はSkypeがshutdownしてしまうという状態で、色んな意味で買い替え時なのかなと。

前回は、価格.comで安かった所で買ったら、何かでAppleに問い合わせた時に、その端末は別名義で登録されてますよと言われ、かなり残念な気持ちを味わったので今回はちゃんとした所で買おうと決めてて、最終的にはMac整備済み製品を選択w。
iPod、iPad、Macの整備済製品とクリアランス - Apple Store (Japan)

スペックは↓で、価格は¥147,300 (今はちょっと値上げしたっぽい。)
＊＊＊＊＊＊＊＊＊
2012年6月発売モデル
15.4インチ（対角）Retinaディスプレイ、解像度2,880 x 1,800（220 dpi）
2.3GHzクアッドコアIntel Core i7プロセッサ（Turbo Boost使用時最大3.3GHz）
8GB 1600MHz DDR3L SDRAM
256GBのフラッシュストレージ
720p FaceTime HDカメラ
NVIDIA GeForce GT 650M、1GB GDDR5メモリ
JISキーボード
＊＊＊＊＊＊＊＊＊
ちなみにSamsungのディスプレイでした。

最初はRetinaなんてとても手が届くまいと思っていたので、全く頭になかったのですが、整備済み製品を見てみると、同等のスペックにパワーアップしたAirを買うのと出費はあまり変わらないことが判明。
現在、同型の新品の販売は行われていないので、正確な比較はできないですが、似たようなRetinaの新品をAppleで買うと￥218,800 ということで、約7万円のディスカウント (+ ちょっとしょぼいCPU)ということで、そのお得感に一気にぐらぐらっとくる。
WWDCでMacbook Airのみ新型が発表されたけど、自分が求めるUXを考えたとき、バッテリーの持ちがいいことや端末の軽さよりも、Retinaディスプレイで子供の写真/動画を見れたりする方が満足度が高いだろうな〜と。
Retina端末はブラウジングでカクツク時があるとか、動作がもたつく時があるというような意見をネットで見てしまったので、念のためApple Storeで実物(メモリが16GBに強化されてるのしか展示がなかったですがw)を触ってみて、全然気にならなかったので、購入を決断。

あと、↓をググってて見つけたのですが、決断を後押ししてくれるとてもいいサイトでした。
アップルストア整備済製品 在庫履歴

簡単に開封の儀。

• 外箱は残念な感じ。

• でも、それ以降は差がなさそう。

今の所は何の不満もなく使えています。寧ろ大満足。
iPadを買った時にも思ったけど、ディスプレイが大きいと写真を見ている時の楽しさが増す。実際の所、自分の目がRetinaと普通のディスプレイの差を見分けられるかというと多分無理ですが、見るたびにRetina使ってるという満足感を得られるので、まあ、それでいいのかなと。ちょっと高い醤油とか味噌を買って長く楽しめるのと似たような感じ。
CUIを扱う時は何かもったいない気がしてきてしまいますがw。

とにもかくにも、５年前は似たような値段で4GBメモリに128GBのHDDに13インチの普通のディスプレイだったわけで、ほんとムーアの法則凄いww。
そして、前のPCは結婚前に駆け込みで買ったのだが、今は嫁１人と子供２人と猫１匹。他にも色々あったな〜。。
次にPCを買い替える時はどんなスペックになって、そして、自分の状況はどうなっているんだろうか。PC買い替える時に人生を振り返るのも悪くなさそうww。