Forwarded from DevFM
В статье Анатомия GNU/Linux (хабр, 2020) просто и понятно описываются такие составляющие операционной системы, как
— загрузчик
— ядро
— начальный образ загрузки
— init
— командная оболочка
— графический сервер
— дисплейный менеджер
— окружение рабочего стола
И всякое разное другое. На картинке представлена схема взаимосвязи упомянутых в статье сущностей
— загрузчик
— ядро
— начальный образ загрузки
— init
— командная оболочка
— графический сервер
— дисплейный менеджер
— окружение рабочего стола
И всякое разное другое. На картинке представлена схема взаимосвязи упомянутых в статье сущностей
Forwarded from Arseniy Trushin
Помогите, пожалуйста, разобрать кейс (Гугл, Цюрих, 2018). Задача на систем-дизайн.
* Есть файл в 4Гб - полная карта. Есть программа, которой можно скормить этот файл, ширину, долготу и язык. Программа за 5 минут сгенерирует локализованную вырезку из карты. Раз в месяц 4Гб файл обновляется. Как сделать систему, доставляющую локализованные "вырезки" на мобильные устройства?
Мне интересен вариант ответа на этот систем-дизайн вопрос "по полной программе":
* Какие вопросы нужно было бы задать интервьюру, если он задал эту задачу?
* Какие оценки "на обратной стороне конверта" нужно здесь делать?
* Как выглядит вся система?
* Какие компромиссы можно здесь обсуждать? Какие варианты можно рассматривать?
У меня есть ещё несколько такого рода задач с разных интервью, которые хотелось бы "по косточкам" разобрать.
* Есть файл в 4Гб - полная карта. Есть программа, которой можно скормить этот файл, ширину, долготу и язык. Программа за 5 минут сгенерирует локализованную вырезку из карты. Раз в месяц 4Гб файл обновляется. Как сделать систему, доставляющую локализованные "вырезки" на мобильные устройства?
Мне интересен вариант ответа на этот систем-дизайн вопрос "по полной программе":
* Какие вопросы нужно было бы задать интервьюру, если он задал эту задачу?
* Какие оценки "на обратной стороне конверта" нужно здесь делать?
* Как выглядит вся система?
* Какие компромиссы можно здесь обсуждать? Какие варианты можно рассматривать?
У меня есть ещё несколько такого рода задач с разных интервью, которые хотелось бы "по косточкам" разобрать.
Forwarded from Mike
Привет, сколько пользователей и какой профиль нагрузки, где находятся пользователи? Какие требования по отказоустойчивости? Какой размер ответа? Есть ли ограничения? Сколько ресурсов потребляет программа? Может ли она падать? Какие SLO на время ответа и availability? Необходимо ли масштабироваться?
Можно различные расчеты произвести. Например, допустим у нас 10М запросов в день. Одна машина, обрабатывающая запрос, сможет сделать 12*24 (около 300) запросов в сутки, получим количество машин = 10M / 300. Допустим, запрос потребляет полностью одно ядро процессора, тогда средняя машина может выполнить *4 запроса одновременно. Тут добавляем требования отказоустойчивости и размещаем машины в разных датацентрах. Упоминаем какой-нибудь autoscaling, чтобы уменьшить стоимость (профиль нагрузки нам поможет определиться).
В самом простом виде будет такая схема - балансировщик над веб-серверами, которые реализуют такой API: создать запрос на вырезку из карты, прочитать состояние запроса (готов/процент готовности), забрать результат. База данных, которая хранит информацию о запросе (можно хранить kv id-запроса->информация о запросе+результат, зачем что-то сложнее да и масштабироваться проще). Подумать, сколько информации нужно нам хранить и необходимо ли шардировать данные. Очередь задач + обработчики, которые используют карту-4Gb + бинарник. Схема будет примерно такой: пользователь посылает запрос на веб-сервер, который добавляет запись в базу+задачу в очередь сообщений. Воркеры вычитывают очередь, делают работу и размещают данные в базу (обновляют прогресс, если можно или позволяют ресурсы). Клиенты вычитывают информацию (скорее всего polling раз в k секунд). Нотификацию можно приделать, но смысла особого не вижу (клиентам и так придётся ждать 5 минут).
Забыл, тут можно уточнить про кеширование - можно ли результаты запросов использовать повторно (скорее всего, нет)?
Файл в 4Gb хранить прямо на машинах, при изменении раскатывать его физически любым способом, и при обработке поднимать его в память, конечно.
Компромиссов можно много придумать. Хотим нотификации о прогрессе - добавим пуши, улучшим user exp, но усложним систему (железо, поддержка и т.д.) Если результаты тяжелые - давайте хранить результат в отдельном blob-хранилище - уменьшим назрузки с нашей базы, заплатив за использование другого хранилища. Добавьте что-нибудь по вкусу.
Это наброски ответа при наличии отсутствия интервьюера. Надеюсь, что решал ту задачу, которую вы подразумевали 🙂
Можно различные расчеты произвести. Например, допустим у нас 10М запросов в день. Одна машина, обрабатывающая запрос, сможет сделать 12*24 (около 300) запросов в сутки, получим количество машин = 10M / 300. Допустим, запрос потребляет полностью одно ядро процессора, тогда средняя машина может выполнить *4 запроса одновременно. Тут добавляем требования отказоустойчивости и размещаем машины в разных датацентрах. Упоминаем какой-нибудь autoscaling, чтобы уменьшить стоимость (профиль нагрузки нам поможет определиться).
В самом простом виде будет такая схема - балансировщик над веб-серверами, которые реализуют такой API: создать запрос на вырезку из карты, прочитать состояние запроса (готов/процент готовности), забрать результат. База данных, которая хранит информацию о запросе (можно хранить kv id-запроса->информация о запросе+результат, зачем что-то сложнее да и масштабироваться проще). Подумать, сколько информации нужно нам хранить и необходимо ли шардировать данные. Очередь задач + обработчики, которые используют карту-4Gb + бинарник. Схема будет примерно такой: пользователь посылает запрос на веб-сервер, который добавляет запись в базу+задачу в очередь сообщений. Воркеры вычитывают очередь, делают работу и размещают данные в базу (обновляют прогресс, если можно или позволяют ресурсы). Клиенты вычитывают информацию (скорее всего polling раз в k секунд). Нотификацию можно приделать, но смысла особого не вижу (клиентам и так придётся ждать 5 минут).
Забыл, тут можно уточнить про кеширование - можно ли результаты запросов использовать повторно (скорее всего, нет)?
Файл в 4Gb хранить прямо на машинах, при изменении раскатывать его физически любым способом, и при обработке поднимать его в память, конечно.
Компромиссов можно много придумать. Хотим нотификации о прогрессе - добавим пуши, улучшим user exp, но усложним систему (железо, поддержка и т.д.) Если результаты тяжелые - давайте хранить результат в отдельном blob-хранилище - уменьшим назрузки с нашей базы, заплатив за использование другого хранилища. Добавьте что-нибудь по вкусу.
Это наброски ответа при наличии отсутствия интервьюера. Надеюсь, что решал ту задачу, которую вы подразумевали 🙂
Forwarded from Mike
Это характеристика нагрузки. Можно различать распределение запросов по времени в течение дня/недели/месяца, соотношение read:write запросов (или по типам запросов), геораспределенность запросов, роботы/пользователи, десктоп/мобильные. Присутствуют ли traffic spikes? Что-то забыл?
Без обратной связи можно долго гадать, согласен. Можете поделиться своим видением, сообществу, вероятно, будет полезно узнать, как может различаться ответ.
Без обратной связи можно долго гадать, согласен. Можете поделиться своим видением, сообществу, вероятно, будет полезно узнать, как может различаться ответ.
Forwarded from Pattern Guru. Шаблоны проектирования. Архитектура ПО
Шпаргалка по шаблонам проектирования
Описание 23-х шаблонов проектирования из книги "Design Patterns" от Банды четырех. Каждый пункт содержит короткое описание паттерна и UML-диаграмму.
Читать статью
Описание 23-х шаблонов проектирования из книги "Design Patterns" от Банды четырех. Каждый пункт содержит короткое описание паттерна и UML-диаграмму.
Читать статью
Forwarded from Chat Small Data Science for Russian Adventurers
Ну есть умного чего, например гайды https://www.inovex.de/de/blog/prompt-engineering-guide/
Проблема в том, что все эти наборы, рецепты и гайды не сравнивались «в бою». И вот тут соревнование бы подошло.
Проблема в том, что все эти наборы, рецепты и гайды не сравнивались «в бою». И вот тут соревнование бы подошло.
inovex GmbH
Prompt Engineering and Zero-Shot/Few-Shot Learning [Guide] - inovex GmbH
This blog post gives you an overview of prompt engineering, the definition of zero-shot and few-shot learning, and provides a practical guide.
Forwarded from ДНСЙ 🫀
Полезные тулы для визуализации алгоритмов ☺️
https://www.toptal.com/developers/sorting-algorithms
https://visualgo.net/en
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
https://algorithm-visualizer.org/
https://www.toptal.com/developers/sorting-algorithms
https://visualgo.net/en
https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
https://algorithm-visualizer.org/
Toptal
Sorting Algorithms Animations
Animation, code, analysis, and discussion of 8 sorting algorithms on 4 initial conditions.
Forwarded from Roman
Да, Михаил огонь на 146%. Курс его не видел но канал https://www.youtube.com/c/SystemDesignInterview/videos просто 10/10.
Forwarded from Start Career in DS
🐍 Python для анализа данных.
Я тут понял, что в канале не было материалов по изучению питона для новичков.
После ухода курсеры стало совсем печально (раньше часто ссылались на курс от Яндекса и МФТИ).
Перерыл кучу материалов, кажется, вот этот ресурс один из лучших: https://dfedorov.spb.ru/python3/
Тут и базовый Python, и азы библиотек для анализа данных. На скрине приведён скрин части лекций из него :)
А по чему вы изучали/изучаете Python?
Я тут понял, что в канале не было материалов по изучению питона для новичков.
После ухода курсеры стало совсем печально (раньше часто ссылались на курс от Яндекса и МФТИ).
Перерыл кучу материалов, кажется, вот этот ресурс один из лучших: https://dfedorov.spb.ru/python3/
Тут и базовый Python, и азы библиотек для анализа данных. На скрине приведён скрин части лекций из него :)
А по чему вы изучали/изучаете Python?
#couses
Какой-то чувак собрал в одну табличку все бесплатные курсы для вкатывания в DS
Какой-то чувак собрал в одну табличку все бесплатные курсы для вкатывания в DS