Шардинг что это такое
Шардинг
Понравилась статья? Поделись:
Шардинг – это одна из стратегий масштабирования каких-либо приложений. Шардинг стал одной из топовых тем для обсуждения в сообществе Ethereum. Потому что его считают одним из ключевых вариантов решения проблемы масштабируемости этого блокчейна. Термин sharding пришел к нам из английского языка и не имеет перевода. Что это за технология и как ее вндрять на блокчейне?
Содержание
Что такое Шардинг (Sharding)? [ править ]
Как было указано, Шардинг – это стратегия масштабирования приложений. В рамках шардинга информация из общей базы данных делится на блоки и распределяется по разным серверам, которые и называются шардами. Процесс использования этой стратегии называется шардированием. Иногда можно встретить термин партиционирование – это часть шардинга. Так называется процесс разделения базы данных, перед выносом на отдельные сервера.
Шардинг данных разделяют на вертикальный и горизонтальный. Это связано с тем, что база данных изначально представляла собой таблицу. Если разделять таблицу на вертикальные столбцы (заголовок и все данные под ним), то это вертикальный шардинг. Если разделять таблицу по строкам (заголовки всех столбцов и части таблицы под ней), то это горизонтальный шардинг. В любом случае потом части таблицы (то есть базы данных) отправляются на разные сервера.
Зачем применять шардинг? [ править ]
Рано или поздно приложения, которые развиваются, сталкиваются с проблемой масштабирования. Это случается, когда текущий сервер базы данных уже не может так же быстро и эффективно справляться с нагрузкой и давать ответ на запросы приложения. Тогда базу данных и делят на части, отправляя на разные шарды. Также совместно с шардингом часто используют репликацию. В этом случае сервера (шарды) получают копии самих себя. Это повышает отказоустойчивость системы.
Технология шардинга и ее применение [ править ]
Выше мы описали как технология применяется для шардинга базы данных. Технически она выглядит достаточно просто, но на практике применять ее нужно очень внимательно и аккуратно. Потому что когда база данных разбита на части и один запрос должен получить данные с разных шард (серверов), то важно чтобы разделенные данные корректно «собрались» обратно.
Основой большинства криптовалют является транзакция – поэтому в блокчейне шардинг применяется на уровне транзакции. Именно она разбивается на отдельные части, которые также называются шардами. Эти части отправляются на разные узлы и обрабатываются ими. В теории шардинг позволяет криптовалютам ускорить процесс обработки транзакции. Но на практике применить его достаточно сложно.
Сложности реализации блокчейн-шардинга (sharding) [ править ]
Шардинг как средство спасения эфириума [ править ]
С учетом перечисленных выше сложностей, за шардинг никто не берется. Никто, кроме Ethereum. Это единственный достаточно крупный блокчейн, который даже при переходе на Proof-of-stake будет заинтересован в реализации этой технологии.
О шардинге в криптовалютном мире заговорили, когда его назвали одним из способов решения проблемы масштабирования в сети блокчейна Ethereum. Пользователи «эфира» столкнулись с тем, что блокчейн уже не в состоянии обрабатывать растущее количество транзакций. Особенно явно это стало заметно, когда набрала огромную популярность игра Cryptokitties и существенно замедлила работу блокчейна. Эдвард Сноуден описал ситуацию так: «представьте, что для покупки чего-либо вам нужно не просто хранить данные о всех ваших покупках в течение жизни, но и давать доступ к проверке этой базы данных каждый раз, когда вы собираетесь что-то купить».
Презентовал шардинг лично сооснователь Ethereum Виталик Бутерин. Это произошло на тайбэйской конференции BeyondBlock в конце ноября 2017 года. Тогда же была презентована дорожная карта проекта, который по словам разработчиков, должен был вывести Ethereum на уровень платежной системы Visa. Уже через два месяца разработчики отчитались, что первая часть дорожной карты шардинга в блокчейне «эфира» реализована. И в начале мая этого года Виталик Бутерин сообщил, что скоро в сети Ethereum можно будет внедрять шардинг. Правда, для этого придется провести сетевой хардфорк.
Как именно будет внедрен шардинг – пока точно не сообщается. Возможно, проблема доверия между нодами будет решена с помощью внедрения системы материальной стимуляции – когда ноды будут получать вознаграждение за достоверную информацию и будут штрафоваться в случае нарушений. Мы писали выше, что внедрение этой технологии требует алгоритма консенсуса Proof-of-Stake (PoS). И если сейчас сеть «эфира» работает на Proof-of-work (PoW), то скоро она перейдет на протокол Casper, что означает использование гибридного протокола PoW/ PoS. А это приближает внедрение шардинга. 10 мая была выложен первая версия программного обеспечения Casper FFG 0.1.0, которая доступна для тестирования. Пока точной информации о внедрении протокола в Ethereum нет.
Что такое шардинг?
Что такое шардинг?
Шардинг — метод разделения и хранения единого логического набора данных в виде множества баз данных. Другое определение шардинга — горизонтальное разделение данных.
Когда и кто изобрел шардинг?
Концепция шардинга применялась в управлении традиционными централизованными базами данных с конца 1990-х годов. Термин «шард» (фрагмент) получил распространение благодаря одной из первых многопользовательских ролевых онлайн-игр, Ultima Online, в которой разработчики распределили игроков по различным серверам (разным «мирам» в игре), чтобы справиться с трафиком.
Популярный сценарий применения шардинга в бизнесе — разделение базы данных пользователей по географическим локациям. Пользователи, относящиеся к одной географической локации, объединяются в одну группу и размещаются на уникальном сервере.
Что такое шардинг в контексте блокчейна?
Блокчейн — это база данных с нодами, представляющими индивидуальные серверы. Применительно к блокчейну, шардинг подразумевает разделение сети блокчейна на индивидуальные сегменты (шарды). Каждый шард содержит уникальный набор смарт-контрактов и балансов счетов.
За каждым шардом закрепляется нода, верифицирующая транзакции и операции, в отличие от схемы, в которой каждая нода отвечает за верификацию каждой транзакции во всей сети.
Разделение блокчейна на более управляемые сегменты позволяет увеличить пропускную способность транзакций и тем самым решить проблему масштабируемости, с которой сталкивается большинство современных блокчейнов.
Как работает шардинг?
Объяснение на примере Ethereum:
Блокчейн Ethereum состоит из тысяч компьютеров или нод, каждая из которых «одалживает» сети определенный объем хешрейта. Именно этот хешрейт позволяет Ethereum Virtual Machine (EVM) функционировать — выполнять смарт-контракты и управлять децентрализованными приложениями (DApps).
В настоящее время Ethereum работает на основе последовательного выполнения, в котором каждая из нод должна рассчитывать каждую операцию и обрабатывать каждую транзакцию. Поэтому прохождение транзакцией верификационного процесса требует значительного времени: Ethereum осуществляет приблизительно 10 транзакций в секунду, тогда как у Visa, например, этот показатель в районе 24 000.
Добавление к сети компьютеров не обязательно повышает эффективность, поскольку весь реестр хранится на каждом устройстве, и цепь верификации просто становится длиннее.
Идея шардинга состоит в том, чтобы отказаться от модели, в которой каждая нода должна вычислять каждую операцию, в пользу модели параллельного выполнения, в которой ноды обрабатывают только определенные вычисления. Это позволяет параллельно обрабатывать множество транзакций.
Блокчейн разделяется на отдельные шарды (поддомены или сегменты). Ноды управляют только той частью реестра, к которой они прикреплены (выполняют процессы и подтверждают транзакции), а не поддерживают весь реестр.
Какие проблемы решает шардинг?
Шардинг — потенциальное решение проблемы масштабирования.
Чем популярнее становится блокчейн, тем больше пользователей инициируют транзакции, запуск децентрализованных приложений и другие процессы в сети. В результате, скорость транзакций падает, что препятствует расширению блокчейна в долгосрочной перспективе. Рост транзакционной активности требует от нод интенсифицировать процесс верификации транзакций. Существует угроза того, что эти блокчейны могут «закупориться», как это произошло с Ethereum в период бума CryptoKitties, когда на долю игры приходилось 11% транзакций сети.
Если группы нод отвечают за индивидуальные сегменты, то каждой ноде не нужно поддерживать весь реестр для выполнения каждой операции. Поэтому валидация транзакций может осуществляться параллельным, а не линейным образом, что повышает скорость сети. Таким образом решается проблема масштабирования.
Каковы недостатки шардинга?
Основные проблемы шардинга — коммуникация и безопасность. Если разделить блокчейн на изолированные сегменты, то каждый шард станет отдельной сетью. Пользователи и приложения одного поддомена не смогут коммуницировать с пользователями и приложениями другого поддомена, не применяя особый механизм коммуникации.
В сегментированном блокчейне также возникает проблема безопасности, поскольку хакерам легче захватить один шард — по причине меньшего хешрейта, требуемого для контроля индивидуальных сегментов (так называемая атака 1%).
После захвата сегмента атакующие могут направить недействительные транзакции в основную сеть. Также данные в этом конкретном сегменте могут стать недействительными и оказаться безвозвратно утрачены. Ethereum предлагает решение в виде рандомизированной выборки — протоколы шарда случайным образом назначаются в различные секции для подтверждения аутентификации блоков.
Каковы альтернативы шардингу?
Разработчики предложили два решения, позволяющих повысить производительность и скорость транзакций в блокчейнах.
Первое решение — увеличение размера блока. Ключевая идея — чем больше размер блока, тем больше транзакций можно поместить в него и, следовательно, тем больше число транзакций в секунду.
Однако чем больше блок, тем больше вычислительной мощности необходимо для его верификации. Если размер блока увеличить значительно, то лишь наиболее мощные компьютеры смогут управлять вычислительной мощностью, необходимой для деятельности в качестве нод.
Высокая стоимость такого компьютерного оборудования означает, что пулы нод неизбежно станут меньшего размера и более централизованными, что повышает риск атаки 51%. Увеличение размера блока также требует хардфорка, который грозит расколом сообщества: если не все пользователи примут обновление, то возникнут две разные цепи, использующие разные монеты. Увеличение размера блока не может быть долгосрочным решением.
Второе предложение — использовать альткоины с тем, чтобы различные функции и приложения были реализованы на собственных сетях с собственными монетами.
Такая модель повысит производительность, поскольку единый блокчейн не будет перегружен, но также увеличит риски безопасности, поскольку вычислительная мощность будет распределена по нескольким блокчейнам. Опять же, риск взлома сети возрастет и потому, что вычислительная мощность, необходимая для осуществления атаки 51%, будет гораздо меньше.
Кто использует шардинг?
Zilliqa — первая платформа, внедрившая шардинг. На стадии тестнета она сумела достичь показателя в 2828 транзакций в секунду.
Экосистема блокчейна Near позволяет разработчикам создавать и применять децентрализованные приложения. Near называет себя «шардированным блокчейном на PoS» и утверждает, что его технология шардинга позволяет нодам оставаться достаточно небольшими для того, чтобы функционировать на устройствах невысокой производительности — потенциально даже на мобильных телефонах.
Ethereum предлагает экосистему блокчейна для внедрения DApps на основе смарт-контрактов. Ethereum Foundation планирует включить шардинг в обновленную версию протокола Ethereum 2.0.
Среди прочих работающих с шардингом проектов: Cardano, QuarkChain и PChain.
Каково будущее шардинга?
Технология шардинга фигурирует в white paper цифровой валюты Libra. В преддверии запуска компания Facebook приобрела компанию Chainspace, чья команда разработчиков специализируется на шардинге. Конкретные детали пока неизвестны, но можно предположить, что в блокчейн Libra внедрят разновидность шардинга.
Шардинг теоретически может стать решением так называемой трилеммы блокчейна.
Трилемма блокчейна, как пояснил Виталик Бутерин, состоит в том, что одновременно можно сохранять только две из трех ключевых особенностей блокчейна — безопасности, децентрализации и масштабируемости. Если преодолеть сложности, с которыми сталкивается шардинг, то можно будет масштабировать распределенные сети, не жертвуя децентрализацией или безопасностью.
Подписывайтесь на новости Forklog в Facebook!
Масштабирование базы данных через шардирование и партиционирование
Масштабирование базы данных через шардирование и партиционирование
Денис Иванов (2ГИС)
Всем привет! Меня зовут Денис Иванов, и я расскажу о масштабировании баз данных через шардирование и партиционирование. После этого доклада у всех должно появиться желание что-то попартицировать, пошардировать, вы поймете, что это очень просто, оно никак жрать не просит, работает, и все замечательно.
Немного расскажу о себе — я работаю в команде WebAPI в компании 2GIS, мы предоставляем API для организаций, у нас очень много разных данных, 8 стран, в которых мы работаем, 250 крупных городов, 50 тыс. населенных пунктов. У нас достаточно большая нагрузка — 25 млн. активных пользователей в месяц, и в среднем нагрузка около 2000 RPS идет на API. Все это располагается в трех датацентрах.
Перейдем к проблемам, которые мы с вами сегодня будем решать. Одна из проблем — это большое количество данных. Когда вы разрабатываете тот или иной проект, у вас в любой момент времени может случиться так, что данных становится очень много. Если бизнес работает, он приносит деньги. Соответственно, данных больше, денег больше, и с этими данными что-то нужно делать, потому что эти запросы очень долго начинают выполняться, и у нас сервер начинает не вывозить. Одно из решений, что с этими данными делать — это масштабирование базы данных.
Я в большей степени расскажу про шардинг. Он бывает вертикальным и горизонтальным. Также бывает такой способ масштабирования как репликация. Доклад «Как устроена MySQL репликация» Андрея Аксенова из Sphinx про это и был. Я эту тему практически не буду освещать.
Перейдем подробнее к теме партицирования (вертикальный шардинг). Как это все выглядит?
У нас есть большая таблица, например, с пользователями — у нас очень много пользователей. Партицирование — это когда мы одну большую таблицу разделяем на много маленьких по какому-либо принципу.
С горизонтальным шардингом все примерно так же, но при этом у нас таблички лежат в разных базах на других инстансах.
Единственное отличие горизонтального масштабирования от вертикального в том, что горизонтальное масштабирование будет разносить данные по разным инстансам.
Про репликацию я не буду останавливаться, тут все очень просто.
Перейдем глубже к этой теме, и я расскажу практически все о партицировании на примере Postgres’а.
Давайте рассмотрим простую табличку, наверняка, практически в 99% проектов такая табличка есть — это новости.
У новости есть идентификатор, есть категория, в которой эта новость расположена, есть автор новости, ее рейтинг и какой-то заголовок — совершенно стандартная таблица, ничего сложного нет.
Как же эту таблицу разделить на несколько? С чего начать?
Всего нужно будет сделать 2 действия над табличкой — это поставить у нашего шарда, например, news_1, то, что она будет наследоваться таблицей news. News будет базовой таблицей, будет содержать всю структуру, и мы, создавая партицию, будем указывать, что она наследуется нашей базовой таблицей. Наследованная таблица будет иметь все колонки родителя — той базовой таблицы, которую мы указали, а также она может иметь свои колонки, которые мы дополнительно туда добавим. Она будет полноценной таблицей, но унаследованной от родителя, и там не будет ограничений, индексов и триггеров от родителя — это очень важно. Если вы на базовой таблице насоздаете индексы и унаследуете ее, то в унаследованной таблице индексов, ограничений и триггеров не будет.
2-ое действие, которое нужно сделать — это поставить ограничения. Это будет проверка, что в эту таблицу будут попадать данные только вот с таким признаком.
В данном случае признак — это category_id=1, т.е. только записи с category_id=1 будут попадать в эту таблицу.
Какие типы проверок бывают для партицированных таблиц?
Бывает строгое значение, т.е. у нас какое-то поле четко равно какому-то полю. Бывает список значений — это вхождение в список, например, у нас может быть 3 автора новости именно в этой партиции, и бывает диапазон значений — это от какого и до какого значения данные будут храниться.
Тут нужно подробнее остановиться, потому что проверка поддерживает оператор BETWEEN, наверняка вы все его знаете.
И так просто его сделать можно. Но нельзя. Можно сделать, потому что нам разрешат такое сделать, PostgreSQL поддерживает такое. Как вы видите, у нас в 1-ую партицию попадают данные между 100 и 200, а во 2-ую — между 200 и 300. В какую из этих партиций попадет запись с рейтингом 200? Не известно, как повезет. Поэтому так делать нельзя, нужно указывать строгое значение, т.е. строго в 1-ую партицию будут попадать значения больше 100 и меньше либо равно 200, и во вторую больше 200, но не 200, и меньше либо равно 300.
Это обязательно нужно запомнить и так не делать, потому что вы не узнаете, в какую из партиций данные попадут. Нужно четко прописывать все условия проверки.
Также не стоит создавать партиции по разным полям, т.е. что в 1-ую партицию у нас будут попадать записи с category_id=1, а во 2-ую — с рейтингом 100.
Опять же, если нам придет такая запись, в которой category_id = 1 и рейтинг =100, то неизвестно в какую из партиций попадет эта запись. Партицировать стоит по одному признаку, по какому-то одному полю — это очень важно.
Давайте рассмотрим нашу партицию целиком:
Ваша партицированная таблица будет выглядеть вот так, т.е. это таблица news_1 с признаком, что туда будут попадать записи только с category_id = 1, и эта таблица будет унаследована от базовой таблицы news — все очень просто.
Мы на базовую таблицу должны добавить некоторое правило, чтобы, когда мы будем работать с нашей основной таблицей news, вставка на запись с category_id = 1 попала именно в ту партицию, а не в основную. Мы указываем простое правило, называем его как хотим, говорим, что когда данные будут вставляться в news с category_id = 1, вместо этого будем вставлять данные в news_1. Тут тоже все очень просто: по шаблончику оно все меняется и будет замечательно работать. Это правило создается на базовой таблице.
Таким образом мы заводим нужное нам количество партиций. Для примера я буду использовать 2 партиции, чтобы было проще. Т.е. у нас все одинаково, кроме наименований этой таблицы и условия, по которому данные будут туда попадать. Мы также заводим соответствующие правила по шаблону на каждую из таблиц.
Давайте рассмотрим пример вставки данных:
Данные будем вставлять как обычно, будто у нас обычная большая толстая таблица, т.е. мы вставляем запись с category_id=1 с category_id=2, можем даже вставить данные с category_id=3.
Вот мы выбираем данные, у нас они все есть:
Все, которые мы вставляли, несмотря на то, что 3-ей партиции у нас нет, но данные есть. В этом, может быть, есть немного магии, но на самом деле нет.
Мы также можем сделать соответствующие запросы в определенные партиции, указывая наше условие, т.е.category_id = 1, или вхождение в числа (2, 3).
Все будет замечательно работать, все данные будут выбираться. Опять же, несмотря на то, что с партиции с category_id=3 у нас нет.
Мы можем выбирать данные напрямую из партиций — это будет то же самое, что в предыдущем примере, но мы четко указываем нужную нам партицию. Когда у нас стоит точное условие на то, что нам именно из этой партиции нужно выбрать данные, мы можем напрямую указать именно эту партицию и не ходить в другие. Но у нас нет 3-ей партиции, а данные попадут в основную таблицу.
Хоть у нас и применено партицирование к этой таблице, основная таблица все равно существует. Она настоящая таблица, она может хранить данные, и с помощью оператора ONLY можно выбрать данные только из этой таблицы, и мы можем найти, что эта запись здесь спряталась.
Здесь можно, как видно на слайде, вставлять данные напрямую в партицию. Можно вставлять данные с помощью правил в основную таблицу, но можно и в саму партицию.
Если мы будем вставлять данные в партицию с каким-то чужеродным условием, например, с category_id = 4, то мы получим ошибку «сюда такие данные нельзя вставлять» — это тоже очень удобно — мы просто будем класть данные только в те партиции, которые нам действительно нужно, и если у нас что-то пойдет не так, мы на уровне базы все это отловим.
Тут пример побольше. Можно bulk_insert использовать, т.е. вставлять несколько записей одновременно и они все сами распределятся с помощью правил нужной партиции. Т.е. мы можем вообще не заморачиваться, просто работать с нашей таблицей, как мы раньше и работали. Приложение продолжит работать, но при этом данные будут попадать в партиции, все это будет красиво разложено по полочкам без нашего участия.
Напомню, что мы можем выбирать данные как из основной таблицы с указанием условия, можем, не указывая это условие выбирать данные из партиции. Как это выглядит со стороны explain’а:
У нас будет Seq Scan по всей таблице целиком, потому что туда данные могут все равно попадать, и будет скан по партиции. Если мы будем указывать условия нескольких категорий, то он будет сканировать только те таблицы, на которые есть условия. Он не будет смотреть в остальные партиции. Так работает оптимизатор — это правильно, и так действительно быстрее.
Мы можем посмотреть, как будет выглядеть explain на самой партиции.
Это будет обычная таблица, просто Seq Scan по ней, ничего сверхъестественного. Точно так же будут работать update’ы и delete’ы. Мы можем update’тить основную таблицу, можем также update’ы слать напрямую в партиции. Так же и delete’ы будут работать. На них нужно так же соответствующие правила создать, как мы создавали с insert’ом, только вместо insert написать update или delete.
Перейдем к такой вещи как Index’ы
Индексы, созданные на основной таблице, не будут унаследованы в дочерней таблице нашей партиции. Это грустно, но придется заводить одинаковые индексы на всех партициях. С этим есть что поделать, но придется заводить все индексы, все ограничения, все триггеры дублировать на все таблицы.
Как мы с этой проблемой боролись у себя. Мы создали замечательную утилиту PartitionMagic, которая позволяет автоматически управлять партициями и не заморачиваться с созданием индексов, триггеров с несуществующими партициями, с какими-то бяками, которые могут происходить. Эта утилита open source’ная, ниже будет ссылка. Мы эту утилиту в виде хранимой процедуры добавляем к нам в базу, она там лежит, не требует дополнительных extension’ов, никаких расширений, ничего пересобирать не нужно, т.е. мы берем PostgreSQL, обычную процедуру, запихиваем в базу и с ней работаем.
Вот та же самая таблица, которую мы рассматривали, ничего нового, все то же самое.
Как же нам запартицировать ее? А просто вот так:
Мы вызываем процедуру, указываем, что таблица будет news, и партицировать будем по category_id. И все дальше будет само работать, нам больше ничего не нужно делать. Мы так же вставляем данные.
У нас тут три записи с category_id =1, две записи с category_id=2, и одна с category_id=3.
После вставки данные автоматически попадут в нужные партиции, мы можем сделать селекты.
Все, партиции уже создались, все данные разложились по полочкам, все замечательно работает.
Какие мы получаем за счет этого преимущества:
Перейдем ко второй части доклада — это горизонтальный шардинг. Напомню, что горизонтальный шардинг — это когда мы данные разносим по нескольким серверам. Все это делается тоже достаточно просто, стоит один раз это настроить, и оно будет работать замечательно. Я расскажу подробнее, как это можно сделать.
Рассматривать будем такую же структуру с двумя шардами — news_1 и news_2, но это будут разные инстансы, третьим инстансом будет основная база, с которой мы будем работать:
Та же самая таблица:
Единственное, что туда нужно добавить, это CONSTRAINT CHECK, того, что записи будут выпадать только с category_id=1. Так же, как в предыдущем примере, но это не унаследованная таблица, это будет таблица с шардом, которую мы делаем на сервере, который будет выступать шардом с category_id=1. Это нужно запомнить. Единственное, что нужно сделать — это добавить CONSTRAINT.
Мы еще можем дополнительно создать индекс по category_id:
Несмотря на то, что у нас стоит check — проверка, PostgreSQL все равно обращается в этот шард, и шард может очень надолго задуматься, потому что данных может быть очень много, а в случае с индексом он быстро ответит, потому что в индексе ничего нет по такому запросу, поэтому его лучше добавить.
Как настроить шардинг на основном сервере?
Мы подключаем EXTENSION. EXTENSION идет в Postgres’e из коробки, делается это командой CREATE EXTENSION, называется он postgres_fdw, расшифровывается как foreign data wrapper.
Далее нам нужно завести удаленный сервер, подключить его к основному, мы называем его как угодно, указываем, что этот сервер будет использовать foreign data wrapper, который мы указали.
Таким же образом можно использовать для шарда MySql, Oracle, Mongo… Foreign data wrapper есть для очень многих баз данных, т.е. можно отдельные шарды хранить в разных базах.
В опции мы добавляем хост, порт и имя базы, с которой будем работать, нужно просто указать адрес вашего сервера, порт (скорее всего, он будет стандартный) и базу, которую мы завели.
Далее мы создаем маппинг для пользователя — по этим данным основной сервер будет авторизироваться к дочернему. Мы указываем, что для сервера news_1 будет пользователь postgres, с паролем postgres. И на основную базу данных он будет маппиться как наш user postgres.
Я все со стандартными настройками показал, у вас могут быть свои пользователи для проектов заведены, для отдельных баз, здесь нужно именно их будет указать, чтобы все работало.
Далее мы заводим табличку на основном сервере:
Это будет табличка с такой же структурой, но единственное, что будет отличаться — это префикс того, что это будет foreign table, т.е. она какая-то иностранная для нас, отдаленная, и мы указываем, с какого сервера она будет взята, и в опциях указываем схему и имя таблицы, которую нам нужно взять.
Схема по дефолту — это public, таблицу, которую мы завели, назвали news. Точно так же мы подключаем 2-ую таблицу к основному серверу, т.е. добавляем сервер, добавляем маппинг, создаем таблицу. Все, что осталось — это завести нашу основную таблицу.
Это делается с помощью VIEW, через представление, мы с помощью UNION ALL склеиваем запросы из удаленных таблиц и получаем одну большую толстую таблицу news из удаленных серверов.
Также мы можем добавить правила на эту таблицу при вставке, удалении, чтобы работать с основной таблицей вместо шардов, чтобы нам было удобнее — никаких переписываний, ничего в приложении не делать.
Мы заводим основное правило, которое будет срабатывать, если ни одна проверка не сработала, чтобы не происходило ничего. Т.е. мы указываем DO INSTEAD NOTHING и заводим такие же проверки, как мы делали ранее, но только с указанием нашего условия, т.е. category_id=1 и таблицу, в которую данные вместо этого будут попадать.
Т.е. единственное отличие — это в category_id мы будем указывать имя таблицы. Также посмотрим на вставку данных.
Я специально выделил несуществующие партиции, т.к. эти данные по нашему условию не попадут никуда, т.е. у нас указано, что мы ничего не будем делать, если не нашлось никакого условия, потому что это VIEW, это не настоящая таблица, туда данные вставить нельзя. В том условии мы можем написать, что данные будут вставляться в какую-то третью таблицу, т.е. мы можем завести что-то типа буфера или корзины и INSERT INTO делать в ту таблицу, чтобы там копились данные, если вдруг каких-то партиций у нас нет, и данные стали приходить, для которых нет шардов.
Выбираем данные
Обратите внимание на сортировку идентификаторов — у нас сначала выводятся все записи из первого шарда, затем из второго. Это происходит из-за того, что postgres ходит по VIEW последовательно. У нас указаны select’ы через UNION ALL, и он именно так исполняет — посылает запросы на удаленные машины, собирает эти данные и склеивает, и они будут отсортированы по тому принципу, по которому мы эту VIEW создали, по которому тот сервер отдал данные.
Делаем запросы, какие мы делали ранее из основной таблицы с указанием категории, тогда postgres отдаст данные только из второго шарда, либо напрямую обращаемся в шард.
Так же, как и в примерах выше, только у нас разные сервера, разные инстансы, и все точно так же работает как работало раньше.
Посмотрим на explain.
У нас foreign scan по news_1 и foreign scan по news_2, так же, как было с партицированием, только вместо Seq Scan-а у нас foreign scan — это удаленный скан, который выполняется на другом сервере.
Партицирование — это действительно просто, стоит всего лишь несколько действий совершить, все настроить, и оно все будет замечательно работать, не будет просить есть. Можно так же работать с основной таблицей, как мы работали ранее, но при этом у нас все красиво лежит по полочкам и готово к масштабированию, готово к большому количеству данных. Все это работает на одном сервере, и при этом мы получаем прирост производительности в 3-4 раза, за счет того, что у нас объем данных в таблице сокращается, т.к. это разные таблицы.
Шардинг — лишь немного сложнее партицирования, тем, что нужно настраивать каждый сервер по отдельности, но это дает некое преимущество в том, что мы можем просто бесконечное количество серверов добавлять, и все будет замечательно работать.