Какой самый экономически эффективный способ разбить централизованную базу данных?

Question

Исходя из этого вопроса ...

• Что делать, если вы действительно испортили дизайн распределенной системы?

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

Итак, они хотят, чтобы я цитировал (хм). Для того, чтобы я мог получить это как можно точнее, мне нужно будет решить, как я на самом деле это сделаю. Вот 3 сценария ...

Сценарии

Разделить базу данных

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

Реализация кэширования в самой маленькой системе

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

1. Настройка нового сервера в офисе клиента (внутри компании).
2. Перемещение центральной базы данных и веб-службы на новый внутренний сервер.
3. Сохраните веб-сайт на размещенном сервере, но измените URL-адрес веб-службы так, чтобы он указывал на офисный сервер.
4. Реализация простой системы кэширования изображений и наиболее часто используемых данных (например, информации о продукте).

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

Кроме того, не все данные могут быть кэшированы, например, когда клиент обновляет свой заказ. Кроме того, избыточность соединения становится здесь огромным фактором; Что делать, если офисное соединение отключено? Ничего не поделаешь, кроме как показать клиенту сообщение об ошибке, что является неприятным, но неизбежным злом.

Тайна, вариант № 3

Предложения приветствуются!

SQL-репликация

Я рассмотрел репликацию MSSQL. Но у меня нет с этим опыта, поэтому я беспокоюсь о том, как обрабатываются конфликты и т. Д. Это вариант? Учитывая, что есть физические файлы, и так далее. Кроме того, я считаю, что нам нужно перейти с SQL Express на платный SQL и купить две лицензии.

Технические

Компоненты

• Сайт ASP.Net
• Веб-сервис ASP.net
• .Net настольное приложение
• База данных MSSQL 2008 express

Соединения

• Офисное соединение : 8 мбит вниз и 1 мбит вверх заявленная линия (50: 1)
• Размещенный виртуальный сервер: Windows 2008 с 10-мегабитной линией

Answer 1

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

Этот веб-сервис вполне может быть благодатью, поскольку он позволяет вам разделять сообщения, не влияя на клиента.

Давным-давно я занимался проектированием именно такой системы.

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

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

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

Когда я говорю здесь о сервере, я имею в виду сервер БД с набором веб-сервисов, которые взаимодействуют между собой.

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

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

Вторая функция каждого неосновного сервера заключалась в координации изменений с ведущим. Это включало очень упрощенный процесс фактической прозрачной передачи большей части работы на главный сервер.

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

Дело в том, что если у вас есть веб-служба, это даст вам большую гибкость в отношении того, как вы реализуете это.

Вероятно, я бы начал с изучения возможности реализации одного из методов репликации SQL-сервера

Применяются обычные заявления об отказе от ответственности:

Answer 2

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

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

Answer 3

Разделение базы данных не сильно поможет, но добавит кошмара.ИМО, сначала вы должны попытаться оптимизировать базу данных, обновить некоторые индексы или, может быть, добавить еще несколько, оптимизировать некоторые запросы и так далее.Для настройки производительности базы данных я рекомендую прочитать некоторые статьи с сайта simple-talk.com .
Кроме того, чтобы сэкономить пропускную способность, вы можете добавить массовую обработку в свой клиент Windows, а также добавить архивирование (архивирование) в свойвеб-сервис.
И, вероятно, вам следует перейти на MS SQL 2008 Express, это также бесплатно.

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

РЕДАКТИРОВАТЬ 01/ 03:
Если узким местом является соединение «вверх», вы можете сделать только следующее:
1. Добавить архивирование сообщений для службы и клиента
2. Выполнить массовые операции и использовать их
3.Попробуйте уменьшить количество операций для каждого пользовательского случая для наиболее частых случаев
4. Добавьте локальную базу данных для клиентов Windows и выполните все операции, используя ее, и синхронизируйте локальную базу данных и основную базу данных по таймеру.

И репликация sql не сильно вам поможет в этом случае.Самым быстрым и дешевым решением является увеличение количества подключений, поскольку все другие способы (кроме первого) займут много времени.
Если вы решите переписать службу для поддержки большого объема, я рекомендую вам взглянуть на Агата проект