[Перевод] Как мы выстраивали инфраструктуру данных в Wish

Я пришел в Wish 2,5 года назад, дела в компании шли отлично. Наше приложение было в топе в iOS и Android магазинах и продавало более 2 миллионов товаров в день.

Мало кто верил, что можно построить большой бизнес, продавая дешевые товары. Однако, используя данные, Wish смогли бросить вызов этим сомнениям. Аналитика данных всегда была у нас в крови.

Но когда наш бизнес стал расти огромными темпами, мы не были к этому готовы, обнаружилось множество проблем с аналитикой. Каждая команда внутри компании стала нуждаться в срочной поддержке в работе с данными и многое упускала из виду в своем поле деятельности. В то время наши аналитические возможности еще только зарождались и не могли удовлетворить все растущий спрос.

В данном посте я расскажу о том, какие уроки мы извлекли за это время, а также распишу верный путь для компаний, находящихся в поисках способов масштабирования их аналитических функций.


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

[Из песочницы] Своя СУБД за 3 недели. Нужно всего лишь каждый день немного времени…

Своя СУБД за 3 недели. Нужно всего-лишь каждый день немного времени уделять архитектуре; и всё остальное время вкалывать на результат, печатая и перепечатывая сотни строк кода.

По закону Мерфи, если есть более одного проекта на выбор — я возьмусь за самый сложный из предложенных. Так случилось и с последним заданием курса о системах управления базами данных (СУБД).

обложка /dropSQL

Дропнуть студентов

Как мы выбирали между 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 кэше будет очень накладно, тем более пейджинг и богатый набор сортировок никто не отменял. По сути, под каждый запрос от пользователя формируется полностью уникальный набор отфильтрованных записей.

...Далее...

[Перевод] Создаём Q&A-бота: пошаговая инструкция

Привет, Хабр! Сегодня мы хотим поделиться с вами инструкцией по созданию бота, который будет анализировать вопросы и отвечать на них. Казалось бы, мы могли бы просто рассказать про QnA Maker, который выполняет эту функцию. Но, есть одна загвоздка – он поддерживает ограниченное количество языков. Поэтому, под катом мы поделимся пошаговой инструкцией создания Q&A-бота, универсального для любого языка.

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

[Из песочницы] Альтернативная архитектура СУБД и подход к разработке приложений

Я расскажу о технологической платформе, пригодной для создания информационного ядра системы или приложения. Платформа содержит простой высокоуровневый конструктор модели данных и базовый интерфейс для работы с ней, поддерживает ролевую модель доступа, эмулятор запросов SQL (CRUD), API, а также дает возможность загружать произвольные рабочие места — элементы UI — и наполнять их данными. У платформы есть некоторые принципиальные отличия от бесконечного множества «конструкторов», из-за чего она и появилась. Некоторые из отличий достойны качественного холивара, другие просто упрощают жизнь разработчика, кем бы он ни был. Несколько приложений уже работают у живых клиентов, из них будут приведены рабочие примеры выполнения задач. Здесь вы можете собрать веб-приложение, не изучая язык программирования: мы оперируем только бизнес-терминами и формулами, не сложнее, чем в MS Excel. Безусловно, понимание принципов работы баз данных поможет вам разработать более живучий, масштабный и богатый функционалом продукт, но этот сервис не требует специфических знаний для простых решений, которые составляют, навскидку, не меньше 80% прикладной разработки (например, кустарной и всего, что сейчас работает в Экселе). Ну-ну, продолжай ...Далее...

Индексы в PostgreSQL — 9

В прошлых статьях мы рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и следующие методы: хеш-индексы, B-деревья, GiST, SP-GiST, GIN и RUM. Тема этой статьи — BRIN-индексы.

BRIN

Общая идея

В отличие от индексов, с которыми мы уже познакомились, идея BRIN не в том, чтобы быстро найти нужные строки, а в том, чтобы избежать просмотра заведомо ненужных. Это всегда неточный индекс: он вообще не содержит TID-ов табличных строк. Упрощенно говоря, BRIN хорошо работает для тех столбцов, значения в которых коррелируют с их физическим расположением в таблице. Иными словами, если запрос без предложения ORDER BY выдает значения столбца практически в порядке возрастания или убывания (и при этом по столбцу нет индексов). Метод доступа создавался в рамках европейского проекта по сверхбольшим аналитическим базам данных Axle с прицелом на таблицы размером в единицы и десятки терабайт. Важное свойство BRIN, позволяющее создавать индексы на таких таблицах — небольшой размер и минимальные накладные расходы на поддержание. Работает это следующим образом. Таблица разбивается на зоны...Далее...

[Из песочницы] Apache Ignite vs Oracle СУБД

Apache Ignite – распределенная база данных в памяти, подобные БД получают распространение и хочется сравнить с тем что уже есть и зарекомендовало себя, например реляционная СУБД Oracle. Ignite имеет широкие возможности распределенных вычислений, также есть поддержка SQL на уровне ANSI-99, в производительности SQL и хочется сделать некоторое сравнение. Настройка БД будет в обоих случаях во многом по умолчанию, в случае Oracle это XE, а в случае Ignite это два узла(node) на одном компьютере. Компьютер i5 7400 (4-ядра) 3.5Ггц, 8Гб ОЗУ, SSD диск.
В качестве тестовых данных буду использовать данные КЛАДР (~223 тыс. записей) в качестве среды выполнения запросов DBeaver в котором настроены два подключения к Ignite и Oracle. И первое что сделаю импортирую данные в таблицы, Данные КЛАДР из DBF переведу в CSV, а затем средствами DBeaver выполню импорт в таблицы.
Читать дальше →

MSSQL SERVER – пример применения связанного сервера

Сегодня решил поделиться статьей как однажды мне пришел на выручку связанный сервер при работе с MSSQL. Сначала опишу ситуацию, в которой мне пришлось с ним познакомиться.
Читать дальше →

Выбор надежной БД в высоконагруженном проекте

Привет!

Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно. Наша технология хранения информации многократно доказала свою надежность. Компания развивается, и мы озаботились вопросом выбора БД на ближайшие 10 лет. Наша цель — быть готовыми к 100-кратному росту и при этом не менять платформу каждые 2-3 года. Конкуренция на рынке баз данных развита: представлено много решений, большая часть из них open source и/или бесплатные. Ищем «идеальное решение»™ для нашей задачи.
Читать дальше →


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