Грузите апельсины бочках. Релизы в Golang проектах

Данная статья является продолжением инструментальной темы затронутой в прошлой публикации. Сегодня мы постараемся разобраться со сборкой релизов Golang приложений в виде единого исполняемого файла, включающего ресурсные зависимости, и вопросом оптимизации размера итоговой сборки. Также рассмотрим процесс построения рабочего окружения отвечающего следующим требованиям:


  1. Переносимость. Окружение должно быть легко воспроизводимо на различных машинах.
  2. Изолированность. Окружение не должно влиять на версии установленных библиотек и программ на машине разработчика.
  3. Гибкость. Окружение должно позволять собирать релизы для различных версий Golang и Linux (разные версии дистрибутивов и glibc).
  4. Повторяемость. Не должно быть магии и тайных знаний, то есть все шаги сборки проекта и зависимостей должны быть описаны кодом.
Читать дальше →

Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) in-memory БД. С Join и полнотекстовым поиском

Всем привет,

Я директор по разработке компании Рестрим. Мы разрабатываем и сопровождаем платформу IPTV/OTT телевидения. У платформы около 10 миллионов пользователей. Платформа первого поколения проектировалась в 2010 году, и была ориентирована в первую очередь на IPTV приставки.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном реляционном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать несколько сотней тысяч RPS на всю систему.

Это означает, что запросы от клиентов и близко не стоит подпускать к реляционной SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш. Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.

...Далее...

Как мы выбирали между Elastic и Tarantool, а сделали свою (самую быструю) inmemory БД. С Join и полнотекстовым поиском

Всем привет,

Я директор по разработке компании Рестрим. Мы разрабатываем и сопровождаем платформу IPTV/OTT телевидения. У платформы около 10 миллионов пользователей. Платформа первого поколения проектировалась в 2010 году, и была ориентирована в первую очередь на IPTV приставки.

С середины 2016 года мы проектируем и разрабатываем новое поколение платформы. Принципиальное отличие от первого поколения — поддержка API "тонкого" клиента. Если старая платформа предполагает, что на клиента при запуске загружается метаинформация о всем контенте, который доступен для абонента, то новая платформа должна отдавать срезы данных отфильтрованные и отсортированы для отображения на каждом экране/странице.

Высокоуровневая архитектура на уровне хранения данных внутри системы — постоянное хранение всех данных в централизованном SQL хранилище. Выбор пал на Postgres, тут никаких откровений. В качестве основного языка для разработки — выбрал golang.

У системы порядка 10м пользователей. Мы посчитали, что с учетом профиля теле-смотрения, 10М пользователей может дать несколько сотней тысяч RPS на всю систему.

Это означает, что запросы от клиентов и близко не стоит подпускать к SQL БД без кэширования, а между SQL БД и клиентами должен быть хороший кэш. Посмотрели на существующие решения — погоняли прототипы. Данных, по современным меркам у нас немного, но параметры фильтрации (читай бизнес-логика) — сложные, и главное персонализированные — зависящие от сессии пользователя, т.е. использовать параметры запроса как ключ кэширования в K-V кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.

...Далее...

GopherCon Russia 2018: конференция пройдет 17 марта в Москве

image

Всем привет!

Радостная новость для всех, кто любит Go — в России будет свой GopherCon с докладами и докладчиками :)

17 марта в Москве выступят Brad Fitzpatrick и Дмитрий Вьюков из Google, Jessie Frazelle из Microsoft и не только. В программе уже 11 отборных выступлений, о которых мы подробно расскажем под катом, а до 20 января еще можно предложить свой доклад в CFP.

Будет два параллельных потока, синхронный перевод в обе стороны в главном зале, огненное афтепати, крутые активности от наших партнеров (привет вам от Gett, JetBrains и Google). Ждем 400 участников, присоединяйтесь и вы!

Итак, что в программе:
Читать дальше →

Тесты на знание Python, PHP, Golang и DevOps: разбор викторины AvitoQuiz на Highload

Конференция Highload++ 2017 отгремела, и это было круто — как всегда. Мы пересматриваем доклады, вовсю пользуемся опытом, которым с нами поделились коллеги и с удовольствием вспоминаем разные активности, которые проводились вне зоны докладов.


На нашем стенде, например, можно было пройти тест на знание одного из языков программирования (Python, Go, PHP) или тест для DevOps и получить красочную тематическую футболку. Сегодня хотим предложить вам ещё раз окунуться в атмосферу конференции и разобрать ответы на самые Highload-задачи из нашего теста. А может, вы сможете решить их, не заглядывая под спойлер?


