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

Question

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

私はデータベースオプションを見ていました：私の選択はRDBMS：Postgresql/MySQLでした。最初の1年間で最大400人のユーザーにスケールアップする可能性があります。通常、ユーザーあたり1日あたり20〜40ページビューです。各ビューには、データのフェッチとデータの更新が含まれます。 ACIDへの準拠が必要です（そう考えています）。したがって、トランザクション量は膨大ではありません。

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

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

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

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

ConcernedOfTunbridgeWells · Answer

オプション1

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

選択した標準RDBMSプラットフォームを使用します。
いくつかのユーザー構成可能なフィールドを使用してスキーマを設定し、アプリケーションでテナントごとの構成を容易にします。
テナントごとのメタデータから、フィルターが組み込まれているデータデータのテナントごとのビューと、メタデータ。提供されるレポートもメタデータを継承できます。彼らがMIをしたいなら次に、データをオフにして、トランザクションデータの抽出物を提供するか、支払いを行う場合は別のサーバー上の追加のMISアプリケーションを提供します。
クライアントが自分のプライベートインスタンスの料金を支払い、カスタムビルドを維持する準備ができている場合を除き、これ以上のカスタマイズ（つまり、スキーマに対する根本的な変更はありません）を提供しないでください。

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

これらのデータベースシステムは、ごく普通のハードウェアで記述した種類のボリュームを処理します。 NoSQLデータベースに値する種類のトランザクション量は実際にはありません。他に必要なアーキテクチャ上の理由がない限り、最先端を行くことにはあまり意味がありません。
それらは成熟した、よく理解されたテクノロジーです。
システム管理、バックアップ/復元、レプリケーション、レポート、災害復旧は、すべてRDBMSプラットフォームで適切に分類されています。
すべての主要なRDBMSプラットフォーム用のJDBCを含むクライアントライブラリを入手できます。
ビューは、ユーザーごとのカスタマイズに使用でき、アプリケーションメタデータから生成できます。
XMLフィールドやEAV構造よりもはるかに効率的です。

Duncan Pauly · Answer

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

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

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

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

実際にアプリケーション要件の前に列を作成する必要はありません。列は動的に（ユーザーに大きな影響を与えることなく）テーブルに追加でき、ビューも動的に更新できます。変更の順序について考える必要があるだけです。テーブルを変更し、次にビュー、次にアプリケーションコードを変更します。

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

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