小規模企業の顧客向けの Web ベースの Clojure アプリケーションとして、VB ベースのオンプレミス (ローカルにインストールされた) アプリケーション (請求 + 在庫) を書き直すことを検討しています。これは、同様の取引を行う顧客向けの SaaS アプリケーションとして提供される予定です。
私はデータベースのオプションを検討していました。私の選択は RDBMS でした: Postgresql/MySQL。最初の 1 年で 400 ユーザーにスケールアップする可能性があります。通常、1 ユーザーあたり 1 日あたり 20 ～ 40 ページ ビューです。ほとんどの場合、静的ビューではなくトランザクション用です。各ビューには、データのフェッチとデータの更新が含まれます。ACID準拠が必要です（またはそう思います）。そのため、取引量は膨大ではありません。
私の好みに基づいてこれらのいずれかを選択することは非常に簡単でしたが、SaaS アプリの典型であると私が信じているこの 1 つの要件については、顧客/ユーザーを追加するにつれて、また顧客ごとにスキーマが変化します。ビジネス要件の変化 (最初は限られた柔軟性しか提供しません)。私は DB の専門家ではないので、考えたり読んだりしたことに基づいて、さまざまな方法でそれを処理できます。
- 複数のテナントをホストする単一の DB を使用して、MySQl/Postgresql で従来の RDBMS スキーマ設計を行います。また、顧客を追加したり、既存の顧客に変更を加えたりした場合に、将来の変更に対応できるように、各テーブルに十分な数の「自由に移動できる」列を追加します。これには、スキーマに小さな変更が加えられるたびに変更が DB に反映されるという欠点がある場合があります。Postgresql では、スキーマの更新をロックせずにリアルタイムで実行できることを読んだことを覚えています。しかし、このユースケースでどれほど苦痛であるか、またはどれほど実用的であるかはわかりません. また、スキーマの変更により、新しい/マイナーな SQL の変更も導入される可能性があります。
- RDBMS を使用しますが、データベース スキーマを柔軟な方法で設計します: エンティティ属性値に近いものを使用するか、単にキーと値のストアとして使用します。(Workday、FriendFeed など)
- 全体をオブジェクトとしてメモリ内に保持し、定期的にログ ファイルに保存します (例: edval、lmax)。
- MongoDB や Redis などの NoSQL DB を使用してください。しかし、私が収集できることに基づいて、それらはこのユースケースには適しておらず、ACID に完全に準拠していません。
- VoltDb や JustoneDb (クラウドベース) など、SQL および ACID に準拠した動作を保持し、「新世代」の RDBMS である NewSQL Db を使用してください。
- 私は neo4j(graphdb) を見ましたが、それがこのユースケースに適合するかどうかはわかりません
私のユースケースでは、スケーラビリティや分散コンピューティング以上に、「スキーマの柔軟性 + ACID + 適度なパフォーマンス」を達成するためのより良い方法を検討しています。私がネットで見つけたほとんどの記事では、スキーマの柔軟性がパフォーマンス (NoSQL DB の場合) とスケーラビリティにつながる原因であり、ACID/トランザクションの側面は除外されています。
これは「スキーマの柔軟性と ACID」トランザクションの「どちらかまたはどちらか」のケースですか、それともより良い方法はありますか?