NoSQL-主なものについて簡単に

セルゲイ・チュレンツェフ（TextMaster）

私の名前はSergey Tulentsevです。数年前からNoSQLデータベースに興味があり、今日は私の知識と経験を皆さんと共有したいと思います。



このレポートの恩恵を受けるのは誰ですか？ これは、構造化されていると主張するレビューレポートです。 どこかでNoSQLについて聞いたことがあれば、40分後にはさらに多くのことを知るようになり、用語でナビゲートしやすくなり、プロジェクトのデータベースをより自信を持って選択できるようになります。



また、一般的なアプリケーションの例と、NoSQLデータベースの使用方法についても説明します。



少し歴史。







この用語は1998年に初めて登場しました。CarloStrozziという名前の男が彼のリレーショナルデータベースと命名しました。 ただし、それ自体を操作するためのSQLインターフェースは提供されず、XMLファイルをソーセージするbashスクリプトのセットでした。 ウィキペディアによると、このデータベースの最後のリリースは2010年にリリースされ、何らかの形で正常に機能しました。 彼女のことは報告書の準備の過程でしか知りませんでしたが、以前彼女のことを知らなかったのは良いことだと思います。



2009年に、サンフランシスコの他の男たちが新しい分散データベースについて議論する会議を開催し、ツイッター用のハッシュタグ、長い短いハッシュタグが必要になりました。 誰かがNoSQLハッシュタグを思いついて、SQL、ACID、およびあらゆる種類のクールなものがあるデータベースがあることを強調しましたが、これを持たない他のデータベースについて説明します。 人々はハッシュタグが好きでした、それは制御不能になって、まだインターネットをサーフィンします。



NoSQLという用語。 2つの解釈があります。1つは古いもの、もう1つは新しいものです。 元のものはNoSQLです。つまり、一般に、SQLはありませんが、このデータベースを操作するための他のメカニズムがあります。 そして、新しい解釈は「SQLだけではありません」-これはSQLだけではありません。 おそらくSQLですが、他にも何かがあります。



そのようなサイトhttp://nosql-database.orgがあります-これは異なるNoSQLデータベースのリストです。 説明、タイプ、公式プロジェクトへのリンク、知っておく価値のある簡単な重要事項が含まれています。 自由に登って読むこともできますが、最も人気のあるものについて説明します。



データベースの最も一般的な分類は、データ型によるものです。



重要なタイプは、キー/値ストア、またはキーと値のペアのストレージです。







これは最もポピュラーなタイプであり、同時に最も単純でもあります。最も原始的なインターフェイスを備えています。 そして、理論的には、そのようなデータベースの最小インターフェースは、取得、設定、削除の3つの操作のみで構成されています。 おそらくこのインターフェースを満たすデータベースがいくつかありますが、通常、現代の一般的なデータベースはより多くの利点を提供します。たとえば、一度に多くのキーを取得したり、キーの有効期間を設定したり、キーの有効期間を取得したり、サーバーの状態を確認するサービスチーム...



このクラスの顕著な代表はMemcashedです。 そして、これはRedisのおかげです。 なぜストレッチで？ 彼は実際には彼が単独でいる独自のカテゴリを持っているため、このカテゴリは「データ構造サーバー」と呼ばれます。 いくつかのタイプのキーと想像を絶するものを作成するために使用できる非常に豊富なコマンドセット（150以上）があるため、このカテゴリに属しますが、このカテゴリを考慮しない場合は、キー/値でここに起因することができます。 Riakもあります。



ドキュメント指向データベース。







これは、前のカテゴリの非常に複雑なバージョンです。 これにより複雑さが増します。また、ボーナスも提供されます。値は、読み取りまたは削除以外の操作ができない不透明なテキストBLOBの種類ではなくなり、値をさらに微妙に操作できるようになりました。 ドキュメントの一部のみが必要な場合は、それを読むか、一部のみを更新できます。



