Для нас, это связка Шапрей + PostgreSQL. Шапрей – сервис для хранения соотвествия шард-пользователь. В конце статьи есть ссылочка на youtube-видео про него.
нет (своего) шардирования
Да, это так. Про путь шардирования в Диске (от встроенного в монгу к шарпею+pg) есть такая статья
Что означают пересечения связей с и без прямоугольничков? Мои предположения не дали нормального ответа.
Прямоугольнички показывают что эти связи проходят мимо друг друга. То есть линия отправки push уведомления идёт из подсистемы отправки пушей в сторону клиента и стрелочка пересекала другие линии. Хотелось показать, что пересечение – это просто огрехи схемы. На самом деле есть как минимум два прямоугольничка, без которых можно было бы обойтись "погнув" линии связей сильнее, но получилось как получилось.
И сколько получают ваши еноты за такое? Хотя бы молоко за вредность даёте им?)
Молоко всегда есть на кофепоинтах) У нас есть процесс для повышения надёжности, чтобы енотам ничего не вредило. Недавно как раз Игорь Обручев рассказывал про это в видео.
Были ли случаи ошибок/проблем при миграции, так что ту сагу приходилось откатывать и срочно фиксить проблему? Или еноты не пострадали?
Мы нашли непротестированные автоматикой сценарии на нулевом этапе выкатки, когда выкатили только код и включили его на тестировщиков и тестовые аккаунты разработчиков. Мы поняли что есть недописанные автотесты на кейсы, когда гость в эксперименте, а владелец нет. И наоборот. Вот это пришлось дополнительно описывать, тестировать, фиксить места где что-то было не так. Таким образом код довольно долго не был включён на реальных пользователей. Потом мы очень медленно повышали процент, но откатывать не приходилось. Возможность "дёрнуть рубильник" была вплоть до последнего процента.
Да, первый вариант действительно ближе к тому что есть на самом деле – добавили несколько шардов, провели им миграции схемы БД и после этого в координаторе указали их как доступные для пользователей. Бывает так, что новые шарды добавляются чтобы разгрузить какие-то слишком загруженные, тогда нужно ещё мигрировать часть пользователей с загруженных шардов)
Поэтому да, у нас отсутствует обязательный процесс "добавили шард – надо переселить вот такой-то процент пользователей с вот таких-то шардов, а то функция сопоставления ключ-шард поломается", зато и гибкость выше – можно перевезти именно пользователей с тех шардов, на которые сейчас нагрузка выше и например больше места занято.
Статья конечно не совсем про скорость загрузки) Файлы загружаются в отдельный сервис для хранения бинарных данных, а в нашей БД хранятся ссылки на эти файлы.
Скорость загрузки определяется не только исходящим каналом от клиента, но и
- количеством активных клиентов
- настройками QoS и другими методами шейпинга трафика для гарантированной полосы пропускания
- роутингом трафика из провайдера точки тестирования до провайдера точки хранения. Для больших файлов это конечно меньше влияет, но на маленьких могут быть особенности)
В целом, со стороны Диска настройки подобраны так, чтобы обеспечивать высокую скорость параллельной загрузки тысячами клиентов, так как стабильная скорость для большинства загрузок для нас важнее пиковой для некоторых.
Интересно было бы подробней узнать про методику тестирования – как измеряли скорость в разные облачные хранилища)
везде где вводится пароль просто нельзя взять и сбросить раскладку на английскую
В макос так и есть. Во всех системных местах ввода паролей (log screen, повышение полномочий при установке программ и тд) раскладка сама переключается на английский. Наверное это можно отключить, чтобы выстрелить себе в ногу, но я никогда так не заморачивался.
Ну в этом случае да, k8s можно использовать скорее в образовательных целях)
Я пока что использую Swarm, K8s для моих проектов выглядит слишком большим решением. Тоже считаю, что рановато Swarm хоронить)
Мне кажется Swarm и k8s — это разные масштабы. То есть если проект растёт постепенно, от одной машины к десятку — Swarm хорошее решение. Сначала пишем dockerfile для каждого подпроекта, потом compose, потом практически меняем версию композ файла и добавляем описание ресурсов/тэгов. Понятно как расти.
Если есть раскатанное на сотню серверов решение, то лучше внедрять k8s. Гугл же это делал для своего кейса. Может у вас в проекте было не так много серверов, что особой радости от перехода на куберы не случилось? Ну или апдейты продукта не настолько частые например.
Минусую, если есть политика в посте. На техническом ресурсе это для меня выглядит как желание автора скрыть свой низкий технический уровень. Если проблема интересная и пост полезный — отсылки на личное мнение по политическим вопросам просто не нужно.
Для того, чтобы посмотреть и проверить есть Live образы. Не нужно ничего ставить: воткнул флешку, перезагрузил и попробовал как оно. Я так в своё время, лет 10 назад, сделал с Sony vaio и перешёл на mint. С тех пор ставил его даже на Mac Pro (который «урна») — все нужные устройства всегда подхватывались без моего вмешательства. Если даже в Linux mint что-то не работало автоматом, то потом добавить обычно боль. Так что с точки зрения такого редкоземельного железа, я бы потестил live флешку и если бы устроила поддержка, то начал бы продумывать переход.
Никаких понтов, такое уже было в «Ложной слепоте» Питера Уоттса. Там в конце здоровенный список литературы по темам, затронутым в книге (от биологии до проблемы сознания).
А что с маками не так?
Макбук про 13" например на немецком Apple.com стоит 1500€ (по сегодняшнему курсу 113550₽), на русском Apple.com такой же 110000₽. Аналогичная ситуация с парой других моделей, которые посмотрел.
На одной из новых машин ставил 18.04 и тоже наткнулся на отсутствие /etc/network/interfaces. Решается установкой ifupdown и выпиливанием nplan и netplan.io.
Можно было бы оставить netplan, но переписывать шаблонные конфиги под новую сетевую утилиту – не было желания и времени.
Мне кажется по той же причине, почему в роутерной виртуалке 16.04 а не 18.04. Время на изучение нового инструмента тоже нужно затратить. Свои особенности есть у каждого окружения. RouterOS на мой взгляд требует гораздо больше сетевых навыков, чем Ubuntu в плане настройки сети. Ну или я просто уже сам привык делать также как автор, а ни один микротик мне так и не удалось настроить.
DNS чаще всего открыты на вполне определённые IP адреса (которые выдаются в DHCP).
Остальные соединения чаще всего просто дропаются, а соединения на 80 порт редиректятся на кэптив.
Так чтобы были просто разрешены все запросы на 53 порт — с таким не сталкивался у вендоров WiFi оборудования.
Мне кажется стандартное на диаграммах что-то такое)
Рисунок был сделан, а потом перерисован уже не мной, так что конечная схема не уверен в чём сделана)
Сейчас вроде почти все диаграммостоители умеют, если правильно всё соединить – к "маячкам", а не просто к координатам)
Для нас, это связка Шапрей + PostgreSQL. Шапрей – сервис для хранения соотвествия шард-пользователь. В конце статьи есть ссылочка на youtube-видео про него.
Да, это так. Про путь шардирования в Диске (от встроенного в монгу к шарпею+pg) есть такая статья
Прямоугольнички показывают что эти связи проходят мимо друг друга. То есть линия отправки push уведомления идёт из подсистемы отправки пушей в сторону клиента и стрелочка пересекала другие линии. Хотелось показать, что пересечение – это просто огрехи схемы. На самом деле есть как минимум два прямоугольничка, без которых можно было бы обойтись "погнув" линии связей сильнее, но получилось как получилось.
Молоко всегда есть на кофепоинтах) У нас есть процесс для повышения надёжности, чтобы енотам ничего не вредило. Недавно как раз Игорь Обручев рассказывал про это в видео.
Мы нашли непротестированные автоматикой сценарии на нулевом этапе выкатки, когда выкатили только код и включили его на тестировщиков и тестовые аккаунты разработчиков. Мы поняли что есть недописанные автотесты на кейсы, когда гость в эксперименте, а владелец нет. И наоборот. Вот это пришлось дополнительно описывать, тестировать, фиксить места где что-то было не так. Таким образом код довольно долго не был включён на реальных пользователей. Потом мы очень медленно повышали процент, но откатывать не приходилось. Возможность "дёрнуть рубильник" была вплоть до последнего процента.
Очень круто, что показан путь)
Подскажите, а как быть с миграциями? Alembic автоматом поддержит в случае совместимости с SQLAlchemy? Или туда тоже пулл реквест понадобится?)
Да, первый вариант действительно ближе к тому что есть на самом деле – добавили несколько шардов, провели им миграции схемы БД и после этого в координаторе указали их как доступные для пользователей. Бывает так, что новые шарды добавляются чтобы разгрузить какие-то слишком загруженные, тогда нужно ещё мигрировать часть пользователей с загруженных шардов)
Поэтому да, у нас отсутствует обязательный процесс "добавили шард – надо переселить вот такой-то процент пользователей с вот таких-то шардов, а то функция сопоставления ключ-шард поломается", зато и гибкость выше – можно перевезти именно пользователей с тех шардов, на которые сейчас нагрузка выше и например больше места занято.
Спасибо за вопрос)
Статья конечно не совсем про скорость загрузки) Файлы загружаются в отдельный сервис для хранения бинарных данных, а в нашей БД хранятся ссылки на эти файлы.
Скорость загрузки определяется не только исходящим каналом от клиента, но и
- количеством активных клиентов
- настройками QoS и другими методами шейпинга трафика для гарантированной полосы пропускания
- роутингом трафика из провайдера точки тестирования до провайдера точки хранения. Для больших файлов это конечно меньше влияет, но на маленьких могут быть особенности)
В целом, со стороны Диска настройки подобраны так, чтобы обеспечивать высокую скорость параллельной загрузки тысячами клиентов, так как стабильная скорость для большинства загрузок для нас важнее пиковой для некоторых.
Интересно было бы подробней узнать про методику тестирования – как измеряли скорость в разные облачные хранилища)
В макос так и есть. Во всех системных местах ввода паролей (log screen, повышение полномочий при установке программ и тд) раскладка сама переключается на английский. Наверное это можно отключить, чтобы выстрелить себе в ногу, но я никогда так не заморачивался.
Я пока что использую Swarm, K8s для моих проектов выглядит слишком большим решением. Тоже считаю, что рановато Swarm хоронить)
Мне кажется Swarm и k8s — это разные масштабы. То есть если проект растёт постепенно, от одной машины к десятку — Swarm хорошее решение. Сначала пишем dockerfile для каждого подпроекта, потом compose, потом практически меняем версию композ файла и добавляем описание ресурсов/тэгов. Понятно как расти.
Если есть раскатанное на сотню серверов решение, то лучше внедрять k8s. Гугл же это делал для своего кейса. Может у вас в проекте было не так много серверов, что особой радости от перехода на куберы не случилось? Ну или апдейты продукта не настолько частые например.
Минусую, если есть политика в посте. На техническом ресурсе это для меня выглядит как желание автора скрыть свой низкий технический уровень. Если проблема интересная и пост полезный — отсылки на личное мнение по политическим вопросам просто не нужно.
Просто 7 можно получить только ещё раз заплатив) с 6 автоматом не обновится.
А что с маками не так?
Макбук про 13" например на немецком Apple.com стоит 1500€ (по сегодняшнему курсу 113550₽), на русском Apple.com такой же 110000₽. Аналогичная ситуация с парой других моделей, которые посмотрел.
Можно было бы оставить netplan, но переписывать шаблонные конфиги под новую сетевую утилиту – не было желания и времени.
Ждать. Или сразу найти 5–10 клиентов и ждать пока уйдёт один из них.
DNS чаще всего открыты на вполне определённые IP адреса (которые выдаются в DHCP).
Остальные соединения чаще всего просто дропаются, а соединения на 80 порт редиректятся на кэптив.
Так чтобы были просто разрешены все запросы на 53 порт — с таким не сталкивался у вендоров WiFi оборудования.
Думаю Яндекс выложит прошивку в opensource, как только это станет общепринятой практикой. Так что подождём когда это сделают Google, Amazon и Apple.