afiskon
+1
С вашего позволения, хотел бы добавить пару (возможно, спорных) советов от себя.

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

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

vim query.sql
:!psql query.sql


Просто первое, что в голову пришло.
afiskon
+1
Все через psql
afiskon
0
В настоящее время не пользуюсь никакими.

Раньше пробовал разные. Советую посмотреть на DataGrip от JetBrains.
afiskon
0
Большое спасибо за интересную серию статей.

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

Очень жаль, что вы про MariaDB забыли, был бы полноценный LEMP стек. Ну и Memcached можно было бы для кучи.
afiskon
0
Ну как же она неизвестна? Вы же можете сделать тестовую инсталляцию и сказать \d, правда?
afiskon
+1
Хороший цикл статей. Читаю с удовольствием. Спасибо.
afiskon
+3
Я бы еще добавил к возможным подходам ZSON.

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

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

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

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

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

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

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

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

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

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

Про «Вы не платите за то, что не используете» смотрите мой пост.

Хочу также подчеркнуть что мое субъективное мнение — это мое субъективное мнение. Я ни в коем случае никому его не навязываю.