Что такое осколки и почему это важно?

Ответ 1

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

От Wikipedia:

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

Дополнительная информация о sharding:

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

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

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

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

Ответ 2

Если у вас есть запросы к СУБД, для которых местность довольно ограничена (например, пользователь только запускает выбор с помощью "где username = $my_username" ), имеет смысл поставить все имена пользователей, начиная с AN на одном сервере, и все из МЗ - с другой. При этом вы получите линейное масштабирование для некоторых запросов.

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

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

Ответ 3

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

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

Ответ 4

Является ли осколок главным образом важным в широкомасштабных приложений или делает это применяются к более мелким масштабам?

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

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

Ответ 5

По-моему, уровень заявки не должны определять бизнес где данные должны быть сохранены

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

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

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