Минимальная необходимая пропускная способность для удаленного сервера базы данных
Я хочу создать небольшое складское приложение для своей компании. У нас есть центральный склад, который распределяет до 8 точек продаж по всей стране. Они настаивают на собственном решении. Я подумываю настроить центральный Linux-сервер MySQL DB и подключить к нему филиалы для хранения продаж.
Запросы к БД из веток будут минимальными, может быть 10 в час. Однако мне нужно, чтобы все филиалы могли хранить данные о каждой продаже (идентификатор продукта, идентификатор клиента) в центральной базе данных в пиковое время не чаще, чем раз в пять минут.
У меня вопрос: можно ли мне обойтись простыми линиями DSL 24 Мбит / с /768 Кбит / с? Если нет, то каково требование полосы пропускания? Могу ли я рассчитывать на маршрутизатор с балансировкой нагрузки для объединения дополнительных линий при необходимости? Можете ли вы предложить некоторые технические характеристики серверного оборудования?
Хорошо, позвольте мне прояснить это немного. Все, что мне нужно, это хранить данные (prodctID, itemsSold), когда что-то продается, и получать информацию о наличии в других магазинах. Например, чтобы вернуть количество определенного продукта в других филиалах, чтобы пополнить запас с центрального склада, или чтобы какой-то другой филиал отправил что-то еще. Я предполагаю, что одна строка (branchName, itemQuantity) для каждой другой ветви (7 ветвей - 7 строк) всякий раз, когда из чего-то выходит ветвь. Я думаю, что отправленные данные минимальны, но я не знаю, есть ли накладные расходы. Как я могу это оценить?
5 ответов
Только вы можете ответить на этот вопрос, измерив или оценив использование пропускной способности на основе количества запросов и / или транзакций и размера набора данных для запроса и / или транзакции, умноженного на количество запросов и / или транзакций за определенный период. времени.
Поскольку вы не собираетесь передавать много данных, вам не понадобится слишком большая пропускная способность. Кроме того, может помочь сжатие с использованием SS SS Tunnels.
По моему опыту, задержка является гораздо более серьезной проблемой для удаленных (DB) приложений.
Вы также можете настроить локальные экземпляры MySQL в кластерном решении. Распространение изменений будет управляться асинхронно самой базой данных.
Учитывая узкие рамки вашего проекта, на самом деле должно быть довольно просто определить тип полосы пропускания, которую вы будете использовать, и количество времени, которое потребуется.
Отправка запросов
Это довольно просто рассчитать. Давайте предположим, что это ваш запрос:
SELECT COUNT(*) as Qty, Branch
FROM ProdsTable
GROUP BY Branch
ORDER BY Branch
Это 79 символов. 79 символов = 632 байта, у вас 24Mb входящее соединение, поэтому запрос будет 24*1024*1024/632 одновременные запросы (39819) до ограничения пропускной способности. Я не могу сказать вам, сколько времени это займет с уверенностью, потому что:
- Доступная пропускная способность будет определенно определяться скоростью восходящего соединения клиента
- Существуют дополнительные заголовки и аутентификация, которые выполняются с запросами, особенно если вам нужно инициировать соединение перед отправкой запроса
Но это должно быть достаточно быстро.
Извлечение данных
Давайте предположим:
productID CHAR(20)
itemsSold INT
Это общая сумма 20 + 4 байта для каждого ряда. 7 рядов = 7*(20+4) = 168 байт. У вас есть 768 КБ исходящей полосы пропускания, поэтому вы можете одновременно отправить 4681 запрос такого размера, прежде чем они начнут сжиматься в конце полосы пропускания.
Теперь забудь все, что я только что сказал
Потому что это намного больше, чем просто это. Как я уже упоминал, есть издержки при аутентификации, инициировании соединений, и затем у вас есть задержка по DSL-каналам, возможные проблемы с коэффициентом конфликтности, и поскольку это не по коммутируемой сети, есть все шансы, что целая куча TCP - сборка и повторная передача будут требоваться для каждого отдельного запроса, и это может существенно повлиять на воспринимаемую скорость.
Единственный способ действительно узнать это попробовать.
Требование к полосе пропускания должно быть связано не только с частотой запросов, но и с выходными данными запросов и размером таблиц. Например, один запрос может вернуть одну строку, а другой запрос может вернуть тысячи строк. Таким образом, нет конкретного ответа, если у вас нет приблизительного размера данных и типа запросов.