Что такое шардинг и почему это важно?

Question

Я думаю, что я понимаю, что осколки - это возврат ваших нарезанных данных (осколков) в простое для работы с агрегатом, что имеет смысл в контексте. Это правильно?

Обновление : Я думаю, что я борюсь здесь. По моему мнению, уровень приложений не должен определять бизнес, где должны храниться данные. В лучшем случае это должен быть клиент-шард. Оба ответа ответили на вопрос «что, но не почему?». Какие последствия это имеет помимо очевидного прироста производительности? Достаточно ли этих усилений для компенсации нарушения MVC? Черепок является наиболее важным в приложениях очень большого масштаба или он применяется в более мелких приложениях?

Answer 1

Sharding - это еще одно название для «горизонтального разбиения» базы данных. Возможно, вы захотите найти этот термин, чтобы прояснить его.

Из Википедия :

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

Еще немного информации о шардинге:

Во-первых, каждый сервер базы данных идентичен и имеет одинаковую структуру таблиц. Во-вторых, записи данных логически разделяются в изолированной базе данных. В отличие от многораздельной базы данных, каждая полная запись данных существует только в одном сегменте (если нет зеркалирования для резервного копирования / избыточности), причем все операции CRUD выполняются только в этой базе данных. Возможно, вам не понравится используемая терминология, но она представляет собой другой способ организации логической базы данных на более мелкие части.

Обновление: Вы не сломаете MVC. Работа по определению правильного шарда, в котором будут храниться данные, будет прозрачно выполняться вашим уровнем доступа к данным. Там вам нужно будет определить правильный шард на основе критериев, которые вы использовали для шардирования вашей базы данных. (Так как вам нужно вручную разделять базу данных на несколько различных сегментов, основываясь на некоторых конкретных аспектах вашего приложения.) Затем вы должны позаботиться о загрузке и хранении данных из / в базу данных, чтобы использовать правильный фрагмент.

Может быть этот пример с кодом Java делает несколько более понятным (это касается проекта Hibernate Shards ), как это будет работать в сценарии реального мира.

Обращаясь к «why sharding»: это в основном только для очень крупных приложений с партиями данных. Во-первых, это помогает минимизировать время отклика на запросы к базе данных. Во-вторых, вместо одного большого сервера вы можете использовать более дешевые машины более низкого уровня вместо одного большого сервера, которого может быть недостаточно.

Answer 2

Если у вас есть запросы к СУБД, для которых локальность довольно ограничена (скажем, пользователь только запускает селекторы с «где username = $ my_username»), имеет смысл поместить все имена пользователей, начинающиеся с AM, на один сервер и все из новозеландцев на другой. Таким образом, вы получаете почти линейное масштабирование для некоторых запросов.

Короткая история : Шардинг - это, по сути, процесс распределения таблиц на разные серверы для равномерного распределения нагрузки на оба.

Конечно, в реальности все намного сложнее. :)

Answer 3

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

Зачем нам нужны распределенные системы?

• Увеличение доступности.
• Более простое расширение.
• Экономика: создание сети меньших компьютеров с мощностью одного большого компьютера обходится дешевле.

Подробнее вы можете прочитать здесь: Преимущества распределенной базы данных

Как шардинг помогает распределенной системе?

Вы можете разбить поисковый индекс на N разделов и загрузить каждый индекс на отдельный сервер. Если вы запросите один сервер, вы получите 1 / Nth результатов. Таким образом, чтобы получить полный набор результатов, типичная распределенная поисковая система использует агрегатор , который будет накапливать результаты с каждого сервера и объединять их. Агрегатор также распределяет запрос на каждый сервер. Эта агрегаторная программа называется MapReduce в терминологии больших данных. Другими словами, Распределенные системы = Sharding + MapReduce (хотя есть и другие вещи).

Визуальное представление ниже.

Answer 4

Шардинг важен в очень крупномасштабные приложения или делает это применить к более мелким?

Осколок является проблемой тогда и только тогда, когда ваши потребности превзойдут то, что может обслуживать один сервер базы данных. Это отличный инструмент, если у вас есть надежные данные и у вас невероятно высокие требования к масштабируемости и производительности. Я предполагаю, что за все 12 лет, что я был профессионалом в области программного обеспечения, я столкнулся с одной ситуацией, которая могла бы выиграть от шардинга. Это продвинутая техника с очень ограниченной применимостью.

Кроме того, будущее, вероятно, будет чем-то увлекательным и захватывающим, как массивное объектное «облако», которое стирает все потенциальные ограничения производительности, верно? :)

Answer 5

Изначально Sharding был придуман инженерами Google, и вы можете видеть, что он довольно активно используется при написании приложений в Google App Engine. Поскольку существуют жесткие ограничения на количество ресурсов, которые могут использоваться вашими запросами, а сами запросы имеют строгие ограничения, шардинг не только поощряется, но и почти полностью обеспечивается архитектурой.

Еще одно место, где можно использовать сегментирование, - это уменьшить конкуренцию за объекты данных. При создании масштабируемых систем особенно важно следить за частями записи, которые часто записываются, потому что они всегда являются узким местом. Хорошее решение состоит в том, чтобы отделить эту конкретную сущность и записать ее в несколько копий, а затем прочитать итоги. Пример этого "счетчика с осколками по GAE: http://code.google.com/appengine/articles/sharding_counters.html

Answer 6

Sharding делает больше, чем просто горизонтальное разбиение. Согласно статье Википедии ,

Горизонтальное разбиение разделяет одну или несколько таблиц по строкам, как правило, в пределах одного экземпляра схемы и сервера базы данных. Это может дать преимущество за счет уменьшения размера индекса (и, следовательно, усилий по поиску), при условии, что существует некоторый очевидный, надежный, неявный способ определить, в каком разделе будет найдена конкретная строка, без необходимости предварительного поиска в индексе, например, в классическом Пример таблиц CustomersEast и CustomersWest, где их почтовый индекс уже указывает, где они будут найдены.

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

Кроме того,

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

Answer 7

На мой взгляд уровень приложения не должен иметь никакого делового определения где данные должны храниться

Это хорошее правило, но, как и большинство вещей, не всегда правильное.

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

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