UUID (universally unique identifier) — это стандарт идентификации, используемый в создании программного обеспечения, стандартизированный Open Software Foundation (OSF) как часть DCE — среды распределённых вычислений (Distributed Computing Environment (англ.)). Основное назначение UUID — это позволить распределённым системам уникально идентифицировать информацию без центра координации. Таким образом, любой может создать UUID и использовать его для идентификации чего-либо с приемлемым уровнем уверенности, что данный идентификатор непреднамеренно никогда не будет использован для чего-то ещё. UUID представляет собой 16-байтный (128-битный) номер.
В PostgreSQL, по умолчанию, нет индекса для столбцов массива uuid (uuid[]).
Для примера, вот простая таблица с столбцом массива uuid:
CREATE TABLE someitems (
items uuid[]
);
Но когда мы пытаемся создать на нем индекс:
CREATE INDEX someitems_items_index ON someitems USING GIN (items);
Получаем следующую ошибку:
ERROR: data type uuid[] has no default operator class for access method "gin"
Поэтому мы должны создать тип индекса, который понимает, как сравнивать элементы массива uuid (uuid[]). Читати далі…
Обновился графический интерфейс для управления СУБД PostgreSQL – pgAdmin 4. Будем надеяться что новая версия не будет так сильно “сыпаться” 🙂 Пока ещё нет ни deb-пакета, ни ссылок на репозиторий, но попробовать уже хочется 🙂
Так что сегодня я расскажу как поставить pgAdmin4 в режиме клиента (pgAdmin4 Desktop)
Потоковая репликация (streaming replication) является передачей записей из WAL (Write-Ahead Log) от мастера к репликам. Писать при этом можно только в мастер, но читать можно как с мастера, так и с реплик. В итоге мы получаем не просто горизонтальное масштабирование, а ещё и отказоустойчивую архитектуру (failover).
Приступим к настройке реплики.
Сегодня я расскажу как довольно просто поднять и настроить свой собственный сервер карт (тайловый сервер) на основе Ubuntu Server 14.04 LTS и OpenStreetMap.
OpenStreetMap (дословно «открытая карта улиц»), сокращённо OSM — некоммерческий веб-картографический проект по созданию силами сообщества участников-пользователей Интернета подробной свободной и бесплатной географической карты мира.
Несмотря на то что PostgreSQL является довольно мощной базой данных, в ней отсутствует полноценная поддержка хранения таблиц в оперативной памяти.
Ниже я расскажу как заставить PostgreSQL хранить выбранные таблицы в оперативной памяти для быстрых операций с ними.
Всё будет происходить в Debian.
Создадим пустую папку для монтирования
mkdir /mnt/ramfs
И смонтируем в неё ramfs
mount -t ramfs none /mnt/ramfs
Создадим папку для PostgreSQL и назначим на неё права.
mkdir /mnt/ramfs/pgdata
chown postgres:postgres /mnt/ramfs/pgdata
chmod 600 /mnt/ramfs/pgdata
Далее зайдём под суперпользователем базы данных PostgreSQL – postgres
su postgres
psql
И создадим новый TABLESPACE, размещение которого мы укажим в папке с смонтированной ramfs
Выдадим права на работу с этом TABLESPACE нашему пользователю (например myuser)
postgres=# GRANT CREATE ON TABLESPACE ram TO myuser;
Теперь нам осталось только создать новую таблицу и указать при её создании TABLESPACE ram.
Например:
CREATE TABLE mytesttable (
begin_ip ip4 NOT NULL,
end_ip ip4 NOT NULL,
begin_num bigint NOT NULL,
end_num bigint NOT NULL,
country_code character(2) NOT NULL,
country_name character varying(255) NOT NULL,
ip_range ip4r
)
TABLESPACE ram;
Теперь PostgreSQL будет работать с этой таблицей как и с другими даже не подозревая что она “лежит” в ОЗУ.
Топ 10 самих популярных команд для управления сервером PostgreSQL для настоящих администраторов баз данных (DBA).
Большинство команд подходят как для консольной утилиты psql, так и для запуска через ваш клиент.
Сегодня я расскажу как можно работать с базой данных PostgreSQL с помощью nginx’a без application’a (например, PHP или любого другого). Т.е. эта технология абсолютно не зависит от языка, на котором сделан сайт/проект/система.
Мы будем использовать мощь PostgreSQL в хранимых процедурах (stored procedures/functions), а кэшировать с помощью быстрого Redis. Читати далі…
Предел возможностей БД часто упирается в дисковые операции. Поэтому стоит оптимизировать эти операции, меняя логику, архитектуру, масштабируя и пр.
Запрос выведет статистику по таблицам в обратном порядке по сумме операций записи, т.е. сверху будут таблицы с наиболее интенсивной записью.
SELECT
schemaname AS schema, -- схема
relname AS table, -- таблица
pg_size_pretty( pg_relation_size(relid) ) AS tsize, -- размер
n_tup_upd + n_tup_ins + n_tup_del AS write, -- операций записи (I/U/D)
seq_scan + idx_scan AS read, -- всего чтений
n_tup_ins AS ins, -- операции INSERT
n_tup_upd AS upd, -- операции UPDATE
n_tup_del AS del -- операции DELETE
FROM
pg_stat_user_tables
ORDER BY
( n_tup_upd + n_tup_ins + n_tup_del ) DESC