noSQLを使用する前に1000回考える必要がある理由

なぜこの記事を書いているのですか？ まず、nosqlの本質と、このタイプのストレージを意識的に選択する必要がある理由についての人々の理解に貢献したいと思います。 第二に、私は志を同じくする相手に会うこと、そしておそらく議論することを嬉しく思います。 この記事が気に入ったら、新しい記事でより詳細に明らかにできる質問を聞いてうれしいです:)



nosqlソリューションは現在暗くなっているという事実にもかかわらず、人々は新しいタイプのストレージに切り替えることに消極的です。 これは正しいですか？ 私の意見では、はい。 そして、プロの道で出会ったさまざまなnosqlリポジトリの例を使用して、その理由を説明しようとします。

物語の始まり

すべての良い一日。 これは大規模なエディションでの私の最初の「ペンテスト」です。興味深い結果が得られることを願っています:) nosqlの用語はこの記事で書かれています 。



最も一般的なDBMSであるMySql、PostgreSql、Oracleを検討してください。 多くの違いがありますが、3つともデバッグされた豊富な機能を備えたリレーショナルデータベースです。 小さなカフェ用のワークフローシステム、銀行アプリケーション、名刺サイトを作成できます。 これは、ほとんどすべてのタスクに対する一般的なソリューションです。



初心者の開発者は、最初のSQLデータベースに遭遇したときにどのような問題に遭遇しますか？

1. SQL構文を学ぶ必要がある
2. リレーショナルモデルの本質を理解する必要がある
3. お気に入りの開発言語でデータベースのクライアントをマスターする必要があります

それだけです。その後、人は1つのデータベースをマスターするだけでなく、データベースファミリをマスターし、たとえばMysqlからOracleに簡単に切り替えることができます。 （PL / SQLと他の重要な違いについて少し忘れてください）。 そして、まだORMを使用している場合は...



この想像上の単純さは、残酷な冗談を演じることができます。 たとえば、Oracleで5行のクエリをデバッグする場合、最適化を試みます。 ここでは、無料のチーズはネズミ捕りでのみ発生することを理解し始めます。



それにもかかわらず、これは膨大な量のクエリ言語手段を使用して情報を選択する便利さです-それは幸せではありませんか？



率直に言って、2年以上、私はmysql、oracleを真剣に検討していません。 そして、私が気を散らして誘惑したものを説明します...

アルフレスコ

そして、 それが機能するためにはSQLソリューションが必要ですが、私はまだalfrescoを私の最初のnosqlデータベースと考えています。



この素晴らしいプラットフォームに基づいて最初に座って開発する人にとって、何を勉強する必要がありますか？ はい、実際には、それだけです:)



彼女は完全に異なっています。 その中のデータ構造は、xmlを使用して記述されます。 接続は、いわゆる関連付けを使用して定義されます。 例：投稿、その中のコメントのリストは関連付けです。 そして、モデルの継承があります。 1つの「テーブル」を別の「テーブル」に継承できます。



nosqlソリューションは必然的に高速なリポジトリであるという意見があります。 しかし、alfrescoは非常に遅いリポジトリです。 本当に、本当に。 欠点のうち、リクエストAPIに名前を付けることもできます。 リポジトリにアクセスするには2つの方法があります。javaapiを使用してIDで関連付けとオブジェクトを取得する方法と、Lucene Query Engineを介した属性と関連付けによる選択を使用したより複雑なクエリです。 クエリは怖いように見えますが、クエリエンジンの単純なラッパーを作成して、次のようなクエリを作成できるようにしました： Query.field(title).eq("").and(Query.field(text).like("**"));



そして人生はより美しく、より楽しくなりました。 リクエストはメモリから書き込まれましたが、同僚が見つけます（こんにちは！:)）



それでも、これは素晴らしいことです。なぜなら、ワークフローシステムを作成することは非常に便利であり、ドキュメントを移動する大規模で複雑なビジネスプロセスで、1人のユーザーと「夜を過ごす」からです。 最終的に何らかの結論に達するまで。 たとえば、解決するには：done。



その後、バージョン3の始まりであり、2011年には4がリリースされました。多くのおいしいものが追加され、おそらくパフォーマンスが向上しましたが、新しいストレージに夢中になりすぎました...

カサンドラ

これは私の愛であり、今まで変わらない。 同僚は彼女にあまり熱心ではありませんでしたが、これはサーバー上のRAMの不足によるものだと私は考えています。 当然、サーバー上にブロブがある5億行になると、8 GBを超えるRAMを使用する必要があります...ノードがハングアップすることがあります。



しかし...非常に高速な記録、高速な読み取り。 データを完全に制御し、データベースが書き込み速度または読み取り速度に接続されないという確信。 私はまだ自分のプロジェクトでそれを使用していますが、彼女はまだ私を失望させていません。 この基地の特徴は、殺すのが難しいことです。 たとえば、デフォルト設定のMongoDbを使用する場合など、サーバーがダウンすることを恐れず、復元を行う必要があります。



データベースへのリクエストはthrift apiを使用して行われますが、これは外観が非常に怖いです。 接続プールのような必要な設備がすべて不足しています。 バイトのセットを入れると、実際にはバイトのセットが得られます。 この問題は、Alfrescoの場合と同様に、より大きな規模でのみ解決しました。ORMフレームワークを作成する必要がありました。これは、,約のアドオンとなり、同時にパフォーマンスの制限を課しませんでした。 自転車に代わるオープンソースの選択肢がありましたが、それらはすべて、解決されるタスクのコンテキストでは不快に思えました。



