У меня высокопроизводительная система (ну, я думаю, но пока нет на 100%), полностью написанная на C #, и я думаю, что я допустил некоторые большие архитектурные ошибки при проектировании. Причина в том, что его нелегко масштабировать.
Хотя в настоящее время он работает довольно хорошо, я хочу убедиться, что он масштабируется по горизонтали для увеличения объемов, которое, как я ожидаю, может произойти через несколько месяцев.
Эта система имеет большое количество одновременных соединений данных, поступающих в систему, которые в конечном итоге попадут в базу данных после обработки. В настоящее время мы получаем около 300 записей / соединений в минуту.
Система спроектирована следующим образом.
- Вся система размещена на сервере win 2003 с 8 ГБ ОЗУ / 4 vCPU в Амазонке
- C # Сокет-сервер, который получает данные и помещает их в MSMQ
- Процессор для данных и вставки в таблицу базы данных sql server 2008. Одна из основных таблиц содержит около 3 ГБ данных даже после очистки периодических данных. Это имеет правильные индексы, и в настоящее время отчеты достаточно быстры даже для удаленного местоположения.
- Эти обработанные данные затем отправляются в MQ, который затем обрабатывается для правил, которые будут генерировать определенные оповещения
- Есть несколько других связанных программ, кроме перечисленных выше
Теперь основное беспокойство вызывает масштабируемость процессора на шаге (3) и масштабируемость Sql server 2008. Поскольку размер одновременных соединений увеличивается вместе с данными sql-сервера, это усложняет мою жизнь.
Я предложил 2 варианта. Одним из них является серьезная замена серверных процессоров, учитывая тот факт, что нынешняя система полностью построена на технологиях Microsoft.
Для всех опций, для основной самой большой таблицы используйте решение для хранения с балансировкой нагрузки (с репликацией потока) postgresql / pgpool III. Другие таблицы и схемы останутся в SQL Server 2008. Это дает мне экономически эффективное решение для хранения базы данных.
Вариант 1:
- Заменить MSMQ на JBOSS & HornetQ
- Поместите процессор данных на шаге 3 в управляемый контейнером "управляемый сообщениями компонент" в контейнере JBOSS ejb, который предоставит мне варианты для балансировки нагрузки и кластеризации.
- Эта опция потребует, чтобы я переместил основную часть моего решения в unix / linux (я рассматриваю fedora)
Вариант 2:
- Замените MSMQ очередями ActiveMQ (кластеризованными и с балансировкой нагрузки).
- Напишите приложение Java, которое будет обрабатывать сообщения очереди и заботиться о сохранении базы данных.
Эта опция позволит мне увеличить количество серверов linux с экземпляром кластера activemq и новым экземпляром приложения java.
Вариант 3:
- Замените MSMQ очередями ActiveMQ (кластеризованными и с балансировкой нагрузки).
- Используйте только текущий процессор данных (с некоторыми небольшими изменениями для передачи данных в postgresql)
Эта опция заставит меня остаться с Windows
Обратите внимание, что система представляет собой систему реального времени. Достаточно, если система защищена от неисправностей на 99%. Это не торговая система, поэтому я могу позволить себе небольшую потерю данных.
Не знаю, объяснил ли я, что я хочу ясно. Но я приветствую любые вопросы, так как они определенно помогут мне объяснить это намного лучше.
Пожалуйста, дайте ваши ценные предложения, чтобы сделать правильный выбор для долгосрочного решения. На самом деле я сам против варианта 3, но не хочу снова ошибиться, исключив его из списка.
Muthu
Добавлено для уточнения:
Извинения за то, что не ясно.
1. Вопрос на самом деле о масштабируемости архитектуры. Особенно горизонтальная масштабируемость.
2. Текущая средняя нагрузка составляет около 300 в минуту, и она не может быть точно распределена в течение одной минуты.
3. В следующие 8-12 месяцев нагрузка может увеличиться в 10 раз.
Проблема в том, что мы продавали около 50 устройств в месяц, и теперь отдел продаж слишком быстро нарастает.Я считаю, что это может удвоиться.
Сервер Sql имел около 8 ГБ данных, и мы ограничили объем хранилища на устройство, и это помогло уменьшить размер.В настоящее время самая большая таблица разделена на 1 раздел на 200 устройств, и запросы являются разумными.Но я вижу узкое место на стороне Sql с масштабируемостью.
Так что даже если сервер Sql установлен на другом сервере, будет ограничение на количество одновременных обновлений, которые я могу сделать на sqlсервер.Я не вижу опции горизонтальной масштабируемости с балансировкой нагрузки для сервера Sql (хотя она поддерживает параметр высокой доступности с кластеризацией).я неправильно понял MS Sql в балансировке нагрузки?