LINUX.ORG.RU
ФорумTalks

Стоит ли пойти работать туда, где пилят форк PostgreSQL на Си, если до этого я всю жизнь просиживал жопу C++20 разрабом в яндексе?

 


0

4

Яндекс или его аналог создаёт зону комфорта с кофепоинтами, когда не нужно интересоваться тем, что происходит в мире, потому что всё внутри написано на своих костылях и если чего-то не хватает, то эт могут написать. Вокруг ходят самоуверенные гении, которых сюда соизволили взять, потому что только они смогли прорешать весь литкод. Эффектно создаётся ощущение богоизбранности, поэтому когда хочется уволиться, тебя останавливает мысль, что ты лох, раз решил уйти из элитного клуба! Некоторым даже платят хорошую зарплату, которой хватает на недвигу (со скидками), особенно если ты пробился в тимлиды. Есть много творчества - пишутся велосипеды с использованием современных компиляторов, можно реализовать гениальную идею - пофиг, что она где-то уже сделана или что это страшное ненужно и велосипед, оправдывающий себя только в данном проекте на данной нагрузке. Минус в том, что нигде больше на рынке знание этих костылей не оценят и выходя оттуда ты не эксперт примерно ни по чему, кроме своих ссаных высоконагруженных костылей.

Но если ты пошёл пилить какой-то форк PostgreSQL, то никакого C++ тебе не будет, будет старый сишный легаси специфический код с собственными механизмами аллокации или исключений и логирований. Это всё не плохо, в яндексе оно тоже всё свое, но там хотя-бы оно завёрнуто в конструкторы-деструкторы и ты можешь что-то творить как настойщий гений художник-я-так-вижу! В постгресе творчества и РАЗРАБОТКИ как таковой скорее всего не будет - MVCC придумали давно до тебя, разрабатывать новые оптимизаторы тебе тоже никто не даст, не до этого, а вот мёржить новую версию постгреса в свой форк ты будешь полгода как обезъяна и тут нужно иметь просто каменную жопу и отсутствие всяких амбиций. В оставшееся время ты будешь фиксить какие-то баги с забытыми указателями, чтобы распутать которые ты будешь сидеть в gdb как тварь неделю. Зато возможно ты станешь экспертом мирового уровня по внутренностям постгреса и в какой-то момент тебя возьмут в перспективный HFT-криптостартап за 800к/наносек, чтобы запилить свой перспективный форк, поддерживающий какой-то особый тип таблиц, но тебе к тому времени будет уже 72 года. Либо ты сможешь после этого уйти куда-то экспертом по оптимизации производительности популярного во всём мире движка СУБД, видя движок насквозь и понимая во что скомпилировался запрос?

Правильно ли описано шило-на-мыло в двух сценариях развития карьеры или второй путь всё же более перспективен, хотя требует большей усидчивости и занудства?



Последнее исправление: lesopilorama (всего исправлений: 2)

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

Такое бывает только на сишном полуасме?

А работ с безопасным рантаймом типа JVM и/или .NET не бывает?

sanyo1234
()

У меня раньше было ощущение, что ядро разрабатывает кучка энтузиастов-фриков, которые не вписались в корпоративный мир it-индустрии
На деле же все оказалось ровно наоборот
Ядро пилят сотрудники оракла, гугла, майкрософта (о боже), которым по работе необходима функциональность, которой еще нет в ядре
А те, кто онли-фан пытается продвигать какие-то опен-сорсные проекты, в конце концов оказываются в изоляции, потому что их проекты никому не интересны, кроме них самих, и постепенно такая разработка гибнет на корню.
Я слабо представляю, как опен-сорс может жить сам по себе вне коммерческой индустрии

kto_tama ★★★★★
()

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

eeiaao
()

Си
C++20
нужно иметь просто каменную жопу и отсутствие всяких амбиций
ты будешь сидеть в gdb как тварь неделю

В принципе плюс / минус везде. Если хочется жопу по-деревянее, надо уходить в пхп фронтенд.

А с амбициями ты вообще ошибся адресом - это тебе в менеджмент.

LamerOk ★★★★★
()

