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

Всем привет,

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

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

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

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

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

...Далее...

[Перевод] Сказ о том, как SQL время экономит

Существует компания, предоставляющая платформу для работы с большими данными. Эта платформа позволяет хранить генетические данные и эффективно управлять ими. Для полноценной работы платформы требуется возможность обрабатывать динамические запросы в среде выполнения не более чем за две секунды. Но как преодолеть этот барьер? Для трансформации существующей системы было решено использовать хранилище данных SQL. Заглядывайте под кат за подробностями!

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

Используем Bash в SQL-стиле

Приветствую! Данная небольшая статья призвана осветить некоторые аспекты применения Bash для анализа файлов в SQL-стиле. Будет интересна для новичков, возможно, опытные пользователи также найдут для себя что-нибудь новое.

Структура задачи:
  • projects
    1. project1/ — проекты
      • conf/
        • <run_configurations>*.conf — конфигурации построения отчетов по таблицам
      • reports/
        • <run_configurations>/
          • report1.json — сами отчеты, содержат статистику по таблицам Apache Hive
          • report2.json
    2. project2/
      ...

Надо: найти просроченные отчеты.

Итак, расчехляем Bash, открываем отдельный терминал для man-ов и приступаем)

Всех, кому интересно — прошу под кат.
Читать дальше →

[Перевод] 6 строк глубокого обучения

Привет, Хабр! Такое понятие, как «Глубокое обучение», существует с 1986 года, когда его впервые употребила Рина Дехтер. Развитие технология получила в 2006 после выхода публикации Джеффри Хинтона об эффективном предобучении многослойной нейронной сети. Сегодня deep learning часто живет в связке с распознаванием речи, пониманием языка и компьютерным зрением. Под катом вы узнаете про использование алгоритмов глубокого обучения в SQL. Заглядывайте!

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

[Перевод] Отличие DAX и MDX

Меня часто спрашивают об основных отличиях DAX и MDX или в целом о различии табличной и многомерной модели.

С точки зрения выражения или языка запросов, одно из наиболее важных различий лежит во внутренней основе обоих подходов.

В кубе, для адресации ячейки в пространстве, у нас есть понятие кортежа. Ось в кортеже устанавливает координаты. Если у нас есть единственный кортеж, то результат — содержание соответствующей ячейки в кубе. Поскольку у атрибутов куба есть элемент All, который служит значением по умолчанию (в большинстве случаев), если атрибут не был включен в кортеж, то мы выполняем агрегацию также, как если бы он там был. Например, следующий кортеж возвращает (агрегированный) объем продаж за 2013 год

(Date.Calendar.[Calendar Year].&[2013], Measures.[Internet Sales Amount])
Читать дальше →

Индексы в PostgreSQL — 7

Мы уже познакомились с механизмом индексирования PostgreSQL и с интерфейсом методов доступа, и рассмотрели хеш-индексы, B-деревья, индексы GiST и SP-GiST. А в этой части займемся индексом GIN.

GIN

— Джин?.. Джин — это, кажется, такой американский спиртной напиток?.. — Не напиток я, о пытливый отрок! — снова вспылил старичок, снова спохватился и снова взял себя в руки. — Не напиток я, а могущественный и неустрашимый дух, и нет в мире такого волшебства, которое было бы мне не по силам. Лазарь Лагин, «Старик Хоттабыч». Gin stands for Generalized Inverted Index and should be considered as a genie, not a drink. README

Общая идея

GIN расшифровывается как Generalized Inverted Index — это так называемый обратный индекс. Он работает с типами данных, значения которых не являются атомарными, а состоят из элементов. При этом индексируются не сами значения, а отдельные элементы; каждый элемент ссылается на те значения, в которых он встречается. Хорошая аналогия для этого метода — алфавитный указатель в конце книги, где для каждого термина приведен список страниц, где этот термин упоминается. Как и указатель в книге, индексный метод должен обеспечивать быстрый поиск проиндексированных элементов. Для этого они хранятся в виде уже знакомого нам ...Далее...

Курс молодого бойца PostgreSQL



Хочу поделиться полезными приемами работы с PostgreSQL (другие СУБД имеют схожий функционал, но могут иметь иной синтаксис).

Постараюсь охватить множество тем и приемов, которые помогут при работе с данными, стараясь не углубляться в подробное описание того или иного функционала. Я любил подобные статьи, когда обучался самостоятельно. Пришло время отдать должное бесплатному интернет самообразованию и написать собственную статью.

Данный материал будет полезен тем, кто полностью освоил базовые навыки SQL и желает учиться дальше. Советую выполнять и экспериментировать с примерами в pgAdmin'e, я сделал все SQL-запросы выполнимыми без разворачивания каких-либо дампов.

Поехали!
Читать дальше →

[Перевод] Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем

SQL пробуждается и наносит ответный удар силам тьмы — NoSQL С самого начала компьютерной эры человечество собирает экспоненциально растущие объемы данных, и вместе с этим растут требования к системам хранения, обработки и анализа данных. Из-за этого в последнее десятилетие разработчики ПО отказались от SQL как от устаревшей технологии, которая не могла масштабироваться вместе с растущими объемами данных — и в результате появились базы данных NoSQL: MapReduce и Bigtable, Cassandra, MongoDB и другие. Однако сейчас SQL возрождается. Все основные поставщики облачных услуг предлагают популярные управляемые сервисы реляционных баз данных: Amazon RDS, Google Cloud SQL, база данных Azure для PostgreSQL (запущена буквально в этом году) и другие. Если верить компании Amazon, ее совместимая с PostgreSQL и MySQL база данных Aurora стала «самым быстрорастущим сервисом в истории AWS». Не теряют популярности и SQL-интерфейсы поверх платформ Hadoop и Spark. А в прошлом месяце ...Далее...

[Из песочницы] SQL Server: Производительность при вставке данных в таблицу с кластеризованным индексом и без

Привет, Хабр! Представляю вашему вниманию перевод статьи SQL Server Insert Performance for Clustered Indexes vs. Heap Tables

Вопрос


Я прочел множество различной документации по современным методам работы с SQL Server, утверждающей, что каждая таблица должна иметь кластеризованный индекс и не быть кучей с некаластеризованными индексами. Большинство источников отмечает административную выгоду от использования кластеризованных индексов. Но есть ли в этом какое-то влияние на производительность и другие положительные или отрицательные стороны?
Читать дальше →

Liquibase: пример автоматизированного наката изменений на реляционную БД

Вместо предисловия


Статья будет интересна тем, кто хоть раз задумывался о вопросе наката изменений (патча) на реляционную БД. Статья не будет интересна тем, кто уже освоил и использует Liquibase. Главной целью данной статьи является указание ссылки на репозиторий с примером использования. В качестве примера я выбрал накат sample-схемы HR на БД Oracle (список всех поддерживаемых БД) — любой желающий может скачать себе репозиторий и поиграться в домашних условиях. Желание продемонстрировать пример вызвано обсуждением этого вопроса на ресурсе sql.ru.

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


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