Разделение базы данных MySQL на клиента
Я работаю над сравнительно небольшой базой данных. Всего в нем 67 таблиц и чуть более миллиона записей. Это около 254 МБ. Приложение, которое работает с ним, работает уже около 5 лет, и объем использования удваивается каждый год. В этом году мы планируем утроить, что почти удвоит базу данных за один сезон. Мои вопросы, это плохая идея разбить базу данных на несколько баз данных. Скажем, у нас есть 300 клиентов, тогда он будет создавать 300 отдельных баз данных, содержащих 67 таблиц, но только данные, относящиеся к этому клиенту. Нет особой причины для объединения данных, кроме внутренней статистики, которая может быть выполнена на другом сервере. Мы не должны становиться больше чем 10000 клиентов в течение его жизни.
Проблемы, с которыми я сталкиваюсь, возникает из-за того, что нам нужно внести изменения в схему "основной базы данных", для которой нужно будет повторить изменение во всех "подчиненных базах данных".
Также репликация будет проблемой при добавлении нового клиента.
Приложение на уровне кода в значительной степени настроено для этого типа установки.
Есть что-то, что я пропускаю? Это ужасная идея?
База данных была создана на скорую руку (не мной), не думая о будущем, и теперь это моя ответственность.
Предстоит еще многое сделать для нормализации, аудита типов полей, оптимизации sql, индексации и настройки сервера. Любая обратная связь будет принята с благодарностью.
5 ответов
У вас есть руки с "нормализацией, аудитом типов полей, оптимизацией sql, индексацией и настройкой сервера"
Нет веских причин разделять это на 300 баз данных. И много веских причин не для того, что вы сформулировали. Пока CustomerId четко разделяет данные клиента через базу данных, у вас все в порядке.
Так что работайте над тем, что вам нужно, и не давайте себе больше совершенно ненужной работы.
Когда размер базы данных и низкая скорость требуют этого, переходите на настоящую платформу SQL.
В настоящее время у вас есть четверть концерта данных. Вы предполагаете, что это удвоится (половина концерта) в этом году. Это 1997? Нет, это 2010 год, и люди имеют гигабайты данных на своих телефонах.
Итак, вопрос в том, какую проблему вы пытаетесь решить? Это не может быть хранилище, потому что это тривиальный объем данных. Если это производительность, то я думаю, что разделение на несколько баз данных может ухудшить ситуацию, если вы планируете сервер для каждой базы данных. Существует аргумент в пользу отдельных баз данных с точки зрения безопасности, но существуют разные способы решения этих проблем.
У вас есть проблемы с вашей текущей средой? Или, по крайней мере, тенденции, которые предполагают, что у вас могут быть проблемы через двенадцать месяцев? Если нет, то просто сиди крепко. Если да, сформулируйте их четко, а затем выясните, как 300 баз данных решат эти проблемы и будут ли они стоить неизбежного горя. Затем откалибруйте это горе на счет 10000 пользователей и снова задайте вопрос.
Могут быть некоторые вопросы, на которые лучше всего ответить "десять тысяч баз данных", но не очень много.
"Наш крупнейший клиент добавляет около 12000 записей в год".
Другими словами, по одной записи каждые десять рабочих минут (при условии восьмичасового рабочего дня). Это не похоже на большую нагрузку при записи.
"Идея состоит в том, чтобы клиент просматривал все данные, а просто получал доступ к своим данным".
Но это не много данных и, конечно, ничего такого, чего не может исправить приличная стратегия индексирования.
Я до сих пор не понимаю, есть ли у вас настоящая реальная проблема сейчас, или вы просто думаете о чем-то, что может стать проблемой в какой-то момент в будущем.
Измените текущую схему для допуска нескольких клиентов, и если на пути к вашему n-му клиенту снижается производительность (и оптимизация SELECT не помогает), вы можете добавлять новые серверы. В нашем случае мы делим данные на "сайты", поэтому один пользователь не может получить доступ к данным, которых нет на их сайте.
Давайте посмотрим на SAP ERP. Это потенциально может вместить тысячи клиентов и миллиарды рекодеров. Это надежная система питания. И все таблицы в нем (кроме системных таблиц) имеют поле "MANDT", в котором указан клиент. Offcource SAP обычно работает с ORACLE, но в вашем случае этого не достаточно из-за небольшой части данных.
Итак, в соответствии с успешной историей SAP и добрыми мнениями о MySQL как о хорошей СУБД, я могу сделать вывод, что вам не следует смешивать БД среди клиентов. Это не даст много
Вопрос, который у меня есть, как осуществляется доступ к базе данных? Есть ли одна установка приложения для каждого клиента? Если это так, то, если хранить отдельные базы данных, вы можете выиграть некоторое время при обновлении приложения (поскольку вам нужно обновлять базу данных только при обновлении приложения). Если к ним обращается одна установка приложения, держите их вместе.
Но есть и другие соображения. Вы упоминаете, что размер сегодня составляет 1 миллион строк при 256 МБ. Это должно быть очень легко в пределах досягаемости товарного сервера. Поэтому, если вы ожидаете роста в наихудшем случае в 5 раз каждый год, вы говорите о 5 миллионах строк в этом году, 25 следующих, 125 третьих, 625 четвертых и 3125 миллионов пятых. Даже 3 миллиарда строк (в зависимости от точного использования и типов запросов) не так сложно обработать для MySQL (все еще в верхнем диапазоне обычного сервера)...
Кроме того, если вы начнете сталкиваться с проблемами, вы всегда можете разбить каждую (или только основные таблицы) на client ключ... Он автоматически управляется MySQL для вас, поэтому у вас нет кошмара обслуживания, чтобы управлять ими самостоятельно...