Enjoy!


Читать дальше →

[Из песочницы] Лёгкий «Frontend» на Golang для ручного тестирования Ethereum смарт контракта без JavaScript и Web3

Привет!


У меня возникла идея разработать надеюсь простое решение, для ручного тестирования смарт контрактов Ethereum. Стало интересно сделать, что-то похожее на функционал вкладки Run в Remix.

Читать дальше →

Восстанавливаем данные из CockroachDB

Восстановить данные из cockroachdb легко — просто накатите всё из бекапа. Как это не делали бэкапы? Для базы, у которой версия 1.0 вышла всего полгода назад? Что ж, не отчаивайтесь, скорее всего данные можно восстановить. Я буду рассказывать про то, как я восстанавливал базу данных для своего проекта потешной социальной сети вбамбуке и стримил сей процесс на ютьюбе.

Как будем восстанавливать

Для начала нужно разобраться с тем, что произошло, почему упал CockroachDB? Причины бывают разные, но в любом случае сервер больше не стартует или не отвечает на запросы. В моём случае, после недолгого гугления, оказалась побита rocksdb база:
E171219 15:50:36.541517 25 util/log/crash_reporting.go:82  a panic has occurred!
E171219 15:50:36.734485 74 util/log/crash_reporting.go:82  a panic has occurred!
E171219 15:50:37.241298 25 util/log/crash_reporting.go:174  Reported as error 20a3dd770da3404fa573411e2b2ffe09
panic: Corruption: block checksum mismatch [recovered]
	panic: Corruption: block checksum mismatch

goroutine 25 [running]:
github.com/cockroachdb/cockroach/pkg/util/stop.(*Stopper).Recover(0xc4206c8500, 0x7fb299f4b180, 0xc4209de120)
	/go/src/github.com/cockroachdb/cockroach/pkg/util/stop/stopper.go:200 +0xb1
panic(0x1957a00, 0xc4240398a0)
	/usr/local/go/src/runtime/panic.go:489 +0x2cf
github.com/cockroachdb/cockroach/pkg/storage.(*Store).processReady(0xc420223000, 0x103)
	/go/src/github.com/cockroachdb/cockroach/pkg/storage/store.go:3411 +0x427
...Далее...

К вопросу о принципах работы асинхронных решений

Предлагаем вашему вниманию отличное новогоднее чтение для программистов :) Статью Александра Чистякова ( alexclear ), которую тот написал, вдохновившись тезисами доклада Mons Anderson ( codesign ) на HighLoad++ 2017.

Александр Чистяков

Давайте поговорим о принципах работы асинхронных решений и рассмотрим предложенную Mons Anderson классификацию. Возможно, нам удастся предложить нашу собственную классификацию.

Для того, чтобы классифицировать существующие решения, придумаем сначала оси координат. С точки зрения инженера-разработчика "синхронная" и "асинхронная" парадигмы основаны на абстракциях, различающихся как сложностью применения, так и «эффективностью» (что такое «эффективность», нам еще предстоит определить).

Осторожно, под катом жёсткий хардкор! Читать дальше →

[Перевод] Обзор реализаций округления в Go


Привет, Хабр! Меня зовут Олег, я PHP-и-не-только-разработчик в Badoo. Меня часто удивляет, насколько по-разному в языках программирования подходят к составлению стандартной библиотеки. Go — не исключение: отсутствие функции math.Round() меня удивило. Однако, покопавшись в этих ваших интернетах, я выяснил, в чём причина. Этими знаниями я и хотел бы поделиться в своём вольном переводе.

Читать дальше →

[Перевод] Линейная регрессия с помощью Go


Долгое время меня интересовала тема машинного обучения. Меня удивляло, как машины могут обучаться и прогнозировать безо всякого программирования — поразительно! Я всегда был очарован этим, однако никогда не изучал тему подробно. Время — ресурс скудный, и каждый раз, когда я пытался почитать о машинном обучении, меня заваливало информацией. Освоение всего этого казалось трудным и требовало много времени. Также я убедил себя, что у меня нет необходимых математических знаний даже для того, чтобы начать вникать в машинное обучение.


Но в конце концов я решил подойти к этому иначе. Мало-помалу я буду пытаться воссоздавать в коде разные концепции, начиная с основ и постепенно переходя к более сложным, стараясь охватить как можно больше базовых вещей. В качестве языка я выбрал Go, это один из моих любимых языков, к тому же я не знаком с традиционными для машинного обучения языками вроде R или Python.

Читать дальше →
  • Новее
  • 1


Последние посты