Хм, 1GB чистых логов в сутки (не в ELK, а строчек) превращается где-то в 100MB внутри того же Clickhouse, т.е. 3GB в месяц, 300GB со всех компонент, еще и SSD не нужен. Это совсем копейки. Ретеншен в год нужен не для всех логов, а для некоторой части, что в том же CH тривиально реализуется через matview.
Т.е. проблема не в объеме логов, а в использовании неудачных (эластик) инструментов работы с ними. Все-таки ES создавался совсем для других задач.
Хм, мой процесс работы с C1 предполагает 1) работаем с файлами RAW на диске 2) после обработки папки - делаем экспорт в JPG в архив для просмотра 3) после обработки файла - скидываем все без кэша в архив
И вот результат 2 и 3 летят в архив и в облако, реализуется простеньким rsync. Но, конечно, Dropbox - не лучший вариант для хранения фотографий (дорого и неудобно).
Охх, статья скорее вредная. Путается техническая конфигурация и бизнес-конфигурация, плюсы и минусы форматов никак не связаны с реальностью, перепутано хранение секретов и конфигурации, куча вредных советов по работе с конфигами. Статья была бы хороша для начинающих, но в текущем виде скорее вредна для начинающих (
А почему на продакшене debug дорого? Да, если несколько десятков тысяч rps - то debug на каждом запросе будет дороговато. Но для средних проектов в 10-100rps (т.е. даже debug в пределах 200k строк в секунду) на нормальном стеке (не ELK) все достаточно недорого.
Второй совет скорее вреден. Технологии в совете 8 или не могут быть использованы в РФ или устарели. Общий уровень советов уровня джуниора. Интересно, как можно относиться всерьез к курсам компании, публикуещей настолько слабые статьи?
Принципиальное отличие ролей "техлида" и "тимлида" нужно далеко не для всех деятельностей. Да даже в IT в некоторых командах не нужен тимлид, в некоторых - техлид, в некоторых - ни тот ни другой (но нужны специалисты вне команды - про людей, процессы и так далее). Единой правильной картинки нет. Но без разделения ролей и активностей нарисовать подходящую картинку для конкретных людей в конкретном проекте - тоже не получится.
Это опять про разницу между techlead и teamlead. Техлид - да, тоже разработчик. Тимлид - про процессы, людей, приоритеты, коммуникации, т.е. совсем другие компетенции.
Очень большая проблема процессов во множестве компаний - это смешивание техлида и тимлида в одном человеке. В результате ничего хорошего не получается.
В какой-то момент мне показалось, что это такая пародия на архитектурные документы. Очень много длинных слов, очень много воды, очень много ненужных деталей - и очень мало содержания. Но, боюсь, что это всерьез - и это грустно (
Хм, в старых проектах - да. И нет, MS SQL не является альтернативой Ораклу (не больше, чем PG). Но для новых проектов выбор БД - не очень простая задача, так как много вариантов.
Ну, а зачем переводить с Oracle на PG один к одному со всеми запросами и логикой. Обычно за годы эксплуатации становится понятно, как можно сделать лучше и проще. Не очень верю в систему на 160 TB, которая не накопила кучу легаси и сомнительных решений и которую нельзя сделать более удобной.
А при чем тут облака? Тут сравнивают PG или Oracle, причем исключительно в on-prem. А для on-prem разницы в стоимости дисков для БД или для S3 - нет никакого, это просто диски. А что в каких-то публичных облаках нет других механизмов хранения файлов, кроме S3 - не делает S3 каким-то особенно дешевым способом.
И это если не вспоминать, что S3 - просто семейство протоколов для хранения LOBов и стоимость хранения очень зависит от реализации. Где-то подешевле, где-то сильно дороже.
Да и Data Lake и BI - не обязательно связаны с S3 (собственно, почти всегда не связаны с S3).
Хм, почему не дешевле Оракла? Админы дешевле, лицензии дешевле. Да, если покупать PgPro - то будет дороже. Но, вообще говоря, смысл покупать PgPro возникает довольно редко и не связан с технологическими особенностями. А надежность и большие объемы данных требуют вообще других решений, не про PG и не про Oracle )
Хм, а зачем в телекоме Оракл? Те задачи, что в телекоме требуют реляционной БД - потянет и PG. А те, что не потянут - не реляционные ) В финтехе, в общем, та же ситуация )
Хм, переносить логику с Oracle на PG - плохая идея. Новая БД требует новых подходов к разработке, так что если запросы Оракла плохо работают на PG - не говорит о проблемах PG, только о проблемах перехода с Oracle. С бэкапом - да, есть проблемы. Впрочем, бэкап на 10TB и для Оракла не очень разумен.
Ну, будем честными, мультимастер в Оракле тоже сомнительная вещи и для обработки транзакций не очень пригоден. Да и PG вполне справляется с процессингом на десятки миллионов активных пользователей - если нормально готовить.
А в RMQ не упираетесь? Там же даже 100K сообщений в секунду вытащить нетривиально. Да и надежность он не особо добавляет, скорее наоборот (особенно если на векторе включить буферизацию)
Хм, 1GB чистых логов в сутки (не в ELK, а строчек) превращается где-то в 100MB внутри того же Clickhouse, т.е. 3GB в месяц, 300GB со всех компонент, еще и SSD не нужен. Это совсем копейки.
Ретеншен в год нужен не для всех логов, а для некоторой части, что в том же CH тривиально реализуется через matview.
Т.е. проблема не в объеме логов, а в использовании неудачных (эластик) инструментов работы с ними. Все-таки ES создавался совсем для других задач.
Хм, мой процесс работы с C1 предполагает
1) работаем с файлами RAW на диске
2) после обработки папки - делаем экспорт в JPG в архив для просмотра
3) после обработки файла - скидываем все без кэша в архив
И вот результат 2 и 3 летят в архив и в облако, реализуется простеньким rsync.
Но, конечно, Dropbox - не лучший вариант для хранения фотографий (дорого и неудобно).
Охх, статья скорее вредная.
Путается техническая конфигурация и бизнес-конфигурация, плюсы и минусы форматов никак не связаны с реальностью, перепутано хранение секретов и конфигурации, куча вредных советов по работе с конфигами.
Статья была бы хороша для начинающих, но в текущем виде скорее вредна для начинающих (
А почему на продакшене debug дорого?
Да, если несколько десятков тысяч rps - то debug на каждом запросе будет дороговато. Но для средних проектов в 10-100rps (т.е. даже debug в пределах 200k строк в секунду) на нормальном стеке (не ELK) все достаточно недорого.
Второй совет скорее вреден. Технологии в совете 8 или не могут быть использованы в РФ или устарели. Общий уровень советов уровня джуниора.
Интересно, как можно относиться всерьез к курсам компании, публикуещей настолько слабые статьи?
Принципиальное отличие ролей "техлида" и "тимлида" нужно далеко не для всех деятельностей. Да даже в IT в некоторых командах не нужен тимлид, в некоторых - техлид, в некоторых - ни тот ни другой (но нужны специалисты вне команды - про людей, процессы и так далее).
Единой правильной картинки нет. Но без разделения ролей и активностей нарисовать подходящую картинку для конкретных людей в конкретном проекте - тоже не получится.
Это опять про разницу между techlead и teamlead.
Техлид - да, тоже разработчик.
Тимлид - про процессы, людей, приоритеты, коммуникации, т.е. совсем другие компетенции.
Очень большая проблема процессов во множестве компаний - это смешивание техлида и тимлида в одном человеке. В результате ничего хорошего не получается.
Хм, а ты не путаешь teamlead и techlead?
Впрочем, в нормальных процессах teamlead вообще не нужен, а вот techlead - да, старший разработчик.
В какой-то момент мне показалось, что это такая пародия на архитектурные документы.
Очень много длинных слов, очень много воды, очень много ненужных деталей - и очень мало содержания.
Но, боюсь, что это всерьез - и это грустно (
Хм, в старых проектах - да. И нет, MS SQL не является альтернативой Ораклу (не больше, чем PG). Но для новых проектов выбор БД - не очень простая задача, так как много вариантов.
Ну, а зачем переводить с Oracle на PG один к одному со всеми запросами и логикой. Обычно за годы эксплуатации становится понятно, как можно сделать лучше и проще. Не очень верю в систему на 160 TB, которая не накопила кучу легаси и сомнительных решений и которую нельзя сделать более удобной.
А при чем тут облака? Тут сравнивают PG или Oracle, причем исключительно в on-prem. А для on-prem разницы в стоимости дисков для БД или для S3 - нет никакого, это просто диски.
А что в каких-то публичных облаках нет других механизмов хранения файлов, кроме S3 - не делает S3 каким-то особенно дешевым способом.
И это если не вспоминать, что S3 - просто семейство протоколов для хранения LOBов и стоимость хранения очень зависит от реализации. Где-то подешевле, где-то сильно дороже.
Да и Data Lake и BI - не обязательно связаны с S3 (собственно, почти всегда не связаны с S3).
Хм, почему не дешевле Оракла?
Админы дешевле, лицензии дешевле. Да, если покупать PgPro - то будет дороже. Но, вообще говоря, смысл покупать PgPro возникает довольно редко и не связан с технологическими особенностями.
А надежность и большие объемы данных требуют вообще других решений, не про PG и не про Oracle )
Хм, а зачем в телекоме Оракл? Те задачи, что в телекоме требуют реляционной БД - потянет и PG. А те, что не потянут - не реляционные )
В финтехе, в общем, та же ситуация )
MVCC появился в 1999 году, довольно давно )
Вообще, могли бы и 25 лет отпраздновать...
Хм, переносить логику с Oracle на PG - плохая идея. Новая БД требует новых подходов к разработке, так что если запросы Оракла плохо работают на PG - не говорит о проблемах PG, только о проблемах перехода с Oracle.
С бэкапом - да, есть проблемы. Впрочем, бэкап на 10TB и для Оракла не очень разумен.
Для PG еще очень дешево можно найти поддержку 24*7 и вообще не нанимать DBA. Для Оракла 24*7 стоит безумных денег (
И чем хранение в S3 дешевле базы? S3 - те же файлы, та же дисковая подсистема, откуда там выигрыш в стоимости-то может появиться?
Ну, будем честными, мультимастер в Оракле тоже сомнительная вещи и для обработки транзакций не очень пригоден. Да и PG вполне справляется с процессингом на десятки миллионов активных пользователей - если нормально готовить.
А в RMQ не упираетесь? Там же даже 100K сообщений в секунду вытащить нетривиально.
Да и надежность он не особо добавляет, скорее наоборот (особенно если на векторе включить буферизацию)