タグ

databaseに関するtjmtmmnkのブックマーク (22)

  • pt-online-schema-changeを用いたスキーマ変更 on Amazon Aurora MySQL - kubell Creator's Note

    こんにちわ。id:cw-tomitaです。 この記事は、Chatwork Advent Calendar 2020 - Qiita の3日目の記事です。 早速ですが、皆さんはauto incrementなRDBのtableのidにはどのような型を利用されていますか? Chatworkでは多くのテーブルでint型が指定されているのですが、9年前にサービスを開始した時には想像もつかないくらいに多くのお客様に使っていただけるサービスへと成長した結果、int型なauto incrementのidを利用しているテーブルで、レコード数がintの上限を迎えそうなテーブルが複数現れ、どかっとまとめてALTER TABLEを実施するという2020年を代表する一大イベント(?)がありました。 今回は、その時に利用したpt-online-schema-changeというツールを使ってのALTER TABLEの実

    pt-online-schema-changeを用いたスキーマ変更 on Amazon Aurora MySQL - kubell Creator's Note
  • pt-online-schema-changeと5.6 InnoDBのオンラインALTER TABLE使い分け

    この記事は MySQL Casual Advent Calendar 2015 の9日目です。 MySQL 5.6から InnoDBのオンラインDDL が導入されて久しいですが、一方で pt-online-schema-change (以下pt-osc)もまだまだ元気です。MySQL 5.5とそれより前ではpt-osc一択になりますが、MySQL 5.6とそれ以上の場合はInnoDBさんに任せるかpt-oscを使うかを選択することができます。 MySQL 5.6でもpt-osc一択にしても構わないといえば構わないんですが、いくつかのケースではInnoDBさんに任せた方が速くなったり安定したりするので、そのあたり解説していきます。 TL;DR ウチの使い分け。 原則 pt-osc スレーブの台数が多すぎない かつ データ容量が馬鹿でかくてストレージいつぶしそう または INSERT大杉で2

  • Comparison of Online Schema Change tools

  • DynamoDB の設計について考えてみる。 - Qiita

    Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R

    DynamoDB の設計について考えてみる。 - Qiita
  • Queries in PostgreSQL. Query execution stages

    Hello! I'm kicking off another article series about the internals of PostgreSQL. This one will focus on query planning and execution mechanics. This series will cover: Query execution stages (this article) Statistics Sequential scan Index scan Nested-loop join Hash join Merge join This article borrows from our course QPT Query Optimization (available in English soon), but focuses mostly on the int

    Queries in PostgreSQL. Query execution stages
  • 6. ロック制御 · PostgreSQL Internals

    ロック制御 ロック 並行して処理を行っているRDBMSでは、データの整合性のためにリソースに対する排他制御が必須 データの読み取り、書き込み、その他 ロックには、ロックレベルと粒度の概念がある ロックのレベル(モード)はPostgreSQLでは8種類 粒度は、テーブル、レコード、トランザクションなど ロックとのいうは、当然データを操作する上で非常に重要にな要素です。特に並行して処理を行っているデータベースではデータの整合性を担保するためにリソースに対する排他制御は必須の機能になります。ロックすべき処理には、データの読み取りや書き込み、その他にもいろいろあります。 ロックには「レベル」と「粒度」という概念があります。 例えば、ロックのレベル、PostgreSQLではモードとも呼ばれますが、この種類は8種類くらいあります。 ACCESS SHAREという共有ロックから始まって、行の排他ロックや

  • 第2回 トランザクションを知ればデータベースがわかる―「データ復旧」「同時実行制御」を行う“不完全な”しくみ(3) | gihyo.jp

    ロックのコスト:スラッシングとデッドロック スラッシング DBMSがロックを行うとき、具体的にはロックの取得と解放という2つの動作をしています。そして、ロックが取得されている資源にほかのトランザクションがアクセスをかけてきたら、共有ロック同士でない限り「ブロック」を行います。あとから来たトランザクションをロック解放まで待たせるわけです。よく駅や空港のトイレで行列ができるのを見かけますが、あれなどまさにブロックされたトランザクション群の典型です[5]⁠。トイレの便座を共有ロックで、というわけにはいきませんね。 このしくみから必然的に導かれる結果は、並行トランザクション数が一定数を超えると、1つのトランザクションが待機させられる頻度と時間が増え、平均のパフォーマンスが悪くなるということです。システムの特性(更新が多いのか、検索が多いのか)やハードウェア性能にも左右されるため、一般的な閾値(いき

    第2回 トランザクションを知ればデータベースがわかる―「データ復旧」「同時実行制御」を行う“不完全な”しくみ(3) | gihyo.jp
  • 空間インデックス(R-tree)入門 - たにしきんぐダム

    R-treeとは空間データを効率良く検索するためのインデックス構造。R-tree について調べたのまとめておく。 目次 目次 参考資料 ナイーブな例 R-tree の概要 各ノードの要素数 参照処理 点検索 範囲検索 データの挿入・削除 挿入処理 ノードの分割 Exhaustive Algorithm Quadratic-Cost Algorithm Linear-Cost Algorithm 削除 木の再構築のアルゴリズム 更新処理 まとめ 参考資料 Guttman, Antonin. R-trees: a dynamic index structure for spatial searching. Vol. 14. No. 2. ACM, 1984. MySQL 5.7 Reference Manual - Creating Spatial Indexes PostGIS 2.3.3d

    空間インデックス(R-tree)入門 - たにしきんぐダム
  • 開発者が知っておきたいSQLの実行モデル~アプリからデータベースへのアクセスを高速化するには?

    データベースのデータ・モデルは解決したい問題に合わせて使い分けることができ、昨今ではドキュメントやグラフなどのリレーショナル以外のモデルも注目されています。また、トランザクション系が生成した大量のデータをリアルタイムで分析するというような、性質の異なるワークロードを扱うことも求められています。これら性質の異なるデータ・モデルやワークロードを扱うにはどのような実装が必要でしょうか。この連載では、開発者の皆様がシステム・アーキテクチャやアプリケーション・コードをより洗練させるのに役立つデータベース・マネジメント・システム(DBMS)の基を振り返り、実装に合った技術の組み合わせを解説します。 第1回はデータベースにアクセスするAPIで最も広く使われているSQLという言語の実行モデルを再確認します。なぜこの言語がリレーショナル・モデルのみならず他のデータ・モデルに対しての操作にも使われるようにな

    開発者が知っておきたいSQLの実行モデル~アプリからデータベースへのアクセスを高速化するには?
  • 大規模解析サービスのためのデータベース構成 ~BigTable/BigQueryの弱点をどう補うか?

    大規模なデータを扱う解析サービスにおいて、データベースの性質の理解や選定、配置、活用方法などはクリティカルな問題であり、サービスとして大きく差をつくる要素にもなります。稿では考慮すべきデータベースの性質の違いから始め、解析サービスにおける考え方や活用のテクニック、構成方法について紹介したいと思います。 解析サービスにおける重要な2つの仕事 ここでは大量のデータを収集する解析サービスの仕事の中でも、重要な2つの仕事についてフォーカスして話を進めていこうと思います。 一つ目は、データを単に収集し、スケーラビリティの高いデータベース(または分散ファイルシステム)に格納し、あとで(管理画面から、もしくはスケジュールバッチなどで)Aggregateするものです。こちらは解析サービスと言われるサービスの多くが行なっている仕事と考えられます。 二つ目は、データによって振る舞いを変える、リアクションする

    大規模解析サービスのためのデータベース構成 ~BigTable/BigQueryの弱点をどう補うか?
  • サイボウズさんの開運研修(データベース)で話してきました

    2024 ( 22 ) 9月 ( 2 ) 8月 ( 2 ) 5月 ( 1 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 東京都オープンデータカタログサイトのCSVを使ってLOAD DATA LOCAL INFILEの練習をする サイボウズさんの開運研修

  • DBの負荷分散手法 | エンジニアの何でもメモ帳

    DBの負荷分散の手法について世の中にある手法についてかなり忘れてしまってきているので、最勉強を兼ねてざっくりと調べてみました。 設計の見直しとチューニング 負荷分散では無いですが、分散設計を考える前に、設計の見直しや、チューニングで救えるケースの方が多いと思うので少しだけ。 設計の見直しやチューニングをしないと、無限にリソースが必用になるので、ここはある程度きちんとやった方が良いと思う。(オンプレでは新規 HWを調達するのは難しいので、通常これをやるしかなくなる) DBの設計を見直す 正規化(データの冗長製の排除)だけだとデータ結合が必用になる事がありパフォーマンスに問題が出ることがある。非正規化(データを冗長に持つ)事も考える。 「スケールアウト」の所で後述するが、既存の DB でデータのリレーションが薄いものは、別 DBとして分割する事で負荷分散される事もできる。 DBのチューニング

    DBの負荷分散手法 | エンジニアの何でもメモ帳
  • MVCC(多版型同時実行制御)

    Table of Contents9.1. はじめに9.2. トランザクションの隔離9.3. リードコミッティド隔離レベル9.4. シリアライザブル隔離レベル9.5. アプリケーションレベルでのデータの一貫性チェック9.6. ロックとテーブル9.6.1. テーブルレベルロック9.6.2. 行レベルロック9.7. ロックとインデックス MVCC(MultiVersion Concurrency Control:多版型同時実行制御)とは、マルチユーザ環境におけるデータベースの性能を向上させる高度な技術です。 PostgreSQLのために、Vadim Mikheev( <vadim@krs.ru>)が実装のを貢献をしました。 9.1. はじめに 多くのデータベースシステムでは、同時実行制御のためにロック機構を使用していますが、PostgreSQLではデータ整合性の維持に多版方式を使用しています。

  • DBの基礎 - コネクションプーリングについて

    コネクションプーリングについて、わかっていないことが多すぎたので、ちょっとだけ調べたことをメモで残しておきます。 今はまだ触りレベルしかわかっていなのいので、もう少しちゃんと分かるようになりたい! 😀 [スライド] データベースの羅針盤 コネクションプーリングを調べている過程で偶然見付け足資料 『データベース技術の羅針盤』。 とにかくわかりやすくて、俯瞰的にDBの業界を知ることができる資料。すばらしすぎる。 🎂 コネクション・プーリングとは?DBのコネクションを一定数確立しておいて、それを使いまわす手法のこと。 DBへの接続に必要となるオーバーヘッドをカットしてWeb/DBの双方の負荷を下げる。 また、WebとDBの接続を使いまわすことで同時接続数を節約する。 用意した、コネクション数を超えたアクセスは、コネクションに空きがでるまで待たされる。 以下はOracle関連の話ですが、基

    DBの基礎 - コネクションプーリングについて
  • LevelDB入門 (基本編) - from scratch

    さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDBGoogle のBigTableをベースにしたアーキテクチャを持

    LevelDB入門 (基本編) - from scratch
  • Home | DBML

    Intro​ DBML (Database Markup Language) is an open-source DSL language designed to define and document database schemas and structures. It is designed to be simple, consistent and highly-readable. It also comes with command-line tool and open-source module to help you convert between DBML and SQL. Table users { id integer username varchar role varchar created_at timestamp } Table posts { id integer

    Home | DBML
  • ID生成方法についてあれこれ

    ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に

    ID生成方法についてあれこれ
  • 2020年現在のNewSQLについて - Qiita

    Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海

    2020年現在のNewSQLについて - Qiita
  • INとEXISTSの実行計画の違い

    Visual SQL Tuning / wetribe 最近行った現場で見ました。何故か昔から(特にOracle界隈?)盲目的に「INよりEXISTSのほうが速い」という迷信があって、も杓子もみーんなEXISTSになっている現場があったりします。 ※以下はOracle10g相手にあれこれチューニングした経験を踏まえての記述ですが、大筋は他のDBでも変わらないと思います。 INもEXISTSもそれぞれ、一概にどっちが良いと決まっている訳じゃないので、ケースバイケースでどっちを使うかちゃんと考えないといけません。 結論 ・INが適している場合とは→選択的述語が副問合せに有る ・EXISTSが適している場合とは→選択的述語が親問合せに有る 選択的述語なんてふにゃっとした単語がでてきたけど、要は副問合せ側で条件絞込みできる場合はIN、親問合せ側で条件絞込みできる場合はEXISTS(のほうが適して

    INとEXISTSの実行計画の違い
  • DBのインデックスと複合インデックス - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    DBのインデックスと複合インデックス - Qiita