[B! db][storage] lepton9のブックマーク

lepton9 id:lepton9

dbとstorageに関するlepton9のブックマーク (9)

Amazon DynamoDB の論文を読んでいく - Qiita
概要 AWS で人気のサービス DynamoDB についての論文が公表され巷で噂になっていたと思う。今回は、その論文を読み込んでいき、ざっくりまとめていくという記事になります。完全趣味な記事なので、興味ある人がいれば幸いです笑 Abstract まず論文のタイトルですが、「Amazon DynamoDB: A Scala ble, Predictably Performant, and Fully Managed NoSQL Database Service」と題したものとなっています。 Amazon DynamoDB は、NoSQL とよばれる部類のデータベースサービスです。一貫した耐久性、可用性、パフォーマンスを提供してくれるマネージドなサービスなのが特徴ですね。冒頭、2021年に66時間にわたる「Amazon Prime Day」中にピーク時8920万リクエスト/秒をさばいてい
lepton9 2022/12/13
aws

db

storage
リンク
Cloud Native時代のデータベース
2021/6/11 #InfraStudy 2nd Season
lepton9 2021/06/12
db

cloud

storage
リンク
理屈で考える、データベースのチューニング / Database tuning How-To
Oracle データベースの内部構造に着目して、さらなるチューニングを行うために必要な基礎知識をまとめた資料です。
lepton9 2020/10/03
performance

db

storage
リンク
理屈で考える、データベースのチューニング | Raccoon Tech Blog [株式会社ラクーンホールディングス技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。パフォーマンス勉強会OracleデータベースMySQLInnoDB こんにちは、羽山です。今回はOracleデータベースのチューニングで少し踏み込んだ内容です。途中で比較対象としてMySQLも登場します。日頃からSQLチューニングの機会があってそれなりに得意としているのに、それでもなぜかパフォーマンスがでないSQLに悩んだ経験はありませんか？謎の遅い現象は特に大規模データベースになってくると発生しがちなのですが、速い場合も遅い場合も必ず理由があります。そこで本記事ではデータベースのチューニングにおいて意外と見落とされがちなローレベルな部分に着目して、さらに一歩上のパフォーマンスチューニングに必要な知識を解説します。この記事を書くきっかけとなったのは私た
lepton9 2020/10/03
db

performance

storage
リンク
[和訳] Dropboxアカウントのせいで胃潰瘍になった - Qiita
こちらのReddit投稿 (https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_account_gave_me_stomach_ulcers/) の和訳記事です。本番環境でやらかしかった人シリーズが盛り上がっていたので波に乗って（？）Twitterにヤバすぎる恐ろしい話が流れてきたのをすかさず和訳してみました。やらかしちゃった人というよりはやらかされちゃった人目線ですがいずれにせよそこら辺の怪談話よりよっぽど怖いです。 Dropboxのアカウントのせいで胃潰瘍になった。皆は誰もが触れたがらない、会社を靴紐やガムやクリップでつなぎとめている「例のアレ」を見つけたことってある？そういうのって往々にして大型連休前の金曜午後4:45に落ちるし、般若のような様相を呈した上司が「このままだと第二のスターリングラード攻防戦が勃発するぞ
lepton9 2019/12/16
trouble

storage

db

neta

work
リンク
PostgreSQLで各テーブルの総サイズと平均サイズを知る - Qiita
DBを使っている時、どのテーブルがどのくらい容量を食っているか知りたいことがあると思う。また今後のサイズ増加を見積もりたいとき、あるテーブルの1行あたりの平均バイトサイズも知りたいはず！ PostgreSQLで見るべきところ pg_classのテーブルの relpagesがブロック数 reltuplesが行数を表すらしい。これらは実際にはプランナが用いる推測値。ANALYZEコマンドを打つとこれらの統計情報が更新されるので、ANALYZE直後にやるほうが正確。まぁ大抵、概算が知りたいだけなのであまり気にする必要ないかもしれないが。ブロックサイズは8K(SHOW block_size;で確認可能)なので relpages / 128Mbytesのサイズを占領しているということ。平均サイズは、バイト数で知りたいのでrelpages * 8192 / reltuplesすれば良い。0割
lepton9 2019/02/05
db

storage
リンク
MySQLのストレージエンジンを自作してみる - 備忘録の裏のチラシ
MySQL のストレージエンジン（SE）を自作してみたときのメモ。バージョンは 8.0.13。アーキテクチャをざっくりと掴むことが目的なので、ストレージエンジンの自作といっても非常に単純な操作しかできないものです。 RDB らしさとも言えるインデックスや行レベルロック、トランザクションなどの高度な処理は実装せず、簡単に入出力の流れを追っていきます。ゴールは以下の基本的な機能を実現して、「あ、こんなもんなんだ〜」感を覚えることです。 CREATE 文でテーブルの作成 INSERT 文で行の挿入 SELECT 文で行の取得ちなみに MySQL のコードは C/C++ です。（といっても、テンプレート等の C++ らしい拡張的な機能は使われておらず、ほぼ C で書かれています。クラスは頻繁に使われているので、俗に「クラスのあるC」なんて言われている模様。そのため、C をある程度理解していれ
lepton9 2019/01/09
db

storage
リンク
「Hadoopの時代は終わった」の意味を正しく理解する - 科学と非科学の迷宮
Hadoopの時代は終わった、という言説をたまに見かけるようになりました。もちろん終わってなどいません。しかし、Hadoopとその取り巻く環境が変化したのは事実です。本記事では、この変化が何なのかを明らかにし、その上で、なぜHadoopの時代は終わったという主張が実態を正しく表していないのかを説明していきます。 DISCLAIMER 私はHadoopを中心としたデータ基盤を取り扱うベンダー、Clouderaの社員です。中立的に書くよう努めますが、所属組織によって発生するバイアスの完全な排除を保証することはできません。以上をご了承の上、読み進めてください。要約データ基盤は、Hadoopの登場により非常に安価となり、今まででは不可能だった大量のデータを取り扱えるようになりました。 Hadoopは、NoSQLブームの中、処理エンジンであるMapReduceとストレージであるHDFSが
lepton9 2017/07/10
db

storage

oss
リンク
データブロックサイズの変更と分析系クエリへの性能影響（SSD編）
PostgreSQL Advent Calendar 2012（全部俺）のDay 22です。最近、PostgreSQL上でデータ分析処理をよく行うようになってきました。また、いろいろなところでSSDも使うようになってきました。 PostgreSQLとデータ分析とSSD、という組合せを考えた時、どのようにチューニングするのが望ましいのか、あるいはどのようなチューニングができるのか、個人的にはまだまだ試行錯誤中だったりします。 SSDはハードディスクと比べてブロックサイズが大きいという特徴があります。また、DWH系のデータベースでは大きいブロックサイズを使うとパフォーマンス上のメリットがある、と言われています。今回は、SSD上でPostgreSQLを使ってデータ分析系の処理を行う時に、データブロックのサイズを変えるとクエリのパフォーマンスにどのような影響を与えるのか、実際にクエリを実行しな
lepton9 2014/04/24
db

performance

storage
リンク
1