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