Формальный непроцедурный язык программирования
Один инстанс PostgreSQL в продакшене — это риск для отказоустойчивости и производительности. В статье разберём, зачем нужны реплики, чем физическая репликация отличается от логической и как настроить базовые сценарии на практике.
Сегодняшняя задача вполне традиционна для любых учетных систем - поиск записей, содержащих максимальное значение по каждому из ключей. Что-то вроде "покажи мне последний заказ по каждому из клиентов", если переводить в прикладную область.
Кажется, что тут и споткнуться-то негде в реализации - но все оказывается совсем не тривиально.
Даже самый простой SQL запрос можно выполнить по-разному. Но из всех вариантов СУБД нужно выбрать оптимальный, как же это сделать? Неужели придётся перебрать все возможные варианты? Давайте разбираться.
Выковыривание информации из html — это скучно. Очень. Между тем, эта потребность выстреливает редко, но метко (© Суворов). Из-за этого есть спрос на готовые и короткие инструкции о том, как это сделать, чтобы не тратить время на изучение. Перед вами как раз такая.
Чтобы добавить хоть какой-то интерес скучнейшему занятию мы для примера будем парсить пользователей Хабра. А чтобы не мелочиться — ещё и реанимируем для этого экспериментальную библиотеку 11-летней давности.
Есть такой проект — htmlSQL. Старая библиотека времён Очаковских и покоренья Крыма (© Грибоедов). Она позволяет делать выборку из HTML в стиле SQL-запросов как на КДПВ, чем она мне когда-то и полюбилась.
Наступил Апокалипсис.
Нет, не стоит бежать запасаться банками с консервами и крышками отечественной бай-колы! Апокалипсис произошёл только в нашей фантазии и с определённой целью — чтобы проверить, а может ли человек, обладающий только книгами по теме и стандартной библиотекой языка, воссоздать инструмент, который будет служить ему верой и правдой?
Так родился учебный проект SicQL, реляционная СУБД, чей символ — сова — это олицетворение силы знаний и мудрости. Олицетворение тех знаний и той мудрости, которые мы получим, создав с нуля то, чем мы пользуемся каждый день, может, не осознавая всей сложности таких инструментов.
Приглашаю присоединиться к увлекательному путешествию!
Мотивированный ИТ-шник, он же реципиент почки, хочет что-то поменять в стране в плане трансплантации органов (лист ожидания).
Суть вопроса: какая информационная система (ИС) в РФ подбирает и распределяет донорские органы? В идеале, покажите код (возьмите на работу на 0.01 ставки, вдруг я на что-то сгожусь, как мотивированный разработчик или тестировщик в прошлом).
То, что данные называют нефтью 21 века известно уже давно: на них учатся нейросети, их мгновенная обработка и передача сильно упростили нашу жизнь, и одной из самых распространенных структур хранения данных является реляционная.
Основным инструментом для взаимодействия с реляционными БД является структурированный язык запросов или же SQL.
Вкратце, на мой взгляд, необходимо знать следующие разделы:
Привет! Меня зовут Пётр, я менеджер по отказоустойчивости в QIWI. В этом посте мы поговорим про выбор новых классов продуктов. Как-то раз мы с одним разработчиком из другой компании стали обсуждать, почему бы не выбрать для работы какую-то распределенную СУБД, поддерживающую SQL? Из этой дискуссии родился мой доклад для нашей QIWI Server Party. Представляю вам его текстовую версию.
Если вы не разобрались в тонкостях работы базы данных, то использование новых средств языка T-SQL может привести к неожиданным результатам в плане производительности.
Вам, наверное, знаком подход радикальной простоты, который заключается в том, чтобы иметь как можно меньше систем и наименьшее количество строк кода и конфигурации. Это снижает затраты на техническое обслуживание и делает изменения дешёвыми и лёгкими. Но радикальная простота не означает использование ассемблерного кода или C.
При написании серверного кода для чтения из базы данных разработчики обычно используют прямой SQL либо ORM. ORM экономит время на написании SQL-кода, но снижает производительность и увеличивает потребность в большем количестве классов. Прямой SQL быстрее и содержит меньше типовых строк кода, но его сложнее...
История создания регулярных выражений берет свое начало с 1942 года. В то время Уолтер Питтс — американский логик, работавший, в основном, в области когнитивной психологии, работал с известным физиологом Уорреном МакКаллоком. Основой их работы были труды связанные с теоретическим построением нейронных сетей. Немного позже, американский математик Стивен Клини изучал события в сетях МакКаллока-Питтса и предложил способ описания таких событий при помощи языка регулярных выражений.
Работа Клини вышла в середине 50-х годов двадцатого века. Научные труды были бы забыты, но американский программист Кен Томпсон в конце 60-х годов обнаружил, что регулярные выражения можно использовать для задания шаблонов поиска строк в длинных текстах. Смысл поиска заключается в том, что регулярное выражения преобразуется в конечный автомат, который производит поиск строк, которые должны соответствовать определенным шаблонам. Для построения конечного автомата Томпсон придумал специальный алгоритм, который сейчас носит название «построение Томпсона». Таким образом Кен Томпсон смог принести в мир стандарт для задания поисковых шаблонов.
Сами по себе, регулярные выражения есть ни что иное, как текстовый шаблон, который соответствует какому-то тексту. В трудах Джеффри Фридла пишется, что: «Регулярные выражения— это мощнейший инструмент, хорошо известный программистам. Однако он может быть полезен не только программистам, но и всем людям, работающим с кодом или простым текстом». При использовании регулярных выражений человеку придется работать с литералами и метасимволами. Это два существенно различающихся по своей сущности понятия. Литералы – это обычные символы, т.е. при записи в строках регулярного выражения они интерпретируются так, как они записаны. Примером литералов в регулярных выражениях может быть любая буквенная последовательность. В свою очередь, метасимволы интерпретируются при поиске особым образом. Примером может служить символ «*», который задает последовательность любого количества литералов.
Под занавес уходящего года предлагаю традиционно вспомнить, про какие интересные возможности и особенности работы с PostgreSQL мы рассказали в нашем блоге.
Если не видели дайджест за прошлый год — время наверстать упущенное!
Они носят множество имен: Data Analyst, Data Scientist, Business Analyst и т. д., но всех их объединяет одна основная черта — эти люди занимаются анализом данных. Итак, начнем с главного. Сколько получают аналитики?
Участвую в стартапе, в котором разрабатывается СУБД нового типа (работает поверх некоторых kv-движков, кардинально расширяя их возможности, про это немного можно прочитать здесь). Для того, чтобы сравнить то, что понемногу получается, с тем, что имеется в индустрии, пришлось на глубоком уровне проработать первоисточники по темам Isolation и Consistency (уточню, что имеется ввиду не та Consistency, что в ACID). Обнаружил интересные нюансы, которые и излагаю в этой статье.
Тезисно:
Ну, и ещё кое-что по мелочи. В конце рассмотрим вот такой венец творения человеческого разума:
Пока PostgreSQL работает штатно, его архитектура легко кажется теорией. Но при зависших транзакциях, проблемах с производительностью или настройке кластера быстро выясняется, что без понимания внутренних процессов администрирование превращается в перебор параметров.
В статье разберём устройство PostgreSQL, отличия основных редакций и базовый сценарий установки на Ubuntu.
Загрузить миллион записей в питон за секунду?
Нет. Получилось еще быстрее!
У меня есть небольшое хобби - я экспериментирую с машинным обучением применительно к торговле на бирже, в частности, с криптовалютами. После различных наколенных экспериментов я захотел создать удобный инструмент - базу торговых котировок. В процессе работы необходима быстрая загрузка достаточно большого количества данных. Это необходимо для расчетов, генерации данных для обучения, бэк-тестинга и других задач. Количество записей, которые нужно загрузить в питон довольно велико - речь может идти о миллионах и более записей.
Расскажу о такой важной особенности работы СУБД TERADATA, как сбор и использование статистик при выполнении запросов и как их наличие или отсутствие может повлиять на скорость выполнения таких запросов. Попытаюсь объяснить, что представляют собой статистики и для чего они нужны TERADATA.
Достаточно часто при проектировании схемы БД возникает задача сохранить по основной сущности некоторый набор простых второстепенных данных.
Например, это могут быть ФИО сотрудников, принимающих участие во встрече, список приложенных к сообщению файлов или перечень отгружаемых по документу позиций.
Во всех этих случаях мы заранее понимаем, что список этот меняется редко и ни индексировать эти данные, ни искать по ним, ни извлекать отдельно от основной сущности (встречи, сообщения или документа), мы не захотим.
Давайте посмотрим, какие варианты хранения таких данных мы можем использовать в PostgreSQL, и какой из них окажется в разы более эффективным.
