『夢のデータベース？「Cloud Spanner」の実力は？』について - Software Transactional Memo
こんな記事が目に入った。 www.itmedia.co.jp 大雑把に完全に間違ったことを言っているわけでもないが、読んでいくといろいろ鼻につくところがあり、どのあたりから間違っているのかと自分に問いただすのは現時点での自分の知識を棚卸しするためにも有用かも知れないと思ったので一言一句漏らさず思うところを書いていこうと思う。 中には枝葉末節な難癖もあるので全部を真に受けない感じで読んで欲しい。 Cloud Spannerの特徴は、これまでリレーショナルデータベースで不可能とされていた「トランザクション処理の大規模分散処理」を実現したところにあります。 単一のトランザクション処理を分散して実行しているかというと、Spannerはトランザクションごとに担当のトランザクションマネージャがそのトランザクション処理全体を取り仕切って行う仕組みになっている。なので「トランザクション処理の大規模分散処理
Zero downtime migrations: 500 million rows
Data makes things hard In this article I'm going to go over some of the tricks we use to handle large data migrations at Honeybadger. Check out the video for a quick overview. When you have a lot of data, your life gets harder. When you only have 1000 rows, you can make DB-wide changes in IRB. With millions of rows, it's not that easy. If you don't believe me, just try it. RAM will spike. Your a
プライマリキーを使った1:1関連でカラム数の多いテーブルを分割する - Hidden in Plain Sight
おそらく多くのソーシャル系アプリにあてはまるRailsのプチ・デザインパターン的な話。 ぼくが今やっているEast Meet Eastには、ユーザごとに数多くのプロフィール属性があります。名前、性別、生年月日、郵便番号、職業などなど、カラム数にしてざっと25個。これを、全部ひとつのusersテーブルに詰め込むのは、コードの見通しという観点からも性能の観点からも、あまりよろしくありません。 なぜならば、ユーザ関連の情報を扱う局面としては主に メールアドレスとパスワードなどを使ってログインする（アカウント情報） プロフィール情報で条件を指定してユーザを検索・推薦する（プロフィール情報） という２つの独立性の高いユースケースにわかれるため、ログイン処理をやってるときにはプロフィール情報はいらないし、プロフィールを検索してるときにはメールアドレスやパスワードをロードするのは無駄です。また、開発やデ
Rails3.0でモデルのER図を簡単に出力する方法
こんにちは、@sawada0903こと澤田です。 今Rails3.0を使ってサービスを開発しているのですが、 DBを定義するにあたり、やはりER図が欲しい。 Rails2.3.8を使っていた頃はRailroadというgemを使っていたん ですが、2008年で開発が止まっており、当然Rails3.0には非対応(涙)。 ちなみにRailroadに関してはこの記事が詳しいです。若干ね。若干。 Railsを見える化「RailRoad」 http://www.moongift.jp/2007/07/railroad/ なのでしばらく頭の中で開発を進めていたんですけど、やっぱり欲しい。 アジャイル気味に開発してるのもあり、かっつり最初から決めたくない。 とはいえリレーションを目で見たいし、複数人で開発するとなると尚更欲しい。 そこで、Googleさんに聞いてみる....。 と！ こんなgemを発見。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why historically do people use 255 not 256 for database field magnitudes?
tuning postgresql for large amounts of ram
ソーシャルゲームのためのデータベース設計
