7

マルチテナントシステムを設計しており、データベースではなくアプリケーション層レベルでテナントによるシャーディングを検討しています。

仮に、これが機能する方法は、着信要求の場合、ルータープロセスが、この要求のテナントと仮想シャードIDを決定するためのプライマリ属性を含むテナントのグローバルコレクションを持っていることです。この仮想シャードIDは、実際のシャードにさらにマップされます。

実際のシャードには、アプリケーションのコードとこのテナントのデータ全体の両方が含まれています。これらのシャードは、LNMP（Linux、Nginx、MySQL / MongoDB、PHP）サーバーになります。

ルータープロセスはプロキシとして機能する必要があります。いくつかのローカルデータベースまたはファイルに格納されているコレクションに基づいて、着信要求のターゲットシャードを決定するためのコードを実行できる必要があります。これをより適切にスケーリングできるようにするために、シャード自体をルーターとしても機能させ、リクエストを適切なシャードに転送するリバースプロキシを実行できるようにすることを検討しています。シャードで実行されているnginxインスタンスは、そのリバースプロキシとしても機能する可能性があります。しかし、リクエストを適切なシャードと照合するために必要なアプリケーションロジックをどのように実行しますか。

このルーターの実装に関するアイデアや提案をいただければ幸いです。

ありがとう

4

2 に答える 2

1

もう1つのオプションは、dbShardsなどの製品を使用することです。dbShardsは、アプリケーションレベルでシャーディングする唯一のシャーディング製品です。このようにして、任意のRDMS（Postgres、MySQLなど）を使用でき、間に何らかのプロキシを配置しなくてもデータベースをシャーディングできます。他の多くのシャーディング製品は、トランザクションを正しいシャードにポイントするためにプロキシに依存していますが、dbShardsは、他の誰かに「尋ねる」必要なしにどこに行くべきかを知っています。

素晴らしい製品。dbshards

于 2011-04-19T21:52:59.493 に答える
0

テナントがほぼ等しいデータ量を生成することを期待しない限り、テナントによるシャーディングはあまり効率的ではありません。

一般的なアプリケーションレベルのシャーディングに関して、私自身の経験を共有させてください。

大量のSaaS製品のバージョン1は、アプリケーションレベルでシャーディングされています。アプリケーションレベルでSQLタイプのソリューションに対してシャーディングする場合、成長に伴うリシャーディングが大きな頭痛の種になることがわかります。または、プロセスを自動化するための重要なツールを作成する必要があります。

データの増加に伴うリシャーディング/リバランスのサポートがすべて組み込まれているため、（Cassandraを含む複数の代替案を検討した後）MongoDBに切り替えました。

アプリケーションがMySQLのリレーショナル機能を必要としない場合、適度なデータの増加が予想される場合は、MongoDBに集中することをお勧めします（これは、可能なデータプラットフォームとしてすでに特定されているためです）。MongoDBがデータシャーディングを処理できるようにします。

于 2011-03-31T18:09:28.647 に答える