Web アプリのバックエンドを構築しています。フロントエンドの API として機能し、Python (正確には Flask) で記述されます。
設計と実装に関していくつかの決定を行った後、データベースの部分に取りかかりました。そして、NoSQL データ ストレージが従来の SQL データベースよりも私のプロジェクトに適しているのではないかと考え始めました。以下は、データベースによって処理される必要がある基本的な機能の説明であり、次に、どのタイプのストレージを選択する必要があるかに関して考えられる長所と短所のリストです。最後に、他の NoSQL データ ストレージではなく RethinkDB を検討した理由について説明します。
API の基本機能
ArtistAPI は、 、Song、Suggestion、Userおよびの少数のモデルのみで構成されていますUserArtists。
Userいくつかの関連データを含む を追加し、いくつかの をそれにリンクできるようにしたいと考えArtistています。Songリクエストに応じて s にs を追加し、 anと aを含むa の aArtistも生成したいと思います。SuggestionUserArtistSong
おそらく、最も重要な部分の 1 つは、Artists が定期的にUsers にリンクされることです (また、 s が何らかの基準を満たさない場合はArtist、システムから (したがって s からも) 削除される可能性があります)。s も s に動的に追加されます。これが意味するのは、s が s の固定セットを持っておらず、s も s の固定セットを持っていないということです。それらは継続的に更新されます。UserSongArtistUserArtistArtistSong
長所
NoSQL の場合:
Artistすべての人が FacebookID やSongSoundcloudIDを持っているわけではないため、柔軟なスキーマ。- JSON API ですが、レコードが JSON として保存されるという事実から恩恵を受けると思います。
- sの数は多いと思います
Songが、特にSuggestions はかなり増えるので、ここでは NoSQL の方がうまく機能します。
SQL の場合:
- 固定されたスキーマは、モデル間の関係に役立つ場合があります。
- Flask は、モデルの定義に非常に役立つ SQLAlchemy をサポートしています。
短所
NoSQL の場合:
- リレーションは実装が難しく、トランザクションのようなモデルの更新には少しコードが必要です。
- Flask には処理を容易にするためのラッパーやモジュールがありません。そのため、データベース操作中にコードを読みやすくするために、ある種のラッパーを実装する必要があります。
- 記録をどのように保存すればよいか、
UserArtist特に
SQL の場合:
- 操作はかさばります。スキーマを定義し、列にデフォルトがあるかどうかを確認し、デフォルトを割り当て、データを検証し、トランザクションを開始/コミットする必要があります。API のような単純なものには面倒すぎると思います。
DB を再考する理由
次の理由から、API の NoSQL の実装の可能性として RehinkDB を検討しました。
- 他のソリューションよりもシンプルで軽量に見えます。
- 大きな利点であるネイティブ Python サポートがあります。
- テーブルの結合や、モデル間にいくつかの関係がある API で役立つ可能性のあるその他の機能を実装しています。
- それはかなり新しいもので、コミュニティから多くの影響と愛が見られます。また、データベースの相互作用を活用する新しいものを継続的に追加するという意志もあります。
これらすべてを考慮して、NoSQL と SQL のどちらが私のニーズにより適しているかについてのアドバイス、および 2 つのその他の賛否両論、そしてもちろん、私が述べていないことのいくつかの修正について、喜んでお聞きします。ちゃんと。