Описание баз данных и особенности работы с ними

Что такое Postgres Pro Standard?

 

Postgres Pro Standard — это объектно-реляционная система управления базами данных (ОРСУБД, ORDBMS), разработанная Postgres Professional в рамках проекта Postgres Pro на основе PostgreSQL, в свою очередь, основанном на POSTGRES, Version 4.2 — программе, разработанной на факультете компьютерных наук Калифорнийского университета в Беркли. В POSTGRES появилось множество новшеств, которые были реализованы в некоторых коммерческих СУБД гораздо позднее.

Postgres Pro Standard, как и PostgreSQL, поддерживает большую часть стандарта SQL и предлагает множество современных возможностей:

• триггеры
• сложные запросы
• внешние ключи
• многоверсионность
• транзакционная целостность
• изменяемые представления

Также вы можете расширять Postgres Pro, так же как и PostgreSQL, например, создавая свои:

• операторы
• процедурные языки
• типы данных
• функции
• агрегатные функции
• методы индексирования

Различия между Postgres Pro Standard и PostgreSQL

Postgres Pro предоставляет наиболее актуальную версию PostgreSQL c дополнительными изменениями и расширениями. Этот продукт включает все новые возможности, реализованные компанией Postgres Professional, а также сторонние доработки, которые уже приняты сообществом PostgreSQL и попадут в новые версии PostgreSQL. Таким образом, пользователи Postgres Pro Standard получают ранний доступ к важным нововведениям и исправлениям.

Postgres Pro Standard предоставляется по следующей лицензии: https://postgrespro.ru/products/postgrespro/eula. Обязательно ознакомьтесь с условиями лицензии, прежде чем загружать и использовать Postgres Pro Standard.

Postgres Pro Standard отличают от PostgreSQL следующие усовершенствования:

• Улучшенный механизм проверки блокировок, не оказывающий отрицательного влияния на производительность.
• Уменьшение объёма записей в WAL, генерируемых при операциях CREATE INDEX с индексами GiST, GIN и SP-GiST.
• Улучшенная производительность при использовании множества временных таблиц в отдельных обслуживающих процессах и при большом количестве одновременных подключений.
• Увеличенная скорость и эффективность планирования для различных типов запросов.
• Уменьшенное потребление памяти при обработке сложных запросов со множеством таблиц.
• Добавление времени планирования в информацию, выводимую модулем auto_explain.
• Возможность замены нулевого байта заданным ASCII-символом при загрузке данных с помощью команды COPY FROM. (См. описание параметра nul_byte_replacement_on_import.)
• Использование ICU на всех платформах с целью обеспечить платформонезависимую сортировку для различных локалей. По умолчанию провайдер правил сортировки icu задействуется для всех локалей, за исключением C и POSIX. (См. Подраздел 22.2.2.)
• Реализация механизма PTRACK, позволяющего программе pg_probackup отслеживать изменения страниц при создании инкрементальных резервных копий.
• Согласованное чтение на ведомых серверах. (См. WAITLSN.)
• Представление pg_recovery_settings, отображающее текущие параметры восстановления из файла recovery.conf.
• Изменение параметров в recovery.conf без перезапуска сервера.
• Повышенная отказоустойчивость в системах Windows.
• Расширенная поддержка редактирования вводимых команд в psql для Windows, реализованная с использованием WinEditLine.
• Унифицированная структура пакетов двоичных файлов для всех дистрибутивов Linux, упрощающая миграцию между ними и позволяющая устанавливать несколько различных продуктов на базе PostgreSQL совместно без каких-либо конфликтов. (См. Главу 16.)

Postgres Pro Standard так же включает следующие дополнительные модули:

