Главная » Блоги Экспертов И ИТ-Компаний » Почему слон не может летать?
Начинаем публикацию статей о практике внедрения СЭД 2 года назад

Почему слон не может летать?

Представьте себе высокую гору. Вам надо добраться до ее заснеженной вершины. У Вас есть слон – прекрасное трудолюбивое животное, которое замечательно работает и катает Вас по небольшим близлежащим холмам. А Вам надо на высокую гору. «Эх, была бы у меня птица…», - думаете Вы. Но за птицу надо платить. А слон бесплатный. Можно ли на слоне добраться до вершины? Безусловно, это займет много времени и сил, но добраться можно. Почти до самой вершины, если будет дорога и ее не преградит пропасть… Возможно, купить птицу будет дешевле, чем использовать слона для подъема на высокую гору?

Мы много лет занимаемся разработкой сложных высоконагруженных систем, которые разворачиваются на кластере серверов, обрабатывают миллионы документов, и обеспечивают работу нескольких тысяч пользователей. В данной статье мы делимся с вами результатами наших исследований о том, насколько применимы для решения серьезных задач современные открытые СУБД, в частности популярная объектно-реляционная СУБД PostgreSQL и ее версия Postgres XL (позволяющая организовать многосерверную работу).

Базы данных в наших проектах находятся под управлением СУБД Cache, которую мы выбрали не случайно. Анализируя 15 лет назад преимущества и недостатки различных реляционных и нереляционных баз данных, мы обратили внимание на СУБД Cache компании с 25-летней (на тот момент) историей – InterSystems. Это была единственная система, предоставлявшая разработчику инструменты для работы с данными напрямую, без необходимости преобразования данных в табличную форму, обеспечивая при этом всю необходимую функциональность баз данных, в том числе гибкие механизмы хранения, индексации, поиска, управления синхронной и асинхронной обработкой данных и самостоятельного управления иерархическими и битовыми индексами. Все это обеспечивало возможность создания платформы, не привязанной к жестким табличным представлениям, как это было бы в случае использования реляционной БД, а значит – с минимальным количеством преобразований данных. При этом СУБД Cache уже тогда позволяла создавать отказоустойчивые конфигурации, масштабируемые по нагрузке, на недорогом аппаратном обеспечении.

В последнее время много говорят о технологии NoSQL. СУБД Cache позволяет организовать шесть разных способов работы с данными: NoSQL key-value и document, а также column, graph, SQL и объектный доступ.

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

Общая информация

Любая информационная система работает с данными. За обработку данных отвечает специальный класс программного обеспечения – системы управления базами данных (СУБД). Основные функции СУБД - управление данными во внешней памяти (на дисках), в оперативной памяти с использованием кэша, а также предоставление данных прикладным приложениям, обеспечение целостности данных, ведение журналов изменений, резервное копирование и восстановление базы данных после сбоев.

На рынке сегодня представлено большое количество СУБД: реляционные, объектные, открытые, закрытые, локальные, сетевые и пр. Для небольшого решения, работающего на одном сервере, (небольшого как по количеству обрабатываемых данных, так и по количеству одновременно подключенных пользователей) практически нет разницы, какую СУБД использовать. СУБД, сервер и дисковая подсистема вполне успеет обработать запросы пользовательских приложений. А для высоконагруженных решений становится очень важным использование всех возможностей программно-аппаратного комплекса. СУБД должна поддерживать распределенную работу: распределять нагрузку между серверами, обеспечивать сохранность данных, размещенных на нескольких серверах и восстанавливать их в случае сбоя, а также учитывать естественные ограничения по скорости записи и чтения данных с диска.

Многосерверные конфигурации используются в проектах, когда производительности сервера или дисковой подсистемы становится недостаточно для обеспечения быстрой и надежной работы. Проблемы могут возникнуть, если диск или сервер не справляется с нагрузкой «на чтение» или «на запись». Рассмотрим, как PostgreSQL и Cache распределяют нагрузку и управляют данными.

Производительности сервера и дисковой подсистемы достаточно для решения задачи Если производительности сервера и дисковой подсистемы достаточно для решения задачи, то обычно используется конфигурация, в которой используется основной и теневой сервер (отказоустойчивость обеспечивается внешними средствами, например, с помощью операционной системы и СХД). Основной и теневой серверы подключаются к одному и тому же дисковому пространству, на котором размещена база данных.

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

Не хватает производительности «на чтение»

Если не хватает производительности «на чтение», то PostgreSQL тиражирует базы данных. Многосерверная конфигурация будет выглядеть следующим образом. К конфигурации одного сервера добавляется требуемое количество реплик баз данных, работающих только на чтение. Поддержка актуальности данных осуществляется через журналы. Также для повышения надежности добавляется еще один (резервный) «узел».

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

СУБД Cache использует принципиально другой подход и не требует тиражирования и синхронизации реплик базы данных. Все операции выполняются через память по сети с сохранением целостности данных. Проблема нехватки производительности “на чтение” решается путем подключения ЕСР- клиентов.

СУБД Cache использует Enterprise Cache Protocol (ECP, протокол распределенного кэша).

В СУБД Cache выделяют две группы серверов - ЕСР-серверы, обеспечивающие взаимодействие с базой данных и ЕСР-клиенты, обеспечивающие исполнение запросов пользователей. Взаимодействие пользовательских приложений осуществляется через ЕСР-клиенты, которые в свою очередь обращаются к ЕСР-серверу для получения данных.

В рамках ЕСР-протокола пользовательские процессы, которые работают на ECP-клиентах и обслуживают запросы, получают доступ к локальному кэшу недавно использованных данных. И только если этих данных недостаточно, ECP-сервер по запросу ЕСР-клиента обращается к базе данных. С помощью протокола ECP выполняется автоматическое управление кэшем: наиболее часто используемые данные сохраняются в кэше, часто обновляемые данные периодически реплицируются по запросу из кэша ЕСР-сервера, обеспечивая постоянную целостность данных на всех ECP-клиентах. При этом внутренний алгоритм СУБД Cache предполагает, что кэши базы данных синхронизируются между ECP-клиентом и ECP-сервером. После внесения изменений на одном из ЕСР-клиентов все остальные ЕСР-клиенты смогут прочитать только актуальные данные из кэша ЕСР- сервера.

Так как информация, которую затребовал тот или иной пользователь, может быть задействована на нескольких ECP-клиентах, необходимо блокировать данные на короткий период времени и быстро выполнять операции. СУБД Cache поддерживает целостность данных в рамках одного ECP-сервера вне зависимости от количества ECP-клиентов, которые к нему подключены.

Для того, чтобы снизить и распределить нагрузку между серверами БД, СУБД PostgreSQL выполняет тиражирование баз данных через журнал. СУБД Cache, благодаря ECP-протоколу и использованию памяти для кэширования данных базы, работает только с одной копией базы данных. Таким образом, сокращается объем используемого дискового пространства.

Не хватает производительности «на запись»

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

В одной из веток PostgreSQL (Postgres XL) недавно была предпринята попытка решить задачу на уровне СУБД и были введены понятия узла (node) и коннектор (connector). Конфигурация PostgreSQL, снижающая нагрузку, будет выглядеть следующим образом. Пользовательские приложения обращаются к коннекторам, которые в свою очередь обращаются к серверам баз данных. Коннекторы осуществляют доступ к узлам. В некотором смысле коннектор - это аналог ЕСР- клиента, но в отличие от него коннектор просто транслирует запрос к серверам баз данных, не накапливая информацию и имея возможности воспользоваться данными, сохранненными в кэше.

СУБД Cache разделяет две разных ситуации: если не хватает мощности диска и если не хватает мощности сервера.

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

Если сервер не справляется с нагрузкой на запись, то производится тиражирование ЕСР-серверов. Каждый ЕСР-клиент может работать со всеми ЕСР-серверами.

Реализация крупного проекта

