MongoDBの薄い本(The Little MongoDB Book) - cuspy diary
Karl Seguinさんの「The Little MongoDB Book」を和訳しました。 この本はMongoDBの基礎を実際に手を動かして学ぶチュートリアルです。 MongoDBの基礎から、データモデルの設計方法、MapReduceなど幅広い内容をカバーしています。 また、特別MongoDBに興味が無くても筆者のNoSQLへの考え方は一読の価値があるだろう。 ダウンロードPDF版 the-little-mongodb-book-ja.pdf epub版 the-little-mongodb-book-ja.epub(あんまりきれいに組版できてないけど…) 誤訳などあれば @hamano まで ソースはこちら: https://github.com/hamano/the-little-mongodb-book 更新履歴2012/04/17 v1.0 初版公開。 2012/06/15 v
RDBMSでコネクションプールが必要な理由、わからない。
Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない（解放まで多少遅延する）ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ（要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか？なぜ(べき、べきでない)のか？どういう要請でそうなのか？と言う問いに僕は答えられません。 2013-09-04 09:31:22
楽観的ロックと悲観的ロック - Super Neurotic Junction
音楽の話題ではないよ。 railsで、DBのレコードロックについてちょっと調べた。 ruby on railsが提供するレコードロックは楽観的ロックと悲観的ロックの２種類がある。 この、いかにも直訳調な名称もどうかと思うけど、たいがい二つ並べて解説されているのでなんかこうよく似たものと思われがち。ところがこの二つ、実は使いどころがまったく違うシロモノだったって話。 悲観的ロックは、レコードを読み込むときかける形式のロックで、要するに「これからこのレコードをいろいろいじるのでほかのやつらは触るなよ」と言う宣言。実装はDBエンジンに依存している。MySQLなりPostegrasなり、主要なDBエンジンはたいてい対応しているはず。 楽観的ロックは、レコードを書き込むときに問い合わせる形式のロックで、要するに「とりあえず変更したレコードを手元に持っているけどほんとにこれ書き込んでいいのかな」という
MVC で「テーブル：モデル＝１：１」が許されるのは小学生まで - Devel::Bayside
本来、MVC の M はロジックを含み、C はイベントハンドリング、ウェブアプリケーションでいえば、画面遷移のみを担当します。 Catalyst でスキーマローダーをつかって、MyApp::Model::XXXX を自動生成してしまうと、「テーブル：モデル＝１：１」という COBOL 全盛期みたいなアーキテクチャになってしまいます・・。それで、仕方なくロジックを C に書くようにすると、C が見るも無残なほど膨れ上がってしまい、メンテナンスの困難な製品ができあがります（笑）。Rails や Catalyst でも、こういう作り方を推奨している雰囲気があります。 「テーブル：モデル＝１：１」が許されるのは、Rails や Catalyst で本当に小さいアプリケーションを作るときまでで、多少大きいアプリケーションを作ろうと思ったら、MyApp::Model::XXXX を自動生成するなら、M
DBのデータ削除について - wwolf.web.fc2.com
DBのデータ削除について最終更新:2010.01.01 物理削除と論理削除 物理削除とは DELETE文を使用してテーブルからデータを完全に削除すること 論理削除とは テーブルに「削除フラグ」などのフィールドを作成しておき、削除処理時に削除フラグを立てて検索条件から外すことで仮想的にデータを亡き者として扱うこと 英語圏ではSoft Deleteと呼ばれるようだ 論理削除のメリット・デメリット メリット 誤操作でデータが削除された場合でも簡単にデータを復旧可能 デメリット 検索時にWHERE句にフラグの確認が必要になる為、SQLが若干複雑になる 削除処理をUPDATE文で行う為、何となく直感に反する（ある種のインピーダンスミスマッチ） レコードが増加し続ける為データベースのコストパフォーマンスを損なう恐れがある 削除フラグを考慮する分、DB設計が若干複雑になる データに個人情報が含まれる場合
ソーシャルゲームログ解析基盤のHadoop活用事例
6. 1 1,000 / AP APAP AP DB d fluentd fluentd mongos mongod(PRIMARY) DB config mongod(SECONDARY) DB fluentd mongos mongod(SECONDARY) config ReplicaSets & Sharding NFS 6 8. 8.5GB 1.4GB / ID Nov 1 23:59:59 hogehoge-ap1 hogehoge ADD_MONEY 12345 [BeforeMoney] 67979 [AfterMoney] 68024 [Money] 45 Nov 1 23:59:59 hogehoge-ap2 hogehoge CONSUME_POWER 12345 [BeforePower] 25 [AfterPower] 20 [ConsumePower] 5 8 10. M
VOYAGE GROUP エンジニアブログ : MySQL InnoDBでのネクストキーロックの落とし穴
2010年06月30日14:34 カテゴリDB MySQL InnoDBでのネクストキーロックの落とし穴 はじめまして、株式会社ECナビ システム本部 情報システムグループの三浦と申します。 私は主にデータベースの運用、管理を行っています。 ECナビでは様々なサービスを展開しています。そしてそれと同じ数と言っても良い程のデータベースが稼動しています。 リレーショナルデータベースがメインでサービスを支えていますが、それを補う形でキーバリューストア的なデータベースも多数存在しています。 メインで活躍しているリレーショナルデータベースは用途によりOracle、MySQL、Netezza等と多岐に渡っています。 今回はMySQL InnoDBで実装されているネクストキーロックの落とし穴をデッドロックと絡めて説明したいと思います。 評価環境のMySQLのバージョンは5.1.39、トランザクション分離
BKCon 2006 - にぽたん研究所
昨日は BKCon 2006 に行ってきた。 BK というのは「一般的にはバッドノウハウの事」なんですが、昨日のは、BKCon と言っても、かつて開催された Bad Knowhow Conference 2004 の続編とかではなく、"B"atara "K"esuma "Con"ference 2006 です。 ※正しくは横浜 Linux ユーザグループ主催の「第 65 回カーネル読書会」のテーマ "mixi.jp: Scaling Out With Open Source" です。 ちなみに、Batara Kesuma さんというのは、株式会社ミクシィの取締役。 mixi の裏側を見せますというか、ちょっと hip な言いかたをすれば "Inside mixi's backend" ってカンジです。 とりあえず、プレゼン内容は YAPC::Asia の時と大凡同じでしたが、プレゼンの持ち
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Health Insurance High Speed Internet Work from Home Healthy Weight Loss Best Penny Stocks Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
クリアネオの口コミって信じていい？効果は確実なの？ | 愛と小町
クリアネオの特徴 無添加・無着色だから肌が弱い人でも安心 ワキガや嫌な臭いの原因となる菌を殺菌・消毒 お得な定期コースは、購入縛りなし！いつでも解約可能 体臭の悩みは老若男女問わず共通の悩みですが、他人には相談しにくいので1人で悩んでいる人が多いんです。 体臭って、自分でニオイが気になった時は、他の人はもっとクサイと思っています。 もしあなたが、自分でワキガかも…と思うのであれば、周りの人はあなたのニオイに気づいているかも… クリアネオは、そんなワキガ臭や足のニオイなど、イヤーな体臭全般を10秒でカットしてくれるんです。 クリアネオの効果や口コミを調査しましたので徹底解説します。 購入時に特典が付いてくるのでお得 公式サイトはコチラ ※特典は毎月変わるので公式サイトでご確認ください クリアネオはどんな人におすすめ？ クリアネオの殺菌率は、なんと99.999%！体臭の悩みを解消してくれるクリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
