DMMプラットフォームにおけるTiDBの導入から運用までTiDB User Day 2024の登壇資料です。
入門 B-link tree
概要 DBMS で広く利用されている B+ tree には様々な variant が存在するが、B-link tree もその1つ。 シンプルなラッチプロトコルで並行アクセスをさばけるよう、リーフノード以外のノードにも右の隣接ノードへのポインタを持たせた構造となっており、PostgreSQL で使われていることでも有名。 この記事では主にこの B-link tree に焦点を当てる。 B+ tree 全般やその他インデックス技術自体に興味がある場合は「最強DB講義 #10 いまどきのデータベース索引技術（石川佳治 教授）」の講義資料を読むのがおすすめ。 B-link tree 理解する上で必須な知識「ラッチ」 「ラッチ」というのはいわゆるロックのことだが、DB においては「ロック」というとトランザクション分離のための高価な(数千CPUサイクルを要する)処理を指すことが多く、「ラッチ」という
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering
※こちらは先日実施された DeNA インフラエンジニア / SRE MEETUP で話した内容を Blog 記事化したものです！ こんにちは！IT基盤部の熊谷です。IT基盤部にて大規模ゲームのインフラを見ている 新卒２年目のインフラエンジニアです。この記事では “DeNA でのデータベース運用とそのツラミ” と、“TiDB導入への検証・検討” をご紹介させていただきます。 データベースの最適解 DeNA のデータベース構成は最適解を求めて改良を積み重ねてきました。最初期の構成、(便宜上、第１世代と呼びます) では VM Instance 上に MySQL を構築し管理する MySQL on EC2 構成。続く第２世代では、マネージドサービスを駆使した Aurora MySQL 構成。この２世代の中で生じた “ツラミ” を解消する次の世代、言わば 第３世代に該当する新しいデータベース構成を現
![次世代データベース TiDB の検証とその評価 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/a7a9ef2e383cbfc8885ee9e5572b0b143267e771/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F01%2Finfra-meetup-tidb%2Fcover.png)
Write-Ahead Log
Write-Ahead Log Provide durability guarantee without the storage data structures to be flushed to disk, by persisting every state change as a command to the append only log. aka: Commit Log Problem Strong durability guarantee is needed even in the case of the server machines storing data failing. Once a server agrees to perform an action, it should do so even if it fails and restarts losing all of
Write-Ahead Logging
1. Overview The default method by which SQLite implements atomic commit and rollback is a rollback journal. Beginning with version 3.7.0 (2010-07-21), a new "Write-Ahead Log" option (hereafter referred to as "WAL") is available. There are advantages and disadvantages to using WAL instead of a rollback journal. Advantages include: WAL is significantly faster in most scenarios. WAL provides more con
CockroachDB から覗く形式手法の世界 #JTF2021w / July Tech Festa 2021 winter
July Tech Festa 2021 winter で使用したスライドです。 バグのない分散システムの設計は果たして可能でしょうか？ この問いに対する一つの答えとして、CockroachDB では形式手法ツール TLA+ を用いて分散トランザクションの正しさを担保しています。 形式手法はシステムの挙動を数学的に解析する技法で、「ノードが特定のタイミングで故障した場合にのみ発生するバグ」といった再現困難な問題を確実に検出することができます。 本講演では、CockroachDB の事例を通して、形式手法が実世界で活用されている様子をお伝えします。 イベント概要：https://techfesta.connpass.com/event/193966/ ブログ記事：https://ccvanishing.hateblo.jp/entry/2021/01/24/185819 録画：https:/
「よろしい。ではDBも内製だ」 IIJのインシデント調査システムが内製すぎる件
IIJ Technical NIGHTは、2020年9月11日にオンラインで開催した技術勉強会です。ここで熊坂氏が、SOC（Security Operation Center）のアナリストを支援するインシデント調査システム「CHAGE（チャゲ）」を社内で開発した理由と、その実装について紹介しました。 IIJのインシデント調査システム 熊坂駿吾氏（以下、熊坂）：IIJの熊坂から、社内で作成しているインシデント調査システムに関して紹介いたします。「インシデント調査システムが内製すぎる件」というところで、IIJの中で作成しているCHAGE（チャゲ）を紹介します。 まず私は2015年にIIJに新卒入社しまして、2018年度からSOCで業務を行っています。アナリスト的なことは詳しくやっていなくて、どちらかというとアナリストたちが業務を行うための環境の整備をしています。 具体的には、Windowsのメ
NewSQL 2020年前半のリリースを振り返る - Qiita
上表の「特徴的な追加/改善内容」の列を見てもらうと分かる通り、下記3つのポイントが機能改善の傾向として共通している（なお、YugabyteDBは2020年2月に2.1をリリース済で2.2の差分が小さい）。 OLAP向け機能の強化（カラムナストア、ベクター化実行） 悲観的ロックのサポート バックアップとリカバリの機能強化 それぞれがどんな意図を持って追加されたのか、次節以降で私なりに解説をしていく。 1. OLAP向け機能強化 このテーマについて議論する前に一つ触れるべきなのは、 「NewSQLは分析系クエリ、つまりOLAP処理に適しているのか？」 という疑問である。 個人的にこれに回答するならば、現時点では"No"となる。 シンプルな言い方をすればRedshiftやBigQuery、最近であればSnowflakeなど分析クエリを専門とするデータベースとは方向性が異なり、まともには競えない。
2020年現在のNewSQLについて - Qiita
Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海
Aria Presto: Making table scan more efficient
Aria is a set of initiatives to dramatically increase PrestoDB efficiency. Our goal is to achieve a 2-3x decrease in CPU time for Hive queries against tables stored in ORC format. For Aria, we are pursuing improvements in three areas: table scan, repartitioning (exchange, shuffle), and hash join. Nearly 60 percent of our global Presto CPU time is attributed to table scan, making scan improvements
スケールアップファーストのNoSQL、ScyllaDB
ScyllaDBとは ScyllaDB(スキュラDB）とは、Apache CassandraをJAVAからC++でリプレースし、Cassandraより10倍以上高速であり、その速さを利用してノード数を「1/5～1/10」に圧縮できる異次元のデータベースです。Cassandraとは、互換性があり、開発はCassandraのドライバ―やCQL、各種コネクター、CLIなどをそのまま利用できます。 高コア数/高帯域のネットワーク/高スループットのDISK I/Oという現代的なハイエンドサーバーの登場は、今日においてサーバーの最大の買い手であるクラウドプロバイダーの存在と、マルチメディア/ML/AIなど益々リッチな計算資源を求める時代的な背景が働いています。 しかし、これらのハイエンドサーバーに、DBのような従来のデータ集約的なアプリケーションをインストールして使おうとすると、機能性には問題がありま
時系列データベースの論文を書いた - ゆううきブログ
先週、第11回インターネットと運用技術シンポジウム (IOTS2018)にて、投稿した論文の発表をしてきました。 IOTSは査読付の国内の研究会であり、2年前に招待講演をさせていただいた研究会でもあります情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ。 実は、そのときに、来年論文を投稿するぞと意気込んでいました。 実際にはそこから2年かかりましたが、この度論文を投稿することができました。 予稿 HeteroTSDB: 異種混合キーバリューストアを用いた自動階層化のための時系列データベースアーキテクチャ スライド 実務から研究へ 今回投稿した論文の内容は、Mackerelで開発した時系列データベースに関するものです。 これらはすでにAWS Summit Tokyo 2017、Web System Architecture研究会で発表済みのものになります。 時
「F1 Query: Declarative Querying at Scale」 - Google内部のクエリ実行プラットフォームF1の動き - 発明のための再発明
はじめに 以前Dynamoの論文を読んだので、ついでにGoogleのF1についての論文読んだ。 Dynamoは古かったが、こちらは2018年発表と新しい。 以下のリンクから手に入る。 https://ai.google/research/pubs/pub47224 F1はSpannerと一緒の文脈に居ることが多くSpannerをいじるためのものだと考えていたが、GoogleSpreadSheetなど複数ソースをまたいで動作するらしい。 論文の内容は全体を通して興味深い内容だった。 この論文では、 どのようにソースをまたいだ動きを実現したか OLTP・OLAP・ETLという、別特性の動きをどのように一体化したか を書いている。 以下、特に興味を引いた１章から４章の内容である。 F1の目的 F1は、社内で必要な機能である以下の３種全てを提供することを目的としている。 少ないレコードを対象とした
カラムナフォーマットのきほん 〜データウェアハウスを支える技術〜 - Retty Tech Blog
こんにちは、Retty.Inc ソフトウェアエンジニア兼データサイエンティストのchie（@chie8842）です。 好きなたべものは焼肉とみかんです。 現在Rettyでは、次世代分析基盤を構築しています。Rettyでは、サービス拡大に伴いログの急増や分析需要の拡大が見込まれるため、高いスループットとコストパフォーマンスを両立する、スケールするアーキテクチャ設計が求められています。 今回は、こうしたスケールするアーキテクチャ設計の実現のために理解しておくべきDWHのコア技術の一つである、カラムナフォーマットに焦点を当てて紹介します。 はじめに - カラムナフォーマットとは カラムナフォーマットとは、データベースの分析用途に利用されるファイルフォーマットの種類の一つです。大量のデータを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくで
Spanner - Qiita
これまで多くのトランザクションの要素技術を説明してきた。 Googleの公開している論文Spanner: Google's Globally-Distributed Database は公開当初、要求される専門技術の多さからよくわからないと言っている人が多かったが、これまでに説明した要素技術をベースにすると理解しやすい。 Spannerとは 複数のデータセンターに跨ってデータベースの内容を複製し続ける事で高い可用性を実現するという構想は数多くあった。 しかしそれらの分散データベースは実用的な速度を実現しようとすると、データモデルがただのRDBより単純化して使いにくかったりトランザクションをサポートしなかったりと、アプリケーションの一貫性を実現するのが難しい。 現にGoogleの社内でもBigtableなどを用いたアプリケーションは複数あるものの、それぞれでそのデータモデルの上で無理やりトラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今まで生き残ってきたRDBMSとこの先10年戦えるデータストア戦略 / Database now and in the past
Write Ahead Log | Grafana Loki documentation
Fast and reliable schema-agnostic log analytics platform
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018
