Что такое пул данных
Пул данных
Всем привет. Сегодня мы поговорим о пуле данных. Под словосочетанием “пул данных” частенько понимаются принципиально разные вещи. Например, система, которая имитирует пользовательский ввод данных и используется для автоматического тестирования какой-либо другой системы. Я же буду подразумевать под пулом данных некоторую программно-алгоритмическую структуру, предназначенную для хранения данных и работы с ними.
Итак, зачем вообще нужен пул данных? Основной принцип разработки софта – модульность. То есть мы стремимся к тому, чтобы минимизировать зависимости между классами, чтобы наша программа была не монолитным куском кода, а набором некоторых подпрограмм, которые можно комбинировать друг с другом, добиваясь гибкости и расширяемости системы. Понятное дело, такой подход – результат эволюции. И его преимущества сложно переоценить. Хотя бы тот факт, что в монолитной программе исправление какого-нибудь участка кода может запросто привести к веерным изменениям по всему монолиту, в то время, как в хорошо продуманной модульной структуре любые изменения останутся локальными, главное только сохранить формат и логику входных и выходных параметров.
Проблема заключается в следующем – большую модульную систему могут разрабатывать не то, что разные отделы внутри одной компании, а и вообще разные компании. При этом, каждый модуль будет замечательно работать, но все эти модули будут работать с данными в разных форматах. Я сейчас объясню, что я имею ввиду. Считается, что системе достаточно быть хорошо задокументированной, чтобы избежать этих проблем. Фактически, происходит следующее.
Допустим, есть набор некоторых данных и несколько хорошо задокументированных классов.
Ну как, осознали? А теперь представим, что у нас есть таких классов не три, а триста. Все эти классы работают абсолютно нормально. Они все получают некоторый набор данных, обрабатывают его и возвращают результаты. Результаты могут содержать уже изменённые данные, могут содержать первоначальные данные, а могут вообще не содержать никаких данных. Точно та же картина и при инициализации этих классов – данные всё те же, а форматы инициализации объектов разные.
В реальной программе такое может произойти, например, с личными данными пользователя. Может существовать много классов, которым нужно использовать данные пользователя. Какой-то класс запросит все данные. Какому-то будет достаточно только электронного адреса и он запросит в конструкторе инициализацию объекта строковой переменной. Одно дело, если вы в существующей системе создаёте новый класс, берёте данные из базы и как-то их обрабатываете. Совсем другое, когда вы вынуждены пользоваться уже обработанными данными и возникает ситуация, когда из нескольких объектов нужно получить одни и те же данные, и у этих данных разный формат. Конечно же вы получите, обработаете и вернёте данные. Снова в новом формате. И так до бесконечности. Рано или поздно, поддерживать систему станет практически невозможно. Даже если всё отлично задокументировано.
Пул данных как раз и решает эту проблему. Итак, пул данных – одно унифицированное хранилище данных, доступное из любой точки программы.
Пул данных обычно является ключевым элементом архитектуры, так что имеет смысл разрабатывать его в начале проекта, а не в конце. Прежде чем разработать пул данных, нужно ввести ряд договорённостей, которым будут следовать все остальные объекты.
Во-первых, нужно всё таки убедиться, что архитектура построена так, что пул данных действительно доступен для любого объекта. Просто чтобы данные в пуле и данные в произвольном порядке не жили рука об руку в одной и той же программе.
Во-вторых, обычно подразумевается, что если данные попали в пул, то их больше можно не проверять. Действительно, пул данных – это не мусорка. Данные должны быть проверены, провалидированы и верифицированы перед записью в пул. Тогда, в любой точке программы, можно получить точные данные, не заботясь о том, кто их туда положил.
В-третьих, нужно разработать один формат для всех данных. Так, чтобы любая подпрограмма могла быть уверенной – она может рассчитывать на конкретный формат данных и этот формат данных не изменится. В противном случае, пул просто не будет иметь смысла.
В-четвёртых, нужно чётко понимать, что пул данных – это не мусорка, а поэтому не стоит хранить в нём временные переменные. Например, такое использование пула данных является недопустимым –
И в-пятых, сам пул данных не имеет права данные изменять. Что положили, то и забрали. Хотя, если некоторый класс считает, что данные в пуле устарели и решает их перезаписать, пул должен с этим согласиться.
Кроме этого, пул данных может содержать массу других особенностей, зависящих от конкретного проекта, а именно – мы можем ввести систему приоритетов и запретить чтение и/или запись данных объектам, которые не могут иметь доступа к этим данным; мы можем хранить данные в базе, в файле или в массиве; мы можем сделать пул объектом, а можем предоставить несколько глобальных функций. В общем, архитектура пула зависит от вашей задачи.
Но хватит слов и перейдём к делу. Давайте разработаем простенький пул данных, который будет иметь уровни доступа и предоставлять пользователю операции записи и чтения.
Вот такой вот пул данных. На самом деле, в реальной задаче можно разработать ещё и проверку типа сохраняемой переменной. А так же, определённый формат для каждого алиаса, т.е. чтобы любой набор переменных под алиасом был всегда одного и того же вида. В общем, полёт фантазии программиста ограничивается только бюджетом его заказчика 🙂
Резюмируя, нужно сказать, что пул данных является стандартом де-факто для сложных веб-систем, которые пишутся более чем одним программистом.
Надеюсь, вы сегодня узнали что-то новое и интересное.
Пул данных
Всем привет. Сегодня мы поговорим о пуле данных. Под словосочетанием «пул данных» частенько понимаются принципиально разные вещи. Например, система, которая имитирует пользовательский ввод данных и используется для автоматического тестирования какой-либо другой системы. Я же буду подразумевать под пулом данных некоторую программно-алгоритмическую структуру, предназначенную для хранения данных и работы с ними.
Допустим, есть набор некоторых данных и несколько хорошо задокументированных классов.
Во-первых, нужно всё таки убедиться, что архитектура построена так, что пул данных действительно доступен для любого объекта. Просто чтобы данные в пуле и данные в произвольном порядке не жили рука об руку в одной и той же программе.
И в-пятых, сам пул данных не имеет права данные изменять. Что положили, то и забрали. Хотя, если некоторый класс считает, что данные в пуле устарели и решает их перезаписать, пул должен с этим согласиться.
Вот такой вот пул данных. На самом деле, в реальной задаче можно разработать ещё и проверку типа сохраняемой переменной. А так же, определённый формат для каждого алиаса, т.е. чтобы любой набор переменных под алиасом был всегда одного и того же вида. В общем, полёт фантазии программиста ограничивается только бюджетом его заказчика 🙂
Резюмируя, нужно сказать, что пул данных является стандартом де-факто для сложных веб-систем, которые пишутся более чем одним программистом. Надеюсь, вы сегодня узнали что-то новое и интересное. Всем удачи.
Другие интересные статьи, посвященные веб-разработке, расположены на сайте «Веб-разработка? Это просто!». Добро пожаловать.
Пулы соединений к БД — зачем и почему
Теория
Так же можно избежать повторного исполнения шагов два и три если мы будем использовать связанные переменные при написание запросов и кешировать результаты шага три, которые мы получаем от сервера.
В настоящее время большинство драйверов для работы с БД поддерживают работу с пулами соединений. Однако всегда есть соблазн написать свою реализацию, которая будет работать быстрее. Давайте проверим сколько мы выиграем используя пулы соединений и кеширование, как в коробочном решении так и в самописном.
Способ измерения
Для тестов используем свободно распространяемую СУБД PostgreSQL, а клиент напишем на JAVA. В БД создадим небольшую таблицу test.test_table (около 10 строк), состоящую из первичного ключа id и строкового значения value. Пусть у нас клиенты параллельно выполняют запросы к БД, для этого создадим потоки, которые будут делать простые запросы поиска по первичному ключу в этой таблице. При создании потоков мы будем указывать различную реализацию пулов соединений, что позволит нам сравнить производительность, т.к. поток будет считать суммарное время потраченное им на выполнение 100 запросов.
Теперь сделаем несколько пулов, и сравним производительность.
Первым будет классический, который на каждый запрос открывает соединение с сервером и после выполнения запроса закрывающий его.
Вторым будет, использующий специальный кеширующий источник данных класс из JDBC драйвера к PostgreSQL — PGPoolingDataSource. Который позволяет задать размер пула соединений, а так же начальное количество соединений. Кроме того в настройках у PreparedStatement есть настройка setPrepareThreshold — отвечающая за количество выполнений запроса, после которого запрос кешируется и не требует парсинга и построения плана выполнения.
Ну и в конце нашу реализацию пулов, когда мы сами кешируем соединения к БД а также результаты разбора SQL запроса (PreparedStatement).
Так же придётся реализовать свой класс соединения с БД, который будет осуществлять кеширование PreparedStatement.
Плюс свой класс реализующей интерфейс PreparedStatement, и не реагирующий на закрытие
Заключение
Ну и наконец сравним производительность трех различных пулов соединений, запустим тесты с количеством параллельных потоков от 1 до 10, для различных реализаций. В результате получился следующая зависимость общего времени выполнения задачи от количества потоков.
Из графика видно, что кешировать соединения с БД явно нужно, это даёт значительный прирост производительности системы. А вот писать самописную реализацию кеширования соединений и PreparedStatement не даёт ощутимой выгоды.
Что такое пул баз данных?
Я просто хотел узнать концепцию пула соединений с базой данных и как это достигается.
5 ответов
база данных подключение объединение-это метод, используемый для открытия соединений с базой данных, чтобы их могли повторно использовать другие.
как правило, открытие соединения с базой данных является дорогостоящей операцией, особенно если база данных удалена. Вы должны открыть сетевые сеансы, аутентифицировать, проверить авторизацию и так далее. Объединение в пул сохраняет соединения активными, так что при последующем запросе соединения один из активных используется вместо необходимости создайте еще один.
обратитесь к следующей диаграмме для следующих нескольких абзацев:
в простейшей форме это просто аналогичный вызов API (1) для вызова API с открытым соединением, который похож на «реальный». Это сначала проверяет пул на наличие подходящего соединения (2) и, если оно доступно, оно предоставляется клиенту. В противном случае создается новый (3).
аналогично, есть вызов close API (4), который фактически не вызывает реальные close-connection, скорее он помещает соединение в пул (5) для последующего использования. В какой-то момент соединения в пуле могут быть на самом деле закрытые (6).
Это довольно упрощенное объяснение. Реальные реализации могут обрабатывать соединения с несколькими серверами и несколькими учетными записями пользователей, они могут предварительно выделять некоторые базовые соединения, поэтому некоторые из них готовы немедленно, и они могут фактически закрывать старые соединения, когда шаблон использования затихает.
Общие сведения о пуле данных в Кластеры больших данных SQL Server
В этой статье описывается назначение пулов данных SQL Server в кластере больших данных SQL Server. В следующих разделах содержатся сведения об архитектуре, функциональных возможностях и сценариях использования пула данных.
В этом пятиминутном видео содержатся общие сведения о пулах данных, а также показано, как запрашивать данные из пулов данных.
Архитектура пула данных
Пул данных состоит из одного или нескольких экземпляров пула данных SQL Server, которые предоставляют постоянное хранилище SQL Server для кластера. Это позволяет обрабатывать запросы производительности кэшированных данных к внешним источникам данных и разгружать работу. Данные принимаются в пул данных посредством запросов T-SQL или из заданий Spark. Для повышения производительности в больших наборах данных принимаемые данные распределяются по сегментам базы данных и хранятся во всех экземплярах SQL Server в пуле. Поддерживаются следующие методы распределения: циклический перебор и репликация. Чтобы оптимизировать доступ для чтения, для каждой таблицы в каждом экземпляре пула данных создается кластеризованный индекс columnstore. Пул данных выступает в качестве киоска данных горизонтального масштабирования для кластеров больших данных Кластеры больших данных SQL Server.
Доступом к экземплярам SQL Server в пуле данных управляет главный экземпляр SQL Server. Наряду с внешними таблицами PolyBase для хранения кэша данных создается также внешний источник данных для пула данных. Контроллер в фоновом режиме создает базу данных в пуле данных с таблицами, которые соответствуют внешним таблицам. В главном экземпляре SQL Server реализован прозрачный рабочий процесс: контроллер перенаправляет определенные запросы внешней таблицы к экземпляру SQL Server в пуле данных (для этого может использоваться вычислительный пул), выполняет запросы и возвращает результирующий набор. Данные в пуле данных можно только получать или запрашивать, но их изменение не поддерживается. Таким образом, для любого обновления данных необходимо удалить таблицу, а затем воссоздать ее и повторно внести в нее данные.
Сценарии пула данных
Обычно пулы данных используются для создания отчетов. Например, сложный запрос, в котором объединено несколько источников данных PolyBase, используемый для создания еженедельного отчета, можно разгрузить в пул данных. Кэшированные данные обеспечивают быстрое локальное вычисление и позволяют не возвращаться к исходным наборам данных. Аналогичным образом данные панели мониторинга, требующие периодического обновления, можно кэшировать в пуле данных для оптимизированного создания отчетов. Кэширование наборов данных в пуле данных также полезно для повторного изучения Машинного обучения Azure.
Дальнейшие действия
Дополнительные сведения о Кластеры больших данных SQL Server см. в следующих ресурсах.