Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

Масштабирование базы данных через шардирование и партиционирование

Блог компании Конференции Олега Бунина (Онтико) Высокая производительность *Разработка веб-сайтов *MySQL *PostgreSQL *


Масштабирование базы данных через шардирование и партиционирование


Денис Иванов (2ГИС)


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

Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.

Перейдем к проблемам, которые мы с вами сегодня будем решать. Одна из проблем — это большое количество данных. Когда вы разрабатываете тот или иной проект, у вас в любой момент времени может случиться так, что данных становится очень много. Если бизнес работает, он приносит деньги. Соответственно, данных больше, денег больше, и с этими данными что-то нужно делать, потому что эти запросы очень долго начинают выполняться, и у нас сервер начинает не вывозить. Одно из решений, что с этими данными делать — это масштабирование базы данных.
Читать дальше →
Всего голосов 37: ↑34 и ↓3 +31
Просмотры 98K
Комментарии 17

Sharding – patterns and antipatterns

Блог компании Конференции Олега Бунина (Онтико) Высокая производительность *MySQL *PostgreSQL *Программирование *


Константин Осипов ( kostja ), Алексей Рыбак ( fisher )


Константин Осипов: Доклад родился из следующего разговора. Я, как всегда, пытался убедить Алексея больше использовать Tarantool, а он сказал, что там до сих пор нет шардинга и, вообще, неинтересно. Тогда мы стали рассуждать о том, почему нет. Я стал рассказывать, что тут нет одного универсального решения, автоматика полная за вас работает, а вы только кофе на работе пьете и все…

Поэтому родился этот доклад — чтобы посмотреть на то, какой бывает шардинг, какие методы в каких системах используются, какие преимущества и недостатки, почему нельзя одной «серебряной пулей» все решить?

Читать дальше →
Всего голосов 36: ↑33 и ↓3 +30
Просмотры 26K
Комментарии 18

TON: Telegram Open Network. Часть 2: Блокчейны, шардирование

Децентрализованные сети Криптография *Алгоритмы *

TON


Данный текст — продолжение серии статей, в которых я рассматриваю структуру (предположительно) готовящейся к выходу в этом году распределенной сети Telegram Open Network (TON). В предыдущей части я описал её самый базовый уровень — способ взаимодействия узлов между собой.


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


Сегодня посмотрим на основной компонент TON — блокчейн.

Читать дальше →
Всего голосов 46: ↑43 и ↓3 +40
Просмотры 28K
Комментарии 14

Как масштабироваться с 1 до 100 000 пользователей

Блог компании Дата-центр «Миран» Хостинг Разработка веб-сайтов *Серверное администрирование *Облачные сервисы
Перевод
Tutorial
Через такое прошли многие стартапы: каждый день регистрируются толпы новых пользователей, а команда разработчиков изо всех сил пытается поддержать работу сервиса.

Это приятная проблема, но в Сети мало чёткой информации, как аккуратно масштабировать веб-приложение с нуля до сотен тысяч пользователей. Обычно встречаются или пожарные решения, или устранение узких мест (а часто и то, и другое). Поэтому люди используют довольно шаблонные приёмы по масштабированию своего любительского проекта в нечто действительно серьёзное.

Попытаемся отфильтровать информацию и записать основную формулу. Мы собираемся пошагово масштабировать наш новый сайт для обмена фотографиями Graminsta с 1 до 100 000 пользователей.

Запишем, какие конкретные действия необходимо сделать при увеличении аудитории до 10, 100, 1000, 10 000 и 100 000 человек.
Читать дальше →
Всего голосов 27: ↑27 и ↓0 +27
Просмотры 17K
Комментарии 25

Хьюстон, у нас проблема. Дизайн систем на отказ

Блог компании Конференции Олега Бунина (Онтико) Высокая производительность *Разработка веб-сайтов *Анализ и проектирование систем *Amazon Web Services *
В 1970 г. американские инженеры запустили аппарат Аполлон-13 к Луне. На борту три батареи топливных элементов, беспокоиться не о чем, всё надежно и многократно продублировано. Но никто не мог предположить, что взрыв кислородного баллона выведет из строя две батареи из трёх. Трагедия! Астронавты вернулись домой, о событии сняли художественный фильм с Томом Хэнксом, а фраза астронавта Джека Свигерта: «Хьюстон, у нас проблема!», вошла в историю.



История Аполлона-13 это еще одно доказательство известного факта, что нельзя подготовиться ко всем возможным неприятностям. Это естественное свойство окружающего мира: железо периодически ломается, код сбоит, а люди ошибаются. Полностью исключить это невозможно.

Для больших распределенных систем такое поведение нормально, это следствие эффекта масштаба и статистики. Именно поэтому Design for Failure (дизайн на отказ) — базовый принцип проектирования облачных сервисов AWS. Системы изначально строятся так, чтобы максимально быстро восстановить штатную работу и минимизировать ущерб от известных и ещё неизвестных сбоев. На HighLoad++ Василий Пантюхин на примерах реальных проблем с боевыми сервисами показал паттерны проектирования распределенных систем, которые используют разработчики AWS.
Всего голосов 21: ↑21 и ↓0 +21
Просмотры 6.5K
Комментарии 1

Как перестать беспокоиться и начать жить без монолита

IT-инфраструктура *История IT IT-компании Микросервисы *


Все мы любим истории. Нам нравится, сидя у костра, рассказывать о своих былых победах, сражениях или просто о своем опыте работы.

Сегодня как раз такой день. И пусть вы сейчас не у костра, но зато у нас есть история для вас. История о том, как мы начали работать с хранилищем на Tarantool.

Когда-то давным-давно в нашей компании была пара «монолитов» и один на всех «потолок», к которому эти монолиты медленно, но верно приближались, ограничивая полет нашей компании, наше развитие. И было однозначное понимание: однажды мы жестко упремся в этот потолок.
Читать дальше →
Всего голосов 21: ↑21 и ↓0 +21
Просмотры 8.7K
Комментарии 11

Как мы создаём почтовую систему нового поколения Mailion. Принципы проектирования масштабируемых хранилищ данных

Блог компании МойОфис Хранение данных *Хранилища данных *Распределённые системы *

МойОфис продолжает цикл публикаций (1, 2) о разработке корпоративной почтовой системы нового поколения Mailion, которая реализуется при грантовой поддержке РФРИТ. В состав Mailion входит объектное хранилище DOS; в предыдущей статье мы рассмотрели его общую архитектуру и ключевые оптимизации, повышающие экономическую эффективность хранения данных. Сегодня мы переходим к одной из самых сложных и увлекательных тем в области разработки баз данных — проблеме масштабирования.

Читать далее
Всего голосов 13: ↑13 и ↓0 +13
Просмотры 9K
Комментарии 5

Как оптимизировать повседневные backend-задачи: три видео с митапа по Java

Блог компании ЮMoney Java *

20 мая прошел седьмой митап для Java-разработчиков ЮMoney Jam. Смотрите видео от наших докладчиков, которые делятся кейсами:

— Как добавлять в чистовой код на Java тестовое поведение и спать спокойно.

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

— Как не попасть в Jar Hell.

Смотреть видео
Всего голосов 19: ↑15 и ↓4 +11
Просмотры 5.6K
Комментарии 6

PlanetScale — Serverless SQL база данных для разработчиков

MySQL *SQL *Системы управления версиями *Администрирование баз данных *Хранение данных *

Этим летом я по уши увяз в serverless-тематике и даже решил переписать один из своих pet-проектов целиком на serverless. Движок для сайта, поддерживающий бессерверные вычисления и вендор для кэширующей прослойки были найдены быстро - NextJS (с деплоем на Vercel) и Upstash с оплатой за каждую отдельную операцию и байт в хранилище. Камнем преткновения стал выбор провайдера для DBaaS. Мне бы хотелось реализовать всё таким образом, чтобы у проекта было две разных базы данных - для разработки и для production, и мне совсем не хотелось запускать базу данных для разработки на локальной машине. Поверхностное ознакомление с DBaaS провайдерами показало, что за дополнительную базу данных пришлось бы платить вдвое больше несмотря на то, что она использовалась бы дай Бог пару раз в неделю. И я ушёл в просмотр докладов и презентаций на YouTube и это именно тот момент когда я открыл для себя PlanetScale. Хочу поделиться своим открытием с вами.

Читать далее
Всего голосов 7: ↑7 и ↓0 +7
Просмотры 2.7K
Комментарии 7

Самые популярные базы данных NoSQL, поддерживаемые ClusterControl

Блог компании OTUS NoSQL *MongoDB *
Перевод

NoSQL ("не только SQL") — это подход к проектированию баз данных, который позволяет хранить и запрашивать данные вне традиционных структур, используемых в реляционных базах данных. Он был создан в первую очередь для работы с неструктурированными данными, которые генерируются из многочисленных источников, таких как документы, аудио, видео, социальные сети и т.д. Базы данных NoSQL лучше всего подходят для современных приложений, где модели данных эволюционируют, а масштабируемость имеет большое значение. Эта база данных приобрела популярность в последние годы, поскольку сейчас компаниям приходится иметь дело с неструктурированными данными больше, чем когда-либо прежде. Эта модель хранит данные иначе, чем традиционные реляционные таблицы, позволяя хранить связанные данные в единой структуре данных. Базы данных NoSQL можно разделить на четыре категории:

Читать далее
Всего голосов 8: ↑6 и ↓2 +4
Просмотры 346
Комментарии 0