В последнее время на хабре довольно много внимания уделяется фреймворку Yii. Он стал и нашим выбором для крупного проекта. А проблема большинства крупных проектов, как известно, в масштабировании. Не менее известно, что можно легко поставить сотни параллельных nginx и отбалансировать нагрузку на процессор, память, диск и даже канал. А вот с СУБД все гораздо сложнее.

Для того, чтобы заранее побороть эту проблему правильным способом было решено реализовать в Yii поддержку шардинга. Речь под катом пойдет вкратце о том что такое шардинг и подробно о:

1. Устройстве ActiveRecord в Yii
2. Реализации на этом устройстве шардинга
3. Проблемах, которые все еще есть в AR

UPD: перенес в PHP, т.к. наличие расширения для шардинга может склонить чашу весов при выборе фреймворка.

Почти в срок, команда 10gen выпустила новый стабильный релиз NoSQL базы данных MongoDB.

Из новинок хочу отметить такие заявленные возможности:

* Авто шардинг — теперь можно создавать кластеры для большого количества данных с «размазыванием» данных по серверам кластера
* Replica Sets — позволит создавать кластеры с быстрой репликацией и отказоустойчивостью
* Оператор $or — если раньше приходилось писать запрос с использованием JavaScript, то сейчас операции OR работают как стандартный запрос
* До 64 индексов на коллекцию
* Оператор $slice — очень удобная штука, можно выбирать первые 5 штук записей или 5 последних, например.
* Поддержка UNIX сокетов и IPv6
* Улучшена поддержка сервиса для Windows

Скачать можно на странице загрузок

Release Notes

Начну с того, что наш проект находится на начальной стадии развития, а его запуск планируется на 1е ноября. И, чтобы сразу отсечь всю возможную критику касаемо преждевременной оптимизации, скажу, что перед командой была поставлена задача разработать приложение, справляющееся с резкими скачками нагрузки (от 1000 до 50000 и т. п.). В связи с этим было решено закладывать хорошо масштабируемую архитектуру, позволяющую легко и быстро увеличивать производительность системы за счет аппаратной части (по принципу scale-out).

Шардинг

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

Зачем вообще нужно горизонтальное масштабирование? Когда возникает вопрос повышения производительности приложения, то есть несколько вариантов. Как известно можно купить новое «железо» для сервера, добавить количество оперативной памяти и т. д. Этот принцип называется вертикальным масштабированием. Однако этот способ может быть достаточно дорогим, долгим, да и имеет предел. Можно конечно купить топовое железо, однако оно может не потянуть все требования вашего приложения.

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

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

Если рассматривать возможности облачной платформы от Microsoft, то они достаточно широкие. Есть auto-scaling, scaling по запросу, причем все это доступно как с помощью UI, так и с помощью SDK, REST API и PowerShell.

Однако если с масштабированием приложения (PaaS) или виртуальных машин (IaaS) все достаточно просто, указываете сколько инстансов вам необходимо, столько и будет, то в случае если ваше приложение использует базы данных MS SQL, возникает несколько вопросов. Конечно первое что приходит в голову — организовать кластер из виртуальных машин SQL Server. Решение достаточно простое и хорошо всем знакомое. А что делать, если приложение использует базу данных как сервис (SaaS)? Что если мы не хотим заниматьсянастройкой кластера SQL Server?

Конечно же, если мы говорим о Windows Azure, то в качестве SQL базы данных будет использоваться SQL Azure. Эта база данных поддерживает технологию горизонтального масштабирования (шардинг) называемую SQL Azure Federations. Принцип ее работы очень простой: логически независимые друг от друга строки одной таблицы хранятся в разных базах данных. Самый простой пример:



Это одна и та же таблица, данные которой хранятся в разных экземплярах базы данных (шардах). То есть данные аккаунта с идентификатором 1 хранятся в первой базе данных, с идентификатором 2 — во второй и т. д.

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

1. «Sharding — patterns & antipatterns».
Доклад Алексея Рыбака (Badoo) и Константина kostja Осипова (Mail.ru).

