これまで多くのトランザクションの要素技術を説明してきた。 Googleの公開している論文Spanner: Google's Globally-Distributed Database は公開当初、要求される専門技術の多さからよくわからないと言っている人が多かったが、これまでに説明した要素技術をベースにすると理解しやすい。 Spannerとは 複数のデータセンターに跨ってデータベースの内容を複製し続ける事で高い可用性を実現するという構想は数多くあった。 しかしそれらの分散データベースは実用的な速度を実現しようとすると、データモデルがただのRDBより単純化して使いにくかったりトランザクションをサポートしなかったりと、アプリケーションの一貫性を実現するのが難しい。 現にGoogleの社内でもBigtableなどを用いたアプリケーションは複数あるものの、それぞれでそのデータモデルの上で無理やりトラ
特徴・機能 様々なデータベースへの接続 Oracle Database へはOCI接続(オラクルクライアント経由)、直接接続(オラクルクライアント不要)で接続出来ます。 PostgreSQL, MySQLへは直接接続(クライアントライブラリ不要)で接続出来ます。 Microsoft SQL Server へは NativeClient 経由で接続できます。 それ以外のデータベースへはADO(OLE DB)または、ODBCで接続出来ます。 SQL入力支援機能 Ctrl+SpaceでSQL文を解析しテーブル名やテーブルカラム名の入力補完が行えます。 共通表式や副照会も解析する強力な機能です。 GUIでのクエリーの設計と分析機能 GUIを使いクエリーの設計と分析を使ってクエリーを作成することができます。 実行計画取得機能 RDBMSがSQLを実行する際の実行計画(アクセスプラン)を表示します。
This is the June 2024 issue of the monthly DB-Engines Ranking of database management systems. You can find the complete and most up-to-date ranking at DB-Engines.com. RankDBMSScoreChanges1.Oracle1244.08+ 7.792.MySQL1061.34-22.393.Microsoft SQL Server821.56-2.734.PostgreSQL636.25-9.305.MongoDB421.08-0.586.Redis155.94-1.866.Redis155.94-1.867.Elasticsearch132.83-2.528.Snowflake130.36+ 9.039.IBM Db212
カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基本的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば1年間の日付なら1〜
これまで階層構造データはリレーショナルデータベースでうまく扱えませんでしたが、その解決策としてジョー・セルコが提案したのが「入れ子集合モデル」です。この手法を紹介した『プログラマのためのSQLグラフ原論』の刊行にあたり、翻訳されたDBエンジニアのミックさんに入れ子集合モデルの将来性についてうかがいました。 なぜRDBで木と階層構造を扱う手法が1冊の書籍に? ――『プログラマのためのSQLグラフ原論 リレーショナルデータベースで木と階層構造を扱うために』についてミックさんにうかがいます。最初に、本書がどういう本なのか教えていただけますか? ミック:内容としては、リレーショナルデータベース(RDB)でグラフ構造の一つである木と階層構造を扱うための方法論「入れ子集合モデル」をメインに解説しています。RDBには大きな問題があり、入れ子集合モデルがそれを解決しうる手法だと見込まれています。その問題と
はじめに 練習用に手頃なサンプルデータベースが欲しくなることってありますよね? 僕の場合だとブログを書くときにサンプルが欲しくなったりするのですが、結果的にはPostgreSQL Tutorialにあったのですが、探すのに少し苦労しましたのでメモします。 環境 MacOS 10.10.5 PostgreSQL 9.4.5 ※PostgreSQLのインストールについては割愛します。 サンプルデータベースを作る まずはPostgreSQL Tutorialからサンプルをダウンロードします。 次にサンプルデータを入れるためのデータベースを用意します。 PostgreSQL内で CREATE DATABASE dvdrental; 次にunzipコマンド先ほどダウンロードしたzipファイルを展開します。 unzip dvdrental.zip 次に同じディレクトリで以下のコマンドを叩きます。 pg
これまでに、(主に)Amazon Redshiftで活用出来るGUIツールとして『Intellij IDEA Ultimate Edition』や『Aginity』等を紹介して来ましたが、Intellij IDEAを開発しているJetBrain社から別種のDB関連ツールが開発されているという情報を先日知りました。 Amazon RedshiftのMac OS X向けGUIツールとして『Intellij IDEA Ultimate Edition』のDatabase Toolsを使う | Developers.IO Redshift専用 Windows GUIツール『Aginity Workbench for Amazon Redshift』が便利かもしれない件 | Developers.IO それがこの『0xDBE』と呼ばれるものになります。アナウンス自体は1年以上前からなされていた様で、
6月 11日 9 : 30 – 11 : 30 [RDB, NoSQL, Hadoopを整理しよう: RDBエバンジェリスト編] RDBの牙城は揺るがない!! ファシリテーター: 生熊 清司(ITR) パネラー: 原 憲宏(日立製作所), 後藤 宏(日本ヒューレット・パッカード), 一志 達也(日本IBM), 北川 剛(日本マイクロソフト), 大本 修嗣(SAPジャパン), 小幡 一郎(インサイトテクノロジー) 6月 12日 9 : 30 – 11 : 30 [RDB, NoSQL, Hadoopを整理しよう: NoSQLエバンジェリスト編] 敵はRDB?? ファシリテーター: 生熊 清司(ITR) パネラー: 上西 康太(Bashoジャパン), 河村 康爾(Couchbase Japan), 原沢 滋(DATASTAX), 土田 正士(日立製作所), 野間 愛一郎(日本IBM), 草薙
QConTokyo ( http://www.qcontokyo.com/KotaUENISHI_2015.html ) の発表スライド
前書き インデックスの 内部構造 インデックス リーフノード 検索 ツリー(Bツリー) 遅いインデックス パートI where 句 等価 演算子 プライマリキー 複合インデックス 遅いインデックス パートII 関数 - where 大文字・小文字を区別する 検索 ユーザ定義 関数 インデックスの作り過ぎ パラメータ化 クエリ 範囲 検索 大なり、小なり、 BETWEEN LIKEフィルタに 対するインデックス インデックスの結合 部分インデックス OracleにおけるNULL NULLに対する インデックス NOT NULL 制約 部分インデックスを エミュレートする 処理しにくい条件 日付型 数値文字列 列の連結 スマートなロジック 数式 パフォーマンスと スケーラビリティ データ 量 システム 負荷 レスポンス タイムとスループット 結合 処理 入れ子 ループ ハッシュ 結合 ソートマ
NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは?(前編) NTTデータオープンソースDAY2015 現在のシステム構築では、オープンソースのソフトウェアを使うことは当たり前になってきています。PostgreSQLはそうした中で主にエンタープライズ向けのデータベースとして着実に事例を増やしてきています。 その中で、PostgreSQLを大規模なミッションクリティカルなシステムの中で使うには、どのようなノウハウが求められるのか。オープンソースの利用に積極的なNTTデータがその事例を、1月26日に開催されたイベント「NTTデータオープンソースDAY 2015」のセッション「NTTデータとPostgreSQLが挑んだ総力戦。PostgreSQLを極限まで使い切ったその先に見たものとは?」で紹介しています。講演内容をダイジェストにしまし
2. copyright © 2014 kuwata-lab.com all rights reserved まえがき 現在、アプリケーション開発の現場では O/R Mapper (ORM) が普及しています。今後 も ORM を使った開発は、増えることはあっても減ることはないでしょう。 しかし ORM は、アプリケーション開発者にとっては便利でも、DB 管理者 (DBA) か らみたらトラブルの種でもあります。それが特にパフォーマンスに関する問題であるこ とが多いため、開発者と DBA が対立することも珍しくありません。 とはいえ、ORM による問題はすでに解決策が用意されている場合があります。本当の 問題は、すでに存在する解決策があまり知られていないことではないでしょうか。 そこで本発表では、ORM によってどのような問題が起こりやすいか、どう解決・予防 すればいいか、そして ORM
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
弊社ではシークレットの管理を自社のSecrets Managerによって管理しており、ほとんどの社内プロダクトはこれと連携しています。Secrets Managerと自社Kubernetes基盤との連携は最適とはいえず、Kubernetes上のアプリケーションからシークレットを利用する際の、利便性の悪さや、シークレット取得のための認証情報の管理にリスクがあるなどの問題がありました。 従来の解決策として、External Secrets OperatorやSecrets Store CSI Driverなどがありますが、エコシステムに組み込むにあたってSecrets Store CSI Driverに強みがあり採用しました。そしてKubernetes環境により適した安全なシークレット管理を実現するため、自社のセキュリティ基盤と連携しプラットフォームレベルでシークレットの提供がサポートができる
エンタープライズシステムのエンジニアをやって10年以上。思うところを書いていきます。その他趣味を少々。。。 DBの世界に起きた大きな波 現在、どの製品を使ったとしてもRDBの性能問題は必ずといっていいほど発生する。理由は簡単で、CPU、ネットワークが高速化(CPUはマルチコア化、ネットワークは10G-Ethernetの一般化やInfiniBandなど)するのにディスク(ストレージ)が高速化に追いついていないからだ。その差を埋める役割として、RDBが担っているケースが多く、性能問題になるケースが散見される。 だが、そういう時代の流れに対して大きな変革が起きようとしている。SSDはかなりコモディティ化してきたので言うに及ばずといった感じだが、個人的には速いもののディスクの置き換えにすぎないと思っている。つまり、SSDは速いがDBのアーキテクチャに大きな変革をもたらすものではない。が、ここにきて
皆さん、こんばんは。笹亀です。 7月もあっという間に10日間が過ぎて、夏真っ盛りになってきました。 自分も夏対策でアイス眠というマットレスを購入して夏を乗り越えようと思っております。 さて、本日はストアドプロシージャについて検証をしてみたいと思います。 ストアドプロシージャとは、一連のSQL文や処理に名前をつけて保存したものです。 PHPの関数と同じでSQLを関数みたいにしたものがストアドプロシージャになります。 MySQLではストアドプロシージャはMySQLでは5.0から利用が可能です。 今回はMySQLのストアドプロシージャの使い方だけではなく、 生PHPで記載したときとのパフォーマンスを比較してみたいと思います。 MySQLのストアドプロシージャを呼び出して処理をするPHPプログラムとストアドプロシージャで作成したものと同じSQLを実行するPHPプログラムを作成します。 上記2つのプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く