MongoDBの束縛でダウン

私たちの多くはかつて熱意を持ってMongoDBを習得するために駆けつけました。本当に美しいのは便利なJSON形式であり、柔軟なスキーム（正確には完全な不在）です。 しかし、しばらくして、すでにMongoが確実に「保護」されているとき、失望がプロジェクトに設定されます。 最も単純なクエリでは、ドキュメントを絶えず突く必要があり、もう少し複雑なクエリでは、1日の作業時間をほぼ終わらせることができます。また、異なるコレクションに参加する必要がある場合は...



そして今、誰かがJSONの部分的なサポートでPostgresに戻ってきています...



しかし、幸いなことに、それはすでに偽造されており、Mongoの本格的な代替品であり、本格的な半構造化ビッグデータDBMS AsterixDBはすでに急いでいます。 このプロジェクトは、伝説的なDBMSのパイオニアであるMichael Stonebreakerの見習いであるUCI教授Michael Careyが主導しています。



このプロジェクトは、単にビッグデータの分野における研究イニシアチブとして始まり、当初はMapReduceとSQLの共通スタックの作成に焦点を当てていました。 しかし、ほんの数年前、ビッグデータJSON DBMSを構築することが決定されました。 Michael Careyによると、「AsterixDBはMongoで正しく処理されています。」AsterixDBの主な機能は何ですか？



1.スキーム。 はい、スキームはまだ有用であり、完全に取り除く必要はありません。 JSONリポジトリでは、フィールドの一部は事前に知られており、修正されており、変更できません。 しかし、当然、Asterixはデータスキーム全体を完全に設計することを強制しません。 あなたはスキームなしで生き続けることができます。 ただし、少し順序を変えたい場合は、固定されたフィールドをデータスキーマに配置し、残りは「オープン」のままにします。 それは何を与えますか？ 挿入中のデータのチェック、よりコンパクトなストレージ、データのある場所の視覚的表現。



例：

タイプTwitterUserTypeをopen {として作成します。
        スクリーン名：文字列、
         lang：文字列、
         friends_count：int32、
         statuses_count：int32、
        名前：文字列、
         followers_count：int32
     }

TwitterUserTypeデータ型を作成し、リストされているすべてのフィールドは固定されていますが、型が開いているため、任意の他のフィールドを追加できます。 これで、このタイプに基づいて、「親」タイプを作成できます。

タイプTweetMessageTypeを閉じたものとして作成{
         tweetid：文字列、
        ユーザー：TwitterUserType、
        送信者の場所：ポイント？、
        送信時間：日時、
        参照トピック：{{string}}、
        メッセージテキスト：文字列
     }

ここでは、タイプがTwitterUserTypeに対応する「ユーザー」フィールドが表示されます。 コードには登りませんでしたが、名前付きの型に割り当てることなく、ネストされた構造をすぐに記述することは可能だと思います。 しかし、そうでなくても、私はそのような機能がすぐに現れると確信しています。



ああ、はい、AsterixDBでサポートされているデータ型：

• ブール
• Int8 / Int16 / Int32 / Int64
• フロート
• ダブル
• ひも
• ポイント-ジオメトリ
• ライン-ジオメトリ
• 長方形のジオメトリ
• 円-ジオメトリ
• ポリゴン-ジオメトリ
• 日付
• 時間
• 日時
• 期間/年-月-期間/日-時間期間
• 間隔-時間間隔、AsterixDBは時間間隔のためのAlainのロジックを実装しますが、これは恐ろしいことですが、役に立つ場合があります

さて、ネストされたタイプ：

• 記録
• 注文リスト
• 順不同リスト

2.リクエストの言語！ Mongoのどこかで、データをグループ化し、集計し、計算されたフィールドで補完されたソースフィールドの特定のサブセットを作成する必要があります。 その後、ひどい頭痛が始まります。 そのため、AsterixDBには、緩やかに構造化されたデータ専用に設計されたすべてのSQL機能を備えた本格的なクエリ言語があります。 これは、XML DBMSで使用される機能的なXQueryクエリ言語の簡略化です。 XQueryのW3C仕様に取り組むよう読者を派遣するつもりはありませんが、もし望むなら、Wellcomeに！ AQL言語（Asterix Query Language）のミニチュートリアルを作成してみます。



クエリ言語の基礎は、FLOWR（ほぼ花）命令For-Let-OrderBy-Where-Returnです。 ここにもGroupByを挿入しますが、少し後で説明します。 これをSQLに変換すると、次のようになります。



SQLのほぼFROM句の場合、ここで実行するコレクションを選択します。 Forの後、値を持つ変数のテーブルを取得し、その上に、ほとんどSQLのように、残りの操作が適用されます。



例：後



for $x in users, $y in groups







次の形式でエントリを取得します。



($x : user1, $y : group1), ($x : user1, $y: group2), ...







これは、SQLの通常のクロス積です。



Letは追加の句です。ここでは、新しい変数を入力できます。 これは、ForタプルをFor結果に追加するのではなく、単に新しい変数とその値を追加するだけです。



OrderBy-すべてがシンプルで、SQLソートと同等です。



Where-再び、通常のフィルター、SQL Whereの完全な類似物。



