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

17

У меня есть статистика облачной статистики (структурированные данные :: CSV); который я должен предоставить администратору и пользователю.

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

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

Итак, вопросы:

  

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

     

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

     

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

     

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

Примечания:

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

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

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

    

задан Kanagavelu Sugumar 30.06.2016 в 08:42
источник
  • Вам нужна каждая строка, или было бы хорошо собирать только агрегированные данные? Например, можете ли вы хранить частичный агрегат для каждого часа или дня для каждого типа вещей, которые вы запрашиваете? Можете ли вы дать некоторые сведения о том, как выглядят фактические данные? –  Bohemian♦ 05.07.2016 в 08:31
  • @Bohemian Результаты каждого узла будут похожи на CSV, и если пользователь хочет знать одновременных пользователей в определенное время; то каждый кластер java будет иметь свою сумму одновременных пользователей во всех своих узлах. И теперь у нас есть СУМ в Mgr, чтобы дать окончательный результат. Наконец, мне нужны функции SQL, такие как COUNT, MAX, SUM на уровне Java Mgr. –  Kanagavelu Sugumar 05.07.2016 в 08:38
  • Нужно ли делать текущие результаты на микросекунду? Подумайте внимательно, прежде чем отвечать. Это нормально, если они правильные, как в 1 миллисекунду назад? 1 секунда назад? 1 минута назад? Оптимальное решение отличается для каждого из этих ответов, и чем дольше данные могут быть «устаревшими», тем быстрее реагирует на пользователя (может быть достигнуто несколько миллисекунд, если центральным данным разрешено за несколько секунд отставать от фактических данных). –  Bohemian♦ 05.07.2016 в 10:00

5 ответов

6

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

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

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

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

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

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

  

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

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

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

    
ответ дан Captain Fogetti 01.07.2016 в 01:25
  • Я думаю, что сеанс UI не будет минимальным, так как заинтересованы только администраторы. Однако я могу проверить «Trident API». –  Kanagavelu Sugumar 08.07.2016 в 09:09
2

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

    
ответ дан amitmah 08.07.2016 в 01:03
  • Да, я не хочу изобретать; Я просто хочу знать, как существующие технологии решают эту проблему. –  Kanagavelu Sugumar 08.07.2016 в 09:01
  • Для статистического анализа данных БД у вас есть инструменты мониторинга бизнес-активности (BAM), которые могут сообщать вам данные в реальном времени, например, сколько пользователей выполняют определенные действия простым графическим способом. Его компонент SOA-пакета, который предназначен для организации оркестровки в более широком масштабе. –  amitmah 08.07.2016 в 21:12
  • refererence oracle.com/technetwork/middleware/bam/overview/index.html –  amitmah 08.07.2016 в 21:27
2
  

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

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

  

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

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

ответ дан objectNotFound 08.07.2016 в 03:24
  • Что касается «индивидуальной БД»; Я думаю, что у меня все еще есть возможность объединить несколько кластеров для соединения с одной БД; но надолго я думаю о нескольких БД. –  Kanagavelu Sugumar 08.07.2016 в 09:04
  • Вопрос в том, почему? Какая бизнес-потребность может быть удовлетворена только через несколько БД? Если вы не ожидаете сбора 100 или терабайт данных ... централизованное решение БД всегда будет проще реализовать и поддерживать. –  objectNotFound 08.07.2016 в 14:58
2

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

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

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

    
ответ дан Alexandar Petrov 09.07.2016 в 15:00
1

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

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

  

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

Java предоставляет встроенную Java-базу данных как часть дистрибутива Java, которая также доступна как база данных Apache Derby. Эта база данных может использоваться как база данных SQL в памяти. JavaDB & amp; Apache Derby хранит данные на диске. Таким образом, вы не потеряете данные после перезагрузки. Отметьте здесь Ссылка Ссылка

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

  

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

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

  

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

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

  

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

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

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

Примечания:

  

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

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

  

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

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

  

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

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

    
ответ дан Lokendra Chauhan 01.09.2016 в 20:27