Все перечисленные вами технологии довольно распространены и приемлемы как для одно-, так и для мультитенантных приложений.Я бы сказал, что поддержка 7 «вещей» для SaaS - это скорее функция того, как вы используете технологии, а не то, какие именно.Похоже, у вас уже есть приложение для одного арендатора, которое работает.Так что, вероятно, нет особых причин отклоняться от выбора технологий, если что-то уже не работает очень хорошо.Ваш вопрос, в остальном, довольно открытый, поэтому трудно быть слишком конкретным.
У меня есть некоторые отзывы о разделении базы данных (и, возможно, других вещей) по идентификатору клиента.Если вы знаете, что со временем у вас может быть много арендаторов (скажем, много тысяч или более, особенно если они маленькие), то, что вы предлагаете, возможно, лучше.Однако, если у вас будет меньшее количество арендаторов (особенно если они большие), вы можете рассмотреть базу данных на каждого арендатора, поэтому у каждого из них есть свое собственное табличное пространство.Под этим я подразумеваю одну установку базы данных с несколькими экземплярами одной и той же схемы внутри нее, по одному на каждого клиента.
Есть несколько причин, по которым это может быть преимуществом.Одним из них является производительность, как вы упомянули.Добавление идентификатора клиента в каждую отдельную таблицу приводит к дополнительным расходам на доступ к диску, времени запроса и увеличивает сложность кода.Каждый индекс в базе данных также должен включать идентификатор клиента.Вы рискуете смешать данные между арендаторами, если не будете осторожны (хотя фильтр Hibernate поможет смягчить это).Имея базу данных на каждого арендатора, вы можете ограничить доступ только к правильной.Портирование вашего текущего приложения, вероятно, будет также намного проще, вам просто нужно перехватить ваш запрос где-то на раннем этапе, чтобы выбрать арендатора на основе URL-адреса и указать нужную базу данных.Резервное копирование также легко сделать для каждого клиента, что особенно полезно, если вы когда-нибудь захотите разрешить ему загрузить резервную копию.
С другой стороны, есть причины этого не делать.Вам придется иметь дело со многими схемами баз данных, и они должны будут обновляться независимо (что может быть преимуществом, если вы хотите избежать отказа всех арендаторов для изменения схемы, вы можете развернуть их постепенно).Это позволяет вам иметь особые случаи, которые могут отличаться от того, чтобы рассматривать платформу как истинное мультитенантное развертывание SaaS, которое обновляется одновременно, что приводит к управлению несколькими версиями в рабочей среде.Наконец, я слышал, что существует почти переломный момент, когда почти каждый поставщик базы данных находится в числе экземпляров схемы, которые они будут поддерживать в одной установке (хотя предположительно некоторые могут достигать сотен тысяч).
Этодействительно зависит от вашего варианта использования, конечно.Вы упомянули об одном арендаторе, и это заставляет меня поверить, что у вас сейчас не так много арендаторов, однако вы упомянули, что число арендаторов растет.Я не уверен, что вы имеете в виду сотни или миллионы, но надеюсь, что это поможет некоторым из ваших соображений.Желаем удачи!