タグ

ストレージに関するsh19910711のブックマーク (23)

  • 自宅に必要なRAIDと自宅では不要なRAID - treedown’s Report

    RAIDもかれこれいくつかの記事で話題に出してきましたが、今までの記事、 - 部長、そろそろRAIDで安心したくないですか? - treedown’s Report とか、 - 社長、サーバに投資する予算はありますか? - treedown’s Report といった記事で、実際のRAIDに対する考え方や使い方の一例をご紹介しました。 また「RAID5障害で最大の恐怖はバッドストライプ - treedown’s Report」でRAIDの障害(マイナーで分かりにくい)事例もご紹介しました。 これらは会社業務で利用する場合のRAIDの話です。 以前にも書きましたが、 世の中にはRAIDで安心は購入できたのに安全が購入できていないかった不幸な事例も数多くあります。 会社であればパートナー(取引先)や会社の先輩・上司などから指摘をもらえるかもしれませんが、個人やホームオフィスではそうもいきません

    自宅に必要なRAIDと自宅では不要なRAID - treedown’s Report
    sh19910711
    sh19910711 2024/03/06
    "世の中にはRAIDで安心は購入できたのに安全が購入できていないかった不幸な事例も数多く / テープは保存メディアとしていまでも魅力的 / HDDの故障タイミングは人間が決めることができない" 2015
  • Kubernetesで構築する大規模時系列データのスケーラブルな分散処理

    CloudNative Days Tokyo 2023 での登壇資料です

    Kubernetesで構築する大規模時系列データのスケーラブルな分散処理
    sh19910711
    sh19910711 2024/02/09
    "内製時系列データベース / 1年運用仕切れば1億円弱のコストを削減できる見込み / Delta Encode: 素のデータではなく、前レコード値との差分だけ保存 + Varintsと組み合わせることでデータの圧縮が見込める" / 2023
  • Introduction to Modern Analytical DB

    [db tech showcase Sapporo 2015] B16:ビッグデータには、なぜ列指向が有効なのか? by 日ヒューレット・パッカード株式...Insight Technology, Inc.

    Introduction to Modern Analytical DB
    sh19910711
    sh19910711 2022/02/11
    2012.11 / "Column-Stores vs. Raw-Stores [Dan08] / 性能差を起こす本質的な違いは何か > 列志向化によるI/O削減は本質的な理由ではなく、compression/late materialization/join optimization等のプラン最適化が性能向上の鍵"
  • "CRUD is dead"(死んだのは"U"と"D")と「RethinkDB」、もしくはAuroraの周辺話し - たなかこういちの開発ノート

    ときどき参加させていただいている「Scala勉強会」にて、OE氏(@OE_uia)より、ScalaDays 2015 in San Franciscoのレポートがありました。いろいろ話はあったわけですが、その中でひとつ気になったフレーズがありました。それは、 "CRUD is dead" です。 調べましたらTwitter上でこのような会話がされているのが見つかりました。"CRUD is dead"を唱えているのはJonas Bonér氏、Typesafe社の設立者の一人で現CTOです。会話の最後の方で、 "FP is nice. But this slide is about killing 'update-in-place'. Event logging is my primary tool." ※「FP」は「Functional Programming」です。 と述べています。「「更

    "CRUD is dead"(死んだのは"U"と"D")と「RethinkDB」、もしくはAuroraの周辺話し - たなかこういちの開発ノート
    sh19910711
    sh19910711 2021/06/06
    2015 / "Amazon Auroraが大々的にアナウンスされた、またSSDが十分に普及しSSD自体も進化しきった現在からこれらの記事を読むと、いろいろ思いが巡るとともに、Auroraを使いこなす観点においても背景理解が進みました"
  • ゲーム向けファイルシステムの設計の難しさ - .mjtの日記復帰計画

    ゲーム向けのファイルシステム抽象化は近年超クッソ激烈に複雑化しており、大分手を付けられない問題になってきた。 ゲーム配布/ストレージ様式の変化 ...とにかく歴史的に様々な方式が使用されている。例えば、ゲームを発売後パッチするにはHDDやSSDのようなFSを持った大容量ストレージが必要になるが、それが可能になったのは2001年以降(PS B.B. Unitやoriginal Xboxなどの登場以後)と言える。(サテラビュー('95)やDreamcast('98)のようなプラットフォームでもDLCの類は存在したがゲームの不具合修正をpost releaseで行う目的には使えなかった。) PS4ではプログレッシブダウンロード(ゲームを複数セグメントに分割し、一部のダウンロードが完了した段階で起動許可)をサポートしているが、導入自体はPS3版The Last of Usの方が早い( https:

    ゲーム向けファイルシステムの設計の難しさ - .mjtの日記復帰計画
    sh19910711
    sh19910711 2021/05/23
    "動画のようなストリーミングと異なり複雑なアクセスパターンを持つ / シークは非常に古典的だが現在も問題 > HDDにインストールされる可能性があるためよく使用されるデータはコピーしてでも近傍に配置"
  • データ記録用磁気テープが最近凄いことになっている件

    ひょんなことから磁気テープについて調べ始めたところ,大きな変化が起きていることがみえてきましたので紹介します. はじめに 一般的には磁気テープってなじみが薄いと思いますが,最近のものはいろいろ進化していて,優れた特徴を持っています. ストレージに関しては素人ですが,調べてみて目を引いた特長をあげると次のようになります. 継続する容量増加 HDD を上回る書き込み速度 高い信頼性 長期データ保持 使い勝手 これらを踏まえると,写真や動画データを多く扱う個人の方には,大容量 NAS を継ぎ足していくよりも優れたソリューションかも知れません. (ドライブは新品だと手が出る価格ではないのでヤフオクで調達のこと) 以降では,それぞれの特長について順に紹介します. [20年1月17追記] テープの性能向上を支える材料(BaFe磁性体)についてこちらに追記しましたので,合わせてご覧いただけると幸いです.

    データ記録用磁気テープが最近凄いことになっている件
    sh19910711
    sh19910711 2021/01/17
    "長期データ保持は昔から磁気テープの特徴でしたが、2010年代の初めに導入された磁性体の変更によってそれが強化 / メタルからバリウムフェライト(BaFe)に"
  • ストレージ重要

    以下動画のテキストです https://youtu.be/NLa53pX-8oM

    ストレージ重要
  • AWS の IOPS と I/O クレジットがよくわからなかったので整理した - stamemo

    最近 AWS を触り始めて、EBS を使っているのだが、どうも I/O 速度に制限がかかる仕様があるらしい。調べてみると IOPS やら I/O クレジットやらといった考え方が出てきた。ドキュメントを読んでもわかりづらかったので整理してみた。 そもそもの前提 最初に結論 I/O クレジットその1: 消費と補充のルール I/O クレジットその2: クレジットが枯渇したら I/O クレジットその3: IOPS には上限もある I/O クレジットその4: IOPS の I/O ってそもそも何? 参考 そもそもの前提 AWS のボリュームでは無尽蔵に I/O を発生させることはできず、AWS 側で帯域制限ならぬ I/O 制限が実施されている。 この制限が具体的にいつ、どのように、どれだけ働くのかという仕組みが I/O クレジット という考え方。この時に使う単位が IOPS(I/O per Seco

    AWS の IOPS と I/O クレジットがよくわからなかったので整理した - stamemo
  • Snapshot & Backup

    Azure Hybrid全体整理! ~ Azure Hybrid Dayに登場した要素 + αの関係性を整理! ~

    Snapshot & Backup
  • 高トランザクションシステムとしてのメールシステム

    [2019/05/27開催「IIJ Technical NIGHT vol.7」の講演資料です] ISP が運用するメールシステムでは極めて大きな流量のメールを処理しています。 セッションでは、メールシステムの“メール”という単語に囚われすぎることなく、汎用的な視点で大規模メールシステムの要件と特性を考察します。 また、この考察を踏まえて IIJ のメールシステムのアーキテクチャについて紹介します。 ▼講演者 ネットワーククラウド部 アプリケーションサービス部 サービス開発課 鈴木 高彦

    高トランザクションシステムとしてのメールシステム
  • [作業ログ]ESP8266でSDカードを読んでみる - Qiita

    ・目的 wifiでAPに接続する際、コードに接続情報を書きたくないので、SDカードから読み込ませる事にする。 ESP8266は3.3Vなので、SDのDIP化カードを使うとき、レベル変換しなくてよいので、ハードに疎い人間にとってはとても便利。 ・準備 1.SDカード とりあえず、読み込ませるSDカードのrootディレクトリ直下に「HOGE.TXT」というテキストファイルをつくって適当な文字列を何行か記述した。 ※たぶん、ファイル名が長かったり、日語がはいってたりすると、FAT16で読んだ時みたく、ニョロになるので全角文字列のない短い名前の大文字のファイル名とした。 ※ファイルの中身は、シリアルで出すので、とりあえずは、全角文字を混入しないものとした。 ※念のため、持ってるSDカードで一番容量が少ないmicroSDの4Gを使用した。 (多分、3DSについてたやつ。。。) ディレクトリ。 中身

    [作業ログ]ESP8266でSDカードを読んでみる - Qiita
  • Datadog でストレージがあと何ヶ月で枯渇するかを予測する - Qiita

    概要 Datadog に追加された linear regression functions (線形回帰関数) を利用して、DB などのストレージがあと何ヶ月で枯渇するかを予測するという話。 背景 ストレージに対する監視として、使用率が X% を超えたらアラートを出す、というのがオーソドックスなもの。例えば Increments では AWS の推奨閾値である 85 % (出典は関連資料項目を参照) を超えたら Slack に通知が来るようにしている。 しかし、使用率が 85% に達した時、残り 15% をどれくらいの期間で消費するかは実はさまざまなケースがある。緩やかにストレージを消費し、残り 3 ヶ月で消費するケースもあれば、残り 1 週間で消費するケースもあるだろう。残り 1 週間で枯渇するケースの場合、対応が慌ただしくなってしまうかもしれない。 そこで、現在の使用量に対する閾値監視だ

    Datadog でストレージがあと何ヶ月で枯渇するかを予測する - Qiita
  • ESP8266 + microSD > ユニバーサル基板実装 / SDへ書込みしてみた - Qiita

    ESP8266用基板を新たに実装した。ESP8266基板は7枚目。 microSDの基板は以下を購入した。 sunhayato CK-40 税込み602円 @ デジット microSD関連については上記のリンクの配線をそれぞれ対応するESP8266のピンに実装(VDD, CLK, DAT0, VMD, VSS, CD)。 CK-40は1番ピンから8番ピンまでをストレートピンヘッダの長い方にはんだ付けし、反対の短いピンをユニバーサル基板に実装した。 フレームグラウンド関連のピンはとりあえずストレートピンヘッダにはんだ付けしたが、ESP8266には特別接続していない。 code v0.1 参考 https://www.arduino.cc/en/Tutorial/ReadWrite 上記を参考に以下を実装した。 #include <SPI.h> #include <SD.h> // SD pi

    ESP8266 + microSD > ユニバーサル基板実装 / SDへ書込みしてみた - Qiita
  • ストレージ関係のツールとか眺めてた • masu-mi's blog(dirty pages)

    最近はデータ保存の観点で調べてみたり考えてみたりする事が増えてきた。 Storage Weeklyで出てきたデータ保持・配信系ミドルウェアやツールを中心に調べてみた。 ストレージ・データベース・オーケストレーション・コンフィギュレーションは網羅的に探したくなるので今度に回す。 BlockChainもストレージやコンテンツ配信系に意外と応用されていたけど、アルゴリズムから押さえたいので勉強してから別途まとめる。 ユーザーデータは、4K・全天球画像・3Dモデルみたいに巨大化する方向とセンシングデータみたいに大量な小さい時系列データの方向が特に増加すると思ってる。 システムデータは今まで通り、リポジトリ・ログ・メトリクス・コンテンツ配信・アーカイブが主軸だけれど、 リポジトリはマシンイメージ・Dockerイメージ・DCOSパッケージが増えていきそう。またコンテンツ配信で学習モデルも加わる気がする

  • MogileFSをバックエンドとしたPrivate S3の作り方

    Java クライント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)Kazuya Sugimoto

    MogileFSをバックエンドとしたPrivate S3の作り方
  • RubyとAWSでつくるメディアストレージ基盤 - Qiita

    概要 基盤の果たす役割としては、「利用者が基盤に向けてファイルをアップロードし、なんらかの(変換を含む)処理を行って利用サービス側に通知する」というものになる。 そこで、想定する利用イメージを大まかにでも理解してもらうため、抽象的なイメージを図示する。 ファイルをアップロードしたいユーザーは、まず基盤の利用サービスに対してアップロード権限の発行を依頼する。 図では省略したものの、利用サービス側はその依頼を受けて、基盤に対してアップロードチケットの発行を依頼し、取得した情報をアップロードしたいユーザーに対して返す。 アップロードユーザーはそれを受けて、基盤に対してファイルのアップロードを行い、アップロード・バリデーション・変換が済んだものについては基盤が利用サービスに結果を通知するというのが大まかな流れとなる。 次に、基盤の持つ責務について簡単に解説したい。 基盤は、メディア

    RubyとAWSでつくるメディアストレージ基盤 - Qiita
  • 勘違いしないようにしたい、Amazon Glacierのデメリットあれこれ | Pieces of Peace

    1GBが約1円/月のAmazon Glacierへ簡単にバックアップ&同期できるフリーソフト「FastGlacier」 – GIGAZINE 先日GIGAZINEでこんな記事が公開されてました。反応を見ていると「写真の保管に使えそう」「消せないファイル置き場にいいね」などと皆さんの印象はよさそうですが、実はこれ、「転んでも泣かない方」専用です1。 注意喚起として、転びそうなポイントを挙げておきます。 ダウンロードは二重の「有料制」 公式サイトによると、データをダウンロードするにはデータ取り出し料とデータ転送料の2種類の費用を払う必要があります。 前者は無料範囲を越えると0.01USドル~/GB、後者は~0.12USドル/GBということで、例えば100GBのアップロード済みデータを全てダウンロードすると 一ヶ月かけてゆっくりダウンロードする 12.83USドル 回線速度が許す限り急いでダウン

  • AWSマイスターシリーズReloaded -Amazon Glacier-

    AWS Black Belt Techシリーズ Amazon Elastic Compute Cloud (Amazon EC2)Amazon Web Services Japan

    AWSマイスターシリーズReloaded -Amazon Glacier-
  • Amazon Glacier と AWS CLI 1.0 で格安バックアップ環境を作る - ほとラボ

    Amazon Glacier 使ってバックアップ環境つくりたいなー でも rsync 的な使い方したいけどどうやってやったらいいかわからないなー と思っていたら、先日 AWS CLI 1.0 がリリースされて新しくsyncコマンドが使えるようになったので、これはチャンスと思い手を出してみた次第。 AWSまわりを軽く説明 知ってる人は読まなくていいです。 Amazon S3 Amazonのクラウドストレージ。 Dropboxのバックエンドなんかにも使われている、Web開発者にはお馴染みのアレ。 特筆すべきは 99.999999999%(イレブン・ナイン) の堅牢性。 なんだかよくわからないけどめっちゃ9が並んでるから多分すごい(小並感 Amazon Glacier 同じく、Amazonのクラウドストレージ。 価格が 1GBあたり1円/月(S3の約10分の1) とかなり安いが、データをダウンロ

    Amazon Glacier と AWS CLI 1.0 で格安バックアップ環境を作る - ほとラボ
  • ややこしすぎるAmazon Glacierのデータダウンロード料金まとめ | Pieces of Peace

    まだまだ続くGlacierネタ、もうしばらくお付き合いくださいまし。 1GB/1セント/月の料金で個人向けバックアップサービスとしても注目のAmazon Glacierですが、その安さの仕組みゆえか、ややこしいのが料金体系。 特にデータダウンロードの方は料金表を見てるだけではいくらかかるかまったく分からない複雑さで、FAQを読み解いてようやく理解しかけてきたところ。せっかくなのでまとめておきます。 時間がない方向け:公式の計算機を使いましょう Amazon Web Services Simple Monthly Calculator 身も蓋もないですが、金額を把握したいだけならそれが一番手っ取り早いです。計算しとけばあとで驚く心配なし。 ↑200GB保管、50GBを1日でダウンロードの例。 では次に、データダウンロード料金計算の仕組みを知りたい方向けに、実際に料金体系を分解してみます。 デ