タグ

DBに関するfroakのブックマーク (16)

  • 【チラ裏】あなたは本当にそのデータストアが好きで使うんですか? - oranie's blog

    チラシの裏的な雑記です。 サービスに新しいデータストアを選ぶ際にこの辺を情熱を持って説明してくれる人が好き、という話です。 そのデータストアを使う理由はなんですか?みんなが使い慣れている物から変える理由は「有名な会社が使っていて^^」「他のチームが使っていて^^」とかではなくて、既存の物では解決出来ない問題を解決するアプローチになっていますか? もし単純にキャッチアップしておきたいというレベルなら、あなたの趣味で作るシステムで運用する、では欲求を満たせませんか? 同じようなプロダクトは他にもあると思いますが、そのプロダクトで無ければいけない理由はなんですか? まだ新しいプロダクトだった場合、あなたはそのコードを読んで、バグを報告して、必要であればパッチを書く覚悟を持っていますか? あなたはチーム内でそのプロダクトの第一人者になる、という覚悟がありますか?他のメンバーへの啓蒙や情報共有を率先

    【チラ裏】あなたは本当にそのデータストアが好きで使うんですか? - oranie's blog
    froak
    froak 2013/04/25
  • [Rails3] ActiveReocrdで外部DBを使う

    Railsでは基的に1つのDBを使用するように設計されています。デフォルトで使用するDBは config/database.yml 内で、実行モード(Rails_Env:development/test/production)別にDBが指定されていますが、これらのデフォルトのDB以外のDBに接続するやり方です。 用途としては例えば、他のシステムで使用しているユーザテーブルを参照する(いわゆるレガシーDBというやつですね)、アクセスログデータを別のサーバ上に保管する、などといった場合があるでしょう。 ここで想定する外部DB/テーブルの条件使用しているデータベースのアダプタがある MySQL, PostgreSQL, SQLite3, Oracle, DB2, SQL Server, ... 使用するテーブルに、整数型の単独の主キーが存在する Railsアプリケーションのサーバからアクセスが

    froak
    froak 2012/12/01
  • DBサーバーの負荷分散

    MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する

  • キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると

    2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster(以下、Oracle RAC)でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか? 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ

    キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると
  • まるで魔法のようなストレージエンジン??VP for MySQLによる驚愕のテーブル操作テクニック。

    先日、SPIDERストレージエンジンについて2度に渡りブログで紹介した(その1:Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン、その2:快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう!)が、SPIDERの作者である斯波氏は、実はもう一つ驚くべきストレージエンジンを開発している。その名も、VPストレージエンジンだ。ちょっと地味な名前だが、VPとは、Vertical Partitioning(垂直パーティショニング)の略で、複数のテーブルの上にVPストレージエンジンを被せて、垂直パーティショニング(カラムごとにデータを格納する領域を分ける)を実現するというものだ。他のテーブルの上に被せるアーキテクチャをとっているという点では、VPとSPIDERの発想は同じである。以下は、VPストレージエンジンの動作

    まるで魔法のようなストレージエンジン??VP for MySQLによる驚愕のテーブル操作テクニック。
    froak
    froak 2010/04/21
  • MySQLコミュニティ騒然!MySQL 5.5.4が与えるインパクト。

    先週、MySQL Conference & Expo 2010が開催され、盛況のうちに終了した。カンファレンスに合わせる形で、MySQL 5.5.3および5.5.4がリリースされたのだが、これが目を見張るような進化を遂げている。特に性能面での進化には目を見張るものがある!Jeremy ZawodnyやMark Calleghanといったコミュニティの重鎮たちも「非常にエキサイティングなリリースだ!」などと表して歓迎の意を表している。 というわけで、日はMySQL 5.5.3/5.5.4の新機能および変更点についてレビューしてみよう! おさらい。 〜 MySQL 5.5の既存の機能 〜MySQL 5.5が登場したとき、その新機能については以前にもエントリで紹介したが、ここで改めておさらいしてみよう。MySQL 5.5は、正確にいうと現在最新バージョンであるMySQL 5.1の「次の次」のバ

    MySQLコミュニティ騒然!MySQL 5.5.4が与えるインパクト。
  • Google App Engine上のベスト・プラクティス、その1: Datastore

    Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと(=頭を使うべきところ)は、データベースの設計である。特にリレーショナル・データベース(RDB)上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En

    froak
    froak 2010/02/08
  • DB設計の神ツール「ERMaster」なら、ここまでできる

    DB設計の神ツール「ERMaster」なら、ここまでできる:ユカイ、ツーカイ、カイハツ環境!(11)(1/3 ページ) 無料のEclipseプラグイン「ERMaster」とは データベースのテーブル設計を行うときに皆さんは、どのようにしているでしょうか? いくつかの無料で利用できるツールが提供されているので、筆者はそれらを利用していましたが、最近「ERMaster」と呼ばれるEclipseプラグインの存在を知りました。 ERMasterは、ほかのツールに比べ、直感的で分かりやすいUI(ユーザーインターフェイス)に、カスタマイズ可能な、Excelで出力できるテーブル定義書、辞書機能など痒いところに手が届くERモデリングのツールです。稿では、このERMasterについてご紹介します。 ERMasterの主な特徴、8つ ERMasterには、主に次のような特徴があります。 【1】直感的で使いや

    DB設計の神ツール「ERMaster」なら、ここまでできる
  • Oracleデータベースの深層(3)−BBEDでデータファイルをハッキング - /* Grid Thinking */

    今回利用するサンプルデータは最初からサンプルスキーマとして インストールしたHRスキーマのJOBSテーブルです。 ご覧の通り19件データが存在する。 sys@O11G2> select * from hr.jobs; JOB_ID JOB_TITLE MIN_SALARY MAX_SALARY ---------- ----------------------------------- ---------- ---------- AD_PRES President 20080 40000 AD_VP Administration Vice President 15000 30000 AD_ASST Administration Assistant 3000 6000 FI_MGR Finance Manager 8200 16000 FI_ACCOUNT Accountant 4200 9

    Oracleデータベースの深層(3)−BBEDでデータファイルをハッキング - /* Grid Thinking */
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    froak
    froak 2009/11/02
  • (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場

    InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近1秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー

    (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
    froak
    froak 2009/10/29
  • レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ

    MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台+1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う!」「ここがおかしい!」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基構成、方針 2台+1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ
  • 「Linux-DBシステム構築/運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか? - kazuhoのメモ置き場

    松信さんがやってくれました。 ずいぶん前からデータベースの「正しい」構築と運用方法についてまとめたはないかなーと思ってました。自分はこれまで、様々なネットワークアプリケーションのプログラミングやデータベースの設計、チューニングを行ってきています*1が、問題が解決できたようには見えても、果たしてそれが最適な解決策だったのか不安に感じることがありました。それは、体系的な知識に欠けているからです。だから、網羅的な教科書がほしいなぁって思ってたんです。 とあるインターネットでこの前、松信さんから「いま書いてる」って話を聞いて、一部を見せていただいたりしたんですが、つい昨日、手元に届きました。やったね☆ 名前は「Linux-DBシステム構築/運用入門」。「入門」と銘打たれているものの、基礎的な知識から、なぜそうなるのか、どう応用すればいいのか、といった点まで広くカバーしている*2、全方位的な隙のな

    「Linux-DBシステム構築/運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか? - kazuhoのメモ置き場
  • Silicon Soul » HadoopDBのアーキテクチャ

    ■HadoopDBのアーキテクチャについて HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads. Azza Abouzeid, Kamil Bajda-Pawlikowski, Daniel J. Abadi, Avi Silberschatz, Alex Rasin. In Proceedings of VLDB, 2009. より、 HadoopDBのアーキテクチャに関する章から、Hadoopに追加された4つのコンポーネントについて順に読んできます。 ▼Database Connector Database Connectorは、クラスタの各ノードにある個別のデータベースとTaskTrackerの間のインタフェースで、 HadoopのInputFo

    froak
    froak 2009/07/31
    HadoopDB
  • もう1つの、DBのかたち、分散Key-Valueストアとは

    もう1つの、DBのかたち、分散Key-Valueストアとは:分散Key-Valueストアの命「Bigtable」(1)(1/3 ページ) RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle MapGoogle Earth、Google Analytics、Goog

    もう1つの、DBのかたち、分散Key-Valueストアとは
    froak
    froak 2009/07/03
  • IT news, careers, business technology, reviews

    Heads on: Apple’s Vision Pro delivers a glimpse of the future

    IT news, careers, business technology, reviews
  • 1