Без схем / гнучка + база даних ACID?

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

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

Вибирати будь-яке з них було б не на основі моїх переваг, але для цієї однієї вимоги, яка, на мою думку, є типовою для програми SaaS: Схема буде змінюватися, оскільки я додаю більше клієнтів / користувачів і для кожного клієнта зміна вимог до бізнесу (я пропоную лише обмежену гнучкість лише для початку). Оскільки я не є експертом з питань БД, виходячи з того, що я можу думати і прочитав, я можу це впоратися різними способами:

1. Майте традиційний дизайн схеми RDBMS в MySQl / Postgresql з єдиною БД, що розміщує декілька орендарів. І додайте в кожну таблицю достатньо стовпчиків, що постійно плавають, щоб забезпечити подальші зміни, оскільки я додаю більше клієнтів або змін для існуючого клієнта. Це може мати слабкий бік поширення змін до БД кожного разу, коли в схему вносяться невеликі зміни. Я пам'ятаю, як читав, що в Postgresql оновлення схеми можна робити в режимі реального часу без блокування. Але не впевнений, наскільки болісно чи наскільки це практично в цьому випадку використання. А також, оскільки зміни схеми можуть також вводити нові / незначні зміни SQL.
2. Мати RDBMS, але розробити схему бази даних гнучко: із близьким до сутності-атрибутом-значенням або просто як сховище ключа-значення. (Наприклад, робочий день, FriendFeed)
3. Майте всю пам'ять в якості об'єктів і періодично зберігайте їх у файлах журналу (наприклад, edval, lmax)
4. Перейдіть до такої БД NoSQL, як MongoDB або Redis. Але виходячи з того, що я можу зібрати, вони не підходять для цього випадку використання та не повністю сумісні з кислотами.
5. Зайдіть за деякими NewSQL Dbs, такими як VoltDb або JustoneDb (на основі хмари), які зберігають поведінку, сумісну з SQL та ACID та є RDBMS "нового покоління".
6. Я подивився на neo4j (graphdb), але не впевнений, чи підійде це для цього випадку використання

У моєму випадку використання, більш ніж масштабованість чи розподілені обчислення, я шукаю кращий спосіб досягти "Гнучкості в схемі + кислотна кислота + деякі розумні показники". Більшість статей, які я міг знайти в мережі, говорять про гнучкість у схемі, як про причину, що призводить до продуктивності (у випадку БД NoSQL) та масштабованості, не залишаючи сторону ACID / транзакції.

Це "або" випадок транзакцій "Гнучкість схеми проти ACID" чи є кращий вихід?

Варіант 1

Для цього є кілька причин, які я поясню нижче. По-перше, ось як це зробити.

• Використовуйте свій вибір стандартної платформи RDBMS.

• Налаштуйте схему за допомогою декількох налаштованих користувачем полів та зробіть, щоб ваша програма полегшила конфігурацію на основі орендаря.

• З метаданих орендодавця можна створити перегляд орендарю їхніх даних, у яких вбудовані фільтри та стовпці, названі з ваших метаданих. Будь-які надані звіти також можуть успадкувати метадані. Якщо вони хочуть зробити дані MI, то надайте їм витяг даних про трансакцію або, можливо, якусь додаткову програму MIS на іншому сервері, якщо вони за це заплатять.

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

Причини цього:

• Ці системи баз даних будуть обробляти типи томів, які ви описуєте на досить звичайному обладнання. Ви дійсно не маєте такого обсягу транзакцій, який заслуговує на базу даних NoSQL. Якщо у вас є якась інша архітектурна причина, щоб цього хотіти, немає великого сенсу розвиватися в кровотоці.

• Вони зрілі, добре розуміють технології.

• Управління системою, резервне копіювання / відновлення, тиражування, звітування та відновлення після аварій добре відсортовано на платформах RDBMS.

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

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

• Це значно ефективніше, ніж поля XML або структури EAV.

З PostgreSQL у вас є можливість використовувати окремі бази даних, окремі схеми або представлення для вирішення питань багатосторонньої оренди.

Використання декількох баз даних (в межах одного сервера баз даних) робить адміністрування складнішим, оскільки кожною базою даних слід керувати індивідуально. Тому це доцільно лише в тому випадку, якщо безпека між орендарями викликає найбільше значення.

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

Перегляди дозволяють орендарям бачити різні частини загальної структури таблиці та дозволяє контролювати, до яких таблиць, до яких стовпців і до яких рядків вони мають доступ. Єдине застереження полягає в тому, що ваша програма повинна гарантувати, що вона використовує лише ті види, а не базові таблиці, інакше існує можливість випадкових витоків даних між орендарями через дефекти програмного забезпечення.

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

Ваша єдина проблема - якщо вам потрібно додати новий стовпець, який потрібно додати до наявного індексу або потрібен новий індекс. Саме тоді таблиця може бути заблокована від використання під час створення індексу - але PostgreSQL підтримує можливість одночасно будувати індекси, не блокуючи таблицю. Це прекрасно працює, якщо новий індекс не повинен бути унікальним і не виявить порушення унікальності.

Можливо, вам не потрібна база даних NoSQL, оскільки вони ефективно видаляють схему з бази даних і вимагають, щоб програма замість неї управляла. Це не здається, що ваші обсяги вимагають такої жертви.