Недавно вышла новая версия стандарта HTTP. В мае 2015 года был утвержден HTTP/2, который получил распространение среди браузеров и веб-серверов (включая NGINX и NGINX Plus). На данный момент более 60% используемых браузеров поддерживают HTTP/2, причем эта цифра продолжает увеличиваться с каждым месяцем.

Стандарт HTTP/2 основан на протоколе SPDY, разработанном компанией Google. В Google Chrome поддержка SPDY будет осуществляться до начала 2016 года. NGINX одним из первых реализовал протокол SPDY и сейчас играет ведущую роль в продвижении HTTP/2. Была опубликована статья, в которой дано подробное описание HTTP/2, приводится сравнение со SPDY и подробно описывается процесс внедрения нового протокола.

Всем доброго времени суток! Недавно жизнь подкинула автору увлекательную работу по развертыванию MongoDB кластера с настройкой репликации и шардирования, а также аутентификации c использованием x.509 сертификатов. В данной статье я в первую очередь хотел бы изложить свои мысли и поделиться полученными опытом. Так как некоторые вещи оказались не тривиальными и сделать их с первого раза не удавалось, то думаю мои пошаговые инструкции могут пригодиться для освещения вопроса тем кто только знакомится с шардированием данных и работой с MongoDB в целом.
Также я буду очень рад увидеть рекомендации по добавлению/изменению конфигурации кластера и просто вопросы или критику по самой статье или по сути вопроса.

В предыдущей статье мы поделились своим опытом внедрения и использования СУБД ClickHouse в компании СМИ2. В текущей статье мы затронем вопросы масштабирования, которые возникают с увеличением объема анализируемых данных и ростом нагрузки, когда данные уже не могут храниться и обрабатываться в рамках одного физического сервера. Также мы расскажем о разработанном нами инструменте для миграции DDL-запросов в ClickHouse-кластер.

Конференция PG Day проводится уже в четвертый раз. За это время у нас накопилась большая база полезных материалов от наших докладчиков. Уровень докладов в индустрии с каждым годом становится все выше и выше, но есть темы, которые, как хорошее вино, не теряют своей актуальности.

На одном из прошлых PG Day Валентин Гогичашвили, возглавляющий департамент Data Engineering в Zalando, рассказал, как PostgreSQL используется в компании с большим штатом разработчиков, высокой динамичностью процессов, и как они пришли к такому выбору.

Не секрет, что Zalando является постоянным гостем PG Day. На PG Day'17 Russia мы представим вам три замечательных доклада от немецких коллег. Мурат Кабилов и Алексей Клюкин расскажут про внутреннюю разработку Zalando для развертывания высокодоступных кластеров PostgreSQL. Александр Кукушкин поведает о практике эксплуатации PostgreSQL в AWS. Дмитрий Долгов поможет разобраться c внутренностями и производительности типа данных JSONB в контексте эксплуатации PostgreSQL как документо-ориентированного хранилища.

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

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

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

В данной статье рассмотрим архитектуры простых и эффективных KV-хранилищ с использованием цепной репликации (chain replication), которая активно исследуется и успешно применяется в различных системах.

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

Кажется, мы так глубоко погрузились в дебри highload-разработки, что просто не задумываемся о базовых проблемах. Взять, например, шардирование. Чего в нем разбираться, если в настройках базы данных можно написать условно shards = n, и все сделается само. Так-то, он так, но если, вернее когда, что-то пойдет не так, ресурсов начнет по-настоящему не хватать, хотелось бы понимать, в чем причина и как все починить.

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

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

Меня зовут Владислав, я участвую в разработке Tarantool — СУБД и сервера приложений в одном флаконе. И сегодня расскажу вам, как мы реализовали горизонтальное масштабирование в Tarantool при помощи модуля VShard.

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

Хорошо известно, что Ethereum, самая популярная dApps платформа, обрабатывает меньше чем 20 транзакций в секунду. Из-за этого ограничения цена транзакций и время на их подтверждение очень высоки: несмотря на то, что блок в Ethereum публикуется раз в 10-12 секунд, согласно ETH Gas Station время между отправкой транзакции и тем как она действительно попадает в блок в среднем 1.2 минуты. Низкая пропускная способность, высокие цены и долгое подтверждение транзакций не позволяет запускать на Ethereum какие-либо высокопроизводительные сервисы.

