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

Ответ 1

Вы хотите масштабировать свое приложение, но вы разработали неотъемлемое узкое место. А именно: Mgr.

Что бы я сделал, так это то, что я разделил бы Mgr как минимум на две части. Front-end и backend. Передняя часть может быть просто агрегатором и/или контроллером, который собирает все запросы со всех разных серверов пользовательского интерфейса, отбрасывает эти запросы и помещает их в очередь (RabbitMQ, Kafka, Redis, что угодно), создавая сообщение с идентификатором сеанса пользовательского интерфейса или нечто подобное, которое однозначно идентифицирует источник запроса. Тогда вам просто нужно подождать, пока вы не получите ответ в очереди (с другой темой, конечно).

Затем на вашем сервере (на другой стороне очереди) вы можете настроить столько узлов, сколько потребуется вашему загрузчику, и заставить их выполнять одну и ту же задачу. А именно: снимать запросы из очереди и при необходимости вызывать эти API мониторинга производительности. Вы можете масштабировать эти серверные узлы столько, сколько хотите, поскольку у них нет состояния, все состояние, которое необходимо сохранить, уже является частью сообщений в очереди, которые будут автоматически сохраняться для вас Redis/Kafka/RabbitMQ или что бы вы ни выбрали.

Вы также можете использовать Apache Storm или что-то подобное, чтобы сделать это для вас в бэкэнд, так как он был разработан именно для таких приложений.

Apache Storm также имеет встроенную возможность слияния, представленную через Trident API.

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

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

Хорошо, если у вас так много вопросов относительно обработки пользовательских подключений и обслуживания этих клиентов с ответами, я бы предложил забрать книгу по API сервлетов Java. Возможно, вы захотите прочитать это, например: Сервлет и JSP: Учебное пособие (Серия учебников). Он немного устарел, но хорошо написан.

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

Ответ 2

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

Ответ 3

Но для масштабируемости; сбор данных будет собираться несколькими машины (перфорированный монитор), который связан с отдельными БД.

Примерно, какой тип масштабирования вы ожидаете... это 100 с GB нескольких Terra Bytes.... В наши дни SQL Server и Oracle могут обрабатывать действительно большие объемы данных. Как только данные собираются в центральном db, игра идет в поисках и хруста.

Теперь Менеджер (Mgr) отвечает за многоадресную рассылку запроса всем перфорированный монитор; для сбора данных общей статистики для удовлетворения единого пользовательского интерфейса запрос.

Это будет важной задачей, чтобы написать это, и это будет действительно сложное ИМХО. Тем не менее я не эксперт в этом аспекте.

Ответ 4

Я бы поставил слой Hazelcast или Infinispan или что-то подобное в вашем мониторе производительности вместо Hazelcast. Сам монитор производительности, подобный логике, может быть частью DataGrid. Затем MySQL будет работать как постоянное хранилище этой сетки данных. В этом смысле вы можете иметь более одного Mysql, и каждый mysql будет просто содержать часть данных. Он просто будет работать как способность расширения выйти за пределы вашей максимальной ОЗУ. Сверхурочные вы масштабируете свой монитор производительности, а также масштабируете свои постоянные возможности.

Молодые, затем Map Reduce или другие распределенные функции для агрегации могут привести к огромному количеству паралилизма и способности сервера получать значительно больше запросов. Также такая архитектура масштабируется горизонтально. В конце он должен выглядеть примерно так:

И только на другой ноте, чтобы сказать, что вообще не нужно иметь 1 MySQL для каждой каретки. Это зависит от цели. Я также забыл диспетчера на диаграмме, но все, что просто, может либо работать как шлюз к сетке данных, либо, наоборот, его можно объединить с сеткой.

Ответ 5

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

Я хотел бы ответить на него по вашему вопросу, проблемам в текущем подходе и предлагаемом решении...

1) Как я сделаю, чтобы данные для нескольких мониторов были отсортированы на основе запрос клиента в Mgr. Каждый монитор может дать результат в соответствии с клиентский запрос; но все же, как объединить несколько машин с Ява? Средства Как выполнить в памяти sql aggregate/scalar (например, Groupby, orderby, avg) для всех результатов, полученных из множественные кластеры на MGR. Как реализовать SQL-sql-агрегат/скаляр функциональность в java-стороне, любые известные API-интерфейсы? Я думаю, что мне нужно Уменьшите часть метода mapreduce в hadoop.

Java предоставляет встроенную Java-базу данных как часть дистрибутива Java, которая также доступна как база данных Apache Derby. Эта база данных может использоваться как база данных SQL в памяти. JavaDB и Apache Derby хранят данные на диске. Таким образом, вы не потеряете данные после перезагрузки. Проверьте http://www.oracle.com/technetwork/java/javadb/overview/index.html https://db.apache.org/derby/ strong >

Для Map-Reduce простая подборка, основанная на Java, будет работать. В этом случае я не думаю, что вам нужна какая-то специальная структура Map-Reduce. Тем не менее, вы должны учитывать Out Of Memory, пропускную способность сети и т.д., Когда вы читаете данные из нескольких источников

2) Запрос из пользовательского интерфейса (предположим, что select count (*) из DB, где Memory > 1000 МБ) должны быть перенаправлены на несколько машин. Теперь, как отправить параллельные запросы к отдельному монитору и потребляют только тогда, когда все узлы реагируют? Означает, как ждать Пользовательский поток до потребления всего ответы от лучших мониторов? Как вызвать параллельный запрос REST для одного запроса пользовательского интерфейса на MGR.

В идеале приложение типа NodeJS действительно является лучшим в этом случае, когда приложение получает обратный вызов всякий раз, когда возникает ответ HTTP-вызова. Однако вы можете реализовать шаблон наблюдателя, как описано здесь Как выполнить обратный вызов JAVA между классами?

3) Нужно ли мне проверять подлинность пользователя пользовательского интерфейса как на мониторе Mgr, так и на Perf?

Он должен основываться на вашем требовании

4) Считаете ли вы какой-либо недостаток в этом подходе?

Есть несколько недостатков этого подхода

• Данные не должны выводиться по запросу из пользовательского интерфейса. По крайней мере данные должны быть доступны в централизованной базе данных всякий раз, когда есть запрос на создание данных. Вытягивание данных из разных конечных точек является дорогостоящим.
• Статистика должна периодически собираться для ведения истории, а отчеты должны создаваться на основе временного окна перемещения.
• JVM может выходить OutOfMemory, если большие данные должны быть процессом. Требуется правильная обработка.
• Большие данные могут передаваться по сети каждый раз, когда появляется новый запрос. Это может быть для тех же данных снова.

Примечания:

1) Я не пошел на NoSql, потому что данные структурированы и не объединены требуется.

Нет SQL не означает, что не существует структуры. Даже база данных NoSQL лучше всего подходит для таких данных, где вы не обновляете записи, транзакции и т.д. Не требуются.

2) Я не пошел за node.js, так как я новичок для этого и могу взять больше время на его разработку. Также я не разрабатываю никаких параллельных особенно важны, когда единственная резьба лучше всего подходит. Только здесь выполняется push/retrieve данных. Никаких изменений не происходит.

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

3) Я хочу отдельную БД для каждого монитора ИЛИ, по крайней мере, два экземпляра DB с несколькими кластерами для ускорения поддержки экземпляра доступ к статистическим данным BIG реального времени.

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