Что такое sharding и почему это важно?
Существует универсальный класс TreeBasedTable из библиотеки Google guava , который делает именно то, что вы просите. Он также предлагает множество других полезных служебных методов, и его использование показано в руководстве пользователя .
Из TreeBasedTable документов:
Реализация таблицы, чьи ключи строк и ключи столбцов упорядочены по их естественному упорядочению или предоставленными компараторами.
Пример использования:
RowSortedTable weightedGraph = TreeBasedTable.create();
weightedGraph.put(v2, v3, 4.0);
weightedGraph.put(v1, v2, 20.0);
System.out.println( weightedGraph.rowKeySet() ); // prints [v1, v2]
4 ответа
Шардинг - это просто еще одно название для «горизонтальное разбиение» базы данных. Вы можете поискать этот термин, чтобы прояснить его.
Из Wikipedia :
Горизонтальное разбиение - это принцип конструкции, согласно которому строки таблицы базы данных хранятся отдельно, а не разбиваются по столбцам ( что касается нормализации). Каждый раздел образует часть осколка, который, в свою очередь, может располагаться на отдельном сервере базы данных или физическом месте. Преимущество состоит в том, что количество строк в каждой таблице уменьшается (это уменьшает размер индекса и, следовательно, повышает производительность поиска). Если сегментирование основано на каком-либо реальном аспекте данных (например, европейские клиенты и американские клиенты), тогда можно легко и автоматически вывести соответствующее членство в сегменте и запросить только соответствующий сегмент.
Еще немного. информация о сегментировании:
Во-первых, все серверы баз данных идентичны, имеют одинаковую структуру таблиц. Во-вторых, записи данных логически разделяются в сегментированной базе данных. В отличие от многораздельной базы данных, каждая полная запись данных существует только в одном сегменте (если нет зеркального отображения для резервного копирования / избыточности), при этом все операции CRUD выполняются только в этой базе данных. Возможно, вам не понравится используемая терминология, но это действительно другой способ организации логической базы данных на более мелкие части.
Обновление: Вы не сломаете MVC. Работа по определению правильного сегмента, в котором будут храниться данные, будет прозрачно выполняться вашим уровнем доступа к данным. Здесь вам нужно будет определить правильный сегмент на основе критериев, которые вы использовали для сегментирования своей базы данных. (Поскольку вам нужно вручную разбить базу данных на несколько разных осколков в зависимости от некоторых конкретных аспектов вашего приложения.) Затем вы должны позаботиться о загрузке и хранении данных из / в базе данных, чтобы использовать правильный осколок.
Возможно, этот пример с кодом Java делает его несколько более понятным (речь идет о проекте Hibernate Shards ), как это будет работать в сценарии реального мира.
Для решения проблемы " почему сегментирование ": это в основном только для очень больших приложений с большим количеством данных. Первый, это помогает минимизировать время ответа на запросы к базе данных. Во-вторых, вы можете использовать более дешевые машины "более низкого уровня" для размещения ваших данных вместо одного большого сервера, которого может больше не хватить.
Если у вас есть запросы к СУБД, для которых местоположение довольно ограничено (например, пользователь запускает выбор только с 'where username = $ my_username'), имеет смысл поместить все имена пользователей начиная с AM на одном сервере и все из Новой Зеландии на другом. Благодаря этому вы приближаетесь к линейному масштабированию для некоторых запросов.
Короче говоря : Шардинг - это, по сути, процесс распределения таблиц по разным серверам для равномерного распределения нагрузки на оба сервера.
Конечно, это так. на самом деле намного сложнее. :)
Шардинг наиболее важен в очень крупномасштабные приложения или делает это применимы к более мелким?
Шардинг вызывает беспокойство тогда и только тогда, когда ваши потребности превышают возможности, которые может обслуживать один сервер базы данных. Это отличный инструмент, если у вас есть данные, которые можно сегментировать, и у вас есть невероятно высокие требования к масштабируемости и производительности. Я предполагаю, что за все мои 12 лет, которые я был профессионалом в области программного обеспечения, я столкнулся с одной ситуацией, в которой можно было бы выиграть от шардинга. Это продвинутая технология с очень ограниченной применимостью.
Кроме того, будущее, вероятно, будет чем-то забавным и захватывающим, как массивное «облако» объектов, которое стирает все потенциальные ограничения производительности, верно? :)
На мой взгляд, уровень приложения не должно иметь никакого дела определения где должны храниться данные
Это хорошее правило, но, как и большинство других вещей, не всегда правильно.
Когда вы создаете свою архитектуру, вы начинаете с ответственности и сотрудничества. Как только вы определите свою функциональную архитектуру, вы должны сбалансировать нефункциональные силы.
Если одной из этих нефункциональных сил является огромная масштабируемость, вы должны адаптировать свою архитектуру, чтобы удовлетворить эту силу, даже если это означает, что ваша абстракция хранилища данных теперь просачивается на уровень вашего приложения.