Схема меньше / гибкая + база данных ACID?

Я планирую переписать локальное (локально установленное) приложение на основе VB (выставление счетов + инвентаризация) в качестве веб-приложения Clojure для клиентов малого бизнеса. Я намерен предложить это как приложение SaaS для клиентов в аналогичной сфере.

Я искал варианты базы данных: мой выбор был RDBMS: Postgresql / MySQL. Я мог бы масштабировать до 400 пользователей в первый год, обычно с 20-40 просмотров страниц в день на пользователя - в основном для транзакций, а не статических просмотров. Каждое представление будет включать выборку данных и обновление данных. Соответствие требованиям ACID необходимо (или я так думаю). Так что объем транзакций невелик.

Было бы легко выбрать любой из них, исходя из моих предпочтений, но для этого одного требования, которое, я считаю, типично для SaaS-приложения: схема будет меняться по мере того, как я буду добавлять больше клиентов / пользователей и для каждого клиента изменение бизнес-требований (я буду предлагать ограниченную гибкость только для начала). Поскольку я не эксперт по БД, основываясь на том, что я могу придумать и прочитать, я могу справиться с этим несколькими способами:

1. Иметь традиционную схему РСУБД в MySQl / Postgresql с одной БД, на которой размещено несколько клиентов. И добавьте достаточно «свободно плавающих» столбцов в каждую таблицу, чтобы учесть будущие изменения, поскольку я добавляю больше клиентов или изменения для существующего клиента. Это может иметь обратную сторону для распространения изменений в БД каждый раз, когда вносится небольшое изменение в Схему. Я помню, что читал, что в Postgresql обновления схемы можно выполнять в режиме реального времени без блокировки. Но не уверен, насколько больно или насколько это практично в этом случае использования. А также, поскольку изменения схемы могут также вводить новые / незначительные изменения SQL.
2. Имейте RDBMS, но разрабатывайте схему базы данных гибким способом: с близким к значению атрибута объекта или просто как хранилище значения ключа. (Рабочий день, например FriendFeed)
3. Храните все это в памяти как объекты и периодически сохраняйте их в лог-файлах (например, edval, lmax).
4. Перейти на NoSQL DB, как MongoDB или Redis. Но исходя из того, что я могу собрать, они не подходят для этого варианта использования и не полностью совместимы с ACID.
5. Выберите некоторые базы данных NewSQL, такие как VoltDb или JustoneDb (на основе облака), которые сохраняют поведение, совместимое с SQL и ACID, и являются СУБД нового поколения.
6. Я посмотрел на neo4j (graphdb), но не уверен, что это подойдет для этого варианта использования

В моем случае использования, больше, чем масштабируемость или распределенные вычисления, я ищу лучший способ достижения «Гибкости в схеме + ACID + некоторая разумная производительность». Большинство статей, которые я мог найти в сети, говорят о гибкости схемы как о причине, приводящей к производительности (в случае NoSQL DB) и масштабируемости, оставляя при этом сторону ACID / Transactions.

Это случай «или» или транзакций «Гибкость схемы против ACID», или есть лучший выход?

Опция 1

Для этого есть несколько причин, которые я объясню ниже. Во-первых, вот как это сделать.

• Используйте ваш выбор стандартной платформы RDBMS.

• Настройте свою схему с несколькими настраиваемыми пользователем полями и сделайте свое приложение более удобным для настройки для каждого арендатора.

• Из метаданных по каждому арендатору вы можете создать представление по их арендатору со своими встроенными фильтрами и именами столбцов из ваших метаданных. Любые предоставленные отчеты также могут наследовать метаданные. Если они хотят использовать MI для данных, предоставьте им экстракт данных транзакций или, возможно, какое-то дополнительное приложение MIS на другом сервере, если они заплатят за это.

• Не пытайтесь обеспечить больше настроек, чем это (то есть никаких радикальных изменений в схеме), если клиент не готов заплатить за свой собственный экземпляр и поддержку пользовательской сборки.

Причины этого:

• Эти системы баз данных будут обрабатывать объемы, которые вы описываете на довольно обычном оборудовании. У вас нет такого объема транзакций, который заслуживает базы данных NoSQL. Если у вас нет какой-то другой архитектурной причины, чтобы хотеть ее, нет особого смысла идти в тупик.

• Это зрелые, хорошо понятые технологии.

• Управление системами, резервное копирование / восстановление, репликация, создание отчетов и аварийное восстановление - все хорошо отсортировано на платформах RDBMS.

• Вы можете получить клиентские библиотеки, включая JDBC для всех основных платформ RDBMS.

• Представления могут использоваться для индивидуальной настройки пользователя и генерироваться из метаданных вашего приложения.

• Это существенно более эффективно, чем поля XML или структуры EAV.

С PostgreSQL у вас есть возможность использовать отдельные базы данных, отдельные схемы или представления для работы с несколькими арендаторами.

Использование нескольких баз данных (на одном сервере баз данных) усложняет администрирование, поскольку каждая база данных должна управляться индивидуально. Следовательно, это целесообразно только в том случае, если безопасность между арендаторами имеет первостепенное значение.

Отдельные схемы предлагают большую гибкость и безопасность, но делают обновления более сложными, потому что они должны применяться индивидуально и, вероятно, необходимы, только если ваши арендаторы используют совершенно разные структуры таблиц; что маловероятно, если они используют одно и то же приложение.

Представления позволяют арендаторам видеть различные части общей структуры таблиц и позволяют контролировать, к каким таблицам, к каким столбцам и строкам они имеют доступ. Единственное предостережение в том, что ваше приложение должно убедиться, что оно использует только эти представления, а не базовые таблицы, в противном случае существует вероятность случайной утечки данных между арендаторами из-за дефектов программного обеспечения.

Вам на самом деле не нужно создавать столбцы перед требованиями приложения. Столбцы могут добавляться в таблицы динамически (без какого-либо заметного влияния на пользователей), а представления также могут обновляться динамически. Вам нужно только подумать о порядке внесения изменений - т.е. изменить таблицы, а затем просмотреть, а затем код приложения.

Ваша единственная потенциальная проблема - если вам нужно добавить новый столбец, который нужно добавить в существующий индекс или требуется новый индекс. Именно тогда таблица может быть заблокирована от использования во время создания индекса, но PostgreSQL поддерживает возможность одновременного создания индексов без блокировки таблицы. Это работает нормально, если новый индекс не должен быть уникальным и обнаруживает нарушение уникальности.

Вам, вероятно, не нужна база данных NoSQL, поскольку они эффективно удаляют схему из базы данных и требуют, чтобы приложение управляло ею. Не похоже, что ваши объемы требуют такой жертвы.