酔いどれ設計ナイト2019の発表資料です。
![履歴を持つデータの設計](https://cdn-ak-scissors.b.st-hatena.com/image/square/4d264056e8bbeeced060c542ff40cfcd8006c4ca/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Feb07855e280a43bea5c41aa18128ee82%2Fslide_0.jpg%3F12336793)
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術(ビッグデータ、NoSQL、JavaScriptなど)を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか? 私は開発者として、理解していないものを
さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDB は Google のBigTableをベースにしたアーキテクチャを持
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか? A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
仕事でMySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基本的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基本概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'
これまたマニアックな苦笑。 DB Patternsでは、ありがちなデータベース設計を共有することができる。 フォトアルバムだったらこういうテーブルがあって、こことこのキーが共有されるとかなんとかをグラフィカルに見ることができる。 まだ投稿も少ないし、いろいろ突っ込みどころもあるのだが、初心者のうちは確かに悩むところだし、便利なサービスではなかろうか。 ユーザー登録をするとすでにあるパターンをForkしたり、新しく作ったりもできるようだ。興味がある方はどうですかね。
黒猫ソフトウェア工房では、現役SEがこだわりのフリーソフトを開発しています。■最新情報 黒猫 SQL Studio 1.3.10.443 をリリースしました。(2007.10.21)new! 黒猫 SQL Studio 1.3.10.442 をリリースしました。(2007.10.20) 黒猫 Excel DBLink 1.2.3.39 をリリースしました。(2007.10.15) 黒猫 SQL Studio 1.3.10.440 をリリースしました。(2007.9.28) 黒猫 SQL Studio 1.3.10.438 をリリースしました。(2007.9.19) 黒猫 SQL Studio 1.3.10.437 をリリースしました。(2007.9.15) ■黒猫 SQL Studio 黒猫 SQL Studio は、あらゆるデータベースに接続可能な汎用SQL開発
A5:SQL Mk-2は複雑化するデータベース開発を支援するために開発されたフリーのSQL開発ツールです。 高機能かつ軽量で、使い方が分かりやすいことを目標に開発されています。 SQLを実行したり、テーブルを編集するほかに、SQLの実行計画を取得したり、ER図を作成したりすることが出来ます。 特徴・機能 OCI接続・直接接続・ADOまたはODBCを介したDBへの接続 Oracle DatabaseはOCI経由の接続・直接接続が出来ます。 PostgreSQLとMySQLは直接接続が出来ます。 Microsoft SQL Serverは、OLE DBプロバイダを直接呼び出した接続ができます。 IBM DB2は、ODBCドライバを直接呼び出した接続ができます。 その他のデータベースは、ADOまたはODBCを利用して接続します。 Oracle, PostgreSQL, MySQLは、A5:SQL
これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。 この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。 従来のリレーショナルを拡張 従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。 データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。 NoSQLを上回る性能のVoltDB、そのアーキテクチャ
by 柴田 淳 — posted at 2005-10-19 23:56 last modified 2006-12-04 12:41 「水曜日」とか口走ったせいで、いきなり自分の首が絞まっている気がします。 月曜日に言うんじゃなかった。。。でも、とりあえず頑張ります。 さて、パフォーマンスのチューニングと言った場合に、非常に大きなウェイトを占めるのがSQLのチューニングだと思います。アプリケーションがカッチリと固まってしまってからだと大きな変更は難しいものの、それでもやはりパフォーマンスへの影響は大きいでしょう。 SQLのチューニングをする場合、一般的には以下のようなプロセスを踏んで作業を行うことになると思います。 重いSQL文の特定そのSQL文が遅い原因追求SQL文の改善チューニング効果の確認 今回は、処理時間のかかるSQL文をどうやって特定するかを考えてみます。 例えば、アプリケー
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Free Credit Report music videos Migraine Pain Relief Best Mortgage Rates Credit Card Application Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ (「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました) InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能(同期書き込み) innodb_flush_log_at_trx_commit=1,0,2
「A5:SQL Mk-2」は、SQL文の入力支援やER図作成などの機能を備えた高機能なSQL開発環境。Windows 98/2000/XP/Server 2003/Vista/Server 2008/Vista x64に対応する寄付歓迎のフリーソフトで、作者のWebサイトからダウンロードできる。 本ソフトは、SQL文の作成・実行を行える汎用のデータベース開発環境。ADOやODBCドライバーを利用して各種データベースに接続可能で、本ソフトで作成したSQL文を実行し、その結果を表示できる。また、SQLの実行計画を取得したり、実行結果を「Excel」へ出力することも可能。 画面はサイドバーと編集画面の2つに分割されており、サイドバーではデータベースおよび関連するスキーマ・テーブル・ビューといった項目がツリー形式で表示される。編集画面はタブ切り替え式になっており、SQL文やテーブルなどを複数開いて
排他制御の落とし穴を避けるインデックス設計:Dr. K's SQL Serverチューニング研修(5)(1/3 ページ) SQL Serverは一般的にチューニング不要のデータベースと認識されている。しかし基幹系業務システムへの導入が進むにつれて、パフォーマンス・チューニングのニーズは急速に高まってきた。そこで本記事では、日本におけるSQL Serverコンサルタントの第一人者、熊澤幸生氏にSQL Serverチューニングのノウハウを語っていただくことにした。インタビュアーはSQL Serverへの造詣が深いITジャーナリスト、工藤淳氏が担当する。(編集部) 前回の記事「排他制御メカニズムから“待ち”原因を究明する」では、wait事象を引き起こす原因の中から排他制御について解説しました。ロックとラッチ、ロックの粒度、複数粒度でのロックとロックマネージャといったSQL Serverのアーキテ
高木浩光氏からの批判の一つは、数値リテラルをシングルクォートで囲むことに対する論拠のあいまいさであったように思う。 「性能的にも不利だし」 < 性能の影響は皆無。問題はそこではなく、挙動がSQL仕様で定義されているか。 以下にもう少し掘り下げて考察してみよう。 SQL仕様でどう定義されているか? 以下のようなSQLで、列IDがint型であると仮定しよう DELETE FROM DOCUMENTS WHERE ID=1 この数値リテラル1をシングルクォートで囲んだ場合の動作はどう規定されているか? DELETE FROM DOCUMENTS WHERE ID='1' 今手元にJIS SQLなどの規定がないので記憶に頼って書くしかないが、このような場合は、varchar型などの文字型から、int型への「暗黙の型変換」が実施される。つまり、'1'という文字列は、1という数値(整数)に変換されてか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く