Google Summer of CodeのMariaDB：GSoC16のまとめ

MariaDB、最新のGSoCでのプロジェクト、学生、 王、キャベツについてのやや遅れたレポート。



最後-2015th-GSoCは非常に失敗したことが判明しました。 合計で8人の学生がいましたが、多くは夏の途中で（中間評価で）失敗し、3人はカメルーンの同じ大学の（そして明らかに同じコースの）優秀なアプリケーションでしたが、「完全に」という言葉からは何もしませんでした、まあ、1か月半でコメントの1行が修正されたかもしれません。 そして、中期的に失敗した後、彼らは私たちの決定をGoogleに上訴しようとし、霧のような脅威を含むメールを送ってくれました。 たとえば、多くの学生が失敗して自分のイメージを損なうのは良くありません。来年、Googleは場所を与えません。



しかし、Googleは従わず、彼らに与えました。 そして今年は、おそらく対照的に、非常に成功したことが判明しました。



今年、54人の学生が主張する10スロットが割り当てられました。 過去1年間の悲しい経験を考慮して、受け入れられたすべての学生が異なる大学の出身であることを確認しました。ハッキングする場合は、互いに独立しています。 それはいつものことでした-何人かの学生が事前に私たちのメーリングリストに書き込み、IRCに登場し、プロジェクトについて議論しました。 2人の学生が実際のプロトタイプを作成しました。 もちろん、そのようなアクティブなものはすべて受け入れられました。 残りは船外に残され、競争は大きかった。 受け入れられた10人の学生から、次のことが判明しました。

• 1つのプロジェクトはMHA向けでした。 MariaDBは包括的な組織として機能し、プロジェクトはMariaDB / MySQL / Perconaエコシステム内の任意のものになります
• 1つのプロジェクトはMaxScale用でした。つまり、サーバー用でもありませんでした。 上記参照
• 一人の生徒は何もせず、7月に中退しました
• 3人に奇妙なことが起こった-彼らはうまく機能し、問題は予見されなかった。 そして突然、8月末にGoogleはデータに矛盾が見つかったと書いており、不正行為の疑いがあり、プログラムから除外されました。 それは非常にいことが判明し、人々は夏の間ずっと働いていました。 しかし、試みましたが、状況に影響を与えることはできませんでした。
• 5人の学生が最後まで行き、プロジェクトを完了しました。 50％は私たちにとって大成功です。 これら5つについて-以下で、より詳細に。

ダニエル・メドベージェフ：PAD照合なし

ドキュメンテーションに記載されているように（実際には簡潔に、行間で）、異なる長さの文字列を比較する場合、MariaDBサーバー（およびPerconaサーバーとMySQL）は、長さが等しくなるまで（つまり、実際には補完されない、短い文字列をスペースで補完します、ただし、結果は補足のようになります）。 次のようになります。

MariaDB [test]> select "abcd" > "abc"; +----------------+ | "abcd" > "abc" | +----------------+ | 1 | +----------------+ 1 row in set (0.00 sec) MariaDB [test]> select "abc\t" > "abc"; +-----------------+ | "abc\t" > "abc" | +-----------------+ | 0 | +-----------------+ 1 row in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の場合、 '\t'



スペースより小さいため、長い行は辞書的に短いよりも短いです。 これはすべて標準的です。 しかし、そうではありません。 SQL標準では、照合にはこのプロパティがあり、PADSPACEまたはNOPADになります。 前者の場合、比較するとそれぞれ短い行がスペースによって達成されますが、後者の場合、これは起こりません。 したがって、これまでのすべての比較はあたかもPADSPACEであるかのように行われたことがわかりました。 そして今、ダニエル・メドヴェージェフは私たちにパッド照合をしません。 効果は常に顕著ではありませんが、次のとおりです。

 MariaDB [test]> set collation_connection=utf8_general_nopad_ci; Query OK, 0 rows affected (0.00 sec) MariaDB [test]> select "abc\t" > "abc"; +-----------------+ | "abc\t" > "abc" | +-----------------+ | 1 | +-----------------+ 1 row in set (0.00 sec)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このプロジェクトは完全に完了し、現在MariaDB 10.2.2にあります。

Galina Shalygina：マージ不可能なビューへの条件プッシュダウン

ガリナは私たちにとって初めてではありません。 彼女はMariaDBの最も複雑なサブシステムの1つであるクエリオプティマイザーに精通しており、再帰CTEと非再帰CTEの WITH



演算子の実装の作成者です。



