香川大学の学生向けにソフトウェアエンジニアの生存戦略について話をしました - そーだいなるらくがき帳
7/21に香川大学で講演させていただきました。そーだいさんと言えばRDBでしょ！？みたいな感じで先にタイトルが決まった感じですがRDB全然関係ない感じになりました。 僕が超絶リスペクトしてる id:t-wada さんとそこそこリスペクトしてる上司の id:onishi さんの名言を引用させてもらいました。僕はこの2つの言葉が10年戦えるエンジニアの核心をついてると思っています。 つまり 技術は螺旋なので継続的な知識の更新は必須 手を動かす（一歩目を踏み出す）者が未来を作る という2点を踏まえた上でエンジニアにはそれぞれ得手不得手があるわけです。この得手不得手を理解して自分がどのフェーズを戦場として戦うか？って話をしました。この話は前もブログに話をした内容です。 soudai.hatenablog.com そこで僕の経験談としてDBを交えて話をしました。 サービスを作るのが特に好きなタイプで
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現 Googleは、クラウド上で高度なスケーラビリティを実現する、ミッションクリティカルな業務に対応したリレーショナルデータベースサービス「Google Cloud Spanner」を発表しました。 Google Cloud Spannerは、地球規模の大規模分散処理データベースとして、NoSQL並の非常に高いスケーラビリティと高い可用性、そして高速な処理を実現しつつ、SQLに対応。強い一貫性を持つトランザクション処理も実現。企業のミッションクリティカルな業務にも使えると説明されています。 地球規模に分散したリレーショナルデータベース 一般に、ミッションクリティカルな業務に対応したリレーショナルデ
RethinkDBはなぜ失敗したのか | Yakst
つまり、これらのマーケットは小さく、しかもデータベースのマーケット自体よりも小さいのです。とは言え、どれかが他よりもマシになりうるでしょうか？ マネージドホスティングは、本質的にはユーザのためにAWSでデータベースを動かすことで、そうすることでユーザたちは自分で動かす必要がなくなります。これらのサービスを使う代わりになるのは、AWSに自分でデータベースを立てることです。したがって、マネージドなデータベースホスティングサービスが課金できる額には、非常に厳しい上限があることになります。Compose.ioやmLabが、RethinkDBよりも1桁あるいは2桁多いユーザを抱えるMongoDBを提供していることを考えて、マネージドホスティングを提供することには少しの良い点もないという結論を下しました。 Database as a Serviceはマネージドホスティングの更に複雑なバージョンです。D
SILO再考〜次世代DBのアーキテクチャとして - 急がば回れ、選ぶなら近道
大分たってしまったけど、ようやく時間が空いたので、db tech showcase Tokyo 2016 http://enterprisezine.jp/dbonline/detail/8466 で話した内容を記録的に書いておく。あとはSILOの解説を特に自分用に論文の4章を中心に整理しておく。あとはついでに自分の思うところも記す。 ・SILO 元論文はこちら、執筆陣はMITのLiskov一派とEddie Kohler 現在のDB研究の第一線のメンバー。 http://people.csail.mit.edu/stephentu/papers/silo.pdf SILO以降、大きくDBベースのアーキテクチャの考え方は変わりました。ほとんど全ての分散系OLTPはSILOを程度の大小はあるとはいえ、意識していると言っても過言ではないでしょう。前世代ではほぼ「空想か？」ぐらいの扱いだった分散t
Parse
The most amazing feature of Parse Server is that it’s accessible for developers of all skill levels. Personally, I started playing around with Objective-C in 2012. Parse was a way for me to build a complete online app, without having the in-depth knowledge of how to build networking, storage, user systems, etc. The more I built with Parse, the more I learnt JavaScript, which has fortunately allowe
Airbnbのメインデータベースをどうやって2週間で分割したか | POSTD
スケーリング＝時速160㎞で走行しながら自動車の全ての部品を取り替えること －Mike Krieger Instagramの共同設立者＠ Airbnb OpenAir 2015 Airbnbのピーク時のアクセス数は、毎年夏のピーク時で見ると年率3.5倍で増加しています。 2015年夏の旅行シーズンを前に、Airbnbの基盤チームは、夏季のアクセスで予想されるデータ通信量に対処するため、データベースのスケーリングで忙殺されていました。中でも特に全体への影響が大きかったプロジェクトが、特定のテーブルを、アプリケーションの機能に従ってそれぞれのデータベースに分割することを目的としたプロジェクトでした。これは通常、アプリケーション層のフォームの変更やデータ移行、データの整合性を保証する堅牢性テストなど、最小限のダウンタイムで多大な技術的投資を必要とするものです。何週間もかかるエンジニアリング時間
AWSでSESと無料のSQSを使って快適なメールマガジン配信システムを構築した話 - ぷれすとぶろぐ
Amazon Web ServiceでSESとSQSを使って、大量に高速に送ることが出来るメールマガジン配信システムを構築してみました。 もともと、別の開発者の人が開発していたものを、引き継いで受託していたサービスが、日々会員数が増えるたびにメールの配信時間が伸びていき、最終的に2万人に配信するのに6時間ほどかかるシステムになっていました。 システム システム構成はシンプルでAWSのEC2のインスタンス上でDBやアプリケーションが動いており、画像などのリソースの保存にS3を、メール送信にSESを使っています。 ちなみにアプリケーションはJavaEEです。最近ではちょっと珍しい？ですね。 問題点 もともとのシステムは、管理画面から登録されたメルマガ情報からメルマガを受診する対象のユーザーを取得し、名前などを埋め込んだスプールを作成する「スプール生成バッチ」と、DBに登録されたスプールを順番に
Migu という golang 用 DB スキーマのマイグレーションツールを作った話 - 何気に大変
Ridgepole インスパイアの golang 用 DB スキーマのマイグレーションツールを作りました。 https://github.com/naoina/migu Migu は Ridgepole と同様に（バグが無い限り）冪等性が保証されています。 Ridgepole と違うところは、スキーマ定義を DSL ではなくて golang の struct で定義するところです。こうすることによって、モデル定義 ＝ スキーマ定義となるので DRY になります。 使い方 下記を schema.go というファイル名で保存します。ファイル名は何でもいいんですが、ここでは schema.go を使います。package 名も何でも構いません。 package schema type User struct { Name string Age int } 次に migu_test というデータ
『TOTEC2014 インフラチューニング（チューニンガソン）で優勝したはなし』
TOTEC2014 インフラチューニング（チューニンガソン）で優勝したはなし | サイバーエージェント 公式エンジニアブログ インフラ＆コアテク本部の仲山です。 「TOTEC2014 インフラチューニング」という社内チューニンガソンイベントで優勝をいただいたので、 技術ブログを書くことになりました。 TOTECは、サイバーエージェントグループ内の技術者コンテストで、 インフラ、フロントエンド、サーバサイドの分野ごとに、 「チューニンガソン」と呼ばれる形式でその速度向上を競い合います。 今回の「インフラチューニング」では、 参加者はソフトウェアのソースコードを改変できないため、 あくまでミドルウェア等の変更、チューニングや、サーバ構成の最適化のみで闘います。 主なレギュレーション 運営があらかじめ用意したMediaWikiの応答速度を競う。 ソースコードの変更は禁止だが、設定ファイルの編集は
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
LedisDB - A high performance NoSQL like Redis powered by Go.
Data structure Rich data structure: KV, List, Hash, ZSet, Set. Various Backend Various backend databases to choose: LevelDB, goleveldb, LMDB, RocksDB, BoltDB or Memory. Expiration & TTL Supports expiration and ttl in all kinds of data structures. CLI Support Redis clients, like redis-cli, are supported directly. Easy Embedding Easy to embed in Go application. Data Protection Replication to guarant
SQLを作った人たち - 未来のいつか/hyoshiokの日記
リレーショナルデータベース管理システム(RDBMS)は言うまでもないことだけど、データベース管理の基礎中の基礎だ。NoSQLというRDBMSではないデータベース管理システムが出て来ているがそれもSQLがあってこそのNoSQLだ。 リレーショナルモデルはIBM E.F. Codd博士が提唱した。Edgar F. Codd - Wikipedia Codd博士は後にチューリング賞を受賞している。 http://en.wikipedia.org/wiki/File:Edgar_F_Codd.jpg そのデーターモデルを利用したデータベース管理システムのプロトタイプがSystem Rだ。IBM System R - Wikipedia 1974年ごろ発表された。 その成果の一つがSQLだ。誰でも使っているSQLはSystem Rの論文が発祥の地である。そしてその論文を読んでRDBMSを作った男がL
『アメーバピグにおけるDB構成&対応記』
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
各種DBのMac用GUIクライアント - komagataのブログ
内部ツール（僕らでいえば256interns.comとか）は管理画面作らずGUIアプリで変更とか結構便利です。とはいえ、railsなどのアプリ側のみでvalidationしてると不整合が起きるので要注意。これ前提で制約追加するのもいいかも？ Sequel Pro MySQLのGUIクライアント。これを教えてもらって訝しげに使ってみたんですが、今風のMacの使い勝手で使えるのがすごく気に入っちゃいました。 SSL経由やsshで入ったサーバー踏み台にしての接続も一発できて便利。 PG Commander PostgreSQLのGUIクライアント。Sequel Proに比べると使い勝手は良くないけど、HerokuのDBに接続できる！これがデカイ。 接続先のブクマを５個以上保存しておくにはLisenceを買う必要があります。Herokuを多用するから５個あっという間に超えちゃうので買いました。 B
データベースでもっとも重要な３つのアイデア。（世界でもっとも強力な９つのアルゴリズム） - 未来のいつか/hyoshiokの日記
昨日の日記には山のようにブックマークがついた。( 世界でもっとも強力な9のアルゴリズムを読んだ。 http://d.hatena.ne.jp/hyoshiok/20140209/p1 ) データベースはアルゴリズムじゃないだろうというツッコミもあるけど、偉大なアイデアということだろう。それは多分誰も異論はないと思う。そこで紹介されている３つのアイデアは ログ先行書き込み(WAL) 2段階コミット リレーショナルデータベース トランザクションと言う概念が70年代以降発展してきて、その実装にはログ先行書き込みが多大な貢献をした。 2段階コミットによって分散型データベースが信頼性をもって実装できるようになった。 リレーショナルデータベース（というよりもリレーショナルデータモデル）は全ての基盤になっている。 これらの発展は70年代のSystem Rの先駆的な研究開発から始まったといっても過言ではな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLアンチパターン
O/Rマッパーによるトラブルを未然に防ぐ
Mobage を支える Ruby の技術 ~ 複数DB編 ~ : sonots:blog
レガシーなウェブアプリを Rails で拡張するときに DB の扱いで気をつけること #rubyhiroba - 彼女からは、おいちゃんと呼ばれています
2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ
