Demystifying JOIN Algorithms
Joins are an important class of operations in databases and data pipelines. There are many kinds of joins in SQL databases, but this post will focus only on the INNER JOIN. 1 It is possible to make the JOIN between two large tables very efficient if the result is going to be small. That being a common scenario in practice, makes JOINs an interesting topic of research. A naive JOIN algorithm can be
MySQLのGROUP_CONCATがアツい - Qiita
http://qiita.com/advent-calendar/2015/gaiax 初めまして、GaiaxAdventCalender 4日目担当の技術開発部の金田と申します。 既に熱い記事ばかりなので後続の人たちのハードルを下げる為に小ネタで行きたいと思います。 GROUP_CONCATという関数がMySQLにあるんですがそれがアツいのでみんなに教えたいという記事です。 1対多の関係のとき 普通にテーブル設計してると1対多の関係(has many)になるリレーションシップをテーブル間で張ることが多いですよね。 まぁこんな感じで。 ざっくりと記事に対して複数のタグが設定できるような作りを想定してみます。 Entryから出た線がTagは複数に枝分かれしているのがhas manyの関係です。 で、こんなデータが入ってます。 取得するとき 記事と、それに付随したタグの一覧を取得したいときは当
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
深い親子関係のテーブル設計
2. 自己紹介 @yuba 株式会社インターコム 型と制約大好き人間 ブログとかQiitaで書いてる記事がこんな感じです。 論理削除と一意性制約を両立させる方法・DB製品別 – Qiita トランザクションをネストしたらどうなる？ 内側だけロールバックできる？ - Qiita データベース操作でデッドロックは不可避 – C Sharpens you up 外部キー参照しあうテーブルを遅延制約で実現する – C Sharpens you up SQL Serverの計算列を使ってツリー構造データを完全に制約付ける – C Sharpens you up SQLのカラム制約はテーブル制約と等価 – C Sharpens you up
Where狙いのキー、order by狙いのキー
11. I'm yoku0825 ● とある企業のDBA ● オラクれない ● ポスグれない ● マイエスキューエる ● 家に帰ると ● 嫁の夫 ● せがれの父 ● 馬鹿だからかわいいわけじゃなくて、かわいい イルカがたまたまバカだった 12. はじめに ● サンプルデータは MySQLのサンプルデータ ベース(worldデータベース)からインデック スを全て取っ払ったものです ● http://dev.mysql.com/doc/index-other.html ● コードはgithubに上げてあります ● https://github.com/yoku0825/yapc_2014 ● すごく…ウンコードです… 13. はじめに ● 原則、MySQLは1つのテーブルにつき同時に1 つのインデックスしか使いません ● Index mergeとかあるけどアレは例外だし狙って やっても速くなる
長年の議論に終止符 -- MySQL、MariaDB、PostgreSQLのオプティマイザ/エクゼキュータ比較 - interdb’s blog
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
NoSQL or NoJoin? – Daniel Lemire's blog
Several major players built alternatives to conventional database systems: Google created BigTable, Amazon built Dynamo and Facebook initiated Cassandra. There are many other comparable open source initiatives such as CouchDB and MongoDB. These systems are part of a trend called NoSQL because it is not centered around the SQL language. While there has always been non SQL-based database systems, th
SQLに対するMySQLと、NoSQLに対するMongoDBは似ている――主に有害な意味で | Yakst
MySQLのジョインが遅いことでSQL全般のジョインが遅いと思われることがあるように、NoSQLの中でもMongoDBが比較的広く使われるようになってきた今、MongoDBの欠点がNoSQLの欠点だと勘違いされるようになってきているのではないか。「SQL Performance Explained」著者Markus Winand氏の指摘。 昨日(9/30)の夕方、私は「SQLに対するMySQLのように、NoSQLに対するMongoDBにはよくない面がある」とツイートをした。あいにくそのツイートには説明が欠けていた。とはいえ1つのツイートに全ての必要な説明を含むことはできないだろうから、この記事で説明しよう。ツイートへの返事として受け取ったいくつかの疑問に答えられればと思う。 まず最初に、私は多言語永続化の考え方に賛同はするが、NoSQLの熱狂的支持者ではないということを知っておいてほしい。
「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 のブログ
私は、ソーシャル系とは縁遠い仕事ばっかりしているのですが、そういう依頼も若干増えてきたので話題になっている「艦これ」をお盆にやってみた。 残念ながら、「艦これ」の魅力は分からなかった。しかし、ミッションを用意されると、「クリアーしたい」という欲求から意地になるのは、何となく理解できました。それより、同時に始めた「Clash of Clans」には嵌まりました。気になっていた「ゲームの中に如何に自然に課金システムを取り入れるか」という課題についても、個人的には「Clash of Clans」の方が上手に解決しているように思います。 「艦これ」は、同時アクセスが10万以上あって、何度かシステム障害があったとのこと（そりゃあるでしょうが……）。私の興味の方向性は、課金システムであったり、システム構成にあるので、「艦これ」のシステム障害の方が強い興味の対象になります（苦笑） というわけで、「ソーシ
SQL JOINs visualized
Copyright © 2009-2015. All rights reserved. This blog is called myNoSQL and it is written by me, Alex Popescu, a software architect with a passion for open source and communities. It records my readings, learnings, and opinions on NoSQL databases, polyglot persistence, and distributed systems -- subjects that I'm passionate about. The opinions expressed here are my own, and no other party necessar
Probabilistic M2M Relationships Using Bloom Filters
I’d like to present a proof-of-concept I developed as an alternative method for storing many-to-many relationships in traditional SQL databases. A standard M2M relationship, as represented in SQL, looks like this: CREATE TABLE movie ( id SERIAL PRIMARY KEY, title VARCHAR(255) ); CREATE TABLE person ( id SERIAL PRIMARY KEY, name VARCHAR(255) ); CREATE TABLE movies_people ( movie_id INTEGER REFERENC
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Query Optimizations
IDEA * IDEA