ウェブサイトの現在のデータベースは MYSQL であり、多くの曲情報レコードが保存されています。
MongoDB から曲をクエリした方が速いのではないかと思ったのですが?
今後曲情報を追加したり削除したりする場合、同時にMongoDBと同期する必要がありますよね？ NOSQL の経験がありません。アドバイスをお願いします。よろしくお願いします。
给我你的怀抱2017-05-02 09:27:47
多くの問題には解決策が 1 つだけあるわけではありません。つまり、このテクニックやあのテクニックを使用できるということです。学習の目的は何でも構いませんが、実際の運用環境では、複雑さを単純化し、最も使い慣れた最も単純な方法で問題を解決することを強くお勧めします。同じ問題を解決するために 2 つのデータベースを使用する必要があるかどうかを考えてください。
曲のクエリ部分をMongoDBからクエリしたら速いのではないかと思ったのですが？
そうかもしれないし、そうではないかもしれない。それは、データの量、MongoDB を使用したデータ モデルの設計が合理的かどうか、そしてそれに投資する予定のハードウェア リソースの量によって異なります。 NoSQL は水平方向の拡張に重点を置いており、データ量が増加し続けてもクエリ速度を一定レベルに維持できることを意味します。個人的な経験から言えば、数千万、数億のデータがある場合、MongoDB の利点が実際に発揮される可能性があります。データがこのレベルに達するまでは、速度を上げるためだけであれば、追加のデータベースを導入する必要はあまりないと思います。それがもたらす利点とそれが引き起こす複雑さを比較すると、費用対効果が低いとしか言えません。
今後曲情報を追加したり削除したりするときは、同時にMongoDBと同期する必要がありますよね？
データ同期の問題は、「一貫性」の要件がどの程度高いかによって異なります。強整合性の場合、これは分散トランザクションになります。これはおそらくパフォーマンスにとって良いことではなく、トランザクションを高速化するという本来の目的に反します。最終的な整合性を考慮している場合は、Pentaho などのさまざまな MySQL から MongoDB への ETL ツールを検討してください。もちろん、自分でコードを使って実装することも可能ですが、さまざまな耐障害性の問題を考慮するのは簡単ではありません。
世界只因有你2017-05-02 09:27:47
まず第一に、MongoDB は NoSQL の特定の実装であることを明確に理解しておく必要があります。Redis とは異なり、MongoDB が保存するデータ構造はドキュメントベースです。
第二に、クエリの速度は、製品やエンジンの違いに基づいて恣意的に決定するのが難しく、実際の使用状況に基づいて評価する必要があります。それだけでなく、どのような情報がどのように保存されるかについても分析する必要があります。プロセスは練習すればもっと簡単になります）。
以前は MySQL しか学ばなかったのですが、一部の保存データの構造が不確実で複雑なため、MySQL だけを使用してデータを保存したい場合は、多くのテーブルを使用し、外部キーを設定する必要があるため、MongoDB も学びました。ニーズを解決します。
私がやっていることは、ある観点から見ると歌に似た本の練習です。たとえば、書籍の著者が複数いる場合、区切り文字を使用して 1 つのフィールドに複数の著者を格納する方法が簡単です。後のクエリでは特定の問題 (判定条件の複雑さ、さらにはパフォーマンス) が発生します。 )、A ソングには複数の歌手が参加する場合もあります。
私の実践は MySQL + MongoDB もちろん、MongoDB のみを使用して実現することもできますが、特定のニーズをそれに応じて分析する必要があると思います。私の総合的な実践の実践は今も続いており、上に挙げた考え方の1つをいつでも伝えられるようになりました。
世界只因有你2017-05-02 09:27:47
歌詞から曲を探すなどの機能が必要かもしれません。上で述べた Elasticsearch は非常に優れていますが、全文検索に非常に優れた Sphinx もあります。