DBのViewを作ったらRailsプログラムが綺麗になった話 | 自転車で通勤しましょ♪ブログ
最近データベースというかSQLについて勉強しているんですが、奥が深いですね。この前の第9回中国地方DB勉強会のときに聞いたrank関数を使って、ランキング機能をリファクタリングしよう！と思って最近頑張ってます。というのも、複雑なクエリ（遅い）を業種数分（10回くらい）呼んでいたため、Herokuだと結構ギリギリの速度になることもあったので、なんとかしなければ！と思っていたのです。 とりあえず、私の開発環境を載せておきます。 Mac Yosemite Ruby 2.2 Rails 4.2.1 PostgreSQL 9.3.4 ひとまずrank関数を使うところまで まず、NewRelicを使ってActiveRecordが出力しているSQLを取得し、それを0xDBEのコンソールに貼り付けて、rank関数を使って業種でパーティションしてランキングを出すところまでしてみました。rank関数は、関数名
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
Googleスプレッドシートを簡易DBとして利用する - PHP+Ajax編 - Mach3.laBlog
この記事は賞味期限切れです。（更新から1年が経過しています） このお題は以前にも何度か関連記事を書いていますが、 いずれの方法もパフォーマンスがあまり良くなかったり、安定性に問題があるなどしました。 今回はその辺を解決する為のライブラリを考えてみるお話です。 やりたい事 書いてみたもの 基本的な使い方 Ajaxで利用する JSONPで利用する その他オプション・機能など 必ず気をつけなければならないこと まとめ : Googleスプレッドシートの活用について 「新しくなったスプレッドシートと簡易データベース化」でGhostsheetが使えなくなったと書きましたが、新スプレッドシートでもAPIが整備された様で、2014年11月20日現在では正常に動作する事を確認しています。但し、スクリーンショット類は古い物なのでご注意ください。（スプレッドシートIDの取得はURLを参照されるのが良いでしょう
Amazon CTOに聞く、NoSQLデータベース「DynamoDB」がクラウドに何をもたらすのか？
Amazon Web Serviceが提供する、SSD上に構築された高速でスケーラブルなNoSQLデータベース「Amazon DynamoDB」が、東京データセンターでも利用可能になりました。 DynamoDBは、単にNoSQLの持つ高いスケーラビリティを提供するだけではなく、一貫性の制御が可能で、必要なスループット性能も自由に設定できるなど、従来のNoSQLとは一線を画す高性能を、メンテナンスなどの管理の手間をまったく必要とせずに提供するサービスです（関連記事「Amazonクラウド、SSD上の新NoSQLデータベース「DynamoDB」を公開。性能をダイナミックに上げ下げ可能」）。 このDynamoDBの開発経緯や技術について、Amazonのバイスプレジデント兼最高技術責任者（CTO） ヴァーナー・ボーゲルズ（Werner Vogels）氏に、テレビ会議を通じてインタビューを行いました。
Clojureの作者が作ったデータベースDatomicが凄い
プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ本番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ
「データベース暗号化ガイドライン 第1.0版」を公開（DBSC） | ペイメントナビ
2011年11月4日14:14 データベース・セキュリティ・コンソーシアム内の「DB暗号化WG」では、「データベース暗号化ガイドライン 第1.0版」を策定し、2011年11月1日に公開した。同WGでは、2010年8月より検討を開始。9月26日に「データベース暗号化ガイドライン 第0.9版」を公開し、一般から寄せられた意見をもとに第1.0版を策定した。 情報漏えい事件が頻発する中、多くの重要な情報の格納場所であるデータベース（DB）に対するセキュリティ対策が重要視されている。昨今のDBセキュリティにおいて、DB暗号化は情報漏えいに対する抜本的な対策であり、正しい運用を実装することで、リスクの低減もしくは漏えい防止を実現可能だ。しかし、DBの暗号化については、その手間や煩雑な運用イメージやパフォーマンスの低下、心理的不安要素などから敬遠されてきたという。 このような背景から、DB暗号化WG で
SQLライクにHadoop Hiveを使い倒す!
パーティションを利用する 今回は少し凝ったテーブルを定義をしてみましょう。 郵便番号データは毎月更新されるので、テーブル指定時にバージョンも指定できるようにします。このような場合、Hiveではパーティションを使います。 以下に郵便番号を保存するテーブル「zip」を定義しますが、日付型DATEのパーティションverを設定するようにします。 hive> CREATE TABLE zip (zip STRING, pref INT, city STRING, town STRING) > PARTITIONED BY (ver DATE) > ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' > LINES TERMINATED BY '\n'; OK Time taken: 0.128 seconds
高速SSDの落とし穴。データベースで利用するときはご注意を！
今年はSSDの台頭がめざましい。価格の低下、大容量化、そして高速化、さらには低電力化まで期待できるというからもうHDDの出番はなくなるんじゃないだろうかというぐらいの勢いである。しかしそんなSSDもデータベースで利用する時には気をつけてもらいたい。 MySQL Performance Blogでインテル製SSDを使って検証した結果がレポートされている。 インテル製SSDはめっぽう早い。彼らのテストでは一秒間に5250回もの書き込みが出来たそうだ。しかしそれはライトバックキャッシュが有効になっているときの話であって、ライトバックキャッシュを無効にすると書き込みは秒間1200回まで低下したらしい。（それでも高速だが。） で、このインテル製SSDのライトバックキャッシュはくせ者で、バッテリー等で保護されていない。つまり、ライトバックキャッシュにダーティな（まだディスクへの書き出しが完了していない
まったくの初心者もこれでバッチリ 12のキーワードから学ぶデータベース基本中のキホン（後編）
データベースに限った話ではありませんが、特にコンピュータ関連ではたくさんのキーワード（用語）が出てきます。はじめてデータベースの勉強をしようとすると、キーワードの数と難しさ、他分野との意味の違い等にとまどってしまうと思います。そこで本稿では、出現頻度が高く、最低限は押さえておきたいキーワードを12個に絞り、前編に引き続き、残りの6個を紹介します。keyword 1～6については、前編を参照してください。 keyword 7 アカウント 皆さんは、個人情報保護法や内部統制といった言葉を聞いたことがあるでしょうか。 個人情報保護法とは、個人情報の取得や保存／利用に関する義務、違反時の罰則などを定めている法律です。個人情報には氏名や住所、電話番号、生年月日などの基本的な情報や、顔写真やメールアドレスなど、ほかの情報と組み合わせれば個人を識別／特定できてしまう情報やデータが含まれています。また、内
内的・外的ということと外部キー - 極北データモデリング
内的・外的という考え方がある。 野矢茂樹「ウィトゲンシュタイン『論理哲学論考』を読む (ちくま学芸文庫)」 P-50 それが変化したとしてもあなたがなお同一人物であり続ける場合、その性質や関係はあなたという対象にとって 「外的」であるといわれる。それに対して、その性質や関係が失われたならば、もはやあなたはいままでと同一 人物のあなたとはみなされえなくなる場合、その性質や関係は「内的」ということになる。 「変わったらそいつじゃなくなる」ものだけが「内的」なのだから、モノについてはほとんどの性質は「外的」ということになる。 私の属性は、名前・性別・年齢など、思いつきそうなものは全て外的だ（名前を変えようと性転換しようと私が別人になるわけではない）。 このことは、モノをデータベースに写し取った resource についても当てはまる。そのへんのデータベースを眺めてみると、resource にはめ
PostgreSQLの手軽なSQLチューニング
こんばんは、牧野です。 今日は前々回の話題に戻って、PostgreSQLのチューニングの話です。 この前は重いSQLをどうやって見つけるか紹介しました。今回は処理を速くするためのSQLの具体例を紹介します。 １．インデックスを使う 以前も書いたので省略しますが、データ数が多くなってくると（数万件以上とか）インデックスが正しく使えているかどうかで負荷のかかり方が大きく変わってきます。 複数カラムの条件検索の場合は、必要に応じて複合インデックスを作成します。その時は、プログラムの方でWHERE句の順番に気をつけましょう。 ２．VACUUMとREINDEX 特にバッチプログラムで頻繁にデータ更新を行うようなテーブルがある時は要注意です。VACUUMをしないままで運用していくと大変なことになる場合があります。バッチ処理の後等定期的にVACUUMするようにしましょう。 自動バキュームを使うのも有効で
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Migraine Pain Relief High Speed Internet Free Credit Report Cheap Air Tickets Top 10 Luxury Cars Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
連休中はWiiのマリオカートをやりまくってやっとVR7000越えたmikioです。愛車はマッハ・バイクとインターセプターです。さて今回は、分散ハッシュデータベースサーバTokyo Tyrantでmixiの最終ログイン時刻を管理するようにした時の苦労話を書きます。 ログイン処理は負荷地獄 mixiでは、全てのユーザについて、各々の最終ログイン時刻を管理しています。「マイミクシィ一覧」や「お気に入り」などの画面で、友人が近い時間にログインしていてコミュニケーションがとりやすい状態にあるかどうか確認できるようにするためです。 mixiのほぼ全てのページはログインしないと見られないページなので、ほぼ全てのページにアクセスされるたびにログイン確認が行われます。したがって、最終ログイン時刻はほぼ全てのページにアクセスされる度に更新されることになります。mixiの中で最も重いデータベースのひとつとして「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
株式会社スタイルズ
http://www.buena-idea.net/~hironobu/postgresql/p-2-07.html