Разделение базы данных MySQL на клиента

Question

Я работаю над сравнительно небольшой базой данных.Всего в нем 67 таблиц и чуть более миллиона записей.Это около 254 МБ.Приложение, которое работает с ним, работает уже около 5 лет, и объем использования удваивается каждый год.В этом году мы планируем утроить, что почти удвоит базу данных за один сезон.Мои вопросы, это плохая идея разбить базу данных на несколько баз данных.Скажем, у нас есть 300 клиентов, тогда он будет создавать 300 отдельных баз данных, содержащих 67 таблиц, но только данные, относящиеся к этому клиенту.Нет особой причины для объединения данных, кроме внутренней статистики, которая может быть выполнена на другом сервере.Мы не должны становиться больше, чем 10 000 клиентов за все время его жизни.

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

Кроме того, репликация будет проблемой при добавлении нового клиента.

Приложение на уровне кода в значительной степени настроено для этого типа установки.

Есть ли что-то, чего мне не хватает?Это ужасная идея?

База данных была создана на скорую руку (не мной), не думая о будущем, и теперь это моя ответственность.

Предстоит еще многое сделать для нормализации, аудита типов полей, оптимизации sql, индексации и настройки сервера.Любая обратная связь будет принята с благодарностью.

Answer 1

У вас на руках полно «нормализации, аудита типов полей, оптимизации SQL, индексации и настройки сервера»

Нет веских причин разделять это на 300 баз данных. И много веских причин не для того, что вы сформулировали. Пока CustomerId четко разделяет данные клиента через базу данных, у вас все в порядке.

Так что работай над тем, что тебе нужно, и не отдавай себя более ненужной работе.

Когда размер базы данных и ее низкая скорость требуют этого, переходите на настоящую платформу SQL.

Answer 2

В настоящее время у вас есть четверть гигабайта данных.Вы предполагаете, что это удвоение (половина концерта) в этом году.Это 1997?Нет, это 2010 год, и у людей есть гигабайты данных на их телефонах .

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

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

Могут быть некоторые вопросы, на которые лучше всего ответить «десять тысяч баз данных», но не очень много.

---

"Наш крупнейший клиент добавляет около 12000 записей в год."

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

«Идея состоит в том, что клиент скорее просматривает все данные, он просто получает доступ к своим данным.»

Но это не много данных и, конечно, ничегочто достойная стратегия индексирования не может исправить.

Я до сих пор не понимаю, есть ли у вас настоящая реальная проблема сейчас или вы просто думаете о чем-то, что может быть проблемой вкакой-то момент в будущем.

Answer 3

Давайте посмотрим на SAP ERP.Это потенциально может вместить тысячи клиентов и миллиарды рекодеров.Это надежная система питания.И все таблицы в нем (кроме системных таблиц) имеют поле «MANDT», в котором указан клиент.Offcource SAP обычно работает с ORACLE, но в вашем случае этого не достаточно из-за небольшой части данных.
Итак, в соответствии с успешной историей SAP и добрыми мнениями о MySQL как о хороших СУБД, я могу заключить, что вам не следует забывать о БДклиентов.Это не даст много

Answer 4

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

Answer 5

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

Но есть и другие соображения.Вы упоминаете, что размер сегодня составляет 1 миллион строк при 256 МБ.Это должно быть очень легко в пределах досягаемости товарного сервера.Так что, если вы ожидаете роста в наихудшем случае в 5 раз каждый год, вы говорите о 5 миллионах строк в этом году, 25 следующих, 125 третьих, 625 четвертых и 3125 миллионов пятых.Даже 3 миллиарда строк (в зависимости от точного использования и типов запросов) не так сложно обработать для MySQL (все еще в пределах верхнего диапазона обычного сервера) ...

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