Интересно 👍 Не совсем понятно, как в случае с conventions.md сочетаются требования «не дублировать информацию из него» и «отразить все главные принципы разработки из документа @vision.md». Ведь без дублирования не обойтись: если изменится vision.md, придётся править и conventions.md. Может, тогда в vision.md оставить только принципы? Что там есть ещё, кроме принципов?
Спасибо за интересную ссылку 👍. Там, кстати, упоминается: «Мы регулярно проводим для команды учения с имитацией падения одного дата‑центра и, как правило, продолжаем совершенствовать систему эксплуатации по итогам таких учений.» Видимо, эти учения совсем не зря — у нас недавно в двух дата‑центрах Hetzner возникли серьёзные проблемы: ⚠️ Outage Load balancer: There are network problems at the LB host nodes in FSN1 and HEL1. Status: Investigating
Собственно, в основном меня интересует вопрос HA по отношению к данным. Понятно, что воркер можно "перетащить", а вот как с данными обстоит дело если из строя выходит один ДЦ, как это отрабатывается на "учениях с имитацией падения одного дата‑центра"?
«…тут нам мешает “тяжёлый” хвост у распределения веса чатов.»
Можно ли здесь подробнее показать модель с цифрами? Например, если имеются миллионы пользователей и десятки тысяч RPS на сервер, то как именно этот «тяжёлый хвост» приводит к ситуации, где на один сервер может внезапно приходить не 10 000, а, допустим 50 000 RPS (или сколько нужно чтобы потребовалась ребалансировка?
Понятно. Не подскажете, как в web-версии присоединить git-репозиторий? Ну т.е. вот я создал новый каталог, а дальше что с ним делать? Какие-то credentials должны вводится...?
Looking for an alternative to GitBook, Mintlify, or typical Static Site Generators (SSGs)?
В такой постановке вопросы - хорошо бы посмотреть более внятный список key differentiators. Ну или сравнительную табличку - у кого что есть, а чего, наоборот, нет.
Ваша уникальность, с первого поверхностного взгляда (vs GitBook):
Local Storage
Multilingual Support?
По-поводу Multilingual Support не уверен. В GitBook есть, но наши Content Creators не очень довольны.
Интересно, спасибо. Уже в XIX веке знали толк в highload’е (турбин).
Есть несколько вопросов, если позволите.
Fanout обрабатывает очень высокую нагрузку — несколько десятков серверов совместно обслуживают более 300 тысяч RPS.
Сколько серверов отведено под воркеры?
Сервер серверу рознь: можно уточнить конфигурацию железа, в частности, количество ядер CPU?
Как обеспечивается HA при outage уровня датацентра?
Далее. Судя по RPS, можно предположить, что количество активных пользователей не менее миллиона. При таком объёме пользователей возникает вопрос: откуда берётся выраженный дисбаланс, требующий регулярной ребалансировки партиций? Казалось бы, статистически должно обеспечиваться более-менее равномерное распределение нагрузки.
Это верно, конечно.
Но ведь если следовать low coupling, и всяким буквочкам типа S, I и D - зачем "всему" влезать в мозги?
Интересно 👍 Не совсем понятно, как в случае с
conventions.mdсочетаются требования «не дублировать информацию из него» и «отразить все главные принципы разработки из документа @vision.md». Ведь без дублирования не обойтись: если изменитсяvision.md, придётся править иconventions.md. Может, тогда вvision.mdоставить только принципы? Что там есть ещё, кроме принципов?Коммитить fix в ветку new-feature а потом pull request + squash.
Вот тут так делали регулярно.
Ну в новую ветку переключаешься да и всё. Возможно, я чего-то не понял...
Мы используем вот такую коллекцию:
Effective Go
Go Proverbs
Rob Pike's Go Proverbs Series:
Part One
Part Two
Part Three)
google.github.io/styleguide/go/decisions.html
10 things you (probably) don't know about Go
Subtests in Go
Go Type System Overview
Давайте чуть более конкретно. Возьмём принципы.
Контекст
Цель
Декомпозиция
Примеры
Роли
Уточнение
Ясность исходников
Пожалуй что без 4 и 5 можно обойтись, но остальное - в той или иной степени неплохо использовать. Что думаете?
Дальнейшее развитие модальности можливости: оценка Anthropic может не превысить 100 миллиардов долларов.
Понятно, т.е. "несколько десятков серверов" не заняты работой по долгосрочному хранению данных ;)
Благодарю за ответы🤝, было интересно.
Парадокс дней рождения возникает как раз из-за того, что испытаний мало а слотов много и кажется, что пересечений по слотам быть не должно.
Тут же имеется парадокс другого характера - испытаний много, слотов мало и, казалось бы, должен работать ЗБЧ и распределение должно быть ранвомерным.
Интересно было бы взглянуть на более конкретную модельку. Когда и в каком виде появляется неравномерность, в числах.
Спасибо за интересную ссылку 👍. Там, кстати, упоминается: «Мы регулярно проводим для команды учения с имитацией падения одного дата‑центра и, как правило, продолжаем совершенствовать систему эксплуатации по итогам таких учений.» Видимо, эти учения совсем не зря — у нас недавно в двух дата‑центрах Hetzner возникли серьёзные проблемы: ⚠️ Outage Load balancer: There are network problems at the LB host nodes in FSN1 and HEL1. Status: Investigating
Собственно, в основном меня интересует вопрос HA по отношению к данным. Понятно, что воркер можно "перетащить", а вот как с данными обстоит дело если из строя выходит один ДЦ, как это отрабатывается на "учениях с имитацией падения одного дата‑центра"?
Можно ли здесь подробнее показать модель с цифрами? Например, если имеются миллионы пользователей и десятки тысяч RPS на сервер, то как именно этот «тяжёлый хвост» приводит к ситуации, где на один сервер может внезапно приходить не 10 000, а, допустим 50 000 RPS (или сколько нужно чтобы потребовалась ребалансировка?
Да, точно, это было в статье. Проглядел.
Да, спасибо, нашёл уже.
del
Понятно. Не подскажете, как в web-версии присоединить git-репозиторий? Ну т.е. вот я создал новый каталог, а дальше что с ним делать? Какие-то credentials должны вводится...?
По поводу
Верно ли это для browser-based version (File System API/OPFS) ? Или что-то типа IndexedDB используется?
Неплохо. Отлично, даже можно сказать.
Но вот по поводу отличий. Вы пишете
В такой постановке вопросы - хорошо бы посмотреть более внятный список key differentiators. Ну или сравнительную табличку - у кого что есть, а чего, наоборот, нет.
Ваша уникальность, с первого поверхностного взгляда (vs GitBook):
Local Storage
Multilingual Support?
По-поводу Multilingual Support не уверен. В GitBook есть, но наши Content Creators не очень довольны.
Интересно, спасибо. Уже в XIX веке знали толк в highload’е (турбин).
Есть несколько вопросов, если позволите.
Сколько серверов отведено под воркеры?
Сервер серверу рознь: можно уточнить конфигурацию железа, в частности, количество ядер CPU?
Как обеспечивается HA при outage уровня датацентра?
Далее. Судя по RPS, можно предположить, что количество активных пользователей не менее миллиона. При таком объёме пользователей возникает вопрос: откуда берётся выраженный дисбаланс, требующий регулярной ребалансировки партиций? Казалось бы, статистически должно обеспечиваться более-менее равномерное распределение нагрузки.
Какие-то проблемы на бэке определённо есть...
Dependency Hell in Microservices:
Зоопарк блоков для построения архитектуры:
Интересно, а как в этом случае обстоит дело с мобильными устройствами?
Спасибо за детальное объяснение! Насколько я понял, оптимизация здесь делится на две части:
Оптимизация хранения лейблов (labelsets)
Оптимизация хранения точек (временных рядов)
Колоночное хранение, DeltaOfDelta, union'ы для in-place значений
Интересно было бы понять границы возможного: какого уровня экономии памяти можно было достичь, используя "обычный" Go.
Вот, например, энкодер/декодер для ID
https://go.dev/play/p/dGYuyrVCoCf
По первой части пока не вижу очевидной необходимости перехода — или я что-то упускаю?
Дык я согласен про числодробилки, но какое отношение это имеет к проблеме:
"например как garbage collector Go будет всё это обрабатывать"
"И кажется, именно поэтому в Prometheus такой подход пока не используют, хотя попытки были"
?