戻る-ここでは、正確に何を返したいかを尋ねます。 常に列のリストを返すSQLとは異なり、ここではJSON構造をブロックできます。 そして、この句では、結果が異なる断片を生成するネストされたクエリをバングで使用します。



上記のすべてが動揺しないことを願っています。いくつかの例を見てみましょう。 最初に最も原始的なもの：

データセットFacebookUsersの$ユーザー用
ここで、$ user.id = 8
 $ユーザーを返す

FacebookUsersコレクションを選択したところ、これはMongoと同等です：db.FacebookUsers.find（{"id"：8}）



より多くの落書きがありますが、これは単純なクエリ用です。 ブリキが始まると、リクエストの整理がずっと簡単になります。



リクエストはより興味深いものになりました。ここで、結合を実行し、出力に新しいデータ型を作成します。

データセットFacebookUsersの$ユーザー用
データセットFacebookMes​​sagesの$メッセージ
ここで、$ message.author-id = $ user.id
帰る
   {
     「uname」：$ user.name、
     「メッセージ」：$ message.message
   };

すべてが明らかなようですよね？ 結合条件を設定するユーザー/メッセージのペアを介して実行する場合、returnはunameおよびmessageフィールドを含む新しいJSONオブジェクトを作成します。



次に、unameフィールドを使用して、1人のユーザーのすべてのメッセージを1つのJSONオブジェクトにグループ化します。

データセットFacebookUsersの$ユーザー用
 let $ messages：= 
    データセットFacebookMes​​sagesの$メッセージ
    ここで、$ message.author-id = $ user.id
     $ message.messageを返します
帰る
   {
     「uname」：$ user.name、
     「メッセージ」：$メッセージ
   };

ここで、サブクエリをletに変更し、すべてのユーザーメッセージのリストを$ messages変数に割り当てました。 同じことを実現する別のオプション：

 データセットFacebookUsersの$ユーザー用
帰る
   {
     「uname」：$ user.name、
     「メッセージ」： 
              データセットFacebookMes​​sagesの$メッセージ
              ここで、$ message.author-id = $ user.id
               $ message.messageを返します
   }; 

個人的には、リクエストの2番目の形式の方が好きです。データを「事前に」準備してオブジェクトに挿入する代わりに、すぐにネストされた式を記述します。



AQLにはGroupByコンストラクトもありますが、実際にはネストされたクエリに置き換えられており、必要ではありません（ただし、モノがあれば便利です）。 一方、GroupByを使用するとクエリの最適化が向上する可能性が最も高くなりますが、これはすでに効率の問題です。



実際、AQLの基本について説明しました。最後のクエリを作成します。

  
  データセットTwitterUsersの$ユーザー用
   $ user.nameで区別
   $ user.followers_count descによる注文
  制限2
   $ユーザーを返す

ここでは、いくつかの標準SQLチップを一度に見ることができます-明確な、並べ替え、制限。 リクエストが何をしているのかは明らかです。まず、ユーザー名で重複を削除し、並べ替え、最初の2つの値を返し、結果を作成します。



何を忘れましたか？ 集計？ ここではすべてが非常に簡単です-集計は、値のリストを入力として受け取るAQLの単なる通常の関数です。 AsterixDBには、おなじみのすべての集計が含まれ、同時に2つのバージョンがあります。完全にSQLと互換性があり、より人間的です（SQLは集計内でNULLを処理する方法を覚えていますか？） そしてもちろん、自分で書くこともできます。



AsterixDBで他に良いことは何ですか？ クエリ処理システムの基礎であるAlgebrixレイヤーは、将来的に分散DBMS向けの高品質なコストベースのクエリオプティマイザーを作成できる柔軟な代数システムです。 最適化は開発の初期段階にありますが、インデックスは適切に選択されているようですが、統計情報と実際の最適化はまだありません（ただし、クエリのヒントによって許容可能な結果を​​得ることができます）。 Indeskにもいくつかのタイプがあります-Bツリー、キーワード-全文検索用のインバーテッドリスト、ジオメトリ用のRツリー、同様の検索用のn-gram。



AsterixDBはJavaで記述されています。Pythonを愛する人のために、JavaまたはJythonのいずれかにUDF（ユーザー定義関数）を追加できます。



Asterixの一貫性はやや弱く、MongoDBのように、個々のドキュメントのレベルでACIDが使用されます。 一連のドキュメントまたはコレクションに影響するトランザクションサポートプランはありません。 はい、それはすべての人に合っているようです。



さて、今、原則として、MongoDBからより一般的なプラットフォームに移行することが可能になるという希望の火花を願っています。シードされ、開発者が戦うのを待つまで残ります。



まだ完了していないものは何ですか？



フォールトトレランスを備えた真のレプリケーションはまだ完了していません。 APIを使用したデータベースからの結果のストリーミングはありません（これで問題はありませんが、外部リクエストの場合、システムは結果全体を自分用に「準備」し、REST APIを使用して返します）。 クライアントライブラリはまだありません。 統計の収集から始めて、クエリの最適化に関する多くの作業が残っています。 まあ、おそらく小さなタスクの海。



したがって、傍観者を待ちたくない場合は、袖をまくり上げて、このクールなことを終わらせるのを手伝うことができます。



Asterix DBMS