Обработка крупномасштабных данных с MySQL - это не просто определенный набор навыков, так как существует множество способов справиться с большим набором данных.Вот некоторые основные вещи, которые нужно понять:
- Индексы столбцов , как, почему и когда они используются, а также плюсы и минусы их использования.
- Хорошая структура базы данных для баланса между быстрой записью и легким чтением.
- Кэширование, использование нескольких уровней кэширования и различных технологий кэширования ( memcached , redis и т. Д.)
- Изучение запросов MySQL для выявления узких мест и пониманиявнутренние компоненты MySQL, чтобы увидеть, как запросы планируются и выполняются сервером базы данных для повышения производительности запросов
- Настройка сервера MySQL для обработки большого количества одновременных соединений и быстрого доступа к его данным.Узкие места в оборудовании и преимущества использования различных технологий для ускорения работы вашего оборудования (например, хранение данных MySQL на массиве RAID5 для повышения производительности ввода-вывода))
- Использование встроенного MySQLТехнология (например, Репликация ) для разгрузки трафика чтения
Это всего лишь несколько вещей, о которых думают в отношении больших данных в MySQL.Существует еще больше, поэтому компания ищет опыт в этой области.Знание того, что нужно делать, или опыт работы с вещами, которые сработали или не сработали для вас, - это бесценный актив, который может принести компании, занимающейся высоким трафиком, высокой доступностью и большим объемом услуг.edit
Я был бы ремисом, если бы не упомянул источник для получения дополнительной информации.Проверьте Высокая производительность MySQL .Это невероятная книга, в которой много информации о том, как заставить MySQL работать во всех сценариях.Определенно стоит денег и времени, потраченного на их чтение.
edit - хорошая структура для сбалансированных операций записи и чтения
С этим пунктом я имел в виду тему нормализации /денормализация.Если вы знакомы с дизайном БД, вы знаете, что нормализация - это разделение данных, чтобы уменьшить (исключить) количество дублирующихся данных, которые у вас есть о любой отдельной записи.Как правило, это фантастическая идея, поскольку она делает таблицы меньше, быстрее запрашивать, легче индексировать (индивидуально) и уменьшает количество операций записи, необходимых для создания / обновления новой записи.
Тамэто разные уровни нормализации (как отметил @Adam Robinson в комментариях ниже), которые называются нормальные формы .Почти каждое веб-приложение, с которым я работал, не имело особого преимущества, кроме 3NF (3-я нормальная форма).Какое определение, если вы прочитаете эту ссылку в Википедии выше, вероятно, повредит вашей голове.Таким образом, в ламенах (с риском затянуть его слишком далеко ...) структура 3NF удовлетворяет следующим правилам:
- Нет повторяющихся столбцов в одной таблице.
- Создание разныхтаблицы для каждого набора связанных данных.(Пример: таблица
Companies, в которой есть список компаний, и таблица Employees, в которой есть список сотрудников каждой компании) - Нет подмножеств столбцов, которые применяются к нескольким строкам вТаблица.(Пример:
zip_code, state и city - это подмножество данных, которые могут быть однозначно идентифицированы с помощью zip_code. Эти 3 столбца могут быть помещены в их собственную таблицу и на них ссылается Employeesтаблица (в предыдущем примере) по zip_code).Это устраняет большие наборы дубликатов в ваших таблицах, поэтому любое изменение, которое требуется для города / штата для любого почтового индекса, представляет собой одну операцию записи вместо 1 записи для каждого сотрудника, который живет в этом почтовом индексе. - Каждый поднабор данных перемещается в свою собственную таблицу и идентифицируется своим собственным первичным ключом (это затронуто / объяснено в примере для # 3).
- Удалить столбцы, которые не полностью зависят от первичного ключа. (Например, здесь может быть, если ваша таблица
Employees имеет столбцы start_date, end_date и years_employed. start_date и end_date являются уникальными и зависят от какой-либо отдельной строки сотрудника, но years_employed может быть получено путем вычитания start_date из end_date. Это важно, потому что с увеличением даты окончания увеличивается и years_employed, поэтому, если вам нужно обновить end_date, вам также придется обновить years_employed (2 пишет вместо 1)
Полностью нормализованная (3NF) структура таблицы базы данных хороша, если у вас очень большая нагрузка записи. Если ваш сервер выполняет много операций записи, очень легко записывать небольшие фрагменты данных, особенно если вы выполняете их меньше. Недостаток в том, что все ваши чтения становятся намного дороже, потому что вам приходится (обычно) выполнять много JOIN запросов, когда вы извлекаете данные. JOIN s, как правило, дороги и сложнее создать правильные индексы, когда вы используете предложения WHERE, которые охватывают отношения, и при сортировке наборов результатов. Если вам нужно выполнить много операций чтения (SELECT s) ваш набор данных, использование структуры 3NF может вызвать некоторые проблемы с производительностью. Это связано с тем, что по мере роста ваших таблиц вы просите MySQL помещать все больше и больше табличных данных (и индексов) в память. В идеале это то, что вы хотите, но с большими наборами данных у вас просто не будет достаточно памяти, чтобы вместить все это сразу. Это когда MySQL начинает создавать временные таблицы и должен использовать диск для загрузки данных и манипулирования ими. Как только MySQL станет зависимым от жесткого диска для обработки результатов запросов, вы увидите значительное снижение производительности. Это не так в случае с твердотельными дисками, но они очень дороги, и (imo) еще недостаточно зрелы, чтобы использовать их для критически важных наборов данных (я имею в виду, если вы не готовы к тому, что они выйдут из строя и не получат очень быстрая система восстановления резервных копий на месте ... затем используйте их и gonuts!).
Это уравновешивающая часть. Вы должны решить, какой тип трафика будут обслуживать данные, которые вы читаете / пишете, и спроектировать так, чтобы они были быстрыми. В некоторых случаях люди не возражают против того, чтобы записи были медленными, потому что они происходят реже. В других случаях записи должны быть очень быстрыми, а операции чтения не должны быть быстрыми, потому что к данным не обращаются так часто (или вообще, или даже в режиме реального времени).
Рабочие нагрузки, которые требуют много чтений, получают наибольшую выгоду от уровня кэширования среднего уровня. Идея состоит в том, что ваши записи все еще быстрые (потому что вы «нормальные»), а ваши чтения могут быть медленными, потому что вы собираетесь кешировать их (в memcached или чем-то конкурентном), поэтому вы не попадаете в базу данных очень часто Недостатком здесь является то, что если ваш кеш быстро становится недействительным, то кеш не снижает нагрузку на чтение на значительную величину, что не приводит к увеличению производительности (и, возможно, еще больше накладных расходов для проверки / аннулирования кешей).
С рабочими нагрузками, которые требуют высокой пропускной способности при записи, с данными, которые часто читаются и не могут быть кэшированы (постоянно изменяются), вам приходится придумывать другую стратегию. Это может означать, что вы начинаете отменять нормализацию своих таблиц, удаляя некоторые из требований нормализации, которые вы выбираете, или что-то еще. Вместо того чтобы создавать меньшие таблицы с менее повторяющимися данными, вы создаете большие таблицы с более повторяющимися / избыточными данными. Преимущество здесь в том, что все ваши данные находятся в одной таблице, поэтому вам не нужно выполнять столько (или любое) JOIN с, чтобы извлечь данные. Недостаток ... записи дороже, потому что вы должны писать в нескольких местах.
Таким образом, в любой конкретной ситуации разработчик (и) должен определить, какой вид использования будет использоваться структурой данных, и сбалансировать любое количество технологий и парадигм для достижения приемлемого решения, отвечающего их потребностям.Нет двух одинаковых систем или решений, поэтому работодатель ищет человека с опытом работы с этими большими наборами данных.Нахождение этих решений не является чем-то, что действительно может быть изучено из книги, обычно требуется некоторый опыт в этой области и опыт того, как выполняются различные решения.
Я надеюсь, что это помогает.Я знаю, что немного прогулял, но это действительно много информации.Вот почему администраторы делают большие доллары (: