База данных как Вконтакте

Содержание

Но не пойму, как организовать структуру, когда в диалогах может быть множество участников. Нужно больше, чем 2 таблицы?

Отслеживать
задан 14 дек 2017 в 14:07
Андрей Диневич Андрей Диневич
582 1 1 золотой знак 5 5 серебряных знаков 18 18 бронзовых знаков
14 дек 2017 в 14:10
Так же у них в группе VKTech есть видео с выступлением Дмитрия Егорова на HighLoad++
14 дек 2017 в 14:17
Переносим id_user1 и id_user2 в третью таблицу members: id_dlg — id_user да и всё
14 дек 2017 в 15:01

Обычная связь многие-ко-многим?
14 дек 2017 в 15:26

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Делаем таблицу message: id — user_id — dialog_id — time — text user_id и dialog_id делаем внешними ключами и по ним уже тянем данные о пользователях в диалоге и о самом диалоге. Возможно можно получше придумать, но это первое, что пришло в голову

Отслеживать
ответ дан 14 дек 2017 в 14:10
1,553 6 6 серебряных знаков 13 13 бронзовых знаков

mysql
база-данных

Важное на Мете

Подписаться на ленту

Лента вопроса

Как переписать с нуля базу данных личных сообщений ВКонтакте / Дмитрий Егоров (ВКонтакте)

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник: ru.stackoverflow.com

Tarantool: Билли Миллиган в мире СУБД

Привет! Меня зовут Mons Anderson, я архитектор, разработчик, продакт-менеджер и евангелист Tarantool. В VK работаю уже больше 10 лет. Я постоянно нуждаюсь в базах данных, использую их и очень люблю. И в последнее время, когда я говорю про БД, я всё чаще говорю про Tarantool.

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

Поговорим про базы данных в целом

Прежде чем переходить к Tarantool, стоит обсудить базы данных. На DB-Engines они отсортированы по популярности:

Сначала я вычеркнул базы данных, которые являются коммерческими — мне просто не хотелось рассматривать такие решения.

Дальше у нас есть MySQL и Postgres. В целом, более или менее равнозначные инструменты. Но MySQL постоянно падает в рейтингах, а Postgres растёт. Поэтому я выбрал эту тройку — Postgres, Mongo и Redis. Именно они хорошо отражают всё, что происходит с точки зрения использования базы данных: скорость, масштабируемость и реляционность.

Еще по теме: Как сделать сп в ВК скрытным

БАЗА ДАННЫХ ПОЛЬЗОВАТЕЛЕЙ ДЛЯ БОТА ВК

Я специально не буду говорить про облака. На DB-Engines очень много облачных решений, но облако — такая штука, в которой проблемы уже кто-то решил за вас. Обсуждать их не стоит, мы сосредоточимся на решениях на своём железе и на их проблемах.

Первая группа проблем — это кеш. Его инвалидация, когерентность, холодность — он может быть почти тёплый. Кеш приносит проблем едва ли не больше, чем решает. К тому же он увеличивает время работы: сходи посмотри там, там нет — иди в базу, сохранили в кеш — там всё устарело. Кто пользовался, тот знаком с этими проблемами.

Ещё кеш решает проблему только чтений. Решить проблему записи мы не можем никак, кроме как с помощью шардирования, потому что запись не масштабируется таким образом. Мы не можем писать на реплики, они не принимают запись. Поэтому у нас появляется маршрутизация запросов, шардирование, отдельные наборы реплик. Ваш классический мир по умолчанию становится довольно сложным.

В нём появляются различные нагромождения, кеши, шардирование, — но всё это не коробочное.

Большинство современных реляционных баз дисковые. А у дисков есть одно мерзкое свойство: они могут ломаться, рассыпаться, просто тормозить. Если вы много пишете в базу и у вас загружен диск или создаётся резервная копия, или вдруг много логов от операционки — чтение начинает тупить. Дисковая база данных довольно плохо прогнозируема с точки зрения нагрузки, потому что диск влияет на работу базы.

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

Tarantool и смешение разных продуктов

Если смешать Redis с Postgres, взять SQL-схему, но при этом сохранить резидентность (in-memory), то есть сделать из in-memory полноценную реляционную базу данных с различными индексами (primary, secondary, композитными и foreign key), то получится всё как в клёвом хорошем Postgres. Получится надёжно, хотя придётся отказаться от аналитических запросов. Во-первых, гонять их по памяти дорого, во-вторых, зачастую аналитические запросы гоняются по гораздо большим массивам данных. Аналитику мы отодвинем в сторону, потому что обычно реляционные базы данных захлёбываются на нагрузке другого характера. И теперь можно сказать, что Tarantool — это такая база данных, которая как Redis и Postgres: резидентная, быстрая и реляционная.

Можно зайти с другой стороны. Возьмём Redis и Mongo. Mongo хорошо масштабируется, но медленная. Redis хороший и быстрый, но у него нет таких инструментов масштабируемости. А у Tarantool есть. Tarantool — это хорошо масштабируемый in-memory, но, конечно, есть и минусы в сравнении с Mongo. Он всё хранит в памяти. Также у него менее богатые возможности индексации.

У Mongo они действительно круче, потому что она ориентирована строго на индексирование документов. Tarantool тоже умеет их индексировать, но чуть послабее.

Рассмотрим последнее пересечение — Mongo и Postgres. Это поле, на котором сложно определить лучшего игрока. С одной стороны, это схема и реляционность. С другой — отсутствие схемы хранения документов, произвольных данных. Тут всё сложно. Postgres, в целом, тоже идёт в эту сторону: он учится хранить произвольные структуры данных, позволяет их индексировать.

Tarantool занимает промежуточную позицию, потому что нет необходимости выбирать что-то одно, если ты можешь для одних данных сделать коллекцию и хранить в ней табличную информацию, в другой коллекции хранить документы. Tarantool позволяет и так, и так. У него есть инструменты для шардирования, схемы, индексы, возможность хранить документы. Где Tarantool не пересекается с Postgres и Mongo, это хранение на диске, потому что он строго in-memory.

Еще по теме: Как узнать баланс в Вконтакте

Tarantool: что он не умеет и для чего подходит

Каждое перечисленное решение что-то умеет, а что-то — нет. Tarantool берёт от каждого решения то, что ему было нужно на разных этапах своего развития. Получилось решение, которое одновременно умеет всё (или очень многое) из перечисленного.

Но давайте посмотрим на то, что он не умеет. Для этого обратим внимание на наш способ выбора БД. Часто исходят из количества данных. Их может быть мало — хватит памяти одного сервера. Например, у магазина настольных игр данные прирастают медленно и точно влезут в один сервер, даже если бизнес успешный и раскрученный.

А бывает, что данных много, как, например, почти у любого UGC-сервиса, для которого пользователи постоянно генерируют контент. Очень много задач решается в сценариях, когда данных мало, потому что предметная область по своей сути ограничена.

Другой критерий — нагрузка. Она бывает высокая и низкая. Вряд ли нас интересует низкая нагрузка, потому что она никак не влияет на выбор решения, поэтому мы будем говорить сразу про высокую.

Высокая нагрузка бывает двух видов: OLAP (Online Analytical Processing) и OLTP (Online Transaction Processing), нагрузка на чтение. OLTP — это когда мы делаем маленькие точечные запросы. В качестве примера можно привести объектное хранилище (S3), у которого точечная нагрузка, которая строго ограничена конкретными объектами.

Там практически отсутствуют запросы ко всем данным, как и необходимость выбирать их большими списками. А OLAP — это практически всегда какая-нибудь аналитика. Мы берём здоровенный массив данных, который нужно просканировать, просуммировать, что-нибудь с этим сделать. В качестве примера — та же Google Analytics.

И с другой стороны. кроме чтения бывает и запись. Это такая нагрузка, которая «убивает» очень многие базы. Они обычно предназначены для чтения и редко оптимизированы под очень высокую нагрузку на запись.

Теперь давайте посмотрим, какие продукты могут закрывать разные задачи в зависимости от количества данных и нагрузки:

Мало данных, OLTP-нагрузка. До определенного момента может хватить Postgres, он хорошо вывозит точечные запросы. Также для такой нагрузки вполне хорошо пойдёт Redis и уже озвученный мной Tarantool, который здесь, по сути, имитирует первого и второго. То есть он способен обрабатывать OLTP в режиме «мало», причём очень удобно, с SQL и прочими прелестями.

OLAP. Для OLAP с «мало» также вполне подойдёт Postgres. У него есть хорошие возможности для аналитических запросов. Но нельзя не отметить довольно популярного игрока — ClickHouse, хотя ранее я его не называл, так как это вообще отдельный класс баз данных — колоночные. Он прекрасно подходит под аналитическую нагрузку любого масштаба.

Нагрузка на запись. У нас резко отваливаются Postgres, да и много других реляционных баз данных — они не вывезут активную запись. Здесь работают либо in-memory, которые хорошо и линейно пишут на диск, либо LSM-деревья, например, Mongo. Она хорошо и прекрасно пишет.

Когда данных много и OLTP-нагрузка, из перечисленных ранее подходит только Tarantool, потому что он умеет масштабироваться и хорошо подходит под OLTP. Redis и Postgres не справятся с ростом нагрузки, потому что у них из коробки нет шардирования.
Под OLAP у нас остаётся ClickHouse
Под большую нагрузку на запись — всё тот же MongoDB, который хорошо пишет, и Tarantool, потому что он толерантен к такой нагрузке.

Если говорить о Tarantool, то аналитику можно сразу отметать — сценариев, когда его можно использовать для аналитики, исчезающе мало. К тому же есть другое решение, которое хорошо его дополняет. А вот для всех остальных сценариев Tarantool практически идеален.

По прошествии времени я понял, что для решения большинства задач с высокой нагрузкой мне хорошо подходит Tarantool. А ту нишу, где он не подходит, хорошо закрывает ClickHouse.

Еще по теме: Кто купил Вконтакте у дурова

Итог: главное о Tarantool

Почему Tarantool такой особенный? Он даёт выбор. Это плохо и больно, люди не любят выбирать. Есть даже исследования: покупателям гораздо проще, если в магазине будет два вида товара одной категории, а не 30. Tarantool — это конструктор, из которого можно собрать себе шардированную или не шардированную базу данных, с SQL или без, под разные задачи.

И это я ещё не говорил о других задачах, не связанных с БД — IoT-сервисах или брокерах очередей.

Большинству разработчиков гораздо проще взять готовое решение. Если тебе нужен просто резидентный кеш, то достаточно взять Redis, запустить — и всё заработает. А если брать Tarantool, то придётся его настраивать, шагов на начальном этапе будет больше.

Но если в самом начале ошибиться с другой БД и не понять, что понадобится масштабирование или реляционные запросы, то потом будет сложнее перестроиться. А с Tarantool это легко можно сделать на лету. Он упрощает смену парадигмы без смены технологии или платформы. Из личного опыта: во время раннего запуска сервиса S3 (VK Cloud Storage) предполагали один характер данных и нагрузки, а со временем они менялись. Сервис рос, я спокойно менял схему данных и горизонтально масштабировал базу, не меняя слоя приложения.

Tarantool — это конструктор, который можно правильно собрать, прикрутить что-то сбоку. Или его можно собрать неправильно, не так, как это делают другие. В целом, он поможет вам решить задачу. Это надёжный, хороший базовый кубик для построения различных приложений, связанных с базами данных.

Скачать Tarantool можно на официальном сайте, а получить помощь — в Telegram-чате.

Блог компании VK
Администрирование баз данных
Tarantool

Источник: habr.com

Дмитрий Егоров- Как переписать с нуля базу данных личных сообщений ВКонтакте

Дмитрий Егоров — Как переписать с нуля базу данных личных сообщений ВКонтакте и мигрировать на нее без даунтайма.

Предыдущая статья WebForMySelf.com- много обучающих статей и видео по web разработке

Следующая статья Язык программирования- какой вам следует учить в 2017

ЭТО МОЖЕТ БЫТЬ ИНТЕРЕСНОЕЩЕ ОТ АВТОРА

Видеокурс по работе с MySQL

Hacking

Java. От простого к сложному. Научитесь программировать на Java.

Вакансии для программистов

Создаем мобильное приложение с помощью JS. Путь React Native

Секреты и трюки при работе с Git, шпаргалка по Git

Глубокое погружение в ES-модули в картинках

Пишем HTML5-игру за 20 минут, или введение в Phaser framework

Горячее

Как создать потокобезопасный Singleton?

В этой статье вы узнаете о том, что такое localStorage и на рабочем примере узнаем то, как с ним работать в JavaScript.

Как работать с localStorage в JavaScript

Перейдите на вкладку Boot.ini и установите флажок /Safeboot. Нажмите ОК.

База данных как Вконтакте

1 ответ 1

Похожие

Подписаться на ленту