База данных MySQL — дилемма планирования мощности, посоветуйте пожалуйста
У меня есть вопрос хостинга MySQL и планирования емкости. Я хотел бы знать минимальные требования к хостингу для размещения базы данных MySQL типа и размера, описанных ниже:
Фон: У меня есть клиент в финансовой отрасли, который купил сделанный на заказ Программная платформа CMS написана на PHP с базой данных MySQL.
Их текущее решение не имеет каких-либо отчетов, и поставщик программного обеспечения, предоставивший его, позволяет им использовать только некоторые страницы PHP для экспорта всего содержимого таблиц, которые затем клиент должен вручную манипулировать в Excel, чтобы получить свои бизнес-отчеты.
Поставщик не позволит им получить доступ к своей действующей базе данных в порядке
запустить Crystal Reports, заявив, что это риск для базы данных, предпочитая покупать дорогостоящее решение для репликации базы данных; Итак
клиент продолжает выполнять утомительный ручной экспорт целых таблиц
каждый день.
База данных: База данных в настоящее время имеет размер 90 МБ, и поверх нее стоит собственное 9-месячное PHP-решение. У клиента нет доступа к этому, поскольку он размещен у их текущего продавца. Всего 43 таблицы, одна из которых — огромная таблица журнала, занимает 99% размера базы данных.
Верхние четыре размера таблиц, содержащие бизнес-данные, представляют собой крошечные таблицы;
- 34,62 МБ
- 13,79 МБ
- 8,46 МБ
- 7,59 МБ
Подавляющее большинство таблиц являются простыми справочными таблицами для значений данных и имеют всего несколько строк.
Однако самая большая таблица в базе данных — это таблица журналов с большой задницей, размер которой составляет 1400 МБ. Только на эту таблицу приходится более 99,9% от общего размера базы данных.
Вопрос: Учитывая, что решение (несмотря на таблицу журналов) очень мало, когда всего несколько сотрудников делают ввод данных через несколько простых форм PHP, существует ли реальная проблема с запуском Crystal Reports для такой базы данных на производстве? Принимая во внимание, что бывают дни в течение дня — фактически, большинство дня — когда эта база данных просто не используется. Обеды например и вне часов.
Поставщик утверждает, что для бизнеса существует фундаментальный риск запрашивать оперативные данные и что запуск Crystal Reports для этой базы данных может привести к «аварийному завершению работы динамической базы данных, и бизнес потеряет операции».
Клиент также хочет иметь живую панель инструментов; который может быть написан с очень маленьким SQL-запросом, чтобы собрать некоторые числа из этих маленьких таблиц, перечисленных выше.
Я обычно работаю с SQL Server и Oracle, и у меня нет абсолютно никаких сомнений в том, что Crystal Report или запуск представления могут заполнять пользовательский интерфейс некоторыми данными в реальном времени из действующей базы данных, особенно такой небольшой базы данных; В конце концов, для чего нужна база данных, если нельзя ВЫБРАТЬ из нее время от времени?
Необходимо ли избегать «зависания сервера» и «избегать запросов при выполнении других операций на сервере» реплицировать эту базу данных MySQL во вторую базу данных отчетов? По моему опыту, необходимость сделать это относится только к чувствительным, рискованным с точки зрения безопасности или базам данных с большим объемом транзакций.
Использование системы: Система сильно зависит от запланированных заданий CRON каждые полчаса. Может быть 500 пользователей в неделю, каждый из которых входит в систему и вводит некоторые данные (но не так много данных — см. Размеры таблиц выше).
Любые комментарии горячо приветствуются.
Спасибо за ваше время.
Решение
1) Вам нужно 2 $ 5 цифровых океанских серверов.
2) «рухнуть живая БД и бизнес потеряет работу». Абсолютно неверно. Они идиоты. То, что они, вероятно, скрывают, является плохой структурой их базы данных. Скорее всего, они имеют архитектуру 1 таблицы для всех своих клиентов, которые отделены от client_id. Предоставление доступа к таблице даст доступ ко всем данным клиента, поэтому они вынуждают использовать гигантское решение для репликации, чтобы они могли убедиться, что вы получаете только ВАШИ данные.
3) Необходимо ли избегать «зависания сервера» и «избегать запросов при выполнении других операций на сервере»? Да, это.
4) скопировать эту базу данных MySQL во вторую базу данных отчетов? Да, это хорошая практика, так как вы можете настроить аварийное переключение на случай, если произойдет худшее. Если вы действительно параноик, вы можете настроить удаленное переключение при отказе от разных компаний. видя, как это происходит в финансовом секторе, я уверен, что вы этого хотите.
5) По моему опыту, необходимость сделать это относится только к чувствительным, угрожающим безопасности или базам данных с большими объемами транзакций. По моему опыту, всегда хорошо делать резервные копии ваших данных, потому что это случается в жизни и обычно, когда вы меньше всего этого ожидаете.
Что касается вашего использования в реальном времени. Предполагая, что база данных правильно структурирована с использованием индексов, и при использовании InnoDB у вас должно быть минимальное количество проблем, поддерживающих 100 запросов в секунду, поэтому я думаю, что проблема пользователей 500 в неделю — это то, о чем не стоит беспокоиться.
Как я уже упоминал, вам, скорее всего, нужно 2 сервера у разных провайдеров, вероятно, самые дешевые экземпляры, которые вы можете получить, поскольку вам не нужно огромное количество места или ресурсов. Вы можете настроить DNS так, чтобы 1 был основным, а 1 — ведомым для репликации, а затем в случае аварии измените DNS и сделайте другой ведущим.
Надеюсь, это поможет.
Другие решения
Других решений пока нет …