図解 DB インデックスDB インデックスの基礎知識を、図をたくさん使って整理します。 この Book は、暗記をおしまいにしてこんな疑問を自力解決できるようになることを目指します。 「どんなインデックス作ればいいんだっけ？」 「なんで作りすぎちゃだめなんだっけ？」 「この場合インデックスって効くっけ？」 「インデックスでどれくらい速くなるの？」 この本は筆者の理解に連動して追記修正される可能性があります。
自作RDBMSやろうぜ!（Zenn出張版）
Disclamer 本記事は自作DBMSやろうぜ！ のページの 22/05/27 JST 22:38 の時点での内容をZenn記事向けに修正して作成したものです 元コンテンツのライセンスについては以下をご参照ください LICENCE 元コンテンツの方は更新が継続されていますので、よろしければそちらもご覧ください この記事の目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されている必要な情報・情報源がまとまったサイトやブログ記事がないことに気づきました そこで、叩き台として、筆者および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSに関する情報をある程度整理して書
DBMの設計と実装 その0 全体の計画 - 豪鬼メモ
DBMの設計と実装について20回くらいに分けて書いてみる。まずは全体の計画と意気込みから。 諸君 私はDBMが好きだ 諸君 私はDBMが好きだ 諸君 私はDBMが大好きだ ハッシュ表が好きだ 開番地法が好きだ 連鎖法が好きだ 赤黒木が好きだ B+木が好きだ スプレー木が好きだ トライ木が好きだ スキップリストが好きだ ブルームフィルタが好きだ 統計で 会計で 辞書検索で 文書検索で 言語処理で 画像処理で アカウント管理で 機械学習で シミュレーションで ゲームで ローカルで クラウドで この地上で使われるありとあらゆるデータベースが大好きだ 数値を並べただけのテーブルから一瞬で所望のレコードが探せるのが好きだ ノードの分割操作を繰り返していくと根にたどり着いて木の高さが上がった時など心が踊る 単一プロセスの操るライブラリだけでデータ管理が完結するのが好きだ メモリとスレッドに物を言わせて
MySQLのストレージエンジンを自作してみる - 備忘録の裏のチラシ
MySQL のストレージエンジン（SE）を自作してみたときのメモ。バージョンは 8.0.13。 アーキテクチャをざっくりと掴むことが目的なので、ストレージエンジンの自作といっても非常に単純な操作しかできないものです。 RDB らしさとも言えるインデックスや行レベルロック、トランザクションなどの高度な処理は実装せず、簡単に入出力の流れを追っていきます。 ゴールは以下の基本的な機能を実現して、「あ、こんなもんなんだ〜」感を覚えることです。 CREATE 文でテーブルの作成 INSERT 文で行の挿入 SELECT 文で行の取得 ちなみに MySQL のコードは C/C++ です。（といっても、テンプレート等の C++ らしい拡張的な機能は使われておらず、ほぼ C で書かれています。クラスは頻繁に使われているので、俗に「クラスのあるC」なんて言われている模様。そのため、C をある程度理解していれ
データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub｜若手Webエンジニアのキャリアを考える！
データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @
Cloud Spanner のハイレベルアーキテクチャ解説
Last update: 2018/7/5 Google Cloud でゲーム担当をやっているサミールです。 本日のトピックは私が大好きな Cloud Spanner となります。Cloud Spanner は GCP のフルマネージド・グローバルスケール・リレーショナルデータベース・サービスです。Cloud Spanner は裏では NoSQL でよくある分散データベースですので、NoSQL の特性を提供しております。 HA (高可用性）水平方向のスケーラビリティ（動的にダウンタイムなしにノードの追加・削除が可能）なお MySQL のようなリレーショナルDB と同じ特性も提供しております。 スキーマ強整合性SQL クエリ（ANSI 2011）言い過ぎかもしれないが、マルチマスターの MySQL というイメージで良いと思います。 注意点：Cloud Spanner は MySQL 互換では
Dgraph - A high performance graph database written in pure Go
Go Conference 2018 Spring
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
Re: Configuring sql.DB for Better Performance : DSAS開発者の部屋
Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
RDBアンチパターン リファクタリングについて話をしてベストスピーカー賞を取ってきた #builderscon - そーだいなるらくがき帳
Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ
B TreeとB+ Treeの違い - Carpe Diem
概要 インデックスに対してMongoDBはB Treeを採用し、MySQLのInnoDBはB+ Treeを採用しています。 どうして採用しているアルゴリズムが違うのだろう？と思って調べてみました。 主な違い B+ TreeはほとんどB Treeと同じですが、以下の点が異なります。 リーフノードとリーフノードを結ぶポインタがある データはリーフノードのみに保持する 具体例 言葉だけだと分かりにくいので、Visualizeするツールを使って具体例を表示します。 [1, 2, 3, 4, 5, 6, 8, 10, 15, 18]という数列に対し、Order: 3で作ってみます。 Orderは１ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
Azure Cosmos DBで導入されたBounded StalenessはProbabilistic Quorumで実現できるらしい - Qiita
Azure Cosmos DBで導入されたBounded StalenessはProbabilistic Quorumで実現できるらしいreplicationTheoryquorumconsistencyAzureCosmosDB Azure Cosmos DB とは 2017/05/10(米国時間)にMirosoftから発表されたあたらしいデータベースサービスです。特徴的なのは、これまでのデータベースサービスはいわゆるデータセンターに閉じた状態での分散レベルしか提供してこなかった所を、データセンターを跨ぐレベル(惑星規模とか言われる)でサポートしている所です。ホストするデータがどこまででも大きくなれますよ(スケーラビリティ)というよりも、複数の地理的に遠く離れたデータセンター拠点に跨ってデプロイできて、一つのデータセットにアクセスできるよという意味です。これに先立ってGoogleから発表
DBから直接golangのモデルを生成するxoのご紹介 — そこはかとなく書くよん。 ドキュメント
DBから直接golangのモデルを生成するxoのご紹介¶ Webアプリを開発している時に、DBのモデル定義の方法にはいろいろなやり方があると思います。 xo は、 DBから直接 golangのモデル定義を自動生成するツールです。 PostgreSQL MySQL Oracle Microsoft SQL Server SQLite に対応しており、良く使われるRDBをほぼカバーしていると思います。 インストール¶ goのツールですので、 go get でインストールできます。 $ go get -u golang.org/x/tools/cmd/goimports (依存性のため) $ go get -u github.com/knq/xo
データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
MySQLではできないことができるデータベース(広義)達
自分は一応暫くMySQLの開発者だったので、MySQLでできることできないことはすぐわかる訳です。現実的な問題と対峙すること１年間、MySQLは使えることにしか使わないわけで、そうすると構築してしまうと、アラートメールが全く来ないので、水や空気のように存在を忘れてしまいます。でも、使えないことには全く使う気がしないわけで…。というわけでMySQLは結局逆にあまり触れていません。限られた範囲では完成を見ているというわけでしょうか。 データを処理して何か貯めて利用できるものをデータベースとするならば、MySQLを適用する気も起きないような領域があって、近年はそのような領域に挑む別の道具が出てきています。 今回は趣向を変えて、いろいろ現状MySQLでは扱えない問題の解決法を模索したことについて少し触れます。MySQLを離れた話題ですが、いつか遠い未来にMySQLの世界に持って帰る事柄かも知れませ
トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある～業務システムをRDBなしで作れるのか？（前編） エンジニアサポートCROSS 2016
トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある～業務システムをRDBなしで作れるのか？（前編） エンジニアサポートCROSS 2016 数年前にNoSQLが登場した当時、NoSQLにはデータの一貫性を保証してくれるトランザクション機能などが十分に備わっていないため、業務システムのバックエンドとして使うのは容易ではないと考えられていました。 しかしその後、NoSQLをバックエンドにした業務アプリケーションは現実にはいくつか登場してきています。ワークスアプリケーションズが2014年に発表したERPの「HUE」もCassandraをバックエンドに採用した、本格的な業務アプリケーションです。 そのHUEの開発に関わるスタッフが、どういう実装ならばNoSQLが業務アプリケーションのバックエンドに使えるのか、それにはどういう意味があるのか、などについて議論したセッション「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DBアーキテクチャの比較と選択
Internals Of Google DataStore And Technical Overview
https://engineering.mercari.com/entry/2017/12/18/deadlock