Пляшите от целей. Цели ваши какие и достигаются ли они в каждом из случаев?

unDEFER ★★★★★
()
Последнее исправление: unDEFER (всего исправлений: 1)

О роли разработчиков яндекса в ядре линукса:
Разработчики Яндекса внесли весомый вклад в развитие ядра Linux - это производительность файловых систем, сетевая подсистема, управление памятью и отладка.

1. Оптимизация файловых систем (особенно ext4)
«Яндекс» эксплуатирует одну из крупнейших в мире кластерных файловых систем на базе ext4.
Патчи, уменьшающие конкуренцию за глобальные (spinlocks) в коде ext4, что значительно повышает параллелизм и производительность на многопроцессорных системах, например, работа над `s_writers_lock` и `s_mmd_lock`.
Ускорение операций с метаданными: Оптимизация кода, отвечающего за работу с дескрипторами файлов (inodes) и каталогами (directories), что ускоряет операции создания и удаления файлов.
Улучшение работы fsync(): Для обеспечения сохранности данных приложения часто используют вызов `fsync()`, который принудительно записывает данные на диск. Инженеры «Яндекса» оптимизировали его реализацию для ext4, чтобы снизить нагрузку на систему и уменьшить задержки.

2. Сетевая подсистема (Networking)
Оптимизация стека TCP/IP: Вклад в ускорение обработки сетевых пакетов (патчи, связанные с механизмом NAPI, обработкой прерываний).
Разработка и улучшение драйверов сетевых устройств: Внесение исправлений и оптимизаций в драйверы популярных сетевых карт (например, Intel), которые используются в их дата-центрах.
Мониторинг и отладка: Разработка и улучшение инструментов для отладки сетевого стека внутри ядра.

3. Подсистема управления памятью (Memory Management)
Улучшение работы с обратной картой памяти (Reverse Mapping, rmap): Эта подсистема критически важна для эффективного освобождения памяти. Патчи от «Яндекса» были направлены на снижение её нагрузки на CPU.
Оптимизация работы сжатия памяти (zswap/zsmalloc): Вклад в улучшение алгоритмов, уменьшающих накладные расходы при использовании этой технологии.
Борьба с фрагментацией памяти: Патчи, улучшающие работу механизмов компактирования (compaction) и управления «водоразделом» (watermarks).

4. Инструменты отладки и профилирования
Развитие ftrace: Участие в разработке и улучшении этого встроенного трассировщика ядра, который позволяет глубоко анализировать его работу в реальном времени.
Создание и поддержка blktrace: Инструмент для детального анализа работы блочных устройств (дисков), критически важен для отладки производительности IO.

Многие из их разработчиков являются мейнтейнерами отдельных подсистем ядра (например, ext4, драйверов устройств).

kto_tama ★★★★★
()
Последнее исправление: kto_tama (всего исправлений: 1)

Сначала хотел по теме написать, а потом почему-то подумал о кризисе среднего возраста. Ты главное резких решений не принимай, посиди, подумай по-дольше, уже потом решай. Оба стула +- одинаковые, со своими плюсами и минусами. Что тебе ближе - тебе виднее.

aiqu6Ait ★★★★
()
Последнее исправление: aiqu6Ait (всего исправлений: 1)
Ответ на: комментарий от kto_tama

«Яндекс» эксплуатирует одну из крупнейших в мире кластерных файловых систем на базе ext4.

А сколько она им денег сэкономила, например?

MoldAndLimeHoney ★★
()
Ответ на: комментарий от MoldAndLimeHoney

А сколько она им денег сэкономила, например?

А они прямую цифру в долларах не раскрывают, но можно сделать оценку.
Экономия исчисляется сотнями миллионов долларов, если не больше, за всё время эксплуатации.

1. Экономия на лицензиях (Самая очевидная и большая статья)
Проприетарные СХД (Системы Хранения Данных) от компаний вроде Dell EMC, NetApp, IBM дорогие.
Такие системы имеют огромную стоимость не только на покупку (миллионы долларов за стойку), но и на обязательное ежегодное лицензионное обслуживание (15-25% от стоимости железа в год).
Объём данных яндекса исчисляется эксабайтами. Чтобы хранить это на проприетарных массивах, потребовались бы многие тысячи стоек такого оборудования.

