Согласованность данных WebSocket с задержкой

1 mitchkman [2015-12-23 11:05:00]

Предположим, что у меня есть интерфейс JavaScript (например, Angular.js), основанный на Java сервер (Spring, работающий на Tomcat, например) и система управления базами данных (SAP HANA In-Memory, в моем дело). Например, у меня есть графики, которые могут изменяться относительно быстро.

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

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

Когда дело доходит до согласованности, я часто делаю SELECT из базы данных на вставке и снова читаю всю коллекцию объектов, но мои опасения состоят в том, что это не масштабируется.

Существует ли общий подход к этой проблеме или даже существующим структурам?

Изменение: В настоящее время это около 300 объектов с несколькими целыми атрибутами и перекрестными ссылками, которые могут меняться и перестраиваться в миллисекундах, но в будущем могут достигать 10000. Мой вызов здесь - связь между интерфейсом и внутренним интерфейсом, поэтому интерфейс всегда имеет согласованный набор данных в режиме реального времени.

java websocket hana messaging


1 ответ


1 FrankG [2015-12-24 21:21:00]

Насколько близок клиент к серверу? Это расстояние в миле/км или сотни/тысячи миль? Является ли клиент в Интернете или работает на высокопроизводительной VPN? Вы приближаетесь к позвоночнику или десяткам хмеля? Обычно вы обычно не получаете 1 миллисекундную задержку в Интернете, если доверяете общему интернету.

Если вы находитесь во внутренней сети компании, и клиент физически близок к серверу, например, тот же самый компьютер, в той же локальной сети, вы можете получить задержку с одной цифрой ms с помощью WebSocket (я лично получил 3-4 мс во внутренних центрах обработки данных на большой инвестиционный банк).

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

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