Страницы

Уровень 3 (DatabaseCell)

   На этом уровне располагаются системы хранения данных. Это выделенные серверы баз данных, которые работают с системой по собственному протоколу и доступны только службам второго уровня.
Использую Postgres. Но, разумеется, куда без проблем и вопросов. Например, он не умеет работать с асинхронными запросами. А асинхронность в таких больший больших системемах - самая главная штука.

Потому был написан небольшой многопоточный серверок, который

  • Работает в качестве пула соединений
  • Запускает запрос в фон и по завершении информирует удаленный процесс и передает ему результаты.

Как обрабатывать огромные массивы данных? Прежде всего не надо эти огромные массивы создавать, не надо их хранить в огромных таблицах и не надо думать как эти таблицы горизонтально размазывать по серверам.

Основной путь решения проблем управления сложностью на этом уровне становится тактика минимизации блоков управления данными - DataStore. Для каждой задачи выделяется и структурируется минимально возможный уровень обработки данных. Это позволяет активно управлять нагрузкой выделяя наиболее активно используемые зоны данных в отдельные распределенные группы и консолидируя малоактивные на отдельные серверы.

   К примеру,
  • каждый пользователь имеет отдельную зону системной информации, отдельную зону для обработки комментариев и сообщений. 
  • На уровне почтовых адресов каждый район населенного пункта имеет отдельную зону. 
  • На уровне задачи прогнозов в отдельную зону выделен каждый отдельный тип прогнозируемых событий. 
  • На уровне задачи ЖКХ, в отдельную зону выделен каждый дом.
  • Хранилища консолидированных данных также выделены в отдельные зоны. 
Конечно большое число таблиц и схем постгресу не нравится и я это прекрасно понимаю, но за возможность быстрой миграции томов и хранилищ надо чем-то платить.

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

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

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

Следует отметить, что для всех машин 2 и 3 уровней надо применять стратеги географического распределения. Это значит, что при достаточной развитости дата-центра(ов) вторая реплика роя будет располагаться на машине в другом шкафу, третья в другом дата-центре.
Благодаря высокой степени стратификации  процесс реконфигурации массива данных будет проходить быстро и максимально незаметно для конечного пользователя и способен обработать огромные массивы данных.
Related Posts Plugin for WordPress, Blogger...