2. Экономия на «железе» (Капитальные затраты, CAPEX)
Яндекс использует стандартные серверы с прямым подключением дисков (DAS - Direct-Attached Storage) в концепции JBOD (Just a Bunch Of Disks). Это самые дешёвые серверы с большим количеством дисковых слотов.
Специализированные проприетарные дорогие storage-серверы или те же проприетарные массивы, где цена за гигабайт в разы выше.
Стоимость гигабайта хранилища в инфраструктуре «Яндекса» на порядок ниже, чем при использовании коммерческих enterprise-решений.

3. Экономия на операционных расходах (OPEX) и эффективности
Их собственная разработка — «таблетки» (tablets) — позволяет упаковывать данные очень плотно, минимизируя избыточное копирование и дублирование.
Если в проприетарном массиве выходит из строя диск, его замена — это часто дорогая и сложная процедура с обязательным привлечением вендора. В архитектуре «Яндекса» сбой одного диска или даже целого сервера — штатная ситуация, которая обрабатывается автоматически и дешёвой заменой стандартным компонентом.

Короче, если бы «Яндекс» хранил свои эксабайты данных на коммерческих СХД, их ежегодные расходы только на лицензии и обслуживание могли бы легко превышать $50-100 млн в год.
Умножьте это на более чем 10 лет эксплуатации такой системы.

kto_tama ★★★★★
()

Правильно ли описано шило-на-мыло в двух сценариях развития карьеры или второй путь всё же более перспективен, хотя требует большей усидчивости и занудства?

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

kawaii_neko ★★★★
()
Ответ на: комментарий от kto_tama

О роли разработчиков яндекса в ядре линукса

Напиши еще опус о своем вкладе в приближение тепловой смерти Вселенной из-за использования LLM по поводу и без.

kawaii_neko ★★★★
()
Последнее исправление: kawaii_neko (всего исправлений: 1)

Программист C++20, решивший войти в разработку PostgreSQL, столкнётся с несколькими слоями проблем.

Сообщество PostgreSQL крайне консервативно и прагматично.
Любое изменение, особенно касающееся ядра СУБД, должно быть обратно совместимым, не ухудшать производительность ни на йоту и быть действительно необходимым.
Предложение переписать кусок кода на современный C++ «просто потому что это современно и красиво» вызовет недоумение и будет отвергнуто.
Ваш первый нетривиальный патч будут рассматривать месяцами.
Его будут обсуждать в рассылке pgsql-hackers, и десятки опытных разработчиков укажут на все возможные недостатки.

В постгресе собственная система памяти (Memory Contexts).
В PostgreSQL нет `new`/`delete` или `malloc`/`free` в чистом виде.
Всё выделяется внутри Memory Contexts.
Контексты позволяют массово освобождать память (например, по окончании запроса), что предотвращает утечки и сильно упрощает код.
Для программиста на C++ это означает:
Никаких умных указателей в их классическом виде (`std::shared_ptr`, `std::unique_ptr`), потому что они используют `delete`.
Придется использовать собственные аналоги PostgreSQL: `palloc()` (аналог `malloc` в контексте), `StringInfo` (аналог `std::string`), `List` (односвязные и двусвязные списки) и т.д.
Собственная система обработки ошибок (elog/ereport): используется макросовая система `ereport(ERROR, ...)`.
При вызове она долгим прыжком (setjmp/longjmp) раскручивает стек до ближайшего блока-перехватчика (вокруг всего запроса).
Это значит:
Деструкторы объектов не будут вызваны.

C++20 — это не про PostgreSQL.
Ваши знания концептов, корутин, модулей и ranges будут абсолютно бесполезны в 99.9% кодовой базы. Это как привезти современный швейцарский армейский нож на стройку, где работают только кувалдой и зубилом.

