AWS では、異種データベースの移行を予測可能、高速、安全、かつシンプルにするために、2 つのスキーマ変換ソリューションを提供しています。お客様は、次のいずれかを選択することができます。1) AWS Database Migration Service (AWS DMS) コンソールにログインして、AWS DMS Schema Conversion (DMS SC) ワークフローを開始し、フルマネージドな体験をするか、2) AWS Schema Conversion Tool (AWS SCT) ソフトウェアをローカルドライブにダウンロードするか、を選択することが可能です。 どちらのオプションも、ソースデータベースのスキーマと、ビュー、ストアドプロシージャ、関数などのデータベースコードオブジェクトの大部分を自動的に評価し、ターゲットデータベースと互換性のある形式に変換します。自動的に変換で
このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL 第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック(一番遅いところ)を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた
はじめに 本エントリーは某社内で実施するSQL勉強会向けの資料となります。 本エントリーで書籍「SQL アンチパターン」をベースに学習を進めます。書籍上でのサンプルコードはMySQLですが、本エントリーでのサンプルコードはSQL Serverに置き換えて解説します。 また本章以外のエントリーおよび利用するSQLリソースなどは、以下のGitHubを参照ください。 EAV(エンティティ・アトリビュート・バリュー)とは 「リレーショナルデータベースはメタデータの柔軟性が低い」という拡張性の問題についての議論は、リレーショナルモデルが提唱されて以来、途切れることなく議論されてきました。 EAVは「可変属性をサポートする」など、柔軟な設計を目指したことに起因するDB設計のアンチパターンです。 EAV(Entity-Atribute-Value)では、次のような項目を持たせたテーブルが設計されます。
タイトルでほぼほぼ出オチですが、先日、NVIDIAからCUDA Toolkit 11.4と共にリリースされた新機能GPUDirect Storage 1.0のドキュメントを読んでいると、面白い記述を見つけた。 曰く、MOFEDドライバ5.3以降と、Mellanox Connect-X4/5の組み合わせで、NFS-over-RDMAとGPUDirect Storageを組み合わせ、リモートのNFS区画からローカルのGPUへと直接のデータ転送を行う事ができるようになる、と。 14.10. NFS Support with GPUDirect Storage This section provides information about NFS support with GDS. 14.10.2. Install GPUDirect Storage Support for the NFS Cli
概要 ところでこのツイートを見てほしい。このソースコードをどう思う? 世界最悪のログイン処理コード。 実際のサービスで可動していたものだとか……https://t.co/C2bG93ZCkj pic.twitter.com/EfVNAEslrn — はっしー@海外プログラマ🇳🇿元社畜 (@hassy_nz) 2018年8月10日 すごく……セキュリティーホールです…… 一応は動いていますが、あまりに問題がありすぎるため、Twitterでも話題になっていました。 問題点は片手に入り切らないぐらいある気がしますが、一つづつ解説していきます。 ※元記事のタイトルに記載されていますが、このコードはイントラネット内で動作していたものです。 問題点リスト 1. クライアント上のJavaScriptで書かれている 他の問題点を全部ぶっ飛ばすぐらいの重大な不具合です。 クライアントと言うのはこの場合、
2012年03月12日02:24 カテゴリSQLDB2 for IBM i SQL でビット列を評価する (MySQL と DB2 のビット演算の違い) SQL で二進表現されたビット列に対しての評価を行うことができます。 具体的に言うと、何ビット目が 1 か 0 を判定することができるということです。先日紹介した『ぐんぐん実力がつく! 逆算式SQL教科書』から見てみましょう。(P.129 からの例です) 5 という数字は二進数で 00000101 になります。 この 8桁の 0 か 1 について、各桁ごとに SQL で判定ができる、ということなんですね。 MySQL での実行例は ↓ のようになります。 それぞれ一番右の 1桁目から左に向かって 4番目の値までを判定する SQL になっています。 SELECT 5 & 1; SELECT 5>>1 & 1; SELECT 5>>2 & 1
なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ
key テーブルにアクセスするために使ったindexを示す。 ちなみに、possible_keysは「使える候補」で、実際につかったかどうかはkeyの値を見る。 key_len 選択されたキーの長さ。 インデックスのキー長が短いほうが高速になるので、迷ったら長さの短いほうにインデックスをつけるといい。 rows selectの取得件数の見積もり。 ざっくりとしたものなので、where句次第ではもっと少ない件数が返ってくることもある。 extra ほかに使用している条件などがあれば、ここに出力される。 チューニング方法の例 type=null かつ key=null の場合 →インデックスが張られてない&テーブルのフルスキャンが行われている。 where条件で使うカラムにインデックスを張る。 もしくは、インデックスが張られたカラムをwhere条件の中に追加する。 extra=Using fi
エグゼクティブサマリ PHP 5.5.21、PHP 5.6.5 以降、PHPにPDO::MYSQL_ATTR_MULTI_STATEMENTSというオプションが追加され、PDO+MySQLの組み合わせで、SQLの複文を禁止できるようになった。この設定はSQLインジェクションの緩和策として有効である。 はじめに 2013年12月に公開した PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能 にて、PDOとMySQLの組み合わせで、SQLインジェクションの文脈で複文呼び出しが可能であることを報告していましたが、その後のPHPのバージョンアップで、複文実行を禁止するオプションが追加されていましたので報告します。 対象のバージョンは以下の通りです。 PHP 5.5.21 以降 PHP 5.6.5 以降 全ての PHP 7.0、7.1 前述の記事を書いた後、3大
追記(2017年7月) こちらのスキル要件ですが、2017年版を新たに書きましたので是非そちらをご覧ください。 「データサイエンティストというかデータ分析職に就くためのスキル要件」という話題が某所であったんですが、僕にとって馴染みのあるTokyoR界隈で実際に企業のデータ分析職で活躍している人たちのスキルを眺めてみるに、 みどりぼん程度の統計学の知識 はじパタ程度の機械学習の知識 RかPythonでコードが組める SQLが書ける というのが全員の最大公約数=下限ラインかなぁと。そんなわけで、ちょろっと色々与太話を書いてみます。なお僕の周りの半径5mに限った真実かもしれませんので、皆さん自身がどこかのデータサイエンティスト()募集に応募して蹴られたとしても何の保証もいたしかねますので悪しからず。 統計学の知識は「みどりぼん以上」 データ解析のための統計モデリング入門――一般化線形モデル・階層
Macで起動したときの変更方法。Windows版も同様だと思う。(環境がないので試してない) SQL Developerを起動する。 メニューから ツール > プリファレンス を選び、ダイアログを開く。 左の一覧から データベース > NLS を選ぶ。 右の一覧から日付書式(RR-MM-DD)を変更する。(YYYY-MM-DD HH24:MI:SS) 右下のOKボタンを押す。 これで、ワークシートで実行したSQLの問い合わせ結果で、日付型に対して上記の書式が適用される。 参考 Default display format for date field in Oracle SQL Developer | Software Chain
Oracleの統計情報の収集はデフォルトでは自動で行われますが、 以下のプロシージャを実行することによって手動で統計情報を更新することができます。 BEGIN --テーブル単位の収集 DBMS_STATS.GATHER_TABLE_STATS ( OWNNAME => 'ユーザ名' ,TABNAME => 'テーブル名' ,METHOD_OPT => 'FOR ALL INDEXED' ,CASCADE => TRUE ); END; BEGIN --スキーマ単位の収集 DBMS_STATS.GATHER_SCHEMA_STATS ( OWNNAME => 'ユーザ名' ,OPTIONS => 'GATHER' ); END; デフォルトでは1日1回しか更新されないので、大量データを投入後などにすぐにSQL文を実行しても、 インデックスがうまく使われなかったり、逆に全表走査の方が早い場合で
やるまえから結果が見えてる試みではあるんですが。最近SQLを再勉強するにあたり、SQLてのは、手続き的にループ回すのに比べて集合to集合の演算の方が圧倒的に早い、というのを改めて認識した。なので、このエントリはそれを実感するのが目的です。 やったこと 環境はOracle 11g XEを使用。 FROM側とTO側のデータを入れるテーブルを作る。FROM側には100万件レコードを入れておく。 CREATE TABLE FROM_A_TBL (CLM VARCHAR2(16)); CREATE TABLE TO_A_TBL (CLM VARCHAR2(16)); FROMテーブルをカーソルでループしながらTOテーブルに1件ずつINSERTするPL/SQLを作る。 create or replace PROCEDURE TO_WITH_CURSOR IS CURSOR C1 IS SELECT C
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く