• DevConf: переход Uber с PostgreSQL на MySQL

      18 мая 2018 года в Digital October состоится DevConf 2018. И мы решили пересказать некоторые интересные доклады с прошлогодней конференции. Там был доклад с несколько холиварным заголовком: "О чём молчит политрук: к дискуссии о переходе Uber с PostgreSQL на MySQL". В нем разработчик MySQL Алексей Копытов рассмотрел различия InnoDb и PostgreSQL на самом низком уровне, включая организацию данных, памяти и репликаций. Предлагаем вашему вниманию краткий пересказ доклада.


      История вопроса


      Uber перешел с MySQL на Postgres в 2013 году и причины, которые они перечисляют, были во-первых: PostGIS — это геоинформационное расширение для PostgreSQL и хайп. То есть, у PostgreSQL есть некий ореол серьезный, солидная СУБД, совершенный, без недостатков. По крайней мере, если сравнивать с MySQL. Они мало что знали о PostgreSQL, но повелись на весь этот хайп и перешли, а через 3 года пришлось переезжать обратно. И основные причины, если просуммировать их доклад — это плохие эксплуатационные характеристики при эксплуатации в production.
      Читать дальше →
    • IT-инфраструктура штабов Навального и сбор подписей: управление проектом

        Cерия публикаций про сбор подписей

        1. Введение, сайт «Навальный 20!8», подготовка к сбору
        2. Железо и сети, видеонаблюдение
        3. Жнец-2018: система для сбора подписей
        4. Управление проектом

        Это заключительная глава материала про IT-инфраструктуру штабов Навального. Здесь рассказывается про управление проектом и про участников проекта со стороны IT-отдела.




        Работа над проектом


        Подготовка к сбору подписей — долгий, сложный, ресурсоемкий и совершенно незаметный со стороны проект, который не приносит штабу и кандидату никаких «политических очков», а в случае отказа в регистрации оказывается совершенно ненужным. Почему мы решили инвестировать в него такое количество денег, времени и усилий?
        Читать дальше →
      • IT-инфраструктура штабов Навального и сбор подписей: Жнец-2018

          Cерия публикаций про сбор подписей

          1. Введение, сайт «Навальный 20!8», подготовка к сбору
          2. Железо и сети, видеонаблюдение
          3. Жнец-2018: система для сбора подписей
          4. Управление проектом

          Это третья часть материала про IT-инфраструктуру штабов Навального. В предыдущих главах было рассказано про разработку сайта «Навальный 20!8», организацию сети в штабах и производство сканеров документов.

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



          Листы, QR-коды и способы работы с ними


          Подписной лист — основной документ в нашей системе. Первое, что хочется сделать для работы с большой коллекцией объектов, — присвоить им уникальный идентификатор, чтобы связать каждый объект с записью в базе данных. Но форма подписного листа очень строго прописана в законе, любое ее нарушение — это повод забраковать вообще все подписи кандидата. На листе, который подается в избирком, не допускается никаких лишних пометок и символов.
          Читать дальше →
        • Как Linux работает с памятью. Семинар в Яндексе

            Привет. Меня зовут Вячеслав Бирюков. В Яндексе я руковожу группой эксплуатации поиска. Недавно для студентов Курсов информационных технологий Яндекса я прочитал лекцию о работе с памятью в Linux. Почему именно память? Главный ответ: работа с памятью мне нравится. Кроме того, информации о ней довольно мало, а та, что есть, как правило, нерелевантна, потому что эта часть ядра Linux меняется достаточно быстро и не успевает попасть в книги. Рассказывать я буду про архитектуру x86_64 и про Linux­-ядро версии 2.6.32. Местами будет версия ядра 3.х.



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

            Термины


            Резидентная память – это тот объем памяти, который сейчас находится в оперативной памяти сервера, компьютера, ноутбука.
            Анонимная память – это память без учёта файлового кеша и памяти, которая имеет файловый бэкенд на диске.
            Page fault – ловушка обращения памяти. Штатный механизм при работе с виртуальной памятью.
            Читать дальше →
          • Индексы в PostgreSQL — 8


              Мы уже рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и все основные методы доступа, как то: хеш-индексы, B-деревья, GiST, SP-GiST и GIN. А в этой части посмотрим на превращение джина в ром.

              RUM


              Хоть авторы и утверждают, что джин — могущественный дух, но тема напитков все-таки победила: GIN следующего поколения назвали RUM.

              Этот метод доступа развивает идею, заложенную в GIN, и позволяет выполнять полнотекстовый поиск еще быстрее. Это единственный метод в этой серии статей, который не входит в стандартную поставку PostgreSQL и является сторонним расширением. Есть несколько вариантов его установки:

              • Взять пакет yum или apt из репозитория PGDG. Например, если вы ставили PostgreSQL из пакета postgresql-10, то поставьте еще postgresql-10-rum.
              • Самостоятельно собрать и установить из исходных кодов на github (инструкция там же).
              • Пользоваться в составе Postgres Pro Enterprise (или хотя бы читать оттуда документацию).

              Ограничения GIN


              Какие ограничения индекса GIN позволяет преодолеть RUM?

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

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

              Метод доступа RUM в первом приближении можно рассматривать как GIN, в который добавлена позиционная информация, и который поддерживает выдачу результата в нужном порядке (аналогично тому, как GiST умеет выдавать ближайших соседей). Пойдем по порядку.
              Читать дальше →
            • Дайджест новостей из мира PostgreSQL



                Друзья! Мы решили запустить дайджест свежих новостей, статей, релизов и событий из мира PostgreSQL, который будет выходить раз в две недели. В подборке вы найдете ссылки на наиболее интересные материалы по PostgreSQL, вышедшие за период. Если мы пропустили что-то важное для вас – пишите в комментариях!

                Релизы


                • Вышел Postgres Pro Standard 10.1.1. В эту версию перенесены все ключевые доработки и новые возможности СУБД Postgres Pro Standard 9.6, исправлены некоторые найденные ошибки. Также вышла сборка PostgreSQL 10.1 под Windows
                • Вышла версия PgBouncer 1.8.1. Исправлена ошибка в 1.8: добавлен недостающий файл, теперь PgBouncer без проблем собирается из тарбола.
                • Появилась версия драйвера psqlODBC 10.01.0000. Некоторые поправки и усовершенствования по сравнению с версией 10.00.0000. Например, ликвидированы утечки памяти.

                Статьи


                • В статье Jsonb: few more stories about the performance
                  Дмитрий Долгов (Zalando) обнародовал производительность PostgreSQL, MySQL и MongoDB на тестах YCSB. Сравнивалась производительность обработки бинарных JSON-ов (JSONB и BSON). Методика тестирования (в облаке) расписана подробно, есть выводы и рекомендации.
                  До этого тема обсуждалась на PGConf.EU 2017 в Варшаве и на других конференциях. Например, в презентации Олега Бартунова по результатам YCSB-тестирования в Postgres Professional (слайд 81 и далее). В этих тестах на выделенных мощных серверах сравнивались только MongoDB и PostgreSQL, а акцент был сделан на высокую нагрузку (тысячи клиентов одновременно).
                Читать дальше →
                • +46
                • 8,7k
                • 4
              • Задача со звездочкой: как мы перекодировали ФИАС в КЛАДР



                  С 1 января ФНС перестанет обновлять адресный справочник КЛАДР. Он официально устареет, останется один ФИАС. Но многие промышленные системы до сих пор работают с КЛАДР. Поставщики не собираются их обновлять, а переделывать своими руками бизнесу выходит долго и дорого.

                  Мы послушали клиентов и придумали решение: взять ФИАС, который живее всех живых, и написать перекодировщик в КЛАДР.

                  Со стороны задача кажется легкой. Нам так и говорили: «То есть вы просто берете ФИАС и переделываете в КЛАДР?». На деле никакого «просто» нет. У справочников совсем разные структуры и непонятно, как из подкачанного ФИАС раскидать данные в неказистый КЛАДР. При этом общей документации для справочников нет.

                  Это было веселье, которым мы сейчас щедро поделимся.
                  Читать дальше →
                • Доделал игру, работающую на видеокарте

                    Наконец-то я доделал игру, которая работает на видеокарте. Она несколько месяцев повисела в раннем доступе на стиме, и теперь я её окончательно выпустил. Основная фишка игры в том, что она представляет собой физическую симуляцию, которая выполняется на графическом процессоре. Основной код игры — это огромный compute shader, 6 тысяч строк на HLSL. Десятки тысяч взаимодействующих частиц обрабатываются параллельно, и выходит довольно быстро. Всё в игре сделано из этих частиц. Вот несколько гифок о том, как это работает:

                    image
                    Читать дальше →
                  • Индексы в PostgreSQL — 5


                      В прошлые разы мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа, и два метода: хеш-индекс и B-дерево. В этой части займемся индексами GiST.

                      GiST


                      GiST — сокращение от «generalized search tree». Это сбалансированное дерево поиска, точно так же, как и рассмотренный ранее b-tree.

                      В чем же разница? Индекс b-tree жестко привязан к семантике сравнения: поддержка операторов «больше», «меньше», «равно» — это все, на что он способен (зато способен очень хорошо!). Но в современных базах хранятся и такие типы данных, для которых эти операторы просто не имеют смысла: геоданные, текстовые документы, картинки…

                      Тут на помощь и приходит индексный метод GiST. Он позволяет задать принцип распределения данных произвольного типа по сбалансированному дереву, и метод использования этого представления для доступа по некоторому оператору. Например, в GiST-индекс можно «уложить» R-дерево для пространственных данных с поддержкой операторов взаимного расположения (находится слева, справа; содержит и т. п.), или RD-дерево для множеств с поддержкой операторов пересечения или вхождения.

                      За счет расширяемости в PostgreSQL вполне можно создать совершенно новый метод доступа с нуля: для этого надо реализовать интерфейс с механизмом индексирования. Но это требует продумывания не только логики индексации, но и страничной структуры, эффективной реализации блокировок, поддержки журнала упреждающей записи — что подразумевает очень высокую квалификацию разработчика и большую трудоемкость. GiST упрощает задачу, беря на себя низкоуровневые проблемы и предоставляя свой собственный интерфейс: несколько функций, относящихся не к технической сфере, а к прикладной области. В этом смысле можно говорить о том, что GiST является каркасом для построения новых методов доступа.
                      Читать дальше →
                      • +32
                      • 13,4k
                      • 4
                    • Нечеткий поиск в словаре с универсальным автоматом Левенштейна. Часть 2



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

                        Читать дальше →
                        • +32
                        • 16,6k
                        • 3