RDBMS to NoSQLストリーミングソリューションでスケーラビリティとACIDを実現する
私の理解は、主な機能Cassandraが提供する必要があるのは線形パフォーマンスであることです任意のスケール;つまり、1つのC *ノードがアプリから毎秒500クエリまたはコマンドを処理できることがわかっている場合、100のC *ノードが同じクラスターに追加されることを安心できます1秒あたり500 * 100 = 50Kのクエリまたはコマンドを処理できます。
RDBMSとNoSQLの間の主なトレードオフの私の理解は、NoSQLシステムはスケーラビリティを優先する傾向があるが、（機械的には、実装上）取引性を緩和する。したがって、C *のようなNoSQLシステムは通常、非常に適切にスケーリングしますが、MySQLのようなRDBMSシステムが提供できるような古典的なACIDトランザクションを提供できません。
私の理解は、スケーラビリティとトランザクション可能性は相互に排他的であるため、C *のような魔法のNoSQLデータベースが存在しないということですスケーラビリティー（ここでも、あらゆる規模で線形パフォーマンス）and提供するJava JTAが実装されたクライアント（コミット+ロールバック機能）をクライアントに提供）。
これらは私の仮定であり、この質問に向かっています。私がそれらのいずれかについて間違っていたり、見当違いである場合は、まず訂正してください！
これらのすべての仮定で私が多かれ少なかれ正しいと仮定すると、実際にスケーラビリティとACIDトランザクションの両方が実際に必要な場合はどうしますか？ここでの唯一のアイデアは、以下を実装することです。
- JDBC/JTA準拠のドライバーを使用して（トランザクションを使用するなど）、RDBMS（MySQLなど）に書き込むようにアプリを構成します。
- Somehow、RDBMSを構成して（Cassandraのような）非常にスケーラブルなDBに（リアルタイムまたは非常に低いレイテンシで）複製します。これは、RDBMS自体が提供する構成オプションである可能性があります。または、より可能性が高いのは、あるシステムから別のシステムに継続的にETLを実行するために自分で作成する必要があるコードです。ここでの考え方は、アプリがNoSQLテーブルからreadし、それでも大量のデータに対して非常にパフォーマンスの高い読み取りを行うことです。
- どういうわけかRDBMSテーブルをTTLで構成して、テーブルが極端に大きくならないようにし、トランザクションを遅くする可能性のあるシャーディングやその他のトリックが必要になるようにします。繰り返しになりますが、これはRDBMS自体が提供する構成オプションであるか、またはおそらく自分で記述する必要があるコードです。
ここでよく知られている解決策はありますか？このアプローチの落とし穴/警告はありますか？
あなたの仮定は不完全ではありません。スケーラビリティ（許容ネットワークパーティションまたはCAPのP）とトランザクション可能性（一貫性またはCAPのC）の間のトレードオフは、システムのレベルではなく、個々の操作またはトランザクションのレベルで発生します。つまり、トランザクションは一貫しているか、水平スケールを利用できますが、両方は利用できません。ただし、データベースは両方のメカニズムを自由に提供できます。たとえば、cassandraは、軽量トランザクションと大多数の読み取り/書き込みをサポートし、一貫性を保証するメカニズムを提供します。
これらは技術的な特性であるため、画像はさらに複雑になりますが、直感的に期待するようには動作しません。たとえば、googleの cloud spanner は、内部的には最終的に整合性があっても、データベースユーザーの観点からスケーラビリティと強力な整合性を提供します。シャーディングはcheatへの方法であり、システムは全体として水平方向のスケールを利用しますが、1つのシャード内のすべてのデータは強い整合性があります。
ここで、スケーラビリティとの一貫性を実現する方法についての質問に、いくつかの戦略を示します。
- この問題は、書き込み前に読み取る必要がある場合にのみ発生します。そのカテゴリに該当するパーツを分離して、別のメカニズムまたはデータベースを使用してそれらを提供することができます。シャーディングを適用すると、一貫性のあるデータのセットをさらに細分化して、1つのサーバーに収めることができます。
- おそらくすべての読み取りが一貫したビューを持っている必要はないという事実を利用して、キャッシュまたは非ACIDクエリを使用できます（cassandra読み取り整合性ONE）。
- 完全に一貫している必要があるデータの新しい複雑なグラフでデータの複雑なグラフを置き換える場合は、非アトミックな書き込みを使用して新しいバージョンのグラフを記述し、それに切り替えるバージョニング戦略を使用できます。アトミック書き込みのバージョン。