PG Day’17 продолжает радовать вас авторскими статьями. Сегодня, наш старый друг и бессменный автор провокационных статей о Web-разработке varanio расскажет о логической репликации.
Сначала я хотел назвать статью "Гарри Поттер и философский камень", потому что много лет при сравнении PostgreSQL с MySQL кто-нибудь всегда появлялся и замечал, что в Посгресе нет логической репликации (можно реплицировать только всю базу целиком, причем реплика read only), а в MySQL их целых два вида: statement based и row based.
И если statement based — это бомба замедленного действия с лазерным прицелом в ногу, то row based действительно очень не хватало в PG. Т.е. вопрос репликации — как философский камень у любителей баз.
Точнее, в посгресе всегда можно было использовать slony для того, чтобы, например, реплицировать только одну-две нужных таблицы. Но slony — это хитрое поделие на триггерах, которое работает по принципу: работает — не трогай. Т.е. например, нельзя просто взять и сделать ALTER TABLE ADD COLUMN, это надо делать через специальные механизмы. Если же всё-таки кто-то случайно это сделал, а потом, что еще хуже, через какое-то время в панике вернул как было, то быстро разрулить эту ситуацию может только чёрный маг 80lvl. Помимо slony, начиная с 9.4 стало возможно писать свои расширения для логической репликации через wal, вроде бы, пример такого расширения — pglogical.
Но это всё не то!
Когда я узнал, что в dev-ветку PostgreSQL 10 упал коммит, который позволяет из коробки, без экстеншенов и плагинов, логически реплицировать отдельные таблицы, я решил посмотреть, а как оно там работает.
Продолжаем публикацию наших образовательных материалов. Этот курс посвящен изучению основ языка SQL с учетом особенностей объектно-реляционной базы данных PostgreSQL. Программа предусматривает комплексный подход к изучению стандартизованного языка SQL на платформе PostgreSQL, включая некоторые минимальные возможности администрирования пользователей, ролей, схем, базовых таблиц и других объектов базы данных. Мы рассмотрим основы работы с базой данных PostgreSQL и некоторые особенности SQL применительно к ней. Более подробно — под катом.
Всем привет. Это моя первая статья на Хабре, буду рад критике и комментариям.
Статья посвящена простому, но удобному способу построения предикторов особого вида в SQL-подобных языках. Эти предикторы описывают линейный тренд в данных, который можно использовать для решения задач машинного обучения. Идея заключается в том, чтобы по транзакционным данным быстро и эффективно рассчитывать линейные тренды.
Конференция PG Day Russia растет и масштабируется: этим летом мы готовим для вас доклады и тренинги по всем наиболее популярным базам данных, а также по администрированию и хранению данных. в рамках подготовки мы запустили корпоративный блог, где планируем делиться ценной информацией о происходящем в мире баз данных. Первый пост посвящен инструментам разработки для PostgreSQL, его автор varanio будет рад ответить на ваши вопросы и комментарии!
Я поспрашивал различных людей, имеющих отношение к PostgreSQL, что они используют в реальной жизни для разработки приложений, использующих PG.
Это, конечно, не строго математическая выборка, но тем не менее получился некоторый список инструментов на слуху, которые достойны того, чтобы их "пощупать", что я и собираюсь сделать в этой статье.
Если вашего инструмента нет в списке, или у вас просто есть что сказать, добро пожаловать в комментарии.
Итак, вот неформальный топ и субъективное описание.
Продолжаем описание свойств операции релевантная выборка. В первой части рассматривалась фильтрация кортежей регистра правил по значениям входного вектора с последующей сортировкой отобранных кортежей по их релевантности. Упор был сделан на то, как правильно считать (оценивать) релевантность кортежей.
Здесь же более подробно остановимся на самой операции выборки (не будет ни одной формулы!). В общем случае в данной операции могут участвовать (соединяться) не только вектор с таблицей, но и две таблицы. Операцию над таблицами, в которой используется проверка на принадлежность элемента множеству, назовем релевантным соединением. Далее рассмотрим, в чем его особенности.
"Дуэли запрещены в субботу, воскресенье и остальные дни недели."
Речь в статье пойдет о некоторых нюансах операции выборки данных. Эта довольно востребованная в информационных системах операция сводится фактически к определению принадлежности значений (элементов) множествам. Табличная функция, содержащая значения-множества, называется регистром правил. При наличии нескольких множеств, которым принадлежит элемент, возникает вопрос определения наиболее релевантного из них. Вопросам оценки релевантности выборки данных посвящена первая часть работы.
Забегая вперед, укажем, что основным результатом (многолетних наблюдений) является то, что в реляционных отношениях следует учитывать род атрибутов — являются ли значения атрибута отношения конкретными (элементами) или абстрактными (множествами). При этом в операции выборки данных атрибуты входной таблицы и таблицы, к которой обращаются, должны быть разных родов. Более подробно об этом — во 2-й части.
И еще одна оговорка. Там, где приходилось выбирать между простотой (понятностью) описания и его строгостью, автор старался выбирать простоту (хотя слов, в том числе не всегда понятных, все равно набралось много).
Каждая таблица в SQLite по умолчанию содержит приватный ключ на основе автоматически генерируемого 64-битного целого. Это эффективно и удобно в большинстве ситуаций. Неудобства начинаются, пожалуй, только в двух случаях:
Может показаться, что и второй задачи в комбинации с SQLite не должно возникать, но распределенность не всегда означает что-нибудь вроде BigData. Типичный пример (из-за чего лично мне и понадобилось исследование на эту тему) это приложение с возможностью синхронизации данных между устройствами. Это может быть как что-то небольшое, как записная книжка, так и более нагруженное, как история браузера. Проблемой тут становится не столько объем данных, сколько слияние нескольких баз. Очевидно, что целочисленные счетчики записей, начинающие отсчет с 1, неизбежно будут выдавать конфликтующие последовательности, а значит использовать их в качестве уникального идентификатора записи на нескольких устройствах уже нельзя. Можно заморочиться с разделением на поддиапазоны или "сдвиганием" айдишников записей перед их передачей, но это все кривые и хрупкие костыли. Никто так не делает, конечно же. Вместо этого каждое устройство присваивает своим записям что-нибудь вроде GUID-а – просто и надежно.
Здравствуйте, меня зовут Дмитрий Карловский и я… давно не занимался бэкендом, но на днях вдруг наткнулся на мучения SbWereWolf по натягиванию ужа на ежа и не смог удержаться от соблазна сдуть пыль со своего мульти-инструмента OrientDB да оттяпать им чего-нибудь этакого.
Итак, мастерить мы сегодня будем базу данных для интернет-магазина с поиском товаров по параметрам, полнотекстовым поиском, локализацией, автоматическим формированием рубрикатора и мастера добавления товара.
Разбирать мы будем вот этот вот реляционный звездолёт:
А собирать вот такой вот графовый скворечник:
В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.
Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.
