Имеет ли смысл использование веб-серверов с отслеживанием состояния?

Question

Я работаю над веб-приложением, которое исторически было построено на стеке PHP / MySQL.

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

Это дало нам два преимущества.Одним из них было то, что Java, как язык, был намного быстрее, чем процесс PHP.Вторым было то, что мы могли поддерживать весь набор данных в памяти сервера приложений Java.Так что теперь мы можем выполнять операции с большими вычислениями в памяти, и все происходит намного быстрее.

Это работало некоторое время, пока мы не поняли, что нам нужно масштабировать, поэтому нам нужно больше веб-серверов.

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

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

Какие варианты здесь?Переключиться на хранение данных в памяти, ключ-значение?Должны ли мы полностью отказаться от состояния удержания внутри веб-серверов?

Answer 1

теперь переключаемся на Erlang: -)

да, это шутка; но есть доля правды проблема в том, что у вас изначально было ваше состояние во внешнем общем хранилище: в БД. теперь у вас есть (частично) предварительный расчет во внутреннем необщем хранилище: объекты RAM RAM. Очевидный способ - сделать так, чтобы он был предварительно рассчитан, но во внешнем общем хранилище, чем быстрее, тем лучше.

Один простой ответ - memcached.

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

Answer 2

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

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

Answer 3

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

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

Если это так, я не уверен, где сеть связана с ним.Ваши веб-пользователи просто делают пользовательские запросы после завершения работы?Доступны ли данные только для чтения или главным образом для пользователей?Или они постоянно меняют данные на лету?

Интересно, влияет ли выбранная вами технология постоянства на вещи?Возможно, альтернатива NoSQL может быть лучше для вашей проблемы - например, распределенный кластер MongoDB.

Answer 4

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

Все ли делают разные вычисления для всего набора данных?Это то, что вы можете сделать в партии за ночь и иметь доступ к людям в течение дня?Насколько это чувствительно ко времени?

Я думаю, что на эти вопросы вам нужно ответить, потому что в какой-то момент вы не сможете купить достаточно памяти для хранения нужных вам данных.Это может звучать глупо, учитывая, где вы сейчас находитесь, но вы должны планировать, что это правда.Многие разработчики, с которыми я говорил, не задумываются о том, как выглядит успех и как он влияет на их дизайн.