• Модуль dump_stat, позволяющий сохранять статистику данных при резервном копировании и восстановлении.
• Модуль fasttrun, который предоставляет транзакционно-небезопасную функцию для усечения временных таблиц, что предотвращает разрастание каталога pg_class.
• Модуль fulleq, предоставляющий дополнительный оператор равенства для совместимости с Microsoft SQL Server.
• Модуль hunspell-dict, предоставляющий словари для ряда языков.
• Модуль jsquery реализует специальный язык запросов для эффективного, с использованием индексов, поиска в структурированных данных JSONB
• Служба мониторинга mamonsu, исполненная в виде агента Zabbix.
• Модуль mchar, предоставляющий дополнительный тип данных для совместимости с Microsoft SQL Server.
• Модуль online_analyze, привносящий набор функций, которые немедленно обновляют статистику в целевых таблицах после операций INSERT, UPDATE, DELETE или SELECT INTO в них.
• Пул соединений pgbouncer.
• Модуль pg_pathman предоставляет оптимизированный механизм секционирования, а также функции для создания и управления секциями.
• pg_probackup — менеджер резервного копирования и восстановления.
• Модуль pg_query_state, дающий возможность узнавать текущее состояние выполнения запросов в обслуживающем процессе.
• Утилита pg_repack для реорганизации таблиц.
• Модуль pg_tsparser — альтернативный анализатор текстового поиска.
• Модуль pg_variables, предоставляющий функции для работы с переменными различных типов.
• Модуль plantuner, добавляющий поддержку указаний для планировщика, подключающих или отключающих определённые индексы при выполнении запроса.
• Модуль shared_ispell, позволяющий разместить словари в общей памяти.
• Модуль sr_plan, позволяющий сохранять и восстанавливать планы запросов.

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

Подробнее вы можете прочесть в официальной документации.

PostgreSQL — это объектно-реляционная система управления базами данных (ОРСУБД, ORDBMS), основанная на POSTGRES, Version 4.2 — программе, разработанной на факультете компьютерных наук Калифорнийского университета в Беркли. В POSTGRES появилось множество новшеств, которые были реализованы в некоторых коммерческих СУБД гораздо позднее.

PostgreSQL — СУБД с открытым исходным кодом, основой которого был код, написанный в Беркли. Она поддерживает большую часть стандарта SQL и предлагает множество современных функций:

• сложные запросы
• внешние ключи
• триггеры
• изменяемые представления
• транзакционная целостность
• многоверсионность

Кроме того, пользователи могут всячески расширять возможности PostgreSQL, например создавая свои

• типы данных
• функции
• операторы
• агрегатные функции
• методы индексирования
• процедурные языки

Подробнее вы можете прочесть в официальной документации.

Главные обновления в 12 версии:

• Более производительное индексирование.
• Включение JIT-компилятора по умолчанию для большей скорости выполнения выражений при обработке запросов.
• Поддержка автоматического inline-развёртывания Common Table Expressions (пока только нерекурсивных) для большей производительности запросов.
• Поддержка хранимых generated columns, содержимое которых вычисляется по содержимому других столбцов.
• Оптимизация секционирования запросов для таблиц с большим числом секций.
• Более защищённая аутентификация: при аутентификации через GSSAPI канал шифруется и на серверной, и на клиентской стороне.

Подробнее о новом в 12 версии читайте на официальном ресурсе.

Главные обновления в версии 8.0:

• Улучшения словаря данных — теперь MySQL Server включает транзакционный словарь данных, который хранит информацию об объектах базы данных. Подробней об изменениях в словаре данных читайте здесь.
• Улучшения JSON функционала — в 8 версии было много изменений, связанных с JSON в MySQL. Например, добавлен оператор ->>, который является эквивалентом вызова JSON_UNQUOTE() на результате JSON_EXTRACT(). Функции аггрегирования JSON_ARRAYAGG() и JSON_OBJECTAGG(), добавлена возможность частичного обновления JSON колонки и использования диапазонов в XPath выражениях, функция JSON_MERGE() и много другое.
• Оптимизатор — добавлены невидимые и нисходящие индексы. Невидимые не используются оптимизатором, но позволяют протестировать изменение производительности от удаления индекса. И теперь при определении индекса ключ DESC больше не игнорируется, вместо этого индексы будут храниться в обратном порядке.
• Кодировка по умолчанию — в версии 8 стандартной кодировкой будет utf8mb4.
• Роли — появилась возможность создавать роли и закреплять за ними нужные привилегии. Например:

