Как сделать быстрое чтение данных и записи данных в MySQL?

Question

Привет, друзья! Я использую MySQL DB для одного из моих Продуктов, для него сейчас подано около 250 школ, это около 1500000 вставок в час и около 12000000 вставок в день, я думаю, что моя текущая установка, например, только один сервер, может дать сбойс часами, и чтение также, как запись, как я могу сделать это без сбоя сервера БД, главная проблема, с которой я сталкиваюсь сейчас, это медленная запись и чтение данных, как я могу преодолеть это, это очень сложнодля меня, чтобы найти решение. ребята, пожалуйста, помогите мне .. какая модель для решения этой проблемы?

Answer 1

~ 500 вставок в секунду - это совсем не то, что нужно чихать.

Для гибкого решения вы можете захотеть внедрить какой-то тип шардинга. Вероятно, самое простое решение состоит в том, чтобы заранее разделить школы на группы и хранить данные для разных групп школ на разных серверах. Например, данные для школ 1–10 хранятся на сервере A, школы 11–20 - на сервере B и т. Д. Это почти бесконечно масштабируется, если предположить, что между данными из разных школ мало связей.

Кроме того, вы можете просто попытаться использовать больше лошадиных сил для решения этой проблемы и инвестировать в RAID-накопители SSD, и, если у вас достаточно вычислительной мощности, у вас все будет в порядке. Конечно, если это огромная база данных, емкости накопителей SSD может быть недостаточно.

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

Answer 2

Сложно одновременно быстро читать и писать. Для быстрого чтения необходимо добавить индексы. Чтобы получить быстрые записи, вам нужно иметь несколько индексов. И чтобы оба были быстры, они не должны блокировать друг друга.

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

Answer 3

Мой спокойный совет:

• Легкое приложение для вас. Не используйте слой абстракции базы данных высокого уровня, такой как Active Record. Они сосут при масштабировании.
• Узнайте много о производительности MySQL.
• Узнайте о репликации MySQL.
• Узнайте о балансировке нагрузки.
• Узнайте о кеши памяти. (Memcached)
• Наймите администратора (с хорошими знаниями MySQL) или гуру / консультанта по производительности веб-приложений.

Конкретная стратегия зависит от вашего приложения и от того, как оно используется. Mysql-репликация может быть или не быть подходящей (то же самое относится к упомянутой стратегии разделения). Но это довольно простой способ добиться некоторого масштабирования, потому что он не сильно влияет на дизайн вашего приложения. В кешах памяти можно избежать некоторой нагрузки от ваших баз данных, но для их применения требуется некоторая работа и некоторые компромиссы. В конце концов, вам необходимо хорошее общее понимание того, как обрабатывать приложения, работающие с базами данных, при большой нагрузке. Если у вас есть сжатые сроки, добавьте внешнюю рабочую силу, потому что вы не сделаете это правильно в течение 6 недель без опыта.