このGSoCでは、Galinaはメインクエリとマージできないビューを最適化することを選択しました。 もちろん、最良の方法は、マージメソッド（ビューマージ）を使用してビューでクエリを実行することです。この場合、ビューはメインクエリのマクロとして置換されます。 たとえば、次のようなクエリ：

 CREATE VIEW v1 AS SELECT a1+b1 AS c1, d1 FROM t1 WHERE e1>5; SELECT x2 FROM v1, t2 WHERE c1=y2 AND d1=10;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下に変換できます：

 SELECT x2 FROM t1, t2 WHERE a1+b1=y2 AND d1=10 AND e1>5 ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここでオプティマイザーは使用されるすべてのテーブル、すべての条件を確認し、最適なプランを選択できます。 ただし、すべてのビューがこの方法で最適化できるわけではありません。たとえば、ビューでGROUP BY



が使用されている場合、マージは実行できません。 このような場合、プレゼンテーションを別のクエリとして実行し、結果を一時テーブルに保存してから、メインクエリで使用する必要があります。 その結果、オプティマイザーは「全体像」を認識せず、両方の要求を個別に考慮することを余儀なくされます。 つまり、前の例では、テーブルt1



からフェッチするときに条件d1=10



を使用できません。



ここで、新しい最適化が有効になります。 ビューをメインクエリに置き換えることができず、オプティマイザーが一時テーブルを使用して個別に読み取るように強制された場合、この一時テーブルに入力するときにメインクエリの条件を使用して、何らかの方法でビューにプッシュするようになります。 つまり、上記の例では、オプティマイザーはそのようなクエリの結果を一時テーブルに保存します。

 SELECT a1+b1 AS c1, d1 FROM t1 WHERE e1>5 AND d1=10;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、リクエストの実行を桁違いに高速化できます。



この作業も完全に終了し、10.2.3ですでに利用可能です

Shubham Barai、Sachin Setiya：任意の長さのUNIQUE制約

タスクは、任意の長さの一意性制約を実装することでした。 通常、テーブルの作成時に誰かがUNIQUE(a,b,c)



書き込むと、MariaDB（PerconaとMySQLの両方）がフィールドa、b、cにインデックスを作成します。 したがって、制限が取得されます。フィールドの組み合わせの一意性は、これらのフィールドの合計長がインデックスキーの最大許容長を超えない場合にのみ保証されます。 しかし、これは非論理的です！ 「インデックス」は、データへのアクセスを最適化する方法であり、SQL標準にはまったく含まれていません。 また、UNIQUEは、SQL標準から直接のデータの論理的な制限であり、クエリアクセラレーションの特定の実装のいくつかの制限のために、なぜ苦しむべきかは完全には不明です。 私たちの解決策は、隠された別のフィールドを作成することでした。ユーザーはそれを表示する必要はなく、UNIQUEの目的のハッシュをそこに書き込みます。 また、このフィールドでは、通常のインデックスをすでに作成できます。 その中に記録するときは、競合を探す必要があります。競合がある場合は、競合するレコードを引き出して値を直接比較すると、ハッシュは結局一致する可能性があります。 さらに、MyISAMは既にそれを行う方法を知っており、それを行っています-これがSELECT DISTINCT



仕組みです。 しかし、ユーザーテーブルの場合、これは利用できませんでした。 修正したかったもの。



このタスクでは困難な状況が発生しました。 GSoCで数年間提供してきましたが、誰も望んでいませんでした。 そして今年、2つのアプリケーションが彼女に届きましたが、どちらもかなり賢明です。 その後、2人の生徒がワーキング（！）プロトタイプを作成しました。これは、GSoCのメンターとして8年間で初めてのことです。 そして再び、両方（！）と言いました、彼らは言う、それはあまりにも簡単で、InnoDBでそれをやろう。 私は両方を取らなければなりませんでした。 しかし、そのうちの1つを少し修正しました。



ShubhamはInnoDBのジャングルに飛び込み、そのインデックス、ログ、トランザクション、リカバリ、その他の魔法に対処し始めました。 そして、SachinはMyISAM内にこの機能が既に存在していることを忘れたふりをして、プロトタイプを捨て、モーターに依存しない方法でサーバーレベルですべてを実装し始めました。 その結果、両方ともタスクを正常に完了し、低レベルの実装はわずかに高速になり、高レベルの実装は異なるエンジンで動作し、オプティマイザーはこれらの不可視フィールドを使用してクエリを最適化し、他の興味深い利点をもたらします。 私たちはまだ何を決めるかを決めていません-すべてがとてもおいしいです... 10.2では、おそらくそこにたどり着かないでしょう。 おそらく10.3になります。

