А что-нибудь меняется, если данные получаются не от самой «персоны», а от третьих лиц? Например, HR вводит ФИО сотрудника, а затем база собирает его рабочие часы? А если рабочие часы собираются без ФИО? Позволяют рабочие часы и номер карточки идентифицировать человека?
Есть Virtual IP устройство (кажется, Citrix Netscaler), за ним стоят 3 веб сервера. Netscaler перенаправляет входящие запросы на один из них. Ну и еще проводит их health check, периодически обращаясь по фиксированному HTTP адресу на каждом из них.
Схема такая же, как для всех других веб серверов в нашем дата центре, никаких ухищрений не требовалось. Или я о них не знаю, я все-таки далек от железа.
Шард функция не случайна, но создана нами с учетом этой проблемы. У нас достаточно клиентов, чтобы распределение в результате было относительно равномерным. Если что, его не очень сложно подкрутить.
На первом этапе сообщения не распределяются, они все сваливаются в одну очередь. Перед очередью стоит несколько легких веб серверов и балансировщик для отказоустойчивости. Нагрузки на систему здесь невелика.
Потом уже происходит декодирование, применяются общие операции, и уже затем распределение по шардам баз данных. Шард ключ на основе номера клиента.
Машинное обучение — действительно интересный курс. Это один из курсов, с которого и началась Coursera, ведет его сооснователь компании Andrew Ng.
Ни до, ни даже после этого курса я не встречал таких интересных и полезных практических заданий. И система проверки этих заданий очень крутая: пишешь код, отсылаешь его на сервер, там проверяется результат выполнения. Если результат совпадает с ожидаемым, получаешь зачет.
Единственный курс, материалом из которого (кодом) я воспользовался в реальной жизни, хотя моя область деятельности довольно далека от машинного обучения.
В общем по статье — очень ограниченная выборка курсов для обзора «по компьютерным наукам». Совет всем — ищите в первоисточниках.
Согласен. Мы стараяемся не использовать таблицы для очередей.
В основном мы сейчас используем SQL Server Service Broker. Там множество своих тонкостей, но если всё настроено хорошо, то проблем с производительностью в работе с очередями не образуется. В качестве бонуса — относительно простые обработчики мы хостим прямо в SQL Server, накладные расходы получаются очень низкими, никаких проблем с управлением коннектами к БД, опросом очередей, локами и т.д. Но это не для всех задач, конечно же.
Хотя, например, очередь входящего шлюза в продакшене (опять же исторически) — это у нас таблица в базе. Даже при том, что в ней лежат относительно большие сериализованные сообщения, мы его разгоняли до 250,000 в минуту.
Конкретно сложно сформулировать. Мы хостимся в дата центре и конфигурация оборудования обусловлена скорее историческими причинами, чем текущими потребностями.
Очереди хранятся в трех кластерах SQL Server, практически не влияя на их загрузку.
Обработчики крутятся на тех же базах + двух отдельных серверах + есть еще сервера веб сервисов, которыми они пользуются…
Схема такая же, как для всех других веб серверов в нашем дата центре, никаких ухищрений не требовалось. Или я о них не знаю, я все-таки далек от железа.
Потом уже происходит декодирование, применяются общие операции, и уже затем распределение по шардам баз данных. Шард ключ на основе номера клиента.
Про гейтвей ответил выше.
Ни до, ни даже после этого курса я не встречал таких интересных и полезных практических заданий. И система проверки этих заданий очень крутая: пишешь код, отсылаешь его на сервер, там проверяется результат выполнения. Если результат совпадает с ожидаемым, получаешь зачет.
Единственный курс, материалом из которого (кодом) я воспользовался в реальной жизни, хотя моя область деятельности довольно далека от машинного обучения.
В общем по статье — очень ограниченная выборка курсов для обзора «по компьютерным наукам». Совет всем — ищите в первоисточниках.
В основном мы сейчас используем SQL Server Service Broker. Там множество своих тонкостей, но если всё настроено хорошо, то проблем с производительностью в работе с очередями не образуется. В качестве бонуса — относительно простые обработчики мы хостим прямо в SQL Server, накладные расходы получаются очень низкими, никаких проблем с управлением коннектами к БД, опросом очередей, локами и т.д. Но это не для всех задач, конечно же.
Хотя, например, очередь входящего шлюза в продакшене (опять же исторически) — это у нас таблица в базе. Даже при том, что в ней лежат относительно большие сериализованные сообщения, мы его разгоняли до 250,000 в минуту.
Очереди хранятся в трех кластерах SQL Server, практически не влияя на их загрузку.
Обработчики крутятся на тех же базах + двух отдельных серверах + есть еще сервера веб сервисов, которыми они пользуются…