通常、このタイプのデータベースには、豊富なドキュメント構造が含まれています。 木。 おおまかに任意のJSONを想像すると、想像できるあらゆるJSONをそのようなデータベースに書き込むことができます。 そして、通常、広告では、プレスリリースによると、JSONをデータベースに入れて分析することができます。 通常、問題は最初の項目だけで発生するのではなく、実際にはデータベース内のJSONの配置で発生し、その後微妙な違いが始まります。



典型的な代表者は、MongoDB、CouchDB、ElasticSearchなどです。



列データベース。







彼らの長所は、多数の属性を持つ大量のデータを保存できることです。 数十億のレコードがあり、各レコードに300の属性がある場合、これは列データベースにあります。



たとえば、リレーショナルデータベースとは少し異なる方法でデータを保存します-リレーショナルデータベースは行に保存します。 1つの行のすべての属性は横に並んでいます。 これらは逆のことを行い、列を個別に保存します。



ファイルがあります-それはすべての30億レコードからこの列のすべてのフィールドを保存します、すべては近くに保存されます。 したがって、別の列は別のファイルに格納されます。 このため、列のデータ型に関する情報を使用して、改善された圧縮を適用できます。 また、たとえば300列のうち3列が必要な場合、リクエストを高速化できます。残りの297列をロードする必要はありません。



代表者はHBase、Cassandra、Verticaです。 ちなみに、VerticaにはSQLインターフェイスがありますが、依然として列データベースです。



グラフデータベース。







グラフ処理用に設計されています。 念のために、グラフは離散数学、つまりエッジで接続された頂点のセットから得られるものであることを思い出させてください。 興味深い困難なタスクを見ると、そこにグラフが見つかる可能性が高くなります。 たとえば、ソーシャルネットワークは1つの大きなグラフです。 道路ネットワークとルーティング、製品の推奨。



これらのデータベースの長所は、特殊化のために、グラフに対してあらゆる種類の操作を効果的に実行できることですが、同じ特殊化のため、あまり一般的ではありません。



それでも、すべてのタスクにグラフがあるわけではありません。グラフがある場合、それはおそらくそれほど大きくなく、リソースによって、新しいデータベース全体をプロジェクトにドラッグするよりも、何らかの種類のグラフ処理をアプリケーションでひざにかける方が安価です。従う必要があります。 そして、この新しいデータベースには多くの問題があります。 私の練習ではそうでした。



マルチモデルデータベース。







これらは、以前のカテゴリからの2つ以上のカテゴリを同時に含むデータベースです。



必要に応じて-文書を作成し、必要に応じて-グラフを作成します。 たとえば、FoundationDBにはメインレイヤーであるキー/値があり、SQLレイヤーはこのレイヤーの上に何らかの形で適合しています。 配布キットをダウンロードしてニュースレターにサインアップし、毎週メールを送られましたが、配信キットを起動して起動することができず、その仕組みを感じました。 数か月前の3月にAppleがこれらのユーザーを購入し、サイトから配布ダウンロードへのすべてのリンクをすぐに削除したため、今では成功しません。現在、この製品はパブリックドメインに含まれていないようです。 彼らは購入されたので、彼女はおそらくうまくいった。



誰かがそれらを購入するまで、私たちが触れる機会がもう2つあります。



データの保存方法に応じた分類がまだあります。







データをまったく保存しないデータベースがあり、すべてがメモリに保存されます。 したがって、プロセスを再起動すると、データが失われます。 解決方法は2つあります。復元できない重要なデータを保存しないか、レプリケーションを積極的に使用します。 重要でないデータ-これは、たとえば、キャッシュです。キャッシュがどこかに消えた場合、アプリケーションは落ちず、キャッシュが回復してウォームアップするまで減速しますが、致命的なことは何も起こりません。