PostgreSQL — это монолит, невероятно сложное приложение.
Чтобы понять, как исправить баг в оптимизаторе, вам нужно понимать, как работает парсер, планировщик, исполнитель, система блокировок и т.д.
Активно развивающийся форк PostgreSQL должен постоянно сливаться с основной веткой.
Это титанический труд, потому что изменения в ядре очень глубокие и часто затрагивают самые основы. Конфликты будут жуткими.

kto_tama ★★★★★
()

Совсем не понятно почему ты хотишь поменять работу. Зп мала, тебя не ценят, не достиг богоподобия, надоело в яндекс или ты решил что жизнь одна и стоит себя попробовать в порно в разработке постгри? В сообщении просто поток сознания на тему срр vs c. Как только ты сформулируешь для себя это «почему», так сразу на него сам и ответишь - стоит или не стоит.

vtVitus ★★★★★
()
Ответ на: комментарий от kto_tama

Постгри одна из самых понятным по коду. Я там пострянно смотрю реализации системных вещей, очень помогает в понимании почему работает так, а не иначе.

vtVitus ★★★★★
()
Ответ на: комментарий от MirandaUser2

Реализации системных постгрёвых функций и оператороф. И каким местом там индексы.

vtVitus ★★★★★
()
Ответ на: комментарий от MirandaUser2

Что за «системные» вещи в коде PostgreSQL?

Он имел ввиду то, что описано в документации, но на всякий я повторю:

Системные вещи в PostgreSQL реализованы с помощью набора модулей и абстракций.
Абстракция над операционной системой:
Вместо прямых вызовов `fork()`, `read()`, `write()` или `pthread_create()`, ядро PostgreSQL повсеместно использует собственные функции-обёртки, которые решают несколько задач:
Вся работа с ОС идет через один набор функций.
Реализация для Windows, Linux, macOS и других ОС находится в одном месте.
Остальной код пишется против абстракции PostgreSQL, а не против API конкретной ОС.
Обёртки стандартизируют обработку ошибок (например, автоматически проверяют возвращаемые коды и генерируют ошибки через `elog()`).

src/backend/port/: Здесь лежит платформо-зависимый код.
Вместо `fork()` используется `fork_process()`.
Вместо `open()`/`read()` используются `PathNameOpenFile()` и `FileRead()`.
Вместо `malloc()`/`free()` — `palloc()`/`pfree()` (работают в рамках Memory Contexts).

В долгоживущем серверном процессе на C крайне сложно избежать утечек памяти.
Традиционный `malloc`/`free` требует скрупулёзного отслеживания.
Memory Contexts — это иерархические allocator'ы.
Память выделяется не глобально, а в рамках контекста (`palloc()`).
Контексты образуют дерево. У каждого запроса есть свой корневой контекст, а у его этапов (парсинг, планирование, выполнение) — дочерние.
Освобождение памяти — групповое.
Чтобы освободить всю память, выделенную для разбора запроса, достаточно удалить корневой контекст этого запроса. Это происходит мгновенно и надежно предотвращает утечки.
Разработчику в большинстве случаев не нужно беспокоиться о ручном освобождении памяти.

PostgreSQL использует модель «один процесс — одно соединение» (на UNIX-системах).
Постмастер (`postmaster`) - главный управляющий процесс.
Он запускается первым, управляет разделяемой памятью и прослушивает TCP-порт.
Преимущества: Изоляция сбоев (падение одного бэкенда не уронит весь сервер), простота.
Недостатки: Большое потребление памяти и более медленное создание соединения по сравнению с потоковой моделью (threads).

Поскольку процессы изолированы, для координации им нужны мощные механизмы IPC.
Разделяемая память (Shared Memory) - единственный сегмент памяти, доступный всем процессам сервера. В нём хранится самое важное общее состояние:
Буферный кэш (cache данных с диска).
информация о блокировках (Lock Tables).
информация о запущенных транзакциях (CLOG, MultiXact).
Семафоры и `LWLock` (Lightweight Locks)

