タグ

データベースに関するasmblrのブックマーク (6)

  • メディア芸術データベース

    「メディア芸術データベース(開発版)」にアクセスいただきありがとうございます。 2017年3月31日より、「メディア芸術データベース(開発版)」のURLを変更いたしました。 ブックマーク(お気に入り)に旧サイトを登録されている場合は、 新サイト(https://mediaarts-db.bunka.go.jp)へ変更をお願いいたします。 10秒後に自動的に新サイト(https://mediaarts-db.bunka.go.jp)に移動します。 Thank you for accessing the Media Art Database (Development Version). On March 31 2017, the URL for the Media Art Database (Development Version) changed. In ten seconds, you w

    メディア芸術データベース
  • スクレイピングするなら ScraperWiki 使うといいよ - ヤルキデナイズドだった

    Web ページからデータを抽出してデータベースに突っ込むことに性的興奮を覚えるみなさん、 ScraperWiki 使うとキモチイイですよ。以上です。 そうではないみなさんには少々の説明が必要かと思いますので少々書きます。 ScraperWiki はスクレーパ(Web ページをスクレイピングするスクリプト)とスクレイピングで得られたデータを共有しようぜっという Web サービスです。Wiki と名が付いていますが Wiki っぽいページ構成になってるわけではなく、スクレーパやデータを誰でも編集できるようにして成果を共有するという理念が Wiki と共通しているのが由来みたいです。 ScraperWiki を使うとスクレーパを作るのがラクになります: Web ベースのエディタでスクレーパを書き、その場で実行できる PHPPython または Ruby が使える(HTML パーサなどのモジュ

    スクレイピングするなら ScraperWiki 使うといいよ - ヤルキデナイズドだった
  • スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance

    これを書こうと思ったキッカケは、奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」っていう、最近モヤモヤと感じていたことをうまく説明してくれてる記事をみたこと。 年始からちょくちょくサーバの運用環境を物色しながら考えていたことと見事にシンクロした。だいたいの要旨はTwitterのほうでも書いたのだけれど。 ムーアの法則でどんどん向上する技術にくらべ、人間のキャパシティは変化しない定数項として考えていい。だとすれば、そうやって向上する性能を、人間の労力を削減する方向で使えてはじめて、「技術が競争優位性を生む」といえるだけの破壊的な価値がでてくるということになる。 では、現在の技術トレンドを活用することで減らせる「人間の労力」とは何か。 それは、過去10年あまりで定着した、これまでの(そして今なお)Webアプリケーションの定番構成である、「ロードバランサ、ア

    スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance
  • High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ | warikiru

    2009-11-24 High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ ラベル: performance CSS Nite in ISHIKAWAで話をしてから1ヶ月経ったので、薄れゆく記憶の復習も兼ねて思いの丈を綴ってみたw High Performance Web Design 1. What's High Performance?ここでいうパフォーマンスというのはWebサイトの表示高速化についてです。つまり、ページをいかに早く表示させるかという課題です。でも、そうゆうのってサーバー側の問題でしょ?システムエンジニアの管轄じゃないの?と思われがちですが「ハイパフォーマンスWebサイト」の著者であるSteve Soudersの調査によると、80:20。一般的にユーザーの待ち時間の実に80%がブラウザ側、フロントエンドで費やされて

  • レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ

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

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ
  • データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ

    データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 OracleSQLServer、MySQLと色々なDBのチューニングをしてきましたが、

    データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
  • 1