Высокопроизводительные запросы к базе данных

Question

У меня есть настольное приложение .NET, которое используют 5000 пользователей, распространяемых по всей Канаде. Одной из функций является взаимодействие с некоторыми модемами с использованием некоторых параметров, которые мы получаем из базы данных.

Уникальная особенность этой функции:

1 - он должен быть очень быстрым, потому что он обменивается данными с модемными инструментами, и на этом модеме есть тайм-аут, и мы не можем это контролировать.

2 - те данные, которые мы читаем из базы данных, имеют очень большой размер, у них есть параметры для всех типов модемов, которые похожи на 2000 из них.

3 - эта информация меняется не очень часто. Возможно, они меняются только один раз в месяц.

Как лучше всего справиться с этим?

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

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

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

является ли кеш WCF (если возможно) лучшим ответом?

Можем ли мы получить какое-либо преимущество, если обойдем WCF и получим прямой доступ к базе данных?

Пожалуйста, совет, потому что это очень важный вопрос

Answer 1

Почему бы не позволить всем клиентам иметь свою собственную копию данных? Вы заявили, что это не меняется слишком часто. Вы можете иметь его в облегченной базе данных, такой как SQLite; или в файле XML.

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

Таким образом, ваше приложение также будет работать, если центральный сервер SQL не работает (или отсутствует сетевое подключение, высока задержка и т. Д.).

Всякий раз, когда производительность критична (например, если не получен ответ в течение определенного периода времени, что-то не работает), я бы действительно старался избегать зависимости от сети.

Answer 2

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

Те данные, которые мы читаем из базы данных, очень велики по размеру, у них есть параметры для всех типов модемов, которые похожи на 2000 из них.

Параметры модема для 2000 модемов не кажутся огромным объемом информации - самое большее, я ожидаю, что это будет несколько мегабайт данных. Если это так, загрузите его в память на сервере, чтобы ускорить работу службы WCF.

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

Answer 3

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

Для WCF посмотрите на фактическую структуру запроса и определите, является ли сам запрос или данные в запросе ограничивающим фактором.

Некоторые указатели: держитесь подальше от всего, что выглядит как XML. Используйте нотацию JSON, если вам нужно, или просто простой формат записи CSV, если это возможно. Например: «значение1», «значение2» ...

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