私の製品を利己的に使い始め、すぐに大量のバグレポートを投げてくれたチームリーダーと患者の同僚に感謝します:)）



それにもかかわらず、カサンドラはまだメモリを食べて、その不足でハングしました...

リアク

彼との知り合いは短かった。 私はhabrで読んだ-クール。 私はサイトで読んだ-クール。 インストールされ、テストを開始しました。 まず、データベースへのクエリに必要な機能が不足していることに戸惑っていました。 第二に、2,000万行の記録で、基地は非常に奇妙な振る舞いをしました。 彼女はちょうど死んだ。 再起動されたベースはさらに奇妙な動作をしました：搭載された2,000万行から10分間ロードされ、何らかの理由で、4つのうち1つのコアのみを100％強制しました。

これは私の個人的な研究であったため、このデータベースに時間を費やすことはもうしたくありませんでした。

ハイパーテーブル

このデータベースは、サーバーへの10億のレコードに対するメモリ集約度が高くなく、記録が非常に高速だったため、救いのように見えました。 もちろん、そこでの書き込み速度は、選択されたtimeout'aディスクへのフラッシュのみに依存します。 cassandraの後のThrift APIは問題を引き起こさず、ormにハイパーテーブルのサポートを追加するために残りました。



しかし、このベースは非常に不安定であり、ログはあまり情報がなかったため、製品が安定版と呼ばれるのかどうか疑問に思うだけでした。 ネット上の問題について同僚を見つけようとしても、何も得られませんでした。 再起動するだけで、ベースを待つことはできません。 そして、タンバリンで持ち上げる必要がありました。2回再起動し、ログを削除し、さらに2〜3回再起動します。 または5回。 問題はすぐには現れなかったが、彼女は何とか本番に向けて出発した。 一般的に、オプションではありません...

Mysql

（たとえば）



同僚の悲しい顔、悲しい。 Nosqlは問題を解決しませんでした。 すべてが無駄でした。 しぶしぶ、タスクでmysqlをテストし、30億件のレコードで非常にうまく機能しました。 これは、「どうして！ 結局のところ、nosql！ ビッグデータ！」実データにMysqlを使用する必要がありました。 当然：結合なし、複雑な接続。 実際のデータが状況を変え、mysqlのタスクの1つが機能しなかったと言わなければなりません。 それは完全にです。 4秒の要求は超えています。 厳密に最適化されたクエリであっても、今回は接続とSQL機能を使用します。 しかし、Mysqlはまったく異なる仕事をしました。 主なものは、記録バッチの正しい行数です。



一般的に、私たちは財政的に制限されていたため、多くの強力なサーバーを購入することは不可能でした。 彼らが与えるものを使いました。 そして、彼らはできるだけ早く保存しようとしました。

モンゴッド

リストされているデータベースと並行して、 これも使用/使用します 。 これはお気に入りのデータベースでもあり、6つのプロジェクトで既に使用しています。 快適さとして、Javaの便利なORMフレームワークであるMorphiaがあります。これは、データサンプリング、スケーラビリティ、速度の大きな機会です。



もちろん、ここには微妙な違いがあります。

1. 強く推奨されるmongoバージョンを使用> 2
2. 適切なセットアップを行っていない場合は、mongoをシャットダウンせずにサーバーの再起動に注意してください
3. mongorestoreとジャーナリングについて読む:)

私の意見では、このデータベースはSQLソリューションとNosqlの世界の間の移行として素晴らしいものです。 個人的にこのデータベースの利点は何ですか？ スキーマフリー、リクエストのシンプルさ、ドキュメント指向、スケーラビリティ。 このデータベースが着ているパラダイムに満足しています。



それにもかかわらず、mongoの6つのプロジェクトから、入浴せずにmysqlで3〜4を作成することができます。 私はモンゴが好きだからといって、モンゴでそれらを書きました。

Hadoop

最近この仕事を始めました-約3か月前、新しい仕事に移行しました。 Hadoopは、大量のデータを保存および処理するためのソリューションのエコシステムです。 map-reduceとhadoopの本質を理解すると、このソリューションの最初にあるアルゴリズムと原理の単純さが驚くことになります。 それでも、この単純さは、小さな記事を処理しているように200ギガバイトのテキスト情報を処理するのに役立ちます。 問題は、一連のシンプルなアイデアが迅速でシンプルなソリューションをもたらすことです。 そして、データが十分に速く処理されていないように思われる場合は、クラスターにノードを追加します。



もちろん、本質を理解し、Hadoopソースコードを調査し、最初の計算タスクを実装するには時間がかかります。



私にとってこの決定の主な驚きは、本当に大きなデータを保存して処理する必要がある場合、データベースがまったく必要ないかもしれないということでした。



結論として、私はこれについての私の個人的な意見を表明したいと思います。

すべてのタスクに単一のソリューションはありません。 それに最も近いのは、SQLソリューションです。 各nosqlリポジトリは、特定の範囲のタスクのみを解決するツールであると同時に、ファイルの操作、内部の調査、慎重な設定、またはクライアントの作成さえ必要とします。



結論への追加：

特効薬はないので、まず考える必要があります。 また、データベースのマニュアルがどれほど明確であっても、これによる驚きの数は減りません。 現在のnosqlソリューションは若く、欠陥のあるツールがないわけではありません。 それにも関わらず、たとえばmongodb、redis、hbase、cassandraなど、一部の製品は実稼働で使用する準備が整っています。



しかし、「何を使用するか」という質問の答えにたどり着くには、その場合、あなたは自分でそれを必要とします。 特定の問題に対するソリューションをテストおよび調査することにより。