CREATE ROLE 'developer_role';
GRANT SELECT ON database.* TO 'developer_role';
GRANT 'developer_role' TO 'user'@'localhost';

Ознакомиться со всеми обновлениями можно на официальном сайте.

MySQL — свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Разработчики создают функциональность по заказу лицензионных пользователей. Именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

Входит в состав серверов WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP, VertrigoServ. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

Подробнее вы можете прочесть в официальной документации.

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

ClickHouse использует собственный диалект SQL близкий к стандартному, но содержащий различные расширения: массивы и вложенные структуры данных, функции высшего порядка, вероятностные структуры, функции для работы с URI, возможность для работы с внешними key-value хранилищами («словарями»), специализированные агрегатные функции, функциональности для семплирования, приблизительных вычислений, возможность создания хранимых представлений с агрегацией, наполнения таблицы из потока сообщений Apache Kafka и т.д.

Однако при этом имеются и ограничения — отсутствие транзакций, отсутствие точечных UPDATE/DELETE (пакетный UPDATE/DELETE был введен в июне 2018 года), ограниченная поддержка синтаксиса JOIN, строгие типы с необходимостью явного приведения, для некоторых операций промежуточные данные должны помещаться в оперативную память, отсутствие оконных функций, отсутствие полноценного оптимизатора запросов, точечного чтения, присутствие ограничений в реализации некоторых функций, связанных со спецификой использования ClickHouse в Яндексе, и т. д.

Система оптимизирована для хранения данных на жестких дисках (используются преимущества линейного чтения, сжатия данных). Для обеспечения отказоустойчивости и масштабируемости ClickHouse может быть развернут на кластере (для координации процесса репликации используется Apache ZooKeeper). Для работы с базой данных существует консольный клиент, веб-клиент, HTTP интерфейс, ODBC и JDBC-драйверы, а также готовые библиотеки для интеграции со многими популярными языками программирования и библиотеками.

Во многих тестах ClickHouse показывает очень высокую производительность, выигрывая по этому показателю у таких конкурентов как Greenplum, Vertica, Amazon Redshift, Druid, InfiniDB/MariaDB ColumnStore, Apache Spark, Presto, Elasticsearch.

Подробнее вы можете читайте в официальной документации.

Redis (Remote Dictionary Server) – это быстрое хранилище данных типа «ключ‑значение» в памяти с открытым исходным кодом для использования в качестве базы данных, кэша, брокера сообщений или очереди. Redis обеспечивает время отклика на уровне долей миллисекунды и позволяет приложениям, работающим в режиме реального времени, выполнять миллионы запросов в секунду.

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

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

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

Redis уже оснащен встроенными структурами данных и предоставляет множество возможностей их комбинирования и взаимодействия с данными клиента. Разработчикам под Redis доступны более ста клиентов с открытым исходным кодом. Поддерживаемые языки программирования включают Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, R, Go и многие другие.

MongoDB — документоориентированная система управления базами данных с открытым исходным кодом, не требующая описания схемы таблиц. Классифицирована как NoSQL, использует JSON-подобные документы и схему базы данных. Написана на языке C++. Используется в веб-разработке, в частности, в рамках JavaScript-ориентированного стека MEAN.

Система поддерживает ad-hoc-запросы: они могут возвращать конкретные поля документов и пользовательские JavaScript-функции. Поддерживается поиск по регулярным выражениям. Также можно настроить запрос на возвращение случайного набора результатов.

Имеется поддержка индексов.

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

Система масштабируется горизонтально, используя технику сегментирования (англ. sharding) объектов баз данных — распределение их частей по различным узлам кластера. Администратор выбирает ключ сегментирования, который определяет, по какому критерию данные будут разнесены по узлам (в зависимости от значений хэша ключа сегментирования). Благодаря тому, что каждый узел кластера может принимать запросы, обеспечивается балансировка нагрузки.