Код постгреса разбит на четкие модули с хорошо определенными API.
src/backend/parser`: Парсер SQL. На выходе — дерево разбора (`ParseTree`).
src/backend/rewrite`: Система правил и преобразование представлений.
src/backend/optimizer: Планировщик/оптимизатор. Превращает дерево разбора в план запроса (`QueryPlan`).
src/backend/executor: Исполнитель. Интепретирует план запроса, получая результат.
src/backend/storage`: Вся подсистема работы с данными на диске (буферы, менеджеры SMGR, большие объекты, пр.).

Лично я никогда не модифицировал код постгреса.
За внешней простотой организации кода скрыта внутреннея логика, которую разрабатывало не одно поколение программистов
И вот эта внутрення логика постгреса на мой взгляд представляет основную проблему

kto_tama ★★★★★
()
Ответ на: комментарий от kto_tama

Оптимизация файловых систем

Теперь понятно, чего драйвер ext4 настолько жирный в сравнении с ext3

Shadow ★★★★★
()

В HFT на опыт в БД вообще побоку, у них там в лучшем случае что-то in-memory, а чаще просто самописные костыли и файлики.Но какому-нибудь забугорному БД-стартапу опыт с постгрёй будет проще объяснить, чем яндекс.

Как по мне по ценности в резюме примерно одинаково, просто иди где больше платят и меньше нервы тревожат. В частности, в постгре наверное не будет дежурств как в яше (продают коробочный продукт, а не сервис), и у тебя будут нормальные выходные.

snizovtsev ★★★★★
()
Последнее исправление: snizovtsev (всего исправлений: 5)
Ответ на: комментарий от vtVitus

Всё началось с денег - в постгресах дают на 10-30% больше. А потом возникла мысль, что в постгресах все так перспективно, что потом дадут на 100% больше.

lesopilorama
() автор топика
Ответ на: комментарий от lesopilorama

что в постгресах все так перспективно, что потом дадут на 100% больше.

Для этого ты сейчас должен видеть конкретно ту позицию, на которой дают на 100% больше денег, и выбирать новое место работы и стек технологий надо с прицелом на эту самую позицию.

soomrack ★★★★★
()

Постгря-болото с старперами, яростно медитирующими на замшелый древний код, реализующий давно устаревшие концепции организации СУБД. Везде где юзают постгрю и есть требования к производительности, пилят свой форк, ибо протолкнуть что-то новое тем сарперам нереально. Пили свою СУБД, в яндексе. Или еще где. Творчеством и экспериментами занимаются не только в яндексе, но и в любой другой софтовой продуктовой компании.

slew
()

Правильно ли описано шило-на-мыло в двух сценариях развития карьеры или второй путь всё же более перспективен, хотя требует большей усидчивости и занудства?

  1. Ты погнался за деньгами? Или «Яндекс» уже начал подгнивать изнутри? Так в «Постгрессе про» свои наработки в открытый доступ тоже не выкладывают. Сначала они прикрывались открытым кодом, чтобы быстро запуститься на чужом труде, а как дошло до дела, так сразу свои наработки зажали. Тут дело не в самих исходных текстах ПО, все равно их сходу мало кто поймет, а в «совковом» мышлении руководства предприятия. Пойдешь работать к «совкам», так и сам превратишься в такого же «совка» и даже тут, на форуме, перестанешь делиться знаниями с людьми бесплатно.

  2. По моим наблюдениям, из изначальных «плюсистов» получаются лишь никудышные программисты на Си. Привычка «плюсистов» переиспользовать уже написанные классы и библиотеки приводит к поверхностному, «воробьиному» мышлению: вместо продумывания способа решения задачи наилучшим образом, «плюсисты» сразу бегут искать готовую библиотеку. Вроде бы так даже лучше для конторы - быстро и проверено вставляем код, написанный каким-то Васей, и начинаем зарабатывать. Подвох в том, что такие верхогляды разучиваются включать мозги и придумать ничего нового уже не смогут никогда. Тот же «Яндекс» ничего сам не придумал, что начали бы использовать во всем мире: «Яндекс-такси» скопировано с «Убера»; «Алиса» скопирована с «Алексы» и «Сири»; «Облако» тоже скопировано полностью. А раз так, то местечковый уровень развития «Яндекса» останется с ним навечно до конца.

  3. Лучше не мучай себя и «постгрессистов» своим «плюсовым» искореженным мышлением, а то потом начинают появляться классы и объекты, написанные на Си, ибо плюсисты без объектного подхода сами страдают и вокруг только воздух портят.

Enthusiast ★★★
()
Ответ на: комментарий от Enthusiast

Плюси-сишный фашизм из твоего треда подсознательно отфильтровал, перечитаю ещё разок.

lesopilorama
() автор топика

Всю жизнь

C++20

thesis ★★★★★
()

Сиди на пятой точке и не дёргайся: везде всё одинаково.

sparkie ★★★★★
()
Ответ на: комментарий от Enthusiast

Тут дело не в самих исходных текстах ПО, все равно их сходу мало кто поймет, а в «совковом» мышлении руководства предприятия. Пойдешь работать к «совкам», так и сам превратишься в такого же «совка» и даже тут, на форуме, перестанешь делиться знаниями с людьми бесплатно.

Походит ли это на «разработчиков» «отечественных» операционных систем на базе Linux ?

sanyo1234
()
Ответ на: комментарий от Enthusiast

...начал подгнивать изнутри?

По-моему, внутреннее гниение сабжевой конторки вещь перманентно-неизбежная, не?

sparkie ★★★★★
()
Ответ на: комментарий от Enthusiast

Тот же «Яндекс» ничего сам не придумал, что начали бы использовать во всем мире: «Яндекс-такси» скопировано с «Убера»; «Алиса» скопирована с «Алексы» и «Сири»; «Облако» тоже скопировано полностью. А раз так, то местечковый уровень развития «Яндекса» останется с ним навечно до конца.

Можно подумать, способность придумывать на уровне кодера как-то коррелирует со способностью придумывать на уровне продакта?

Ну вот если кодер и придумает даже и интересный новый продукт и руководство яндыкса бросится его сразу реализовывать?

sanyo1234
()
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от lesopilorama

...в постгресах дают на 10-30% больше.

Им люди нужны, кадры. Отсюда все ихние телодвижения и психопоглаживания твоего эго. Только кретин обращается с кадрами, как с мелочью в своём кармане. А они явно не кретины.

Сиди ровно на попе.

sparkie ★★★★★
()
Ответ на: комментарий от lesopilorama

Ну тогда в чём дело? В яндексе надоело, а там новая интересная разработка и бабла больше - какие вопросы? :-)

vtVitus ★★★★★
()
Ответ на: комментарий от kto_tama

Угу.

И, да, ТС'а не подпустят сразу кодить в прод.

...переписать кусок кода на современный C++ «просто потому что это современно и красиво» вызовет недоумение и будет отвергнуто.

И это правильно.

sparkie ★★★★★
()

...самоуверенные непризнанные гении...

Пофиксил, не благодари.

Читал в этих ваших даркнетах о нравах, царящих в Я...

sparkie ★★★★★
()

От такой дилеммы можно и спиться. Мне кажется, стоит попробовать. В крайнем случае можно же будет вернуться.

P. S.
Буквально на днях читал занимательную заметку о разработке Постгреса.
Впечатлило

Евгений сказал, что первый ребейзинг занял 5 месяцев, второй три месяца, третий две недели. Другими словами, чтобы вникнуть в патч к.ф.-м.н. нужно полгода с поддержкой 5 программистов на языке C и одного программиста уровня коммитера.

urxvt ★★★★★
()
Последнее исправление: urxvt (всего исправлений: 1)

Я не знаю как обстоят дела именно у сишников, но в общем и целом Яндекс платит ближе к нижней границе рынка. Соответственно, возможно, на другом месте будут больше платить. А более релевантный рынку опыт (так как меньше велосипедов) на другом месте позволит и дальше эффективнее находить новые места с более конкурентной ЗП.

KivApple ★★★★★
()
Ответ на: комментарий от vtVitus

Ну тогда в чём дело? В яндексе надоело, а там новая интересная разработка и бабла больше - какие вопросы? :-)

Вопрос в том, интересная ли она. Полгода мёржить мастер ветку постгреса в свой форк - жесть какая-то.

lesopilorama
() автор топика
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)