Приложение интенсивного масштабирования и записи (LAMP, MySQL) (приложение в стиле каталога) - PullRequest
Новая
       5

Приложение интенсивного масштабирования и записи (LAMP, MySQL) (приложение в стиле каталога)

0 голосов
/ 04 августа 2010

Мне было интересно, есть ли здесь кто-нибудь, кто имеет опыт работы с данными с интенсивной записью из-за импорта файлов.

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

Установка:

  • внешнее (php) приложение записывает в базу данных MASTER.
  • Настройка репликации - Основная DB реплицируется на два сервера SLAVE DB.
  • один из серверов SLAVE используется в качестве базы данных «для чтения» для взаимодействия с интерфейсом пользовательского интерфейса (тяжелые запросы).
  • Тот же SLAVE-сервер также используется для «ЭКСПОРТА» данных, основанных на запросе, который был предварительно просмотрен во внешнем интерфейсе. (Много столов JOIN).

Основной проблемой был журнал репликации. Пользователи не довольны производительностью и данными, недоступными во внешнем интерфейсе, даже если импортированные ими файлы уже обработаны. Репликация LAG является виновником.

Переход на NoSQL, т. Е. Цель LONG Term. Все еще хочу улучшить производительность на данный момент. Кстати, приложение используется внутри компании, но размещено в известной хостинговой компании. Количество пользователей составляет около 150 пользователей.

Импортированные данные составляют около 200 - 800 тыс. Строк. Каждая строка представляет одну строку.

Будем благодарны за любые входные данные:)

Ответы [ 2 ]

1 голос
/ 05 августа 2010

Есть много факторов, которые играют роль в улучшении задержки репликации MySQL.Возможно, этот подкаст о репликации MySQL на Youtube их администратором базы данных может дать вам несколько советов и указателей:

http://itc.conversationsnetwork.org/shows/detail3299.html

Надеюсь, это поможет.

0 голосов
/ 05 августа 2010

@ Wrikken

(Ответ через окно ответа)

Да, много «вставок» и обновлений. Приложение использует временные таблицы (то есть реальную физическую таблицу с некоторым префиксом) для вставки предварительных данных. И делает много INSERT INTO .. ​​SELECT * FROM ..

Это приводит к тому, что многие операторы реплицируются на SLAVE, которые в конце концов удаляют временные таблицы. Я уже рекомендовал исключить такой тип таблиц из списка таблиц, подлежащих репликации, и вместо использования INSERT INTO ... SELECT * FROM приложения следует просто ВЫБЕРИТЬ все из построения инструкций INSERT, UPDATE, DELETE для приложения пространство памяти и выполнение SQL-кода. Это должно уменьшить количество операторов, связанных с временной таблицей, от репликации.

...