Я планирую переписать локальное (локально установленное) приложение VB (выставление счетов + инвентаризация) в качестве веб-приложения Clojure для клиентов малого бизнеса.Я намереваюсь предложить это как приложение SaaS для клиентов в аналогичной торговле.
Я искал варианты базы данных: мой выбор - СУБД: Postgresql / MySQL.Я мог бы масштабировать до 400 пользователей в первый год, обычно по 20-40 просмотров в день на пользователя - в основном для транзакций, а не статических просмотров.Каждое представление будет включать выборку данных и обновление данных.ACID соответствие необходимо (или я так думаю).Таким образом, объем транзакций не огромен.
Было бы легко выбрать любой из них, исходя из моих предпочтений, но для этого единственного требования, которое, я считаю, типично для приложения SaaS: Схемабудет меняться по мере того, как я добавляю больше клиентов / пользователей и для меняющихся бизнес-требований каждого клиента (я буду предлагать ограниченную гибкость только для начала).Поскольку я не эксперт по БД, основываясь на том, что я могу придумать и прочитать, я могу справиться с этим несколькими способами:
- Иметь традиционный дизайн схемы СУБД в MySQl / Postgresql содна БД хостинг нескольких арендаторов.И добавьте достаточно «свободно плавающих» столбцов в каждую таблицу, чтобы учесть будущие изменения, поскольку я добавляю больше клиентов или изменения для существующего клиента.Это может иметь негативную сторону распространения изменений в БД каждый раз, когда вносится небольшое изменение в Схему.Я помню, как читал, что в Postgresql обновления схемы можно выполнять в режиме реального времени без блокировки.Но не уверен, насколько больно или насколько это практично в этом случае использования.А также, поскольку изменения схемы могут также вводить новые / незначительные изменения SQL.
- Имеют СУБД, но гибко проектируют схему базы данных: с близким к значению атрибута объекта или просто какхранилище ключей-значений.(Рабочий день, например FriendFeed)
- Храните все это в памяти как объекты и периодически сохраняйте их в лог-файлах (например, edval, lmax)
- Переходите на NoSQL DB, такую как MongoDBили Redis.Но, основываясь на том, что я могу собрать, они не подходят для этого варианта использования и не полностью совместимы с ACID.
- Выберите некоторые базы данных NewSQL, такие как VoltDb или JustoneDb (облачные), которые поддерживают поведение, совместимое с SQL и ACIDи являются "новыми поколениями" СУБД.
- Я посмотрел на neo4j (graphdb), но не уверен, подойдет ли этот вариант использования
В моем случае использования болееМасштабируемость или распределенные вычисления, я ищу лучший способ достижения «Гибкость в схеме + ACID + некоторая разумная производительность».Большинство статей, которые я мог найти в сети, говорят о гибкости в схеме как о причине, приводящей к производительности (в случае БД NoSQL) и масштабируемости, оставляя при этом сторону ACID / Transactions.
Является ли это "либо "случай гибкости схемы против ACID", либо есть лучший выход?