Рассмотрим, какая архитектура используется на реальных проектах. Например, крупный проект TripAdvisor, реализованный с использованием СУБД PostgreSQL, согласно презентации Метью Келли (Metthew Kelly) «At the Heart of a Giant: Postgres at TripAdvisor» на конференции PGConf US в 2015 году (

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

Какая же конфигурация была бы построена, если проект был бы реализован на базе СУБД Cache? При реализации высоконагруженных систем, используется несколько ECP-серверов, каждый из которых работает с группой ECP-клиентов.

Благодаря использованию ECP-протокола, в случае фатального сбоя пользовательские сессии будут сохранены. Если на сервере БД произошел сбой, то переход на теневой сервер будет незаметен для пользователя, поскольку на ЕСР-клиенте хранится вся необходимая для работы информация. Обращение к базе производится только если данные в кэше не актуальны. После восстановления работоспособности кэши синхронизируются.

Технические преимущества

СУБД PosgreSQL очень привлекательная технология, особенно для решений, не предъявляющих повышенных требований к скорости и надежности. В серьезных проектах технические недочеты приходится компенсировать раздуванием штата обслуживающего персонала, увеличением количества используемых серверов и привлечением сторонних технологий для репликации, балансировки нагрузки и обеспечения отказоустойчивости.

Ниже приведены технологические преимущества технологий, реализованных в СУБД Cache и (что очень важно) используемых в течение более 30 лет в промышленной эксплуатации.

Преимущество 1. Возможность в многосерверной конфигурации все базы данных использовать в режиме чтение-запись

СУБД PostgreSQL для снижения нагрузки на серверы использует вариант, когда одна БД работает на чтение и запись, а остальные – только на чтение. Синхронизация данных между репликами выполняется с помощью наката журналов: журнал передается и асинхронно накатывается с основного сервера на дублирующие через диск. Следовательно, возникает промежуток времени, при которой приложение обращается к базе данных, но получает неактуальную (устаревшую) информацию. Поскольку запрашиваются данные, в которые были внесены изменения, однако из журнала на дублирующих серверах еще не был произведен накат.

СУБД Cache позволяет сделать так, чтобы все ЕСР-клиенты работали и на чтение и запись, поэтому проблем с доступом к неактуальной информации не возникает. Также, за счет исключения необходимости тиражирования баз данных для распределения нагрузки, для реализации аналогичной по масштабу информационной системы СУБД Cache требуется меньшее количество серверов и дискового пространства.

Преимущество 2. Более высокая скорость предоставления актуальных данных в многосерверной конфигурации

Репликация — механизм синхронизации содержимого нескольких копий объекта. Сведения об изменении, выполненном на основном сервере, записываются в журнал, журнал передается на дублирующий сервер, после чего зафиксированные в нем изменения выполняются на дублирующей базе данных. Данные в двух базах становятся идентичными только после того, как изменения были выполнены в дублирующей базе данных.

Если в проекте используется несколько серверов БД, то СУБД PostgreSQL для синхронизации данных между ними использует журналирование. Для того, чтобы реплика была идентичной основной базе данных, журнал передается и записанные в нем изменения накатываются на дублирующий сервер. Дублирующий сервер будет работать с актуальными данными только после того, как был обработан журнал. Для конечного приложения это означает, что пользователь получит доступ к гарантированно актуальным данным только через некоторое время.

СУБД Cache гарантирует, что пользователь получит доступ к актуальной информации гораздо быстрее, поскольку СУБД Cache использует возможности ЕСР-протокола и выполняет репликацию данных через память: информация передается между ЕСР-клиентами с помощью распределенного кэша.

Если необходимо внести изменение, то ЕСР-клиент отправляет запрос на изменение блока памяти, производится уведомление всех задействованных ЕСР-клиентов о том, что блок будет изменен, после этого ЕСР-клиент получает разрешение установить блокировку. Другими словами, информацию о том, что данные устарели, все ЕСР-клиенты узнают по факту изменения данных, а реальное изменение данных выполняется позже. ЕСР-клиенты гарантированно не будут работать с устаревшей информацией, поскольку уведомление о том, что какой-либо блок устарел они получают сразу же. Если в запросе требуется получить информацию именно этого блока, то только в этом случае происходит обращение к базе данных. Во всех остальных случаях работа осуществляется через кэш.

Обобщая, можно говорить, что СУБД Cache имеет возможность выполнять репликацию на уровне блока в синхронном режиме, без потери времени и с гарантией актуальности данных (преимущество 3).

Не имея на текущий момент аналогичного механизма, СУБД PostgreSQL, вынужден выбирать между потерей времени (в случае синхронной репликации) и неактуальными данными (в случае асинхронной репликации).

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

Преимущество 4. Снижение нагрузки на диск за счет того, что данные предоставляются через кэш

Следствием того, что СУБД Cache использует технологию распределенного кэширования для работы с данными, является минимизация обращения к базе данных и уменьшение нагрузки на диски. Если пришел запрос на выдачу данных, то обращение к базе производится только в том случае, если данные не содержатся в кэше ЕСР-клиента или ЕСР-сервера. Таким образом, нагрузка на диск существенно снижается через некоторое время после старта системы, когда кэш «разогрелся». Редко используемые данные в кэше вытесняются часто используемыми, а при наличии достаточного количества ресурсов вся база данных может быть размещена в памяти сервера базы и/или серверов клиентов.

Преимущество 5. Меньший занимаемый объем дискового пространства

Для балансировки нагрузки СУБД Cache не требуется тиражировать базы данных. СУБД Cache выполняет тиражирование ЕСР-клиентов, которые работают с одной базой данных или размещает данные на разных дисках (мэппинг), оставляя их для приложения логически едиными.

Преимущество 6. В случае сбоя сохраняется контент пользовательских сессий

Поскольку в СУБД Cache реализована уникальная технология работы с данными, ECP-клиент сохраняет пользовательскую сессию в кэше, и в случае сбоя на уровне базы данных может восстановить данные.

Данное преимущество позволяет сделать незаметным для пользователя практически любой сбой на уровне базы данных: если на сервере БД произошел сбой, то переход на теневой сервер будет незаметен, поскольку все данные отдаются из кэша и запрашиваются только в случае необходимости. Если произошел сбой на уровне базы данных, ECP-клиент продолжает работу, поскольку в кэше хранятся все необходимые данные. Пока восстанавливается работоспособность сервера базы данных (или производится переключение на резервный сервер), ЕСР-клиент использует сохраненные в кэше данные.

Резюме

В одном из наших проектов мы разрабатывали сложное высоконагруженное решение, в котором одна из подсистем использовала СУБД PosgreSQL. Мы не умаляем достоинств данной СУБД. Чтобы обеспечить должный уровень надежности и отказоустойчивости, мы дублировали в СУБД Cache данные, размещенные в СУБД PosgreSQL. Оперативная работа выполнялась в двух копиях СУБД PosgreSQL, а ее результаты с помощью асинхронной репликации размещались в основной базе данных под управлением СУБД Cache и были доступны для всех подсистем программного комплекса.

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

Технологические преимущества СУБД Cache, о которых говорилось в данном материале, уже реализованы и используются в промышленной эксплуатации более 30-ти лет:

  • Возможность в многосерверной конфигурации все серверы базы данных использовать в режиме чтение-запись за счет использования ECP-технологии.
  • Более высокая скорость предоставления актуальных данных в многосерверной конфигурации за счет того, что данные предоставляются через кэш.
  • Выполнение репликации на уровне блока в синхронном режиме, без потери времени и с гарантией актуальности данных.
  • Снижение нагрузки на диск за счет того, что данные предоставляются через кэш.
  • Меньший занимаемый объем дискового пространства за счет отсутствия необходимости тиражировать базы данных для снижения нагрузки.
  • Сохранение контента пользовательских сессий в случае сбоя за счет использования ЕСР- технологии.

СУБД Cache управляет данными и осуществляет балансировку нагрузки собственными средствами, без привлечения внешнего программного обеспечения. Корректность транзакций на уровне базы данных обеспечивает ECP-сервер. ECP-клиенты работают с оперативной памятью и распределенным кэшем данных и имеют доступ к нескольким ЕСР-серверам.

Попытка PostgreSQL организовать отказоустойчивую конфигурацию приводят к настоящему коллапсу: невозможно гарантировать, что приложение получит актуальные данные для работы и будет обеспечена надлежащая скорость работы.

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

Итак. Почему же слон не может летать? – Он технически не готов к этому. Возможно, когда- нибудь он и сможет научиться. Но ему придется пройти тот путь, который уже пройден СУБД Cache. Более 30 лет технология ECP работает в промышленном режиме на очень крупных проектах. Такое отставание нелегко преодолеть, особенно если технологические решения не были заложены в архитектуру изначально.

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

В данной статье использовалась техническая документация, размещенная на сайтах http://www.intersystems.com/ и https://www.postgresql.org/ , а также материалы конференции PGConf US http://www.pgconf.us/2015/:

  • «Scale-out PostgreSQL with Postgres-XL»
  • «The Elephants In The Room: Limitations of the PostgreSQL Core Technology»
  • «At The Heart Of A Giant: Postgres At TripAdvisor»
  • «The Future of PostgreSQL Multi-Master Replication»
  • «Presentation: PostgreSQL & EnterpriseDB Market Overview – TechXperts»

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Москва
+7 (495) 741-48-08
---

О компании

Компания ЛЕТОГРАФ занимается разработкой и внедрением одноименной системы управления документами, автоматизации бизнес-процессов и интеграции приложений. Основные направления деятельности - развитие платформы ЛЕТОГРАФ и реализация масштабных проектов внедрения.

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

О платформе ЛЕТОГРАФ

ЛЕТОГРАФ – готовое централизованное расширяемое решение для автоматизации документооборота и архива территориально-распределенных организаций. С помощью платформы ЛЕТОГРАФ могут быть решены все задачи по управлению документами: от «классического» документооборота и архива до управления корпоративным контентом (ЕСМ).

Масштабируемые отказоустойчивые решения на базе платформы ЛЕТОГРАФ устанавливаются централизованно на кластере серверов и реализуют на практике концепцию управления «большими данными». Пользователи работают с системой в интерфейсе веб-браузера и получают доступ к информации в режиме он-лайн со стационарных или мобильных устройств.

 

Система ЛЕТОГРАФ унифицирует работу со всеми электронными и бумажными документами организации (входящими, исходящими, внутренними, кадровыми, архивными, договорами, счетами, заявками и пр.), а также может быть интегрирована с корпоративными и внешними системами.

Адрес: Россия, 105066, г. Москва, ул. Бауманская, д. 6 

Контактное лицо: Александр Иванов, специалист по маркетингу


Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>