Система может быть использована в качестве файлового хранилища с балансировкой нагрузки и репликацией данных (функция Grid File System; поставляется вместе с драйверами MongoDB). Предоставляются программные средства для работы с файлами и их содержимым. GridFS используется в плагинах для Nginx и lighttpd. GridFS разделяет файл на части и хранит каждую часть как отдельный документ.

Может работать в соответствии с парадигмой MapReduce. Во фреймворке для агрегации есть аналог SQL-инструкции GROUP BY. Операторы агрегации могут быть связаны в конвейер подобно UNIX-конвейрам. Фреймворк так же имеет оператор $lookup для связки документов при выгрузке и статистические операции такие как среднеквадратическое отклонение.

Поддерживается JavaScript в запросах, функциях агрегации (например, в MapReduce).

MongoDB поддерживает коллекции с фиксированным размером. Такие коллекции сохраняют порядок вставки и по достижении заданного размера ведут себя как кольцевой буфер.

В июне 2018 года (в версии 4.0) добавлена поддержка транзакций, удовлетворяющих требованиям ACID.

Подробнее вы можете прочесть в официальной документации.

Master, slave — что это и для чего нужно?

Репликация — одна из техник масштабирования баз данных. Состоит эта техника в том, что данные с одного сервера базы данных постоянно копируются (реплицируются) на один или несколько других (называемые репликами). Для приложения появляется возможность использовать не один сервер для обработки всех запросов, а несколько. Таким образом появляется возможность распределить нагрузку с одного сервера на несколько.

Существует два основных подхода при работе с репликацией данных:

• Репликация Master-Slave;
• Репликация Master-Master.

Master-Slave репликация

В этом подходе выделяется один основной сервер базы данных, который называется Мастером. На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Слейв сервер постоянно копирует все изменения с Мастера. С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв за чтение.

Несколько Слейвов

Преимущество этого типа репликации в том, что Вы можете использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.

Задержка репликации

Асинхронность репликации означает, что данные на Слейве могут появится с небольшой задержкой. Поэтому, в последовательных операциях необходимо использовать чтение с Мастера, чтобы получить актуальные данные.

Выход из строя

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

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

Master-Master репликация

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

Выход из строя

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

Используйте Master-Master репликацию только в крайнем случае.

Важное

Репликация используется в большей мере для резервирования баз данных и в меньшей для масштабирования. Master-Slave репликация удобна для распределения запросов чтения по нескольким серверам. Подход ручной репликации позволит использовать преимущества репликации для технологий, которые ее не поддерживают. Зачастую репликация используется вместе с шардингом при решении вопросов масштабирования.

*Информация взята из этой статьи.

Синхронная репликация

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

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

Асинхронная репликация

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

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

К недостаткам этой схемы относится то, что данные могут оказаться несовместимыми (то есть несовместимыми с точки зрения пользователя). Иными словами, избыточность может проявляться на логическом уровне, а это, строго говоря, означает, что термин контролируемая избыточность в таком случае не применим.

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

В частности, конфликты могут возникать по поводу того, в каком порядке должны применяться обновления. Например, предположим, что в результате выполнения транзакции А происходит вставка строки в реплику X, после чего транзакция B удаляет эту строку, а также допустим, что Y — реплика X. Если обновления распространяются на Y, но вводятся в реплику Y в обратном порядке (например, из-за разных задержек при передаче), то транзакция B не находит в Y строку, подлежащую удалению, и не выполняет своё действие, после чего транзакция А вставляет эту строку. Суммарный эффект состоит в том, что реплика Y содержит указанную строку, а реплика X — нет.

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

Основное различие между репликацией и управлением копированием заключается в следующем:

Если используется репликация, то обновление одной реплики в конечном счёте распространяется на все остальные автоматически.

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

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

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