Нужны подсказки для оптимизации доступа к Sybase через большую толстую трубу - PullRequest
Новая
       29

Нужны подсказки для оптимизации доступа к Sybase через большую толстую трубу

0 голосов
/ 21 сентября 2011

У меня есть необходимость доступа к базе данных sybase (12.5) из-за рубежа. Высокая задержка - определенно проблема.

Я уже оптимизировал параметры подключения, чтобы лучше использовать сеть и достиг 20-кратного увеличения производительности, но этого все еще недостаточно: 1 минута для получения 3 МБ данных.

Нам нужно еще 10-кратное или 20-кратное увеличение для нашего приложения.

Технические данные:

  • данные передаются через одно TCP-соединение по протоколу TDS
  • клиентское приложение представляет собой лист Excel с макросами, использующий драйвер Sybase по умолчанию
  • корпоративная среда затрудняет большие изменения в архитектуре более 10 лет, поэтому решения должны быть наименее навязчивыми. Но некоторые изменения могут быть достигнуты из-за важности этого проекта.

Кто-нибудь может дать мне указатели?

Я уже думал о:

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

Спасибо.

Ответы [ 2 ]

1 голос
/ 22 сентября 2011

Попробуйте установить локальную базу данных (ASE или ASA) и синхронизировать эти базы данных с Sybase Mobilink (или Sybase Replication Server, если вам нужна небольшая задержка репликации и у вас много денег).

0 голосов
/ 20 октября 2011

(я знаю, что отвечаю на свой вопрос)

В конце концов, мы решили разработать собственный протокол удаленного доступа к базе данных.Это не сложно, поскольку мы используем только базовое подмножество SQL (SELECT и UPDATE), и протокол все равно не должен понимать SQL.

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

Клиент будет нашим приложением, а сервер будет "прокси"к реальной базе данных, сидящей рядом с ней (как предложено @Tim в комментариях).

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

...