Настройка шардинга базы данных - нет запросов к базе данных

Question

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

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

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

Действительно, я просто ищу простой «полный» пример (надеюсь, с использованием Spring / Java).

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

   • * 1014 Идентификатор_пользователя *
   • База данных / осколок-идентификатор

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

2. Может ли кто-нибудь дать общий обзор того, как это может быть связано весной? В настоящее время моя архитектура очень проста. У меня есть простой компонент DAO Spring с использованием jdbctemplate. Источник данных DAO внедряется (источник данных настраивается в applicationContext.xml). DAO автоматически подключены к моим классам обслуживания. Довольно стандартные вещи.

3. Допустим, я выполнил предыдущий шаг, и теперь мне нужно изменить схему. Существуют ли инструменты управления, которые я могу использовать, чтобы применить изменение схемы один раз и распространить его на 100 других баз данных?

Я использую MySQL. Я считаю, что «MySQL Proxy» может решить проблемы 1 и 2. У кого-нибудь есть опыт работы с этим? Я полагаю, что он не справляется с управлением обновлениями схемы, поэтому мне, возможно, придется развернуть свое собственное решение.

Спасибо!

Answer 1

Я использую пружину и шард в моей компании, идея в том, что

1. Вы бы реализовали ShardDataSourceManager, который был бы в основном пулом соединений, и вы бы искали источник данных по идентификатору шарда.
2. Вы можете определить свои собственные Транзакционные аннотации и аннотировать методы с ним
3. Вам нужно написать перехватчик на слое дао, который будет читать аннотации о методе и некоторую контекстную информацию. Из контекстной информации вы будете искать Shard ID и поиск источник данных и вводить в локальный поток.
4. Слой dao при поиске источника данных изучит локальный поток для создания шаблона jdbc и выполнения запросов к нему.

Answer 2

Вы можете использовать DDAL для реализации доступа к различным базам данных в DAL, и он не зависит от источника данных Spring и управления транзакциями. И есть демонстрационный проект, чтобы показать, как его использовать: https://github.com/hellojavaer/ddal-demos. Вы можете попробовать.

Answer 3

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

Answer 4

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

Новая архитектура Relic - Сбор 20+ миллиардов метрик в день

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

Answer 5

Я не могу разговаривать с Spring, потому что я им не пользуюсь.

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

Теперь я уверен, что это можно сделать с помощью Spring, я просто не могу сказать вам, как.

Насколько хорошо обычные реализации пула соединений с базами данных обрабатывают «100 баз данных» с любым количеством соединений, это другой вопрос (на ум приходят видения нескольких сотен открытых сокетов соединений). Я тоже не могу говорить об этом, не сделав этого.

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

Это было бы моим первым решением проблемы до тех пор, пока она не провалилась при тестировании, но я предполагаю, что точкой сбоя будет реализация пула БД или связанная с этим. Все остальное - это типичный сервер БД и Java.