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

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

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


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


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


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

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

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

Sharding – patterns and antipatterns

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


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


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

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

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

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

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

TON


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


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


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

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

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

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

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

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

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

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

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



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

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

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

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


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

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

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

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

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

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

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

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

ЮMoneyJava

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

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

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

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

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