サイバー戦争黎明期の今こそむしろ徴兵制の好機 | 独り言v6
最近は徴兵制のお話が流行りなようです。野党の「戦争法案」うんぬんの話が引き金なのですが、どちらかと言うとああいう強引な論理には分がないように思えます。 安保法制賛成派の多くは、徴兵の非合理性を主張しています。例えば ■徴兵されないか不安なみなさんへ。 戦闘も同じです。 志願をし、採用試験に合格し、何最近は徴兵制のお話が流行りなようです。野党の「戦争法案」うんぬんの話が引き金なのですが、どちらかと言うとああいう強引な論理には分がないように思えます。 安保法制賛成派の多くは、徴兵の非合理性を主張しています。例えば ■徴兵されないか不安なみなさんへ。 戦闘も同じです。 志願をし、採用試験に合格し、何年も勉強して資格取ったり訓練やったりして、そしてさらに日々訓練を積んでいるプロにしかできないことです。 やる気のないド素人を戦場に連れてったら、なんの任務も遂行できません 陸自、空自、海自それぞ
独り言v6 » RDBMSにおける5つの並列可能性 – L.star的デザイン(2)
前回、と言ってもずいぶん前になるが 超並列RDBMSは成立するか – L.star的デザイン（１） にてある程度の考察をしているRDBMSのデザイン。kumoFSどうだろうとか寄り道しつつ、自分なりの次のステージまで煮詰めることができたので、それについてメモとして書き留めたい。 まず目標として掲げるのは、 標準的なストレージしか持たないサーバ群を使う。 単純CRUDクエリのスケールアウト。読み書き両方 JOIN構文のサポート。特に１TB程度の複数テーブルをINNER JOINして集計できる 1つのクエリ内部を複数サーバに分割させることによる性能向上。スケールアウトというわけではないが。 というところである。かなり無茶な要求と思うが、ここまでサポートできるとデザイン上で納得できれば悪くなかろう。現実に実装する場合には、随所で発生するボトルネックとの戦いになるだろうし。前回は「ストレージノード
「組織のボトルネック」を見抜いて転職を極めよう | 独り言v6
ITエンジニアの価値を貶める『人月商売』の功罪 を読んでみて。 「人月商売」がエンジニアにとってどのような問題点があるかというと、エンジニアの価値を低下させる事になってしまう、という点です。 端的に言うと、「人月」で見積もりを出しているという事は、すなわち自らの価値を、提供価値に対して値段を付ける「知識集約型」ではなく、稼働に対して値段を付ける「労働集約型」へと貶めてしまっているからです。 ITの良い点の一つとして、ルーチンワークをプログラミングで自動化できる点があります。一度システム化してしまえば人の代わりに永続的に価値を生み出し続けられるメリットがあるわけですが、労働集約型モデルで働いていると、永続的に生み出される価値に対する対価は得られず、何人月で作ったかという時間の切り売り部分にしか対価が支払われません。 これはどう考えてもITエンジニアのもたらす価値の安売りであり、自らの価値を下
独り言v6 » 超並列RDBMSは成立するか – L.star的デザイン（１）
前回Oracle exadataについて書いたが、そのとき同時に「L.starにも考えていることがあった」と書いた。一つはpgclusterで培った経験を元に、クエリベースのレプリケーションをまともに動かそうというものなのだが、もう一つがexadataに近い、超並列を可能にするかもしれないRDBMSのアイデアだった。ここではそれを簡単にまとめることで、実際に可能かどうかをあらためて考えてみたい。 あくまで個人的な意見としてだが、超並列超高性能DBを作るうえで、考えたことは以下の通りである。 原則シェアードナッシングしかあり得ない。 読み込みディスクI/Oは、ディスクを増やせばいくらでも高速化可能 書き込みの高速化はシェアードナッシングしか他にない 分散後のデータをレプリケーションさせれば、読み込みの負荷分散まで可能である クエリの今以上の高速化には、複数ノードで１クエリを実行することが可能
ゲーム史的に正しい「ドラクエが日本で生まれたわけ」 | 独り言v6
チームラボ猪子氏が語る「マリオやドラクエが日本で生まれたワケ」 というのがよく荒れておりました。荒れる理由はゲーム史に対する不理解で、例えば以下の文面はゲーム史論文などというテストがあれば０点です。横スクロールアクションとしてのスーパーマリオブラザーズは、もちろんゲーム史的に非常に重要なマイルストーンではあります。しかし、実際には最初どころがわりと後発です。 一瞬話変わるんですけど、これはマリオ。僕の大好きなマリオ。実はマリオというのは世界で一番はじめに、世界で初めて横スクロールアクションという概念を生み出して、実際世界中で大ヒットしています。世界中の人々はマリオを生んだ人に対して、天才なんじゃないかと、神のように賞賛しています。でも考えてみてください。マリオを生んだ人は京都にいて、京都は伝統的な日本の空間の認識によってデザインされた空間に溢れています。もしかすると毎日の生活の中で、自分の
あなたが思うほど真実の数は少なくない。 | 独り言v6
中途半端なグローバル教育に煽られて幼年期に英語を教えるよりも、しっかりとした「日本語脳」を育てるべきだ という記事が目に入ったので。L.starにも娘がいるが、今のところオランダ生まれニューヨーク育ちという自分とは似ても似つかない経歴の持ち主になっており、子どもの教育という面では色々考えることが多い。 海外在住組はやはりその事情が事情なので、「まずはしっかり日本語から」という上記のURLに沿う形のものと、「せっかくだから海外でしか学べないものを」の大体二派に分かれている。まあ言い争いとかになることはほぼ無いが、みなさん自分なりの考えをお持ちである。 ・・・と言うのを考えながら上記を眺めて「ああ、まずはしっかり日本語派の意見でも出てきたかなあ」と見ると、さすがかの東洋経済オンライン炎上事件で有名な原田武夫氏の面目躍如というべき、まさかの右脳左脳論が出てきて飛び上がってしまった。右脳左脳論は、
本物のフルスタックエンジニアをお見せしますよ。 | 独り言v6
去年辺りから聞かれるようになった「フルスタックエンジニア」という単語、いよいよ日本でもバズりだしましたね。最新のエントリで言うと以下でしょうか。 フルスタックエンジニアもオフショアに脅かされる未来 なんとも微笑ましいエントリです。例えばアメリカではスタートアップを中心にフルスタックの求人は増えていますが、それがオフショアになどという話はあまり聞こえてきません。しかし気を取り直して、ちょっと見てみましょう。 フルスタックエンジニアの複合スキルで触れられているシステムのインフラ構築ですが、基本は日本人エンジニアが担当することが多いです。 理由はいろいろありますが、一番の理由としては「IDCが日本にあるから」。 （中略） 今後はIaas型のクラウドをベースにしたシステム開発が増加すると言われてます。 ということは、Iaasが普及すれば、インフラ構築が地理的拘束から開放されることを意味するわけで、
SQLに依存することの危険性 ー 単体DBサーバでは終わらない時代の考え方 | 独り言v6
ベンチャー社長で技術者で:ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！. というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。 L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出
HyPer – 未来のIn-Memory DBMSは古の魔法で超絶OLTP性能とOLAP性能を両立させる | 独り言v6
昨今のDBMSの分野の進歩はGoogleがパンドラの箱を空けてからずっと凄いスピードで進化し続けているが、中でもVoltDBは飛び抜けたOLTP性能に特化したDBMSだ。しかしそのプロトタイプであるH-Storeからもう何年も経っており、当然その先の何か、というのが見えてくる。 最近久々に技術に立ち戻ってちょっと最新のDBMSに関する論文を読むか、とカラム指向データベースの圧縮手法について学ぼうかとStonebraker教授の前作C-Store（後のHP Vertica）を調べたり、ハイブリッドDBの前段に使われるインメモリDBの構造について勉強しようと思ったりしてたら非常に興味深いシステムを見つけたので紹介したい。それはミュンヘン工科大学のHyPerだ。HyPerはH-Storeのあとを受け、そのOLTP性能の高さを受け継ぎながら、OLAP性能に関してもインメモリDBならではのずば抜けた
独り言v6 » Database-as-a-Service 考 ― 我々のデータは雲の中にどう溶け込んでいくのか
久しぶりにRDBMS技術的な記事でも。HerokuがDatabase-as-a-Serviceを開始したらしい。 HerokuがPostgreSQLのDatabase-as-a-Serviceを開始。しかし料金表がおかしいぞ ただしHerokuは昔からPaaSの一環で、バックエンドPostgreSQLをサポートしているのでそれ自体は珍しいわけではない。専用メニューが開始された、ということにすぎない。PostgreSQLではないが、同様のサービスはAmazon RDCで前からMySQLやっているし、SQL Azureもある。 そういえばUmitanuki氏がHerokuオフィスに行ってPostgreSQLとpl/v8の話聞いて来たで遊びに行ったレポートを書いているが、そこの話とも矛盾しない。PostgreSQLは素のまま、管理運用に手を入れて、とにかく万人に扱いやすいシステムに仕上がっている
独り言v6 » VoltDBは何故早いのかは問題ではない。何をするためのシステムなのかが問題だ
ちょっと小旅行に出ている間にアクセスが伸びていて、おかげさまで前回のVoltDBのエントリが大人気だったようだ。まだまだ書き足りない部分がいっぱいあったので、補足する意味も込めて書き足してみたい。それは、H-Storeが従来型RDBMSとどれほど異なったシステムか、ということだ。インターフェースの話や大まかな話はしたが、前提となる部分の話はずいぶん抜けてしまっていた。 NoSQLを超えるSQLデータベース「VoltDB」。Cassnadraとベンチマーク対決！ で、実際にCassandraと比べて検討している Key-Value Benchmarking という記事が紹介されていて興味深い。で、なおかつ勝っていると言うから痛快だ。まあ個人的にはこの勝負は高々３ノードしか使っていない時点でスケーラビリティに勝るKVSにずいぶん不利な内容だな、と言わざるを得ない。せいぜい12ノードぐらいでしか
独り言v6 » VoltDB登場 – RDBMSのようでRDBMSではない新システム
最近また超並列DBのデザインを進めたりRethinkDBの話を書いてみたりとまたRDBMSづいているが、そんなことをしているうちに世の中では実際に並列DBが登場してしまった。 INGRES,POSTGRES,Illustra（と、誰も知らないMariposa)と、RDBMSの世界で革新的な仕事をしているMichael Stonebraker博士。最近何やっているのかと思ったらいつの間にやらH-Storeなる新型のストレージに携わっていて、それがいつの間にかSQL機能をもってVoltDBというプロダクトとしてやってきた。かれこれ40年近く業界の第一線にいることになる。 「NoSQL」を上回る性能を目指す次世代型高速SQLデータベース「VoltDB」登場 などという記事を見てびっくりした次第だ。NoSQL並の性能とRDBMS並のACID準拠、そしてSQL構文が使えるという、これまた夢のようなシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