Основная причина того, что Ethereum не может обрабатывать больше 20 транзакций в секунду заключается в том, что каждая нода в Ethereum должна проверить каждую транзакцию. За пять лет с выхода Ethereum было предложено много идей как решить эту проблему. Эти решения можно грубо разбить на две группы: те, которые предлагают делегировать выполнение транзакций небольшой группе нод с очень хорошим железом, и те, которые предлагают каждой ноде обрабатывать только подмножество всех транзакций. Пример первого подхода — это Thunder, в котором блоки создаются только одной нодой, что позволяет, по утверждениям разработчиков, получать 1200 транзакций в секунду, что в 100 раз больше чем у Ethereum. Другие примеры из первой категории — это Algorand, SpaceMesh, Solana. Все эти протоколы улучшают разные аспекты протокола и позволяют выполнять больше транзакций чем в Ethereum, но все ограничены скоростью одной (пусть и очень мощной) машины.

Hi, I'm one of the developers of the sharded blockchain Near Protocol, and in this article want to talk about what blockchain sharding is, how it is implemented, and what problems exist in blockchain sharding designs.

It is well-known that Ethereum, the most used general purpose blockchain at the time of this writing, can only process less than 20 transactions per second on the main chain. This limitation, coupled with the popularity of the network, leads to high gas prices (the cost of executing a transaction on the network) and long confirmation times; despite the fact that at the time of this writing a new block is produced approximately every 10–20 seconds the average time it actually takes for a transaction to be added to the blockchain is 1.2 minutes, according to ETH Gas Station. Low throughput, high prices, and high latency all make Ethereum not suitable to run services that need to scale with adoption.

На прошлом внутреннем митапе Pyrus мы говорили о современных распределенных хранилищах, а Максим Нальский, CEO и основатель Pyrus, поделился первым впечатлением от FoundationDB. В этой статье рассказываем о технических нюансах, с которыми сталкиваешься при выборе технологии для масштабирования хранения структурированных данных.

Когда сервис недоступен пользователям какое-то время, это дико неприятно, но всё же не смертельно. А вот потерять данные клиента — абсолютно недопустимо. Поэтому любую технологию для хранения данных мы скрупулезно оцениваем по двум-трем десяткам параметров.

В прошлой статье мы рассматривали ограничения и препятствия, которые возникают, когда нужно горизонтально масштабировать данные и иметь гарантию ACID-свойств транзакций. В этой статье рассказываем о технологии FoundationDB и разбираемся, как она помогает преодолеть эти ограничения при разработке mission-critical приложений.

FoundationDB — это распределенная NoSQL база данных с ACID-транзакциями уровня Serializable, хранящая отсортированные пары ключ-значение (ordered key-value store). Ключами и значениями могут быть произвольные последовательности байт. У неё нет единой точки падения — все машины кластера равноправны. Она сама распределяет данные по серверам кластера и  масштабируется на лету: когда в кластер нужно добавить ресурсов, ты просто добавляешь адрес новой машины на конфигурационных серверах и база сама подхватывает ее.

Hi, my name is Vladislav, and I am a member of the Tarantool development team. Tarantool is a DBMS and an application server all in one. Today I am going to tell the story of how we implemented horizontal scaling in Tarantool by means of the VShard module.

Some basic knowledge first.

There are two types of scaling: horizontal and vertical. And there are two types of horizontal scaling: replication and sharding. Replication ensures computational scaling whereas sharding is used for data scaling.

Sharding is also subdivided into two types: range-based sharding and hash-based sharding.

Range-based sharding implies that some shard key is computed for each cluster record. The shard keys are projected onto a straight line that is separated into ranges and allocated to different physical nodes.

Hash-based sharding is less complicated: a hash function is calculated for each record in a cluster; records with the same hash function are allocated to the same physical node.

I will focus on horizontal scaling using hash-based sharding.

Салют, хабровчане! Поздравляем всех с днем программиста и делимся переводом статьи, который был подготовлен специально для студентов курса «Архитектор высоких нагрузок».



«Шардировать. Или не шардировать. Без попыток.»
— Йода

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