サチン・セティヤ：隠し柱

そして、これは前述のパンです。 不可視フィールドを作成するため（また、仮想であり、このハッシュをディスクに書き込むことはできません）、Oracleでは不可視列と呼ばれ、DB2では暗黙的に非表示列を追加することにしました。 シンプルな場合は、フィールドを作成するときに、「非表示」であることを示すことができます。 その後、 SELECT *



およびINSERT INTO table VALUE (...)



は認識されません。 指定された値を表示したり、それに応じて書き込んだりしないでください。 しかし、このフィールドに名前を付けて（チーム内で）言及すると、通常の表示フィールドのように動作します。 これは、動作中の（おそらくクローズドソースでも）アプリケーションを壊さないようにスキームを拡張することを目的としていました。 非表示のフィールドが追加され、古いクエリでは表示されず、新しいフィールドでは名前で呼び出されるため、すべてが機能します。



異なる「不可視性のレベル」を追加することで、このアイデアをいくらか拡張しました。 OracleとDB2の両方で、最初のレベルは上記のとおりです。 まあ、まだゼロがあります-すべてが見える、それは面白くないです。 第2レベル-フィールドはSELECT



でのみ、名前で明示的に言及されている場合にのみ表示されます。 つまり、 INSERT



/ UPDATE



は表示されません。その値は変更できません。 また、 CREATE



/ ALTER



は表示されません-作成または削除できません。 自動的に作成されます。 例は、ROWIDおよびその他の疑似フィールドです。 3番目のレベルでは、フィールドはどこにもまったく表示されません。 これは、ハッシュで非表示フィールドを作成するために必要なものでした。 また、 INDEX(a+b)



などの機能インデックスにも使用できます-また、不可視の仮想フィールドを作成してインデックスを作成します。 そして、あなたは...一般的に、このパンが登場したとき、アイデアはすぐに来ました。



前のタスクの一部として、これも10.3のみに分類される可能性が高い

Varun Gupta：SQL集約関数

また、長い間考えられてきたアイデア。 しかし、実際にはこのGSOCのみを策定できました。 標準ではカスタムSQL関数の作成方法が規定されており、MariaDBはもちろんこれを行うことができます。

 CREATE FUNCTION COUNT_X(x INT) RETURNS INT RETURN (SELECT COUNT(*) FROM data_table WHERE value=x);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、これらは普通の機能です。 ただし、SQLで集計関数を作成することはできません。 少なくとも標準にはありません。 Oracle、PostgreSQL、およびHSQLDBなどにもあります。 MariaDBになりたかった。 私たちは長い間構文について考えました-標準はなく、誰もが独自の方法を持っています。 他の人と同様に比較。 その結果、彼らは自慢しないことを決め、他のみんなと同じように、つまり自分たちのやり方でやった。 もちろん、私たちのオプションはより自然で簡単です。 おそらく、Oracle / PostgreSQL / HSQLDBでこの構文を発明した人たちは、彼らのオプションが最適だと考えています。



次のように機能します。

 CREATE AGGREGATE FUNCTION agg_and(x INT) RETURNS INT BEGIN DECLARE z INT DEFAULT 65535; DECLARE CONTINUE HANDLER FOR NOT FOUND RETURN z; LOOP FETCH GROUP NEXT ROW; SET z= (z&x); END LOOP; END
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

比較のために、脚がどこから成長するかを理解するために、表の列のすべての値のANDを計算する完全に記述された標準の非集計関数を次に示します。

 CREATE FUNCTION col_and() RETURNS INT BEGIN DECLARE x INT; DECLARE z INT DEFAULT 65535; DECLARE CONTINUE HANDLER FOR NOT FOUND RETURN z; DECLARE cur CURSOR FOR SELECT col FROM data_table; OPEN cur; LOOP FETCH cur INTO x; SET z= (z&x); END LOOP; END
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、ロジックは同じで、グループのすべての値を通過する集計関数に特別なカーソルが渡されます。



残念ながら、これも10.2に該当する可能性は低いです。 プロジェクトもほぼ完了していますが。



今年、何らかの理由で、たとえば4分の3までに完了したプロジェクトは1つもありませんでした。 だから投げて、残念で不便を感じる。 彼らが望んだことはすべて行われました。 そしてそれは素晴らしいことです！



来年を楽しみにしています...