タグ

dbとarchitectureに関するyukimori_726のブックマーク (11)

  • 情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ

    情報処理学会インターネットと運用技術研究会が主催されているIOTS2016という研究会で、「サーバモニタリング向け時系列データベースの探究」というタイトルで招待講演をしてきました。 講演のきっかけ インターネットと運用技術研究会(以下IOT研究会)というのは僕にとっては id:matsumoto_r さんが所属されている研究会です。 matsumotoryさんが、ちょうど2年前のアドベントカレンダーで書いた僕の記事に日語だとIPSJのIOTは分野的にもインターネットの運用技術が含まれるので興味深い論文が沢山あると思う とコメントしていただいたのが最初に研究会の存在を知るきっかけだったと思います。 そのときはそんなものもあるのかと思ってちょっとプログラムを眺めた程度でした。 しかし、まさかその2年後にこうして招待していただくことになるとはもちろん思っていませんでした。 id:MIZZYさん

    情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ
  • FastContainerアーキテクチャ構想 - 人間とウェブの未来

    追記:この記事へのコメントとして、この記事以上に内容の趣旨を端的かつ完璧に表しているコメントがありましたので、まずはそれを紹介しつつ、引き続き呼んで頂けると幸いです。 FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる by takahashim FastContainerアーキテクチャ構想 - 人間とウェブの未来 FaaS的だけど「アプリ側の構成も基盤側に合わせて変えるべき」路線なFaaSに対し「アプリは従来のままでもちゃんと動くよう基盤側が頑張るべき」という基盤側の矜持を感じる2016/11/13 18:25 b.hatena.ne.jp 素晴らしいまとめの一言です。それがまさに構想に至った意図でございます。僕もこんな趣旨をかけるようになりたいです。上記の的確なコメン

    FastContainerアーキテクチャ構想 - 人間とウェブの未来
  • Firebaseを使ったサーバーレスWebアプリケーション開発 (ServerlessConfセッション紹介) - yoshidashingo

    セクションナイン の 吉田真吾(@yoshidashingo)です。 第3弾はフロントエンド開発者であるきはるさんです。 プロフィール 名前:佐々木季羽る Kiharu Sasaki 会社名:freelance, Section-9 職種:Frontend Developer SIerで通信系システムの開発に携わった後、コンサルティング会社にて金融系エンタープライズシステムを担当。フリーランスとして独立後は、Webアプリケーション開発を中心に活動中。流しのフロントエンドエンジニア。Section-9メンバー。 Quick Chat ---- ServerlessConf Tokyoでのセッション概要を教えてください Firebaseは、Googleが提供しているバックエンドサービスです。 アプリケーションに必要なサーバー、DBの構築や運用が不要なのはもちろん、データに連動してREST AP

    Firebaseを使ったサーバーレスWebアプリケーション開発 (ServerlessConfセッション紹介) - yoshidashingo
  • UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた

    Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス

    UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた
  • 参照系と更新系の非対称性について、追補 - たなかこういちの開発ノート

    以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは? ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源(=オブジェクト)に関わることであっても、別々の“モデル”として捉えよう、というのがサブジェクト指向の一つの意図です。例えば、「受注」という同じデータ(≒管理対象)に関わることでも、「注文受付オペレーター」観点の“モデル”と「販売管理担当」観点の“モデル”とでは、要求仕様のセットが異なるし、その後の仕様変更の発生タイミングや頻度も異なるでしょう。そういった状況においては、「受注」サブドメインに関わる全ての要求を一つの集約やエンティティに全て載せてしまうと、いわゆるファット・モデルとなり、当初段階はなんとかやり遂げたとしても、その後の仕様変更の度に、当初開発段階に近い苦労を都

    参照系と更新系の非対称性について、追補 - たなかこういちの開発ノート
  • Implementing a Key-Value Store – Part 3: Comparative Analysis of the Architectures of Kyoto Cabinet and LevelDB | Code Capsule

    Implementing a Key-Value Store – Part 3: Comparative Analysis of the Architectures of Kyoto Cabinet and LevelDB Published by Emmanuel Goossaert on December 30, 2012 This is Part 3 of the IKVS series, “Implementing a Key-Value Store”. You can also check the Table of Contents for other parts. In this article, I will walk through the architectures of Kyoto Cabinet and LevelDB, component by component.

    Implementing a Key-Value Store – Part 3: Comparative Analysis of the Architectures of Kyoto Cabinet and LevelDB | Code Capsule
  • KoaでWeb開発: Koaの検証を通じてミドルウェアの概念を理解する - Qiita

    はじめに 動機 やっすいサーバでしかしパフォーマンスは出て、しかも大量のリクエストが来ても大丈夫なサービスを立ち上げたい。。。 そんなわがまま放題な欲求を満たすためにはやはりnode.jsで動作するアプリケーションがいいんじゃないのか、と思ったのです。 しかし、非同期とか超苦手だし・・・と思っていたところに、このKoaというフレームワークが来たわけです。 これまで、何回にもわたって、ES2015の話題を出してきたのは、ひとえにこいつを使うためでした。 ミドルウェア? しかし、Koaの説明の中で、頻繁に「ミドルウェア」というキーワードが出てきます。 自分のこれまでの認識だと、「DB」とか「Apache」とかのを表しているのかと思いましたが、どうも違いそうだと。。。 で、検索してもミドルウェアという言葉の意味がわかっている前提で述べられているものばかり。。。 こいつを自分の中で理解できないかぎ

    KoaでWeb開発: Koaの検証を通じてミドルウェアの概念を理解する - Qiita
  • 強固なデータ・インフラストラクチャを構築するためのログの活用(デュアル書き込みがダメな理由)PART 2 | POSTD

    PART 1.はこちら : 強固なデータ・インフラストラクチャを構築するためのログの活用(デュアル書き込みがダメな理由)PART 1. ログが使われる場面について4つ説明したいと思います。まずデータベースストレージエンジンの内部です。 B-tree はアルゴリズムの授業で学びましたよね? ストレージエンジンに広く使われているデータ構造です。ほぼ全てのリレーショナルデータベースと、多くの非リレーショナルデータベースで使われています。 B-treeについて簡単に説明しましょう。B-treeは、ディスク上で固定長のブロックとなる ページ から構成されており、通常、その固定長は4KBか8KBです。ある特定のキーを探したい時は、まずtreeのルートにあるページから探索を始めます。そのページは他のページへのポインタを内包していて、各ポインタはキーのレンジ(範囲)にタグ付けられています。例えば、もしキー

    強固なデータ・インフラストラクチャを構築するためのログの活用(デュアル書き込みがダメな理由)PART 2 | POSTD
  • Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

    先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

    Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
  • リアルタイムとバッチの違い - kuenishi's blog

    昨日、分散DB読書会のあとに品川のラーメン屋でリアルタイムとは何ぞや〜みたいな話になった。自分の思いついたポエムをここに書いておこう。現場の問題とはあまり関係がない。 Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)というによれば、DSMS (Data Steram Management System) とDBMS (Database Management System)の違いは、クエリを発行するデータ集合の性質にある。つまり、DBMSは今ある有限のデータに対して操作を行うための仕組みで、DSMSはこれからやってくる無限のデータに対して操作を行うための仕組みと定義されていた。このDSMSというやつは、古式ゆかしいストリーム処理システムのことで、まあいわゆるCEP

    リアルタイムとバッチの違い - kuenishi's blog
  • シングルマスタ/マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場

    システム全体で必要な書き込みパフォーマンスが、RDBMSノード1基の IOPS の W% の場合、シングルマスタ+スレーブn台構成のシステム全体のパフォーマンスは、 書き込みパフォーマンス: W 読み込みパフォーマンス: R=(1-w)*(n+1) になる。この n=R/(1-w)-1 って w が増加するとスレーブ増設のメリットが加速度的に失われていく点がイヤ。 例えば、システム全体で要求される書き込みパフォーマンスが W=0.3 で、読み込みパフォーマンスが 3 ならば、シングルマスタ/マルチスレーブ構成で必要なノード数は5台。マルチマスタ構成を採った場合でも理想値は4台なので、そう遜色があるわけではない。 しかし、仮に必要なパフォーマンスが2倍 (W=0.6, R=6) になると、必要ノード数はマルチマスタ構成での8台に対し、シングルマスタ/マルチスレーブ構成では16台と、一気にコス

    シングルマスタ/マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場
  • 1