Вы как-то обошли стороной GitOps, а я считаю, что это очень важный момент при поддержке сложных систем.
GitOps прекрасно живёт и без куба вместе CI/CD системами. Я не вижу здесь проблемы.
Меня больше беспокоит производительность PostgreSQL в контейнере, насколько она разная при прочих равных?
Без hugepages раз в 10 в некоторых случаях медленнее запросы. Есть даже случай почти 100кратного ускорения для таблицы. Но это почти на уровне эзотерики, потому что я до сих пор не понимаю откуда такой прирост.
Это ключевая проблема производительности. Как ни странно, но для меня это ключевая метрика, потому что напрямую влияет на затраты бизнеса.
И не вздумайте в него лезть напрямую. Это будет большой ошибкой.
Ну для того же кубера без этого не обойтись, но намного проще установка, взять тот же RKE2 от Rancher.
...
Это я ещё не говорю про бэкапы, восстановление, менеджмент пользователей. Для всего нужно писать скрипты рукам, если хочешь по уму.
Вы добавите просто ещё один уровень, а значит требования к поддержке, user management, бэкапам, резервированию, обновлениям...
Если хотя бы часть этих проблем сможет решить оператор, то почему бы не попробовать?
Будет простой обмен одних проблем на другие. Работает этот оператор на тех же принципах, что и Ansible, Terrafrom и т.п. Проблемы там те же.
Ладно, лично я логику понял. Не могу с ней согласиться, но как я уже сказал, это ваш опыт, ваши проблемы.
А какой у вас опыт? Сколько кластеров? Где крутятся, в какой обвязке работают?
Я вынужден работать с кубером с 1.6 версии. Я серёфил на хайпе кубера и openstack'а, потому что работал в консалтинге. При этом мне пришлось написать не один оператор. Поэтому я говорю исходя из опыта работы изнутри (как разработчик операторов) и снаружи (как тот, кто поддерживает кластеры).
Ну т.е. вы собираетесь развернуть кластер более 70 нод и на нём поднимать по контейнеру или как? Допустим вы реализуете через StatefulSet + host network. Какие преимущества поддержки, кроме статуса и логов вы получите?
Есть же гораздо легче варианты вроде Nomad, Docker Swarm, CoreOS, Portainer+Docker. Блин, да всё что угодно подходит на мой взляд гораздо лучше, чем костыляние кубера, который в первую очередь подразумевает работу с эфимерными контейнерами, которые можно легко заскейлить в любой момент. Если говорить за StatefulSet, он там максимально чужеродный, но сделал впервую очередь, чтоб внутри кластера создавать сервисы (ну т.е. вы создаёте БД, сервис с ClusterIP и всякая эфимерщина подключается внутри).
Я не осуждаю - у всех свои экзотические фантазии. Но мне правда интересно, чем лучше такая реализация.
Просто интересно, какого профита вы хотите этим добиться? Постгря такая штука, которая гораздо лучше себя чувствует вне контекста контейнеров. Какая вообще польза от кубера для такого статического деплоя?
Справедливости ради, в защиту автора, задача приложения для знакомств такая же как и у любого другого - срубить деньжат с пользователей. Зачастую, цели бизнеса и пользователей не совпадают.
Ситуация, конечно, утрированная, но не далека от истины. Если пользователи нашли друг друга, то они перестанут приносить доход, пока ищут партнёров. Свингеры не в счёт. Эти кролики в вечном поиске, но их всё же не так много.
Вы никак не сможете средствами кубера балансировать на разные кластеры БД с одного порта. Вам нужно либо поставить какой-то пуллер и ему дать порт, либо вешать кластеры на разные порты.
Именно так. Только надо допилить ручками некоторые вещи, чтобы работало как надо. В интернете полно мануалов. Я хотел статью написать, но руки не доходят. Там очень много нюансов надо объяснять.
Это про конфигурацию или код писать надо?
Да. Там нужно для больших запросов кое-что подправить в конфиге и для автоматического анализа пару-тройку функций написать.
Когда требования постоянно меняются комплексно (т.е. "нам нужен белый автомобиль" поменялось на "нам нужно рыть землю") это смена задачи, а не направления. Здесь скорее gitflow нужен, чтоб спокойно оставить наработки и пойти в другую задачу.
А если в задаче уточнились детали, то тесты вперёд обычно выигрывают, потому что сразу всплывают все места, где нужно внести изменения, при этом не нужно искать что сломалось - оно всё вылазит на поверхность. Более того, при реализации тестов, быстрее возникают вопросы к задаче для уточнения, особенно если задача комплексная. Например, какие заголовки использовать, требования к протоколу передачи данных, формат полей и т.п.
Единственное место, где не нужно и вредно TDD - вёрстка.
Для постгреса есть расширение, которое если немного допилить, то можно собирать даже автоматически запросы и даже explain по ним всем сделать и записать в готовую табличку. Даже эффективнее порой, чем методом пристального взгляда собирать статистику по данным и запросам. Я просто запускал в docker-compose окружение, прогонял тестовые сценарии, потом смотрел табличку с сортировкой по проблемным запросам (время выполнения и наличие seq scan).
TDD в значительной степени подразумевает, что вы должны знать, как ведет себя система, еще до ее реализации. Вы должны знать, что вы делаете.
В большинстве случаев вы этого не знаете. Все разработчики, которых я знаю, не знают этого заранее. Я не знаю этого заранее.
Ужас. Я не хотел бы переходить на личности, но это прям даже звучит дико. Если вы не знаете что пишите, то как пишите? Методом научно-ненаучного тыка? По вдохновению правой пятки? Возможно с таким подходом TDD и правда мешать будет. Возможно проблема не в методологии.
Смысл написания тестов до кода, что тесты проверяют функциональность, которая требуется. Если нет требований, то что конечно тесты не написать. Но говорить о вреде TDD просто потому что у вас процессы... ну мягко скажем не очень, как минимум глупо.
Когда в семье, кроме жены, трое детей, то, благодаря distcc, можно компилировать почти на сотне потоков. Хотя возмущения ребенка о просадке FPS могут потребовать некоторых компромиссов )
А я думал, что это я псих, когда маму на Kubuntu перетащил. Но есть и попсихованнее.
новичку которому нужен линукс лучше начинать с минта
Нее, ну это скучно. Если глаза не красные от того, что неделю пытаешься собрать ядро так, чтобы запустить какую-нибудь экзотическую звуковуху, а домашние, соседи, коллеги и парочка суперкомпьютеров не написали вам гневное письмо, что не надо использовать их ресурсы для того, чтобы пересобрать "мир" с новымы USE-флагами для 1% оптимизации работы, то не уверен, что это вообще линуксовый опыт. Попса какая-то и виндузятничество.
P.S.: Это лютый сарказм, если что, и океан самоиронии про студенческие годы.
Вы мне анекдот напомнили про студента, который выучил материал только про блох.
Сам анекдот
Студент сдает зоологию. Знает только про блох. На экзамене достается вопрос про собак. Судент начинает: - Собаки это млекопитающие, покрыты шерстью. В шерсти водятся блохи... дальше все про блох.... Препод: - Ладно молодой человек, расскажите про кошек Студент: - Кошки это млекопитающие, покрыты шерстью. В шерсти водятся блохи... дальше все про блох.... Препод: - Давайте-ка про рыб Студент: - Рыбы это не млекопитающие. Шерстью не покрыты. Покрыты чешуей, но если бы они были покрыты шерстью, то в ней бы водились блохи....
У вас уже есть одна сеть. Она вполне может заниматься поиском закономерностей. Только хранить варианты решений ей не нужно, она может взять это из долговременной памяти. Понятно, что обработка будет не за один раунд, но это эффективнее, чем содержать сразу две сети. Возможно у вас, конечно же, есть целая система размышлений на этот счёт, которые вы не смогли выразить в статье, но пока что лично для меня вторая сеть выглядит избыточной, просто для того, чтобы хранить какие-то протокольные данные.
Я не перепутал, просто вы не поняли, что я имел ввиду.
Чтобы написать программу, которая умеет отличать гору, нам необходимо запомнить все возможные изображения
Вы в долговременной памяти что хранить-то собрались? Долговременная память хранит набор готовых фактов или... решений. При этом наш мозг устроен так, что мы зачастую имеем свойство брать решения и адаптировать их под слегка изменённые факты. А что вы собрались хранить, я так и не понял ни из статьи, ни из ваших объяснений.
У нас шаблонное мышление, за счёт этого мы не храним петабайты, а только очень короткие данные о фактах и способах решения, а сознание дорисовывает по ним уже всю остальную логику. Т.е. мы не храним абсолютно все ответы на все вопросы. Мы храним принципы, которыми разные задачи решаются. А уже от обстоятельств, мы принимаем решение какой принцип подтянуть и как его натянуть на задачу. Это и делает человека профессионалом или умным, а не "зубрилой".
Собственно, почему я и удивился, что вы так переусложнили. Принцип хранить проще и быстрее, а поиск подходящего принципа может делать и сама сеть (одна единственная). Даже оптимизацию можно применить, сортируя долговременные данные по частоте обращений.
Почему мы используем нейронные сети, а не просто запоминаем огромные выборки?
Так вы задачи перепутали. Процесс поиска в долговременной памяти основан на выборе фактов из памяти, а не на анализе запроса. Поэтому вторая нейронка кажется избыточной. В принципе наша память примерно так же к фактам относиться: мы либо помним, либо нет. А уже сознание выбирает что из памяти вытащить.
На самом деле процесс вспоминания действительно может происходить и за малое количество вопросов, просто длина вектора, содержащий вопрос должна быть большой.
...
Но самым эффективным способом общения, как мне кажется, будет являться передачей неопределенного количества векторов скрытого состояния за одно обращение к сети-памяти - модели обработки последовательностей способны генерировать последовательности такой длины, которая им будет необходима.
Ну вы описали сейчас классический bulk-запрос. По факту это экономит часть ресурсов, но всё равно фактически будет много запросов в одном или двух. Это можно делать и в обычных хранилищах. Там и с разными весами можно работать и много с чем. Так что обучать под это сеть кажется каким-то удалением гланд ректально автогеном.
Ощущение, что в данном случае вторая сеть (память) выглядит оверхедной. С учётом того, что общение будет на собственном языке, то и в качестве хранилища может быть обычный key-value с поправками на поиск и вес. Т.е. условно OpenSearch мог бы вполне быть долговременной памятью, а решение о формате и частоте запоминания может заниматься сеть сознания. Тут самое ключевое это скорость записи и поиска, потому что в процессе воспоминаний будет не условные 3-4 вопроса (вы сильно упростили в статье когнитивный процесс), а сотни 2-3, а на запись и того больше.
При этом уверен, что такой сети нужен будет "сон", чтобы переварить все полученные данные и сделать дамп в долговременную память, потому что процесс обработки и записи явно будет не быстрый. Получается для такой сети потребуется посменная работа двух независимых нейронок.
Сочетание этих фирм и стандарт защиты данных это сюр какой-то. "ИП Дырявые Вёдра" - прям так и пусть назовут свой синдикат.
GitOps прекрасно живёт и без куба вместе CI/CD системами. Я не вижу здесь проблемы.
Без hugepages раз в 10 в некоторых случаях медленнее запросы. Есть даже случай почти 100кратного ускорения для таблицы. Но это почти на уровне эзотерики, потому что я до сих пор не понимаю откуда такой прирост.
Это ключевая проблема производительности. Как ни странно, но для меня это ключевая метрика, потому что напрямую влияет на затраты бизнеса.
И не вздумайте в него лезть напрямую. Это будет большой ошибкой.
Вы добавите просто ещё один уровень, а значит требования к поддержке, user management, бэкапам, резервированию, обновлениям...
Будет простой обмен одних проблем на другие. Работает этот оператор на тех же принципах, что и Ansible, Terrafrom и т.п. Проблемы там те же.
Ладно, лично я логику понял. Не могу с ней согласиться, но как я уже сказал, это ваш опыт, ваши проблемы.
Я вынужден работать с кубером с 1.6 версии. Я серёфил на хайпе кубера и openstack'а, потому что работал в консалтинге. При этом мне пришлось написать не один оператор. Поэтому я говорю исходя из опыта работы изнутри (как разработчик операторов) и снаружи (как тот, кто поддерживает кластеры).
Ну т.е. вы собираетесь развернуть кластер более 70 нод и на нём поднимать по контейнеру или как? Допустим вы реализуете через StatefulSet + host network. Какие преимущества поддержки, кроме статуса и логов вы получите?
Есть же гораздо легче варианты вроде Nomad, Docker Swarm, CoreOS, Portainer+Docker. Блин, да всё что угодно подходит на мой взляд гораздо лучше, чем костыляние кубера, который в первую очередь подразумевает работу с эфимерными контейнерами, которые можно легко заскейлить в любой момент. Если говорить за StatefulSet, он там максимально чужеродный, но сделал впервую очередь, чтоб внутри кластера создавать сервисы (ну т.е. вы создаёте БД, сервис с ClusterIP и всякая эфимерщина подключается внутри).
Я не осуждаю - у всех свои экзотические фантазии. Но мне правда интересно, чем лучше такая реализация.
Просто интересно, какого профита вы хотите этим добиться? Постгря такая штука, которая гораздо лучше себя чувствует вне контекста контейнеров. Какая вообще польза от кубера для такого статического деплоя?
Разница в 600М существенная. Интересно, что они из стандартных пакетов выпилили.
Справедливости ради, в защиту автора, задача приложения для знакомств такая же как и у любого другого - срубить деньжат с пользователей. Зачастую, цели бизнеса и пользователей не совпадают.
Ситуация, конечно, утрированная, но не далека от истины. Если пользователи нашли друг друга, то они перестанут приносить доход, пока ищут партнёров. Свингеры не в счёт. Эти кролики в вечном поиске, но их всё же не так много.
Вы никак не сможете средствами кубера балансировать на разные кластеры БД с одного порта. Вам нужно либо поставить какой-то пуллер и ему дать порт, либо вешать кластеры на разные порты.
Именно так. Только надо допилить ручками некоторые вещи, чтобы работало как надо. В интернете полно мануалов. Я хотел статью написать, но руки не доходят. Там очень много нюансов надо объяснять.
Да. Там нужно для больших запросов кое-что подправить в конфиге и для автоматического анализа пару-тройку функций написать.
Когда требования постоянно меняются комплексно (т.е. "нам нужен белый автомобиль" поменялось на "нам нужно рыть землю") это смена задачи, а не направления. Здесь скорее gitflow нужен, чтоб спокойно оставить наработки и пойти в другую задачу.
А если в задаче уточнились детали, то тесты вперёд обычно выигрывают, потому что сразу всплывают все места, где нужно внести изменения, при этом не нужно искать что сломалось - оно всё вылазит на поверхность. Более того, при реализации тестов, быстрее возникают вопросы к задаче для уточнения, особенно если задача комплексная. Например, какие заголовки использовать, требования к протоколу передачи данных, формат полей и т.п.
Единственное место, где не нужно и вредно TDD - вёрстка.
Для постгреса есть расширение, которое если немного допилить, то можно собирать даже автоматически запросы и даже explain по ним всем сделать и записать в готовую табличку. Даже эффективнее порой, чем методом пристального взгляда собирать статистику по данным и запросам. Я просто запускал в docker-compose окружение, прогонял тестовые сценарии, потом смотрел табличку с сортировкой по проблемным запросам (время выполнения и наличие seq scan).
Ужас. Я не хотел бы переходить на личности, но это прям даже звучит дико. Если вы не знаете что пишите, то как пишите? Методом научно-ненаучного тыка? По вдохновению правой пятки? Возможно с таким подходом TDD и правда мешать будет. Возможно проблема не в методологии.
Смысл написания тестов до кода, что тесты проверяют функциональность, которая требуется. Если нет требований, то что конечно тесты не написать. Но говорить о вреде TDD просто потому что у вас процессы... ну мягко скажем не очень, как минимум глупо.
Внуки, видимо, в steam не умеют, раз шугаются. Или привыкли пиратить, откуда и проблемы были.
А я думал, что это я псих, когда маму на Kubuntu перетащил. Но есть и попсихованнее.
Нее, ну это скучно. Если глаза не красные от того, что неделю пытаешься собрать ядро так, чтобы запустить какую-нибудь экзотическую звуковуху, а домашние, соседи, коллеги и парочка суперкомпьютеров не написали вам гневное письмо, что не надо использовать их ресурсы для того, чтобы пересобрать "мир" с новымы USE-флагами для 1% оптимизации работы, то не уверен, что это вообще линуксовый опыт. Попса какая-то и виндузятничество.
P.S.: Это лютый сарказм, если что, и океан самоиронии про студенческие годы.
Вы мне анекдот напомнили про студента, который выучил материал только про блох.
Сам анекдот
Студент сдает зоологию. Знает только про блох. На экзамене
достается вопрос про собак. Судент начинает:
- Собаки это млекопитающие, покрыты шерстью. В шерсти водятся блохи...
дальше все про блох....
Препод:
- Ладно молодой человек, расскажите про кошек Студент:
- Кошки это млекопитающие, покрыты шерстью. В шерсти водятся блохи...
дальше все про блох....
Препод:
- Давайте-ка про рыб Студент:
- Рыбы это не млекопитающие. Шерстью не покрыты. Покрыты чешуей, но если
бы они были покрыты шерстью, то в ней бы водились блохи....
У вас уже есть одна сеть. Она вполне может заниматься поиском закономерностей. Только хранить варианты решений ей не нужно, она может взять это из долговременной памяти. Понятно, что обработка будет не за один раунд, но это эффективнее, чем содержать сразу две сети. Возможно у вас, конечно же, есть целая система размышлений на этот счёт, которые вы не смогли выразить в статье, но пока что лично для меня вторая сеть выглядит избыточной, просто для того, чтобы хранить какие-то протокольные данные.
Вы в долговременной памяти что хранить-то собрались? Долговременная память хранит набор готовых фактов или... решений. При этом наш мозг устроен так, что мы зачастую имеем свойство брать решения и адаптировать их под слегка изменённые факты. А что вы собрались хранить, я так и не понял ни из статьи, ни из ваших объяснений.
У нас шаблонное мышление, за счёт этого мы не храним петабайты, а только очень короткие данные о фактах и способах решения, а сознание дорисовывает по ним уже всю остальную логику. Т.е. мы не храним абсолютно все ответы на все вопросы. Мы храним принципы, которыми разные задачи решаются. А уже от обстоятельств, мы принимаем решение какой принцип подтянуть и как его натянуть на задачу. Это и делает человека профессионалом или умным, а не "зубрилой".
Собственно, почему я и удивился, что вы так переусложнили. Принцип хранить проще и быстрее, а поиск подходящего принципа может делать и сама сеть (одна единственная). Даже оптимизацию можно применить, сортируя долговременные данные по частоте обращений.
Так вы задачи перепутали. Процесс поиска в долговременной памяти основан на выборе фактов из памяти, а не на анализе запроса. Поэтому вторая нейронка кажется избыточной. В принципе наша память примерно так же к фактам относиться: мы либо помним, либо нет. А уже сознание выбирает что из памяти вытащить.
Ну вы описали сейчас классический bulk-запрос. По факту это экономит часть ресурсов, но всё равно фактически будет много запросов в одном или двух. Это можно делать и в обычных хранилищах. Там и с разными весами можно работать и много с чем. Так что обучать под это сеть кажется каким-то удалением гланд ректально автогеном.
Выбор дистра конечно впечатляет... Надо было Gentoo, чтоб прям сразу deep dive. Самое то для новичка (нет!).
Ощущение, что в данном случае вторая сеть (память) выглядит оверхедной. С учётом того, что общение будет на собственном языке, то и в качестве хранилища может быть обычный key-value с поправками на поиск и вес. Т.е. условно OpenSearch мог бы вполне быть долговременной памятью, а решение о формате и частоте запоминания может заниматься сеть сознания. Тут самое ключевое это скорость записи и поиска, потому что в процессе воспоминаний будет не условные 3-4 вопроса (вы сильно упростили в статье когнитивный процесс), а сотни 2-3, а на запись и того больше.
При этом уверен, что такой сети нужен будет "сон", чтобы переварить все полученные данные и сделать дамп в долговременную память, потому что процесс обработки и записи явно будет не быстрый. Получается для такой сети потребуется посменная работа двух независимых нейронок.