このモードは、パフォーマンスを高速化するために使用される場合があります。 たとえば、Redisを見てください。 1秒あたり数十、数十万の操作を処理できます。 もちろん、一部の人々はこれを利用して最大限にロードしますが、データストレージモードで動作する場合、つまり スナップショットをリセットするか、ログに書き込むと、ディスクはこれを実行できなくなり、ディスクを操作するとサーバーの速度が低下します。 したがって、このトリックを適用できます。3つのRedis'ov、1つのマスター、2つのスレーブのシステムを使用します。 マスターでは、すべての永続性をオフにし、ディスクにまったく触れません。マスターであるため、そこに書き込みます。 最初のスレーブでは、永続性も無効にし、そこから読み取ります。 そして、最後の奴隷-誰もそれに触れず、それを読んでいない、そしてそれで私たちは永続性をオンにします。 そして、彼は、設定に従って、データをディスクに保存します。 災害が発生した場合、復旧可能なデータのコピーが作成されます。



Redisには、データをディスクに保存できる2つのモデルがあります。 まず、スナップショットを保存できます-これは現時点でのデータベースのキャストです。 このキャストを適切にするために、Redisはプロセスのコピーを作成し、マスターに発生するレコードによってキャストが破損しないようにします。 そして、このフォークは誰もこのスナップショットに書き込みをしないため、すでにこのスナップショットを保存しています。



このメソッドは、追加のメモリを必要とすることを除いて非常に優れています。 サーバーで発生するアクティビティによっては、最大2倍のメモリが必要になる場合があります。 2 GBのデータベースがある場合、スナップショットを保存するために別の2 GBを空けておく必要があります。



ログにデータを書き込むように構成することもできます-これは別の手法です。 つまり、書き込みコマンドが彼に届くと、彼はすぐにそれをログにすぐに書き込み、動作し続けます。 これら2つのモード（スナップショットとログ）は独立していますが、どちらか一方、または両方を一緒に構成できます。 一般に、このログはここでのみ追加されます-これはプラスであり、すでにログに入力されたデータは変更されず、破損することはできません。 そのため、通常、このログは別のヘッドを持つ別のディスクにこのログを配置します。このディスクでは、Redis以外は何もせず、ディスクヘッドには触れません。 そして、この頭は常にファイルの終わりを指しています。 また、ファイルの最後に新しい操作を書き込むことは、他のアクティビティが発生する通常のシステムで発生する場合よりもはるかに高速です。



MongoDBなどの他のデータベースには、インプレース更新と呼ばれる異なるモデルがあります。 データベース、データファイルのコピーが1つあり、それらを直接「ライブ」で変更します。 これはあまり安全な方法ではありません。たとえば、変更中に電源が切れた場合は、データベースが破損しているため、責任があります。 そのため、いくつかのバージョンの前に、ログを添付していました-制御ログを呼び出し、デフォルトで有効にしました。 したがって、2つのレプリカなしでMongoを実行できるようになり、データが損なわれない可能性があります。



NoSQLについて言えば、CAP定理に言及することはできません。それは2つのブーツのようなものです。







定理は2001年に定式化され、その妥当性を失い、一般的に語る価値がないと考える人もいますが、言及する価値はあります。 このように聞こえます：分散システムは、次の3つの特性のうち2つ以上を同時に持つことはできません-可用性、一貫性、およびパーティションの許容範囲です。



実際、デフォルトではパーティションの許容範囲はどこにでもあるため、アクセシビリティまたは一貫性の2つの選択肢しかありません。 私は、ネットワークが切断された場合、ネットワークが切断された場合に自力で切断されるようなネットワーク切断に耐えることができないシステムを知りません。



可用性は、分散システムがあり、そのノードのいずれかを使用し、回答を受け取ることが保証されている場合です。 データをリクエストすると、このデータの古いバージョンを取得できますが、エラーではなくデータを受信するか、このサーバーに到達しない可能性があります。 データを受け取った場合、システムは利用可能です。



対照的に、システムは調和させることができます。 一貫性とはどういう意味ですか？ あるノードでデータを記録し、しばらくして別のノードでこのデータを読み取ろうとすると、システムに一貫性がある場合、他の場所で記録したデータの新しいバージョンが取得されます。



したがって、分散システムは、APまたはCPの2つのキャンプのいずれかに関連します。







