• +5
    Егор, спасибо за статью. Мне было очень интересно прочитать про индексацию точек с помощью GiST, а также расширение gevel, так как ранее этими возможностями PostgreSQL мне пользоваться не доводилось.

    Касаемо полнотекстового поиска при помощи GIN и pg_trgm не могу не сообщить, что не так давно писал об этом у себя в блоге (раз и два), а также делал доклад на РИТ (слайды). Авось соответствующие материалы кого-то заинтересуют.
    Индексы в PostgreSQL — 5
  • +1
    С вашего позволения, хотел бы добавить пару (возможно, спорных) советов от себя.

    1) Откройте для себя наконец Ninja (cmake -G Ninja ..). Скорость сборки возрастает существенно.
    2) По возможности распиливайте проект на библиотеки и тяните их через git submodules.
    3) Если тест можно написать на Python, пишите на Python.
    4) И вообще раз заговорили про C++: сразу прикручивайте clang-format, clang static analyzer, cppcheck и valgrind, мерьте степень покрытия кода с помощью lcov.

    У себя в бложике я описывал эти моменты более подробно.
    Современный CMake: 10 советов по улучшению скриптов сборки
  • +3
    Amit Kapila не так давно показал, что хэш-индексы иногда могут быть быстрее B-деревьев. Следовательно, если вы ищите только по равенству, имеет смысл сравнить оба варианта и выбрать тот, который на ваших данных и объемах будет быстрее.
    Индексы в PostgreSQL — 3
  • +5
    Спасибо за статью. Стоит добавить, что pthreads также предлагает примитивы синхронизации, в частности мьютексы — см man pthread_mutex_init и далее по ссылкам.
    Pthreads: Потоки в русле POSIX
  • 0
    В соответствии с произношением — ˈbätl
    Примеры реальных патчей в PostgreSQL: часть 3 из N
  • 0
    Ну, например:

    vim query.sql
    :!psql query.sql


    Просто первое, что в голову пришло.
    Примеры реальных патчей в PostgreSQL: часть 3 из N
  • 0
    В настоящее время не пользуюсь никакими.

    Раньше пробовал разные. Советую посмотреть на DataGrip от JetBrains.
    Примеры реальных патчей в PostgreSQL: часть 3 из N
  • 0
    Большое спасибо за интересную серию статей.

    Не подскажете книгу или несколько хороших книг по этой теме?
    Теория радиоволн: аналоговая модуляция
  • +1
    Спасибо, весьма познавательно. Пожалуйста, пишите еще статей о ядре Linux. Материалов решительно не хватает!
    Заметка о способе отладки блокировок в ядре Linux
  • –5
    Статья хорошая. С комментариями выше про Docker и Ansible не соглашусь, я бы лично просто завернул это в виртуалку, притом желательно VirtualBox, потому что он есть у всех.

    Очень жаль, что вы про MariaDB забыли, был бы полноценный LEMP стек. Ну и Memcached можно было бы для кучи.
    Установка и базовая настройка nginx и php-fpm для разработки проектов локально в Ubuntu 16.04
  • 0
    Ну как же она неизвестна? Вы же можете сделать тестовую инсталляцию и сказать \d, правда?
    Пример восстановления таблиц PostgreSQL с помощью новой мега фичи pg_filedump
  • +1
    Хороший цикл статей. Читаю с удовольствием. Спасибо.
    Python: коллекции, часть 2/4: индексирование, срезы, сортировка
  • +3
    Я бы еще добавил к возможным подходам ZSON.

    В случае с текстовыми данными нужно учитывать, что в TOAST уже есть LZ-подобное сжатие, поэтому все большие объемы данных и так жмутся. На выравнивании можно выиграть еще 1-2 процента от силы.
    Уменьшение объема, занимаемого данными PostgreSQL на диске
  • 0
    Последний раз когда я узнавал, книги были сильно устаревшими (была какая-то одна акутальная, но на немецком языке), а статьи быстро устаревали, потому что разработчики ядра не сильно парились по обратной совместимости внутри ядра. То есть чтобы быть в теме нужно постоянно чем-то около ядерным заниматься.
    Перехват системных вызовов Linux с помощью LSM
  • +13
    В высшей мере интересно, спасибо! Реквестирую больше статей о ядерной разработке в Linux.
    Перехват системных вызовов Linux с помощью LSM
  • 0
    Обещанная статья: http://eax.me/sharding/
    Sharding – patterns and antipatterns
  • 0
    Ура-ура! Тестировал бету, был очень доволен. Вы молодцы!
    PVS-Studio для Linux
  • 0
    На счет терминов хочется подчернкнуть, что это не мое личное предложение. Это по мотивам терминологии, используемой в документации Couchbase, Cassandra, Riak, CockroachDB и других СУБД со встроенным шардингом/перебалансировкой.

    По поводу прикручивания транзакций сбоку позвольте не согласиться. Прикручиваются, хоть и не без осведомленности приложения или middleware через который приложение ходит в базу http://rystsov.info/2012/09/01/cas.html По-моему там в статье это не подчеркнуто, но чтобы получить настоящий snapshot isolation нужно при чтении ключей делать с ними то же самое, что и при записи. В документации к некоторым СУБД это называют 2PC транзакциями, но мне этот термин не нравится, так как к настоящему 2PC отношения не имеет.
    Sharding – patterns and antipatterns
  • +1
    Дисклеймер — написанное ниже очень субъективно и скорее всего придирки. И я понимаю, что целью доклада не являлось осветить это все. Тем не менее.

    Во-первых, существует некоторая путаница с терминологией. Каждая СУБД использует немного свои термины, но наиболее общий знаменатель примерно следующий. Под решардингом обычно понимают изменение числа бакетов/vnode. Например, если было hash(key) % 512, решили, что бакетов маловато, и перешли на hash(key) % 1024 или вообще на другую схему. Перенесение бакетов на другие физические машины обычно называют перебалансировкой. Как минимум, было бы не лишним предупредить, что такая путаница вообще есть. Вы же, как я понял, просто для всего решили использовать слово решардинг, тем самым, как мне кажется, оказывая слушателям медвежью услугу.

    Во-вторых, немного удивили повороты в стиле что прокси — это SPOF или что во время перебалансировки нода может упасть. Мне кажется само собой разумеющимся, что прокси должен быть не в одном экземпляре, и что «нода» это на самом деле мастер и пара реплик с фейловером (ручным или автоматическим).

    Наконец, да, полнота доклада. Что на самом деле интересно слушателям? Как им взять какой-нибудь Redis/Tarantool/PostgreSQL/MySQL/иную-систему-без-встроееного-шардинга и на базе нее построить что-то что масштабируется гаризонтально. Что для этого нужно? Да, действительно, какая-то схема шардирования, какой-то сервис дисковери (как получилось, что не вспомнили хотя бы ZooKeeper, не говоря уже про Consul или etcd? снова оказание медвежьей услуги — ведь слушатели побегут писать свое), процедура решардинга, процедура ребалансировки (важно подчеркнуть, что это отдельные вещи) и, самое интересное, транзакции между нодами.

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

    Повторюсь, это все субъективная оценка. И я понимаю, что доклад, видимо, был ориентирован на новичков и делался, наверное, давно. Я постараюсь в ближайшем будущем написать свою версию того, как можно решить все описанные проблемы на примере PostgreSQL.
    Sharding – patterns and antipatterns
  • +2
    При всем моем глубоком уважении к докладчикам, доклад мне кажется слабоватым. Возможно, он просто ориентирован на начинающих.
    Sharding – patterns and antipatterns
  • 0
    Потрясающая статья, больше спасибо!

    Не могли бы вы рассказать, в чем именно заключаются преимущества развертывания PostgreSQL / Greenplum именно на XFS, а не на EXT4?
    Сравнение аналитических in-memory баз данных
  • 0
    Вижу вы послали патч в ЛС. Я его замержил, спасибо!
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Сейчас у zson_learn есть параметр, определяющий минимальное количество раз, которое строка должна встречаться в документах (по дэфолту 2, можно указать другое значение).
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Попробую, но заранее ничего не обещаю :)
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Не уверен, что понял ваш вопрос. Если вы хотите включить расширение для схемы, то насколько я знаю, это работать не будет.
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Если вы не обучаете zson и на тестовом окружении и на проде одновременно, то проблем быть не должно. Иначе перед обучением на тестовом окружении сначала перенесите полностью словарь с прода.

    И конечно же, на все всегда делайте бэкапы!
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Да как вам удобнее так и переносите. Через COPY например.
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Komzpa ну вы же знаете выражение — patches are welcome! :)
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Это, конечно же, просто косяк в тексте, имелся ввиду col. Исправил, спасибо!
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Никто еще не добавил :) В рассылке предлагают включить zson, расширенный для xml и text, в базовую поставку.
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Пока нет. Но по тому же принципу делается не сложно. А Вам правда нужно или просто интересуетесь?
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Это умышленно, но не из-за проблем типа. Автовакуум на всех бенчмарках приводит к тому, что бенчмарк показывает не то, что вы думаете (работу автовакуума, а не тестируемого функционала). В теории автовакуум должен работать даже быстрее, так как размер туплов уменьшается и производится меньше дискового IO, но конкретных замеров я лично не делал.
    ZSON: расширение PostgreSQL для прозрачного сжатия JSONB
  • 0
    Помимо Saga еще придумали транзакции на CAS. Не то, чтобы шибко сложно, и стороннего сервиса не требует. При аккуратной реализации дает snapshot isolation. См также тынц.
    Микросервисы: пожалуйста, не нужно
  • 0
    Большое спасибо. Очень интересно почитать про OpenGL. Некоторое время назад занимался его изучением (остановился на таком — камера, текстуры, вывод текста, освещение без теней), но в настоящее время подзабил. Пожалуйста, пишите еще!
    Анимированные текстуры в OpenGL
  • 0
    Ну тут проблема в том что из-за изменяющихся бизнес требований типа очевидно независимые части внезапно становится зависимыми и наоборот. Пример из практики. Есть аккаунты, они друг с другом никак особо не связаны, можно смело пошардить по ним. Проходит два года и бизнес придумывает реферальную программу из-за которой транзакции на одном аккаунте приводят к изменению на втором аккаунте, и далее по реферальным ссылкам. Внезапно на ровном месте возникли распределенные транзакции между шардами. И это еще не самый сложный пример — логика вычисления комиссии вообще как угодно может меняться, сегодня она одни данные использует, завтра совершенно другие.

    Это я к тому что по дэфолту лучше монолит, см выше.
    Микросервисы: пожалуйста, не нужно
  • +1
    Несколько лет писал микросервисы и в итоге пришел к тем же выводам, что и автор. Как обычно с новыми блестящими технологиями — много хайпа и размахивания руками, мало здравого смысла. В это время суток мне кажется оправданным следующими подход. Если есть монолит, и с ним нет проблем, оставляем монолит. Если с ним есть проблемы, думаем, можно ли решить их НЕ распиливая монолит на сервисы. Если единственное решение в распиливании — распиливаем на сервисы разумного размера (не обязательно микро).
    Микросервисы: пожалуйста, не нужно