Учитывая эти ожидания, какой язык или систему вы бы выбрали для реализации решения?[закрыто]

Question

Вот оценки, которые должна обрабатывать система:

• Более 3000 конечных пользователей
• Более 150 офисов по всему миру
• 1500+ одновременных пользователей в пиковые часы
• Более 10.000 ежедневных обновлений
• 4-5 коммитов в секунду
• 50-70 транзакций в секунду (чтение / поиск/ обновления)

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

Какой бы вы выбрали технологию, почему именно этот выбор и примерно сколько времени потребуется для его внедрения?Спасибо.

Примечание:Я не занимаюсь вербовкой.:-)

Answer 1

Итак, вы спросили, как бы я взялся за такой проект.В мире Smalltalk люди, похоже, согласны с тем, что Gemstone придает вещам волшебный масштаб.

Итак, что я бы на самом деле сделал, так это:Я бы начал разработку с простого изображения Squeak, используя Песчаниковый камень B.Затем наступал момент, когда одно изображение начинало работать слишком медленно.

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

Он обменивается данными с C, Java и Ruby.

На самом деле, у них есть свои Виртуальная машина для ruby, на который тоже стоит взглянуть.

Answer 2

википедия справляется с гораздо более жесткими требованиями с помощью MySQL

Answer 3

Ваши объемы значительны, но вряд ли будут напрягать какую-либо надежную СУБД если запрограммирован эффективно.Если ваша команда неаккуратна (т. Е. небрежно помещает SQL-запросы непосредственно в компоненты, которые затем объединяются в более крупные компоненты), вы сталкиваетесь с вероятностью эффекта "мультипликатора", когда одно логическое требование (получить данные, необходимые для этой страницы) превращается в большое количество физических запросов к базе данных.

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

Предлагаемый вами сценарий, очевидно, тоже рассчитан на 24x7x365, поэтому вам также следует учитывать необходимость требований к мониторингу / информационной панели.

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

Answer 4

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

Answer 5

Ваши ежедневные номера обновлений и коммитов не суммируются.Четыре коммита в секунду = 14 400 в час.

Вы ничего не упомянули об ожидаемом размере базы данных.

В любом случае, я бы сосредоточил свои усилия на выборе надежного серверного модуля, такого как Oracle, Sybase, MS и т.д.Этот выбор будет иметь наибольшее значение в производительности.Внешний интерфейс может быть либо настольным приложением, либо веб-приложением в зависимости от потребностей.Поскольку это будет использоваться во многих офисах по всему миру, веб-приложение может иметь наибольший смысл.

Answer 6

Я бы выбрал MySQL или PostgreSQL.Вряд ли у вас возникнут проблемы ни с тем, ни с другим в соответствии с вашими требованиями.

Answer 7

Я люблю объектные базы данных.С точки зрения количества фиксаций в секунду и обхода базы данных туда и обратно, никакая реляционная база данных не может работать.Проверьте db4o ( дб4о ).Этому очень легко научиться, посмотрите примеры!

Что касается языка программирования и фреймворка пользовательского интерфейса:Что ж, берите то, в чем хороша ваша команда.Динамические языки с меньшими затратами мета-времени, вероятно, сэкономят время.

Answer 8

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

• На что похожа ИТ-культура?Предпочитают ли они много маленьких серверов или меньше больших серверов или большое железо?Какова их позиция по поводу виртуализации?
• На что похожа корпоративная культура?На что похож политический климат?Предложения с открытым исходным кодом вполне могут справиться с нагрузкой, но вам, возможно, придется обратиться к поставщику собственной разработки только потому, что они уже привыкли ориентироваться в политических ветрах крупной компании.Восприятие очень важно.
• Каков уровень зрелости организации?Есть ли у них уже Архитектура предприятия команда на месте?Знают ли они вообще, что такое EA?
• Вы описали оперативную сторону, но как насчет аналитической стороны?Какую технологию OLAP они ожидают использовать или уже имеют на месте?
• Говоря об интеграции, с какими еще системами вам нужно будет интегрироваться?