スキーマレス/フレキシブル+ ACIDデータベース？

私は、小規模企業の顧客向けのWebベースのClojureアプリケーションとして、VBベースのオンプレミス（ローカルにインストールされた）アプリケーション（請求書+在庫）を書き換えることを検討しています。これは、同様の取引の顧客向けのSaaSアプリケーションとして提供される予定です。

私はデータベースオプションを見ていました：私の選択はRDBMS：Postgresql / MySQLでした。最初の1年間で最大400人のユーザーにスケールする可能性があります。通常、ユーザーあたり1日あたり20〜40ページビューです。ほとんどの場合、静的ビューではないトランザクションに使用します。各ビューには、データの取得とデータの更新が含まれます。ACIDコンプライアンスが必要です（またはそう思う）。そのため、トランザクション量は膨大ではありません。

私の好みに基づいてこれらのいずれかを選択するのは簡単でしたが、この1つの要件のために、SaaSアプリの典型であると信じています：スキーマは、顧客/ユーザーを追加し、各顧客のビジネス要件の変更（最初に限って柔軟性を制限します）。私はDBの専門家ではないので、私が考えることができ、読んだことに基づいて、多くの方法でそれを処理できます。

1. 複数のテナントをホストする単一のDBを使用して、MySQl / Postgresqlで従来のRDBMSスキーマを設計します。さらに、顧客を追加したり、既存の顧客に変更を加えたりするときに、将来の変更に対応できるように、各テーブルに十分な「浮動」列を追加します。これには、スキーマに小さな変更が加えられるたびにDBに変更が伝播されるという欠点があります。Postgresqlのスキーマ更新では、ロックなしでリアルタイムに更新できることを読んだことを覚えています。しかし、このユースケースでどれだけ苦痛であるか、どれほど実用的かはわかりません。また、スキーマの変更により、新しい/小さなSQL変更も導入される可能性があるためです。
2. RDBMSを使用しますが、データベーススキーマを柔軟な方法で設計します。エンティティ属性値に近い値を使用するか、単にキー値ストアとして使用します。（就業日、たとえばFriendFeed）
3. オブジェクト全体をメモリ内にオブジェクトとして保持し、定期的にログファイルに保存します（edval、lmaxなど）。
4. MongoDBやRedisなどのNoSQL DBを探してください。しかし、私が収集できるものに基づいて、これらはこのユースケースに適さず、ACIDに完全に準拠していません。
5. SQLおよびACID準拠の動作を保持し、「新世代」のRDBMSであるVoltDbやJustoneDb（クラウドベース）などのNewSQL Dbsを探します。
6. neo4j（graphdb）を見ましたが、それがこのユースケースに適合するかどうかはわかりません

スケーラビリティや分散コンピューティング以上のユースケースでは、「スキーマ+ ACIDの柔軟性+合理的なパフォーマンス」を実現するためのより良い方法を探しています。ネット上のほとんどの記事では、ACID / Transactions側を除外しつつ、パフォーマンス（NoSQL DBの場合）とスケーラビリティにつながる原因としてのスキーマの柔軟性について述べています。

これは、「スキーマの柔軟性とACID」トランザクションの「どちらか」のケースですか、それともより良い方法がありますか？

オプション1

これにはいくつかの理由がありますが、以下で説明します。まず、それを行う方法を次に示します。

• 選択した標準RDBMSプラットフォームを使用します。

• いくつかのユーザー設定可能なフィールドを使用してスキーマを設定し、アプリケーションがテナントごとに設定を容易にするようにします。

• ごとのテナントメタデータから、あなたはのあたりテナントビューを作成することができ、その中に内蔵され、フィルタ、およびあなたのメタデータから名前の列を持つデータを、。提供されるレポートはすべて、メタデータを継承することもできます。データのMIを行いたい場合は、トランザクションデータの抽出を提供するか、支払いがあれば別のサーバー上の追加のMISアプリケーションを提供します。

• クライアントが独自のプライベートインスタンスの料金を支払い、カスタムビルドを維持する準備ができていない限り、これよりも多くのカスタマイズを提供しないでください（つまり、スキーマに根本的な変更はありません）。

この背後にある理由は次のとおりです。

• これらのデータベースシステムは、ごく普通のハードウェアで記述した種類のボリュームを処理します。NoSQLデータベースに値するようなトランザクションボリュームは実際にはありません。他に何らかのアーキテクチャ上の理由がある場合を除き、最先端を行くことはあまり意味がありません。

• それらは成熟した、よく理解された技術です。

• システム管理、バックアップ/復元、複製、レポート、および災害復旧はすべて、RDBMSプラットフォームで適切に分類されています。

• すべての主要なRDBMSプラットフォームのJDBCを含むクライアントライブラリを取得できます。

• ビューは、ユーザーごとのカスタマイズに使用でき、アプリケーションメタデータから生成できます。

• XMLフィールドやEAV構造よりも大幅に効率的です。

PostgreSQLでは、マルチテナンシーに対処するために、個別のデータベース、個別のスキーマまたはビューを使用するオプションがあります。

（同じデータベースサーバー内で）複数のデータベースを使用すると、各データベースを個別に管理する必要があるため、管理がより複雑になります。したがって、これは、テナント間のセキュリティが最大の懸念事項である場合にのみ推奨されます。

個別のスキーマは多くの柔軟性とセキュリティを提供しますが、個別に適用する必要があり、テナントが完全に異なるテーブル構造を使用する場合にのみ必要になるため、アップグレードはより複雑になります。同じアプリケーションを使用している場合はほとんどありません。

ビューを使用すると、テナントは共通のテーブル構造のさまざまな部分を確認でき、どのテーブル、どの列、どの行にアクセスできるかを制御できます。唯一の注意点は、アプリケーションがベーステーブルではなく、それらのビューのみを使用することを保証する必要があることです。そうしないと、ソフトウェアの欠陥によりテナント間で偶発的なデータリークが発生する可能性があります。

アプリケーション要件の前に列を作成する必要はありません。列はテーブルに動的に追加でき（ユーザーへの顕著な影響なし）、ビューも動的に更新できます。変更を行う順序について考えるだけで十分です。テーブルを変更し、次にビューを表示してからアプリケーションコードを変更します。

唯一の潜在的な懸念は、既存のインデックスに追加する必要がある、または新しいインデックスを必要とする新しい列を追加する必要がある場合です。これは、インデックスの構築中にテーブルが使用できないためにロックされる場合です。しかし、PostgreSQLはテーブルをロックせずにインデックスを同時に構築する機能をサポートします。これは、新しいインデックスを一意にする必要がなく、一意性違反が検出されない限り、正常に機能します。

NoSQLデータベースは、データベースからスキーマを効果的に削除し、代わりにアプリケーションが管理する必要があるため、おそらくNoSQLデータベースは必要ありません。ボリュームがそのような犠牲を要求しているようには思えません。