開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
RDBMSのコネクションプーリングとかその辺の話 - wyukawa's diary
データベース技術の羅針盤 from Yoshinori Matsunobu これは素晴らしい資料で後半のキャリアの話とか面白いんだけど、今回書くのはp6,p8に書かれていた下記の話です。 PosgreSQLは接続がプロセスベースなのでLL言語との相性がよくない Pgpool(これはプロキシサーバー的に使うらしい)などのコネクションプールと併用することが多い MySQLは接続がスレッドベースなのでコネクションプーリングが使いづらいLL言語環境では魅力 なんでLL言語だとコネクションプーリングが使いづらいのかわからずつぶやいたらリプライもらってついでにちょっと前に話題になったRDBMSでコネクションプールが必要な理由、わからない。 - Togetterや7年前のブログエントリであるコネクションプーリングの話 - naoyaのはてなダイアリーを読み返してみて思ったことを書いてみる。全然まとまって
SQLアンチパターン - ナイーブツリー
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる（その4）
カラム型データベースはなぜ集計処理が高速で、トランザクションが苦手なのか。インメモリとカラム型データベースの可能性を調べる（その4） 現在主流となっているOracle、SQL Server、DB2などのリレーショナルデータベースは事実上すべて、行（ロー）指向で内部の処理を行っています。一方で、最近急速に注目されているのが、列指向で内部処理を行い、大量データの集計や分析処理に優れた「カラム型データベース」（あるいはカラム指向データベース、カラムナーデータベース）です。 カラム型データベースはSybase IQやNetezza、Verticaなどデータウェアハウス専用のデータベースで主に採用されています。また、SQL Serverには「ColumnStore Index」、Oracle Exadataには「Hybrid Columnar Compression」と呼ばれるカラム型データベースの
インメモリデータベース「MemSQL 2.0」公開。数百ノードへスケールアウト可能で大規模データベース対応へ － Publickey
データベースをまるごとメインメモリ上で処理することにより、従来のハードディスクベースのリレーショナルデータベースよりも劇的な高速化を実現するインメモリデータベースであるMemSQLの最新版「MemSQL 2.0」が公開されました。 MemSQL 2.0はインメモリのスピードとSQLでの問い合わせ、スケールアウト機能、そしてエンタープライズ対応の可用性など、4つの特徴を持つと説明されています。 In-memory architecture Ad hoc SQL-based analytics Horizontal scale-out on commodity hardware Enterprise-grade durability and high availability スケールアウトでデータウェアハウスに対応 MemSQL 2.0はインメモリデータベースの特徴である高速な処理に加えて、
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
第4回 大規模データ処理におけるCPUの2大ボトルネックとは | gihyo.jp
「特定CPUコアでのボトルネック」と「リソースの奪い合い」が2大ボトルネック 第2回、第3回ではディスクI/Oボトルネックについて説明しました。レスポンスとスループットの関係を正しく理解し、I/Oスループットを最大化するようチューニングすれば、ほとんどの大規模処理は速くなります。ユーザもハッピー、皆さんもハッピー、さて家に帰りましょう。 ……しかし、次はだれかからこう聞かれることでしょう。 「CPUの使用率が異様に低いままなんだけど……？」 「CPUの使用率がずっと100％で張り付いているんだけど……？」 どっちやねん！と思うでしょうが、どちらも大規模データを処理するときに特に起こりえる問題です。 ボトルネックは、1つが解消すると、新たなポイントが明らかになるものです。そして多くのケースにおいて、ディスクI/Oボトルネックが解消した場合、次に詰まるのはCPUなのです。 CPUボトルネックは
書籍編集局ブログ｜Ohmsha
2月15日(木)に開催された「Developers Summit 2018(デブサミ)」（主催：翔泳社）にて「ITエンジニアに読んでほしい！ 技術書・ビジネス書大賞2018」のプレゼン大会と投票が行われ、大関真之先生の著書『機械学習入門 ボルツマン機械学習から深層学習まで』がみごと技術書部門の大賞の栄冠に輝きました！ プレゼン大会では大関先生自ら本書に関する熱い熱い思いを披露していただました。このプレゼンによって「読んでみたい！」「数式が苦手だけどこの本なら読める！」と惹きつけられるオーディエンスが続出！みごと大賞に選ばれることとなりました。ブラボー！ 本書は、おとぎ話の白雪姫に登場するお妃様と鏡の関係をなぞらえ、その問答により「機械学習とは何か」「何ができるのか」を楽しいストーリーと可愛らしくしかも的確なイラスト、そして数式をまったく用いることなく解説している画期的な内容です。 登場する
NoSQLの現状。これまでの成功と失敗
NoSQLの登場は、「データベースといえばリレーショナルデータベース」という状況を大きく変えました。リレーショナルデータベースと比べて高速でスケーラビリティに優れたNoSQLデータベースは登場当初から注目されましたが、一方でいまに至るまでさまざまな種類の製品が登場して混沌としているようにも見えます。 （作者 Stefan Edlich、翻訳者 大田 緑 - (株)チェンジビジョン、投稿日 2013年1月1日） NoSQLは厳しい批判に少なくとも4年間さらされてきました。そして、今、NoSQLの現状について中間報告する時がやって来ました。NoSQLの周辺ではいろいろなことが起こったため、全体像をつかんで、どのような目的を達成したか、また、NoSQLはどこで失敗したかを評価するのは簡単なことではありません。 様々な分野において、NoSQLは産業的にも学問的にもかなり成功をおさめてきました。大学
アーキテクチャ設計のアンチパターン集～44のアンチパターンに学ぶDBシステム - プログラマの思索
「44のアンチパターンに学ぶDBシステム」を読んでみて、とても優れたアーキテクチャ設計のアンチパターン集に思えた。 過去の経験上、あるあると思う箇所がたくさんあった。 感想をラフなメモ書き。 【元ネタ】 44のアンチパターンに学ぶDBシステム - give IT a try あなたの現場にも必ずあるDBシステムの"悪い例"が満載！「44のアンチパターンに学ぶ DBシステム」 | oracletech.jp 『44のアンチパターンに学ぶDBシステム』 - 虎塚 44のアンチパターンに学ぶDBシステム : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ） 【本】SQLをしっかり学習したい人におすすめミック本。 | ﾌﾟﾗﾌﾟﾗ式技術系 Access流! 【本まとめ】44のアンチパターンに学ぶシステム構築時の失敗パターン。もっとはやく言ってよーとな
NoSQLの現状
このため、NoSQLの知識を持つ開発者やアーキテクトに対する需要が高まってきています。最近の調査によると、最近必要とされる開発スキルは次の通りです。 HTML5 MongoDB iOS Android Mobileアプリ Puppet Hadoop jQuery PaaS ソーシャルメディア 技術的要求のトップ10の中で、NoSQLデータベースは2つあります。1つは、iOSよりも上です。これがNoSQLをほめているのでなかったら、何なのでしょう?! しかし、一見したところ、NoSQLはますます速く深いところまで適用されるようになっています。2011年の夏に、有名な報告書の中でOracleは次のように述べました。NoSQL DBがアイスクリームの味のように感じるかもしれないけれど、あまり深入りしない方がいい、NoSQLはそれほど長く残らないかもしれないから。そのわずか2、3ヶ月後、Oracl
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で
Active Record - Wikipedia
「アクティブレコード、アクティブ・レコード」はこの項目へ転送されています。イギリスのレコードレーベルについては「ミュージック・フォー・ネイションズ」をご覧ください。 Active Record（アクティブ・レコード）とは、プログラミングにおいて、企業アプリケーションで頻繁に認められるデザインパターンである。 概要[編集] Active Recordはデータベースからデータを読み出すためのアプローチである。データベーステーブルあるいはビューの1行が1つのクラスにラップされ、オブジェクトのインスタンスがそのデータベースの1つの行に結合される。このクラスはデータベースアクセスのカプセル化も行う[1]。オブジェクトの生成後は、保存メソッドで新しい行がデータベースに追加される。 オブジェクトが更新されると、データベースの対応する行もまた更新される。ラッパークラスはテーブルあるいはビューの各カラムに対
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
並列データベースシステムの概念と原理
データベース設計徹底指南
データベース技術の羅針盤
MySQL Index勉強会外部公開用
Database smells
