2017/09/05 db tech showcase Tokyo 2017 http://www.db-tech-showcase.com/dbts/tokyo
PostgreSQLとMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較! オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう? それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース(以下、RDB)を選ぶのが最善なのか?」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
はじめに Amazon RDSのMySQL 5.7で開発を行うことになりました。そこで、少しですがMySQL 5.7の機能を調べる機会がありましたので、今回は「UNION ALL」に関してのオプティマイザの改善について記載したいと思います。 「UNION」と「UNION ALL」の違い 先ずは、改めて「UNION」と「UNION ALL」の違いを簡単に説明しておきます。 UNION 結合対象のSELECT文の結果の全レコードを取得し、重複レコードを除去し返却します。 UNION ALL 結合対象のSELECT文の結果の全レコードををそのままつなげて返却します。 違いは結合した結果から、「重複レコードを除去するか、しないか」だけとなります。 MySQL 5.7での「UNION ALL」の改善とは 後ほど、「UNION」「UNION ALL」の実行計画の例を記載しますが、実行計画は単純であり、
概要 インデックスに対して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は1ノードから出る枝の数のことです。 B Tree B-Tree Visualization B+ Tree B+ Tree Visualization 先程のB Treeと違って、データはリーフノードに持つの
米マイクロソフトはシアトルで開発者向けイベント「Microsoft Build 2017」を開催。1日目の基調講演で、オープンソースデータベースであるMySQLとPostgreSQLのマネージドサービスを提供すると発表しました。 「Azure Database for MySQL」と「Azure Database for PostgreSQL」は、いずれもマネージドサービスとしてマイクロソフトが運用管理や障害対応、パッチ適用、バックアップなどを行うため、利用者は運用の手間をかけることなくこれらのデータベースを利用することができます。 また、データベースへの負荷変動に対してデータベースを停止させることなく自動的に性能をスケールアップ、スケールダウンすることにも対応。 「既存のMySQL、PostgreSQLのツールやドライバ、フレームワークなどと100%互換がある」(クラウド&エンタープライ
Microsoft が MySQL/PostgreSQL のマネージドサービスを始めます 内部的にはずっと前から取り組みがされていて、多くの新規 Azure ユーザから望まれていた一方なかなか出てこなかった MySQL/PostgreSQL のマネージドサービスがいよいよ出てきました。 azure.microsoft.com azure.microsoft.com 何年も待ったわ~ほんとに。。。 これまでの MySQL/PostgreSQL マネージドサービスの課題 各種クラウドにあるサービスには大きく2つの課題があったと思います “インスタンス” というサイジング どのサービスも基本的に “仮想マシン” 単位で要求性能とキャパシティを決めて、そこにセットアップの自動化とバックアップ、そして別インスタンスへのフェイルオーバーを提供するものでした。 仮想マシンでのプロビジョニングはこれまでの
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ
2014-09-09 [MySQL][EXPLAIN] typeフィールドの見方 mysql explain クエリの実行速度が速いものから順に紹介していく。 constテーブルで一致するレコードが1つで、クエリ開始時によみこまれるとconstになる。 テーブルを一度しか読み取らないので、typeフィールドに表示される値のなかで 最も速い。 PRIMARY KEYやUNIQUE INDEXが使用された場合に表示される。 eq_refJOIN や =演算子 でテーブルを結合した場合に、constと同じ条件(PRIMARY KEYかUNIQUE INDEXが使用される)の場合に表示される。 refテーブル結合で、インデックスの左端の先頭部分のみが結合で使用された場合、 または PRIMARY や UNIQUE ではないインデックスが使用された場合に表示される。 = または <=> 演算子で比較
はじめに やあ (´・ω・`) ようこそ、バーボンハウスへ。 このmysqlはサービスだから、まずsystemctl start mysqld して落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このタイトルを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、この記事をかいたんだ じゃあ、注文を聞こうか。 というわけでmysqlをdisります。disるだけなので内容はありません。いいね? mysql には罠がいっぱい そうなんですよ罠がいっぱいなんですよ奥さん。 いやこれはおそらくmysqlに限った話ではないんですけど例えばこういうの! MySQLのチューニングなんてしたらパフォーマンス落ちるだけだし、デフォル
文字コードは面白いね! わーい! たのしー! 🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾🐾 MySQL で utf8mb4_unicode_ci コレーションを使用した時に「🍣」=「🍺」や「ハ」=「パ」になる問題があります。 この utf8mb4_unicode_ci ってなんぞや?と思ってマニュアルを見てみると、 MySQL は、http://www.unicode.org/reports/tr10/ で説明している Unicode 照合順序アルゴリズム (UCA) に従って xxx_unicode_ci 照合順序を実装します。照合順序は、バージョン 4.0.0 UCA 重みキー (http://www.unicode.org/Public/UCA/4.0.0/
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ? MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる? SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
来る2月27日、データベースの新書籍を発売させて頂くことになった。タイトルは「理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL」となっている。単に「データベース」と書いてあるが、RDBがメインのテーマの書籍である。 多くの人が未だにRDBを使いこなせていないのではないか。RDBの使い方をマスターするには何が必要なのか。それがここ数年私が追ってきたテーマであり、この書籍を出すことになった動機である。 あまりにも酷いDB設計、あまりにもスパゲティなクエリ、あまりにも希薄なデータモデルへの理解。そういった問題はどこから生み出されるのか。そのひとつの結論としてたどり着いたのが、「そもそもRDBの使い方があまり理解されていないのではないか」ということだった。名著、SQLアンチパターンでは「やってはいけないケース」について学ぶことができるが、その反対のテーマ、つまり本来どの
■システム日付 ・Oracle SYSDATE ・MySQL NOW()■日付型→文字列型変換(YYYY/MM/DD) ・Oracle: TO_DATE(TO_CHAR(SYSDATE), 'YY-MM-DD') ・MySQL: DATE_FORMAT( SYSDATE() , '%Y-%m-%d')■TRUNC(日付) ・Oracle TRUNC(SYSDATE) ・MySQL DATE(SYSDATE())■ADD_MONTH ・Oracle ADD_MONTHS(SYSDATE, 1) ・MySQL DATE_ADD(SYSDATE(),INTERVAL 1 MONTH)■MONTHS_BETWEEN ・Oracle MONTHS_BETWEEN(SYSDATE, SYSDATE+1) ・MySQL DATEDIFF(SYSDATE(), SYSDATE()+1)■TO_NUMBER
SQLの観点から「Oracle Database」「PostgreSQL」「MySQL」の特徴を整理しよう! 企業の情報システムで利用されているRDBMSでは、近年は商用データベースだけでなくオープンソース・データベースを併用するケースも増えており、選択肢は多様化しています。ご存じの通り、SQLはRDBMS共通の言語ですが、実際は細かな記述の違いやRDBMS独自の機能が多数存在します。そのため、例えば商用データベースからオープンソース・データベースに移行したり併用したりすると、アプリケーションの改修コストや、意図した通りに動作しないといった問題が発生する場合があります。本記事では、SQLの視点からRDBMSの主な差異を紹介し、異なるRDBMSに移行する際の注意点やRDBMS選定のポイントに迫ります。
HOME » » OracleからMySQLへのマイグレーション時に発生した問題点 DB構築 MySQL構築手順 » OracleからMySQLへのマイグレーション時に発生した問題点 OracleからMySQLへのマイグレーション時に発生した問題点 Oracle10gからMysql5.5へマイグレーションを行った際に遭遇したエラーや問題点をまとめました。 Mysqlのマイグレーションを考えている方の参考にして頂ければ幸いです。 ■OracleからMySQLへのマイグレーション時に発生した問題点 ・行サイズの上限問題 ・カラムの中の改行問題(explanation) ・Nullインポート問題 ・OracleのDATE型(yy-mm-dd)をMysqlにインポートする際の不具合 ・余分な空白が入る ・OracleのCLOB出力問題 ・ミリ秒問題 ・文字化け 行サイズの上限問題 Inn
今回のエントリーが最終回です。 内容は「Webアプリケーションの改変(基本的にはSQL文)」についてです。 1)日付データの編集は? (to_char <-> date_format) 2)SEQUENCEの移行は? (SEQUENCE <-> auto_increment) 3)where句で使うrownumは? (rownum <-> limit) 4)NVL関数は? (nvl <-> ifnull) 5)CHR関数を使った「改行コード」の変換は? 6)そのまま使えた同一構文の関数 7)Oracle固有の表の外部結合を標準SQL化 8)日付型にNULLを許さないMySQL 9)DUAL表を使ったSQL文は? 10)弊社製品101NEO固有の問題 11)データベース接続について 参照:MySQLのSQLリファレンス 参照:OracleのSQL言語リファレンス Oracle SQL> se
新OSのWin11はどう進化したか ビジネス上の役割、開発の要因と Win11が目指した5つのポイントを紹介 注目急上昇中のDaaS最新情報 コロナ禍を背景に利用者と機能を拡大中 Azure Virtual Desktop最新情報 電話営業・インサイドセールの革新 AIによる自動文字起こし・会話分析が 音声コミュニケーションの可能性を拓く 年間5,000件の問い合わせに対応 疑問を解消したいユーザーも答える情シスも みんな幸せになるヘルプデスクの最適解 コーマス広告の大変動 プライバシー保護とパーソナライズの狭間で マーケティングの効果を最大化するためには データ活用は次のステージへ トラディショナルからモダンへ進化するBI 未来への挑戦の成功はデータとともにある 全世界22万以上の企業・組織で採用 DX時代の顧客価値創出に大きな役割を担う CI/CD環境の現実解を紐解く リモートワークを
6月初めごろから始めたOracleベースのWebアプリケーションのMySQL化が完了しました。 BLOGへのエントリーがタイムリーでないのが、いまいちですが。。 基本的な作業タスクは以下の通りです。 ・MySQL環境の構築 ・データベースの移行(OracleからMySQLへ) ・Webアプリケーションの改変(基本的にはSQL文) MySQLもRailsのチュートリアルで使用する程度で簡単にしか触ったことがなかったので本当にリアルに使っているWebアプリケーションが簡単に移行できるかは全くわかりませんでした。 実際にやってみると予想以上に簡単に移行できました。 工数的には4人日程度です。 アプリケーション規模は以下の通り ・テーブル数:18テーブル ・画面数:30画面 ・CSV出力アプリ:1本 アプリケーションの概要はユーザマニュアル/管理者マニュアルを参照してください。 MySQLは、日本
データベース移行ではどのような作業を行わないといけないのか?全体的な流れを俯瞰的に見なければ、作業の見積もりなどが難しいことだろう。というわけで、今日はデータベース移行時に必要になる作業について7つのステップに分けて紹介しようと思う。言うまでもないことであるが、移行時には既存システムを直接いじるわけではない。(稼働中のシステムを直接いじるのは、走ってるクルマに乗り込むのと同じぐらい危険な行為である!!)開発用のシステムを別途用意して作業を進めるという前提で読んで欲しい。 1. データベース構築まずは何はともあれ新規データベースを構築することである。MySQLであれば典型的な構成にしておけばそれなりに高速に動作するので、細かいチューニングは後で問題が出てからやれば良い。my.cnfはインストールディレクトリの下のsupport-filesディレクトリにあるものを弄ってもいいし、MySQL P
MySQLには、現在時刻を求める関数としてSYSDATE()とNOW()という2つの関数が実装されている。そして、それらは微妙に動作が違う。SYSDATE()は関数が呼び出された瞬間の時刻を返すのに対して、NOW()はクエリ開始時の時刻を返す。例えば、100秒かかるような長いクエリにおいて両者を利用した場合、SYSDATE()では結果に最大100秒の差が生じるのに対して、NOW()では差が生じない。NOW()では関数が最初に実行された時に結果がキャッシュされ、以降はキャッシュされた値が利用されるからだ。 次のようにSLEEP()を利用するとわかり易いだろう。 mysql> SELECT SYSDATE(), SLEEP(100), SYSDATE(); +---------------------+------------+---------------------+ | SYSDATE(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く