Мы запускаем и грохаем свои кластеры так часто, что это не имеет значения)))
А всё о чем вы говорите просится как продолжение статьи, ведь в этой мы говорим как раз о моменте до. До того, как кластер запущен. И после этого момента начинается совсем другая жизнь.
Вопреки мнению многих про низкое качество кода, полученного от LLM еще раз повторю три важных тезиса статьи:
Что попросил, то и получил, поэтому просить нужно правильно. Это вы указали, но поделюсь парой наблюдений:
помогает просить сначала архитектуру, потом пошаговую реализацию компонентов;
помогает просить сначала тесты (и их надо отревьювить самому), а потом имплементацию;
помогает после неудачного вывода подправить промпт с учетом особенностей, в которых нейронка лажает.
Необходимость ручного ревью никто не отменял, именно в понимании того, какое должно быть решение. В многократном ревью, чтобы код стал как будто своим, и лежит вопрос качества.
Владеть кодом (пусть и сгенерированным) — критически важно. Это буквально знать его и понимать, как он работает.
В целом, практика такая: если сеть не справилась с чем-то, можно либо уточнить задание по разработке компонента (тут все сильно пляшет по архитектуре) либо попросить с нуля, и, возможно — другую сеть.
Это примеры масштабных и зрелых проектов с качественной кодовой базой. А откуда конкретно нейросеть взяла веса для CRUD на Go одному Тьюрингу известно.
Еще не успели покодить, но на вопросы отвечает бодро. 1м токенов выглядит как заявка на победу, а судя по цене, очень похоже, что Anthropic, Google и OpenAI вступили в ценовую войну.
Новые модели сейчас выходят каждую неделю, но знаково, что они научились нормально кодить.
Почти на все ваши вопросы ответ есть в тексте статьи. Итераций — 108. Среднее — это среднее арифметическое, но на графиках можно и разброс увидеть. Время отклика считает сам pgbench.
Почему мы уверены, что таких таблиц хватит для теста? База с выбранным нами сайзингом занимала порядка 2ГБ. Мы специально выбрали такой размер, чтобы он не был ограничением.
Что понимать под производительностью — очевидно, основной продукт СУБД — количество выполненных транзакций за период времени (секунда). Это, по сути, сколько запросов сможет переваривать приложение.
Latancy — второй фактор, играющий значение для веб-приложений, сайтов и различных бэкендов. Это задержка, которая добавляется ко времени ответа приложения клиенту.
Конечно, можно представить и другие сценарии использования СУБД (например, аналитика). Тут — тяжелые джоины и сложные операции, а также скорость записи (если мы собираем данные в ту же базу, где и анализируем).
Но нам для теста вполне достаточно сценария веб-сервера.
Согласен с Вами. Всячески стараемся не допустить у себя появления этих симптомов даже в зародыше.
По непонятной никому причине 4 сообщения 08.03 не были доставлены (отмечено в ЛК СМС-шлюза). Все примерно в одно время и к одному оператору. Скажу честно, мне регистрация по СМС не очень нравится, но это не наша дурь/прихоть, а требование регулятора, и полностью исключить ее не получится.
Поэтому логику регистрации поменяли на email, а телефон подтверждаем уже на втором шаге, перед первым запуском любого сервиса. Сейчас тестируем, скоро накатим на прод.
У Scala есть прекрасно реализованная акторная модель (Akka/Pekko), например, первое где у нас пригодилась Scala - это сервис баланса. Данные у него Strict Consistency (живут прямо в памяти). Масштабируется отлично. А главное — реализуется просто. Еще одно место, где проще было со Scala — контроллер, который в реальном времени управляет каждой единицей ресурсов. Тоже на акторах.
В целом, я согласен, что Go ничуть не хуже в большинстве случаев, собственно, потому мы его и затащили.
Изначально я владел плюс ещё пара человек в команде. Когда MVP делали после ухода с Опенстека, как раз на Скале получилось в несколько сотен тысяч раз быстрее. В итоге в новой системе оркестрации останется Scala-ядро, и вокруг него много Go-сервисов.
Понял, про бизнес-модель. Про неё расскажем. Часть чисел, естественно, не очень открытая, там примерно будет про порядки. Но в целом это планируемый пост как раз. И, опять же, надо понимать, что план — это одно, а реальность — другое, нужен ещё второй пост "а как по факту получилось", а не только "как хотели".
Все от кейса зависит. Часто CA делается на год.
Вообще ротация сертификатов это отдельная тема. Как и любой пункт статьи — можно прям копать вглубь на целую книгу.
Мы запускаем и грохаем свои кластеры так часто, что это не имеет значения)))
А всё о чем вы говорите просится как продолжение статьи, ведь в этой мы говорим как раз о моменте до. До того, как кластер запущен. И после этого момента начинается совсем другая жизнь.
Вопреки мнению многих про низкое качество кода, полученного от LLM еще раз повторю три важных тезиса статьи:
Что попросил, то и получил, поэтому просить нужно правильно. Это вы указали, но поделюсь парой наблюдений:
помогает просить сначала архитектуру, потом пошаговую реализацию компонентов;
помогает просить сначала тесты (и их надо отревьювить самому), а потом имплементацию;
помогает после неудачного вывода подправить промпт с учетом особенностей, в которых нейронка лажает.
Необходимость ручного ревью никто не отменял, именно в понимании того, какое должно быть решение. В многократном ревью, чтобы код стал как будто своим, и лежит вопрос качества.
Владеть кодом (пусть и сгенерированным) — критически важно. Это буквально знать его и понимать, как он работает.
В целом, практика такая: если сеть не справилась с чем-то, можно либо уточнить задание по разработке компонента (тут все сильно пляшет по архитектуре) либо попросить с нуля, и, возможно — другую сеть.
С задачей написать агента, читающего топик kafka и взаимодействующего с libvirt на уровне сокетов они тоже справляются.
Это примеры масштабных и зрелых проектов с качественной кодовой базой. А откуда конкретно нейросеть взяла веса для CRUD на Go одному Тьюрингу известно.
Еще не успели покодить, но на вопросы отвечает бодро. 1м токенов выглядит как заявка на победу, а судя по цене, очень похоже, что Anthropic, Google и OpenAI вступили в ценовую войну.
Новые модели сейчас выходят каждую неделю, но знаково, что они научились нормально кодить.
Да, дефолтный пользователь имеет лимит в 50 подключений.
Совершенно зря.
Вот такой диск взяли у VK.
pgbench даже простой селект считает транзакцией (тут под транзакцией имеется в виду любой запрос к БД).
Поэтому мы и предлагаем каждому тестировать БД под свои нагрузки, а наш тест — это скорее ориентир.
Да, сейчас перепроверили, у Яндекса это спрятано очень глубоко (привет дарк-паттернам).
Спасибо, поправил.
Почти на все ваши вопросы ответ есть в тексте статьи. Итераций — 108. Среднее — это среднее арифметическое, но на графиках можно и разброс увидеть. Время отклика считает сам pgbench.
Почему мы уверены, что таких таблиц хватит для теста? База с выбранным нами сайзингом занимала порядка 2ГБ. Мы специально выбрали такой размер, чтобы он не был ограничением.
Что понимать под производительностью — очевидно, основной продукт СУБД — количество выполненных транзакций за период времени (секунда). Это, по сути, сколько запросов сможет переваривать приложение.
Latancy — второй фактор, играющий значение для веб-приложений, сайтов и различных бэкендов. Это задержка, которая добавляется ко времени ответа приложения клиенту.
Конечно, можно представить и другие сценарии использования СУБД (например, аналитика). Тут — тяжелые джоины и сложные операции, а также скорость записи (если мы собираем данные в ту же базу, где и анализируем).
Но нам для теста вполне достаточно сценария веб-сервера.
Согласен с Вами. Всячески стараемся не допустить у себя появления этих симптомов даже в зародыше.
По непонятной никому причине 4 сообщения 08.03 не были доставлены (отмечено в ЛК СМС-шлюза). Все примерно в одно время и к одному оператору. Скажу честно, мне регистрация по СМС не очень нравится, но это не наша дурь/прихоть, а требование регулятора, и полностью исключить ее не получится.
Поэтому логику регистрации поменяли на email, а телефон подтверждаем уже на втором шаге, перед первым запуском любого сервиса. Сейчас тестируем, скоро накатим на прод.
У Scala есть прекрасно реализованная акторная модель (Akka/Pekko), например, первое где у нас пригодилась Scala - это сервис баланса. Данные у него Strict Consistency (живут прямо в памяти). Масштабируется отлично. А главное — реализуется просто. Еще одно место, где проще было со Scala — контроллер, который в реальном времени управляет каждой единицей ресурсов. Тоже на акторах.
В целом, я согласен, что Go ничуть не хуже в большинстве случаев, собственно, потому мы его и затащили.
Да. А вы разве нет?
Изначально я владел плюс ещё пара человек в команде. Когда MVP делали после ухода с Опенстека, как раз на Скале получилось в несколько сотен тысяч раз быстрее. В итоге в новой системе оркестрации останется Scala-ядро, и вокруг него много Go-сервисов.
Перед тем, как строиться масштабно — мы сделали Proof-of-Concept. Походили по рынку, и поняли, что да, конкурировать реально и очень даже нужно!
Опять-же: про экономику, маркетинговые и продуктовые стратегии — сейчас озвучивать не стану, но в будущем обязательно поделюсь чем возможно.
Да, простите, это заглушка, мы же ещё не запустились в бой. Через несколько дней сделаем нормально.
Понял, про бизнес-модель. Про неё расскажем. Часть чисел, естественно, не очень открытая, там примерно будет про порядки. Но в целом это планируемый пост как раз. И, опять же, надо понимать, что план — это одно, а реальность — другое, нужен ещё второй пост "а как по факту получилось", а не только "как хотели".