実際には、3番目の秘密クラスがあります-それは単なるPですが、彼のシステムがそのようなものであることを認めたがっているデータベースメーカーはありません。 つまり、Pだけの場合、アクセシビリティも一貫性もありません。



したがって、システムがCP（つまり、一貫性とパーティション許容値）自体を呼び出す場合、中断時に（たとえば、クラスターがあり、2つのデータセンター間に間隔があり、データセンター間の接続が切れている場合）一貫したシステムですか？ ノードに目を向けると、ノードは、このレコードを確実に提供できないこと、たとえばシステムのほとんどのノードと通信していないことがわかると、このレコードのアプリケーションを単に拒否し、失敗します。 その後、接続が復元されると、アプリケーションは再試行でき、成功する可能性があります。



また、システムがAPと呼ばれる場合、古いデータを返すことでアプリケーションの要求を満たすために最善を尽くします。書き込み要求を受け入れてどこかに書き込み、クラスター全体で実行できます。 ここには微妙な違いがあります。 たとえば、クラスターを2つに分割し、両方の部分に書き込む場合、競合が発生する可能性があります。 ある部分では1つのキーに1つのデータを書き込み、別の部分では別のデータを書き込みました。接続が復元されると、問題が発生します。データのどのバージョンが正しいのでしょうか。



特にAPシステムの場合、ロシア語への大まかな翻訳で-最終的な一貫性-という用語を思い付きました。これは、競合するエントリがなければ、いつかクラスターが調整された状態になることを意味します。 。



しかし、現実の生活では、紛争の不在に頼る必要はなく、紛争にどのように対処するかを事前に考えなければなりません。



競合するエントリが2つある場合の最も簡単なオプションは、時間の競合を解決することです。大まかに言えば、最後のエントリがすべての勝者よりも遅くなります。



さらにいくつかのシステムは、このすべてをアプリケーションにダンプします。 アプリケーションがデータを読み取ろうとすると、データベースは競合があることを認識すると、競合するすべてのバージョンをアプリケーションに返します。アプリケーション自体は、独自のロジックによって導かれ、正しいバージョンを選択してデータベースに提供する必要があります。



よりスマートなアプローチは、不可能ではないにしても非常に難しい競合を引き起こすデータ型を使用することです。 たとえば、データ型は複数です。 クラスターが壊れていて、半分にメンバーAを追加し、残りの半分にBとCを追加した場合。接続が復元されたら、これらのレコードを保持するのは非常に簡単です。結果セット（A、B、C）。



別の例はカウンターです。 カウンターを個別にインクリメントし、接続が復元されたら、それらを追加して、結果のカウンターを取得します。 Riakデータベースには特別な用語があります-CRDT-競合のない複製データ型を表します。 略語により、興味がある場合はグーグルで検索できます。



NoSQLの使用について話しましょう。 いつ使用しますか？

• 高いスケーラビリティが必要な場合。
  
  
  
  このタイプのデータベースを使用する最も重要な理由ではないにしても、これは最も重要な理由の1つです。複雑さが軽減されているため、拡張が容易だからです。 以前にスケーリングの主な負担がアプリケーションにかかっていた場合、たとえば、20個のmemcacheがあり、アプリケーションがそれらを1つのハッシュリングに収集して信頼性とスケーラビリティを確保している場合、最新のデータベースはすべてを行います。何も設定する必要さえありません。 ノードを実行するだけで、クラスター自体が検出され、クラスターに入り、データの一部がダウンロードされ、データの一部の提供が開始されます。 したがって、望ましい線形スケーラビリティを実現します。これは、NoSQLの世界の聖杯の1つでもあります。
  
  
  
  線形スケーラビリティとは、クラスターリソースを増やすことで、クラスターの特性を比例的に向上させることです。 サーバーの数を2倍にしました。生産性は2倍になりました。 線形にスケーリングする場合、非常にクールです。
  
  
  
  
• プロトタイピングも重要なポイントです。
  
  
  
  従来、リレーショナルデータベースでは、プロジェクトの前とプロジェクト中の両方で、一定量のメンテナンスが必要です。 つまり プロジェクトを開始する前に、データベーススキーマを検討し、作成し、それを使用してデータベースを起動してから、プロジェクトの実行中に新しいビジネス要件が発生するか、何らかの誤りがあることがわかった場合は、列を追加する必要があります...多くの場合、これはブロッキング操作です。 これはどういう意味ですか？ アプリケーションを配置する必要があります。 数日間、1分間オフにするのは、状況の複雑さに依存するか、スキームの更新プロセスを手動で実行します。 つまり 回路をスレーブにロールし、マスターにアップグレードし、他のすべてのスレーブをそれに切り替えて、回路を1つずつロールします。 その前に、アプリケーションのエラーが発生しないように、新しいバージョンと古いバージョンのデータベースを同時に使用できるコードをロールアウトすることを忘れないでください。 これはすべて完了しましたが、面倒です。 できないときにどうして？ したがって、回路図のないデータベース、特にドキュメントの向きは、これに魅了され、新しいデータスキームを使用するだけで、ファイルデータに表示されるだけです。 大まかに言って、フィールドを追加してもまったく問題はありません。 , , . MongoDB , Postgres .
  
  
  
  
• — .
  
  
  
  : , , , - , , , .
  
  
  
  
• .
  
  
  
  , , . Mongo , .. , , 20- join', Mongo, Mongo. 利益
  
  
  
  
• — .
  
  
  
  , , . , , Redis. . Redis' , 10 , , .
  
  
  
  
• — .
  
  
  
  , e-mail. . , e-mail. , , e-mail' . , - worker e-mail.
  
  
  
  
• .
  
  
  
  , — , , . facebook, , , . , Amazon S3 . Riak' Mongo .
  
  
  
  . , Riak' — 2-3- , Mongo — 16 , , 16 .
  
  
  
  
• .
  
  
  
  - Redis, Riak Casandra .
  
  
  
  
• — « ».
  
  
  
  
  
  
  
  , , ? , , , SELECT COUNT(DISTINCT) — . , -, - , Hadoop Hadoop' .
  
  
  
  — . . — HyperLogLog. , . Salvatore ( Redis'), . , , , , 12 , 0,8%. — , .. 2 7 — 12 . , . ( ).
  
  
  
  
• — .
  
  
  
  . , , .
  
  
  
  
• .
  
  
  
  , - , Sphinx ElasticSearch.
  
  
  
  

NoSQL ?

• .
  
  
  
  , , . , : « » « , », .. , - . , , . Hacker News Redis', , , , - .
  
  
  
  
• , « MongoDB» — Sarah Mei.
  
  
  
  MongoDB — . , — , — , — , , , — ! , , , . — , , , , — , 5 — .
  
  
  
  , , , , . ID', ID' . , .
  
  
  
  
• Embedding — .
  
  
  
  
  
  
  
  — . , e-mail, , . — … — .
  
  
  
  , , , , ( ) — , 10 . 5 .
  
  
  
  TextMaster' . , — , — . , .. . . .
  
  
  
  2 , , , . , .. , . つまり Embedding' .
  
  
  
  
• Embedding- — Embedding.
  
  
  
  1- — MongoDB — - . , , Mongo , , , « «ruby»», ««ruby» «nosql»» ««ruby», «nosql»» — . , , — , . -, 2- , ID' , , .
  
  
  
  
  
  
  
  , , .. . ID' , .. .
  
  
  
  
• .
  
  
  
  « JSON, ». — . , , , .
  
  
  
  
• .
  
  
  
  Stack Overflow ( ) « 5- , ?». . , « ?». つまり , , - , . , MongoDB — — , . - .
  
  
  
  

.







, . , — , . , -. . , - , . — . - — , , , - , - , - 3- service pack'a. , , .

連絡先

» sergei.tulentsev@gmail.com

» twitter

» tech.tulentsev.com

— HighLoad++ Junior .



また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。 私たちの教科書にはすでに30以上のユニークな資料があります。 接続してください！



— " - ", , HighLoad++ Junior . NoSQL ? 確かに！