С точки зрения производительности лучше ли соединение mormot rest, чем прямое соединение Oracle?

Question

Я работаю в компании над огромным приложением, созданным с помощью Delphi 10 Seattle (VCL), используя прямое соединение с сервером базы данных Oracle (2-уровневый).

Один из экспертов предложил перейти на 3-уровневую архитектуру, используя mormot (или другая библиотека / компоненты).

Одним из его аргументов является то, что новая архитектура (3-х уровневая) обеспечит большую производительность (время обмена данными), потому что https быстрее, чем прямое соединение оракула, а объекты json намного легче (без использования политики кэширования для остальных), и мы может после этого сделать веб-клиентов.

Я не поняла

• Почему https быстрее, чем протокол соединения Oracle? (если это правда, почему оракул не использует https и json в качестве протокола для обмена данными?).
• Разве это не проблема безопасности, если мы разрешаем все функции и запросы на стороне клиента (даже если мы будем делать веб-клиенты)?

радушно

Answer 1

В контексте любой n-уровневой инфраструктуры удаленный доступ к SOA через решение REST может иметь выигрыш в производительности.

Документация mORMot пытается представить все эти концепции (SOA, REST, MVC, n-Tier, Чистая архитектура, DDD...) и только тогда говорит о влиянии на производительность. Не принимайте документальное предложение изолированно. Рассмотрим всю картину и варианты использования.

Почему https быстрее, чем протокол соединения Oracle?

HTTPS не "быстрее" сам по себе. Это означало, что оно может быть более эффективным для удаленного подключения, особенно через Интернет.

Протокол Oracle Connection был разработан для работы в локальной сети, тогда как HTTP - это модель запросов / ответов.

Основной PRO протокола Oracle заключается в том, что он является более полным (сложным?), Чем простая модель запросов / ответов: он может взаимодействовать с сервером Oracle для кэширования операторов и данных, он может иметь уведомления в реальном времени, он может подготовить данные в двоичном виде готовы для кодирования.

С точки зрения производительности, основной CON протокола Oracle заключается в том, что он требует большего количества обходов по другим каналам: он был разработан для работы в локальной сети с низкой задержкой. По интернет-соединению оно будет намного медленнее и, по соображениям безопасности, очень вероятно будет инкапсулировано в VPN - что еще больше снизит производительность.

Мы не должны говорить о "производительности" абстрактно. Есть несколько способов сделать скин для кошки... Если вы хотите получить сырую производительность запросов, используйте другой тип базы данных, например, Redis.

Но для бизнес-приложений основной момент "производительности", возможно, больше касается масштабирования. И здесь, протокол Oracle имеет большую стоимость в соединениях с базой данных. Поддержание соединения, особенно поддержание транзакций, может быть очень сложным. Вы можете поддерживать до нескольких десятков / сотых одновременных подключений к БД на типичном сервере Oracle. Принимая во внимание, что очень легко иметь REST-сервер, поддерживающий тысячи одновременных клиентов. И даже если в настоящее время вы ожидаете только несколько клиентов, как вы можете представить свое будущее? В настоящее время все серьезные приложения ожидают REST-подобного интерфейса. И держите соединение с базой данных локальным на стороне сервера.

Разве это не проблема безопасности, если мы разрешаем все функции и запросы на стороне клиента (даже если мы будем делать веб-клиенты)?

Безопасность - еще одна проблема, и здесь веб-клиент REST имеет известную и проверенную стратегию с надлежащей методологией аудита. Вы никогда не будете "пускать все функции на клиент" в интерфейсе REST. Фреймворк предлагает несколько способов аутентификации и авторизации - проверьте документацию, от URI-подписи до JWT.

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

В любом случае, такая среда, как mORMot, была разработана, чтобы предлагать REST, SOA, ORM и веб-MVC в одном пакете, а производительность была повышена с нуля - в качестве бонуса. Если вы планируете проектировать приложение RAD VCL/FMX, используйте прямое подключение к базе данных и ориентируйтесь на данные. Если вы хотите что-то более открытое и обслуживаемое, подумайте о SOA и ориентируйтесь на сервис. Сегодня я разрабатываю все свои SOA-решения в виде микро-сервисов с автономными базами данных и mORMot как инструмент с огромной производительностью - до миллиона элементов данных в секунду.

Answer 2

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

Я не думаю, что https в целом быстрее, чем прямое соединение, но это зависит от множества переменных.

Более того, сам mORMot должен также подключиться к базе данных, для чего он может использовать некоторый Direct Oracle Access (я полагаю, тот же, что и тот, с которым вы сравниваете его), или OleDB (он же ADO), который в целом такой же или медленнее чем DOA, так что там нет никакой выгоды. Есть только дополнительные издержки mORMot. Смотрите программную архитектуру mORMot.

Итак, как это может быть лучше?

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

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

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

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