20140711 MySQL Casual Talks vol.6 / 続・Amazon RDS Casual TalksMori Tetsuya
@ainame user.articles.preload(:comments, :stocks_count) みたいにstocks_countのようなassociationを生やしており、stocks_countの内部実装はPreloaderが弄られていてIDだけ取ってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame これを抽象化するために、Article.has_many(:stocks, counter: true) みたいにすると、article.stocksとarticle.stocks_countがほぼ同じSQLで同時に定義されるようになってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame それを実現している実装がこれです / k0kubun/activerecord-precount https:
— そーだい@初代ALF (@soudai1025) 2015, 8月 24 とブーメラン投げて見事に刺さってるので今から記事書く。 両サイドにはかなり厳しい話もするが俺の本音を聴いておけ(関白宣言) まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。 なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。 むしろ実際に使ってみた際の違いをにフォーカスする。 1. SQLの違い 基本的にMySQLでやっていたことはPostgreSQL出来る。 しかし関数の挙動の違いは幾つかある。 例えば時間から曜日に該当する数字に変換した場合に MySQL → date_format(time,"%w") 0から始まり、日曜日に該当する PostgreSQL → to_char(time,'D') 1から始まり、日曜日に該当する など挙動に互換性
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
※この内容は個人的な考察なので、間違っている箇所もあると思います。そういう部分を見つけた際はぜひ教えて下さい。 RDBMSの検索を早くするためにIndexって使いますよね。例えばこんなテーブル CREATE TABLE user ( id INT UNSIGNED NOT NULL, name VARCHAR(255) NOT NULL, UNIQUE INDEX (id) ); idカラムにIndexを張っています。これはidでの検索を高速にするためです。ここでidカラムにIndexが貼っていない場合と比べると検索時間が大幅に変わってきてしまいます(特にレコードが多くなった時) ではなぜIndexを貼ると検索が早くなるんでしょう?? Indexとはその名の通り索引を意味します。特定のカラムの索引を作成しておくことで検索を高速化します。 (本の最後によみがな順で単語が並べられたりしています
本日、qpstudyで「データベースとは」という内容について、そして「リレーショナルモデルとは」という内容について話す機会を頂いた。リレーショナルモデルという硬い内容であったにも関わらず、出席者の皆さんには最後まで良い反応をして頂けたように思う。実はリレーショナルモデルについて誤解している、あるいは知らない人が本当に多い、そして良い解説書がないということを普段問題として感じており、そういった背景から今回qpstudyの話を引き受けさせて貰った。今回発表した内容が皆さんのお役に立てば幸いである。 発表の内容はほぼ現在WEB+DB PRESSで連載している「理論で学ぶSQL再入門」のいくつかの回のものを要約したものになっている。連載ではさらに詳しい内容について説明しているので、興味のある人はぜひWEB+DB PRESSのバックナンバー(連載はVol.68〜)を購入して頂きたい。 本日発表したス
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
スライド1: PHP と MongoDB で学ぶ次世代データストア佐藤琢哉LOCAL PHP 部 スライド2: スライド3: 突然ですが スライド4: 4月から札幌市民になります!!!!! スライド5: 友達が少ないので皆さん遊んでやってください スライド6: • MongoDB って何?• 使い方• 他の DBMS との比較• MapReduce• まとめアジェンダ スライド7: そもそも何の話? スライド8: MongoDB すごいよ! スライド9: MongoDB って何? スライド10: http://www.mongodb.org/ スライド11: MongoDB (from "humongous") is a scalable, highperformance,open source, schema-free, documentorienteddatabas
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く