Назад | Перейти на главную страницу

Рекомендации по системе с высоким уровнем транзакций

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

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

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

Я знаю, как разрабатывать приложения, особенно клиент-серверные. И я знаю, как проектировать и создавать базы данных и все серверные процессы и функциональность бизнес-логики. Но я не совсем уверен, что именно нужно заказчику в данном конкретном случае.

Заказчик требует, чтобы эта система обменивалась данными между клиентом и сервером через беспроводное сотовое соединение 3G.

Система должна быть масштабируемой, потому что транзакций будет много, хотя транзакции могут быть «пакетными».

Будет несколько локаций, и в каждой локации будет от 2000 до 5000 пользователей.

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

Каждое общение пользователя с сервером будет проходить около 60 транзакций. (5000 пользователей проходят 60 транзакций каждые 10 минут = 300 000 транзакций каждые десять минут [или 30 000 транзакций в минуту; 500 транзакций в секунду])

Мои вопросы к этой группе:

  1. Каков наилучший дизайн для такой системы с большим количеством транзакций, которая масштабируется по мере увеличения количества транзакций и количества местоположений?

  2. Какой язык разработки для клиентского приложения был бы лучшим? (будет ли MS Access работать ??)

  3. Я знаю, что Microsoft SQL Server достаточно мощный, чтобы справиться с рабочей нагрузкой, особенно с несколькими серверами, разделением данных и т.д. И я почти уверен, что MySQL также будет работать. Но является ли одна из этих двух баз данных лучшим выбором (пожалуйста, поясните свой ответ с четкими объективными причинами, а не только личными предпочтениями или мнением)?

  4. Упомянутый клиентом GoDaddy предлагает несколько баз данных MySQL за определенную сумму в месяц, но разве для этого не требуется веб-сайт / приложение? GoDaddy не размещает только базы данных для клиент-серверных приложений?

  5. Может ли такая система должным образом функционировать через сотовые беспроводные соединения 3G между сервером (ами) и до 5000 клиентов при ранее упомянутых суммах транзакций?

Будем признательны за ваши мысли и предложения.

Спасибо

SQL Server и MySQL могут справиться с такой нагрузкой без проблем. 500 транзакций в секунду - это не очень большая рабочая нагрузка.

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

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

Хотя GoDaddy может справиться с этим, для чего-то такого масштаба вам, вероятно, понадобятся выделенные серверы. Начиная с чего-то вроде RackSpace, EC2 или Azure, а затем переходя на выделенные серверы в вашем собственном CoLo или центре обработки данных.

Раньше я был известен как разработчик MSAccess - создавать простые приложения очень легко, и как только вы освоите VB, все еще относительно быстро разработать сложную логику, однако постоянное разочарование было попыткой масштабировать ее для нескольких пользователей. - получение правильной проверки работы и настройки клиентского программного обеспечения / промежуточного программного обеспечения времени выполнения на компьютере пользователя, устранение блокировок записей и получение приемлемой производительности от удаленных баз данных. Очень скоро это превратится в кошмар. И это было примерно с 30 пользователями на одном сайте.

Мысль о поддержке тысячи пользователей, распределенных по несколько сайтов заставит меня с криком выбежать из здания!

Каждый пользователь будет связываться с сервером автоматически каждые десять минут. ... Каждое общение пользователя с сервером будет проходить около 60 транзакций

Итак, вы на самом деле говорите о распределенной базе данных - OMG !!!!!!! ВЫ НЕ ХОЧЕТЕ ЭТОЙ БОЛИ!

Как говорит Мрденни, рабочая нагрузка на сервер невелика, и практически любая многопользовательская СУБД должна быть способна поддерживать уровень транзакций.

Но если бы это был я, НИКАКОГО Я не попытался бы реализовать пользовательский интерфейс с помощью MS Access.

Вы не предоставили много информации об отношениях между сайтами / пользователями / сетью. Кажется странным, что вы пытаетесь подключать сайты с помощью 3G, а не с помощью обычного WAN / VPN, но также кажется странным, что у вас будут клиенты внутри сайта, общающиеся через 3G. Также необычно найти устройство 3G, способное запускать MSAccess.

Если я предполагаю, что на каждом сайте есть обычная инфраструктура и что сайты подключены через 3G, то я бы выбрал локальную базу данных на каждом сайте - с веб-интерфейсом (без развертывания). Затем позаботьтесь о консолидации / публикации данных между сайтами по отдельности (и у MySQL, и у MSSQL есть инструменты для облегчения этого - с Oracle это немного сложнее).

Конечно, если у вас тысячи сайтов и тысячи пользователей - это другая история. И если ты можешь только подключите их через 3G, тогда может быть более эффективным пакетирование данных на клиенте - что довольно сложно в старых браузерах, но вполне возможно с локальным хранилищем GoogleGears / HTML5.

Несмотря на то, что вы можете бесплатно распространять клиент среды выполнения MSAccess, стоимость повторной реализации системы на PHP или ASP, вероятно, будет меньше, чем стоимость развертывания и управления всеми этими экземплярами MSAccess (при условии, что клиентские устройства могут запускать MSAccess).

Заказчик упомянул GoDaddy

О, Боже. Похоже, одна из компаний, о которой вы читаете через день на dailyWTF.