MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ
PostgreSQLとMySQLとMariaDBのNoSQL実装状況 - Qiita
Happy Birthday to me!! この記事はラクス Advent Calendar 2016の6日目です。 昨日は@morihirokさんの「rmの-fオプションで泣かないために」でした。 OSS RDBに実装されたNoSQL実装状況まとめ いつの間にやら主要なOSSなRDBであるPostgreSQLとMySQL/MariaDBにNoSQL機能（というよりもドキュメントDB機能）が付いていたので仕事にも使えそうなのでまとめ。 各種都合によりPostgreSQL優遇気味で。しかし "PostgreSQL contains NoSQL." の「お前は何を言っているんだ」感がすごいですね……。 各DBMSごとのNoSQL機能実装バージョン PostgreSQL PostgreSQL 9.4でjsonb型がサポート 9.2でサポートされたjson型（テキスト）から発展し、jsonb型は
「MySQLからOracle, PostgreSQLに聞きたい」へ回答してみる
論理バックアップと物理バックアップ、どっちが主流だと思います？ （偏見でいいです） MySQLだと（偏見） データベースが十分小さい間 .. 稼働系で mysqldump mysqldumpでリストアが追いつかなくなると .. バックアップ専用スレーブ作ってそれを止めて（or XtraBackup）物理バックアップ Oracle Databaseは物理バックアップが主流と思います。 In-Placeでのリストア＋リカバリによる復旧がいわゆる「王道」であり、Oracle Database(および一般的なRDBMS製品)では、それを達成できるバックアップ手段が物理バックアップなので 物理バックアップとリストア＋リカバリによる復旧を基本とすると、DBAは業務内容にあまり依存せずにバックアップおよび復旧の設計ができる側面もありそうです。 論理バックアップを基本とすると、どうしても業務内容を意識して
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
AuroraとRDS MySQL 5.7のsysbench - Qiita
この記事を見て、結果に疑問を持ったので、AuroraとRDS MySQL 5.7のベンチマークを取ってみました。 動作環境 サーバ Aurora 5.6.10a / db.r3.large / SingleAZ MySQL 5.7.10 / db.r3.large / SingleAZ io1 / 100GB / 1000iops 設定はそれぞれ以下を変更 sync_binlog = 0 innodb_flush_log_at_trx_commit = 2 クライアント 4.1.17-22.30.amzn1.x86_64 / c4.2xlarge sysbench 0.4.12 サーバとクライアントはすべて同じAZ 並列数を高くできるように以下の値を増やした max_connections max_prepared_stmt_count nofile テストスクリプト --oltp-tab
Relational Databases: PostgreSQL, MySQL, SQLite - Hyperpolyglot
databases: architecture | client | select | where | dates | join | aggregate | sort and limit | insert, update, and delete | schema | sequences | indices | import and export | script | function | query tuning | user | python | ruby | help | admin sql: types | casts | literals | dates | identifiers | operators | functions | distinct | qualified * | regular expressions | sequences | group by | aggre
Local database vs Amazon RDS
You should fully tune the MySQL Environment, particularly your InnoDB settings. (See the bottom of my Answer for tuning tips). This would be much better than fighting Amazon for elbow room in RAM/Disk. Why did I say fight? If you just spun up an Amazon RDS instance of MySQL, you would subject yourself to whatever constraints are given. All models of MySQL Amazon RDS have the same major options but
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL 8.0へのアップグレードのメリットと必要性
Compare CockroachDB
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
MySQLとPostgreSQLコマンド比較表 - Qiita
SQLの観点から「Oracle Database」「PostgreSQL」 「MySQL」の特徴を整理しよう！
http://www.cpa-lab.com/tech/046