Что нового в MySQL 5.1
3 мин
Осталось совсем немного времени до выхода MySQL 5.1. В статье будут рассмотрены изменения и новые возможности этой версии.
Oracle закручивает гайки
3 мин
Перевод
Это перевод заметки Исчезновение набора тестов или очередная часть MySQL стала закрытой? (Disappearing test cases or did another part of MySQL just become closed source?)
Около недели назад я изучал MySQL 5.5.27 и заметил любопытную деталь. Несмотря на то, что новый релиз MySQL содержал обычный набор исправлений, ни один из них не сопровождался тестом.
Около недели назад я изучал MySQL 5.5.27 и заметил любопытную деталь. Несмотря на то, что новый релиз MySQL содержал обычный набор исправлений, ни один из них не сопровождался тестом.
MySQL Performance real life Tips and Tricks. To be continued.
6 мин
По заявкам трудящихся решил написать еще одну статью, посвященную оптимизации запросов в MySQL.
В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.
В данной статье я немного вернусь к вышеописанному и опишу пару примеров, с которыми столкнулся на проекте недавно, после этого приведу еще пару небольших примеров относительно того что такое хорошо и что такое плохо в MySQL.
В прошлой статье habrahabr.ru/blogs/mysql/38907 рассматривались вопросы оптимизации LIMIT, GROUP BY, COUNT.
В данной статье я немного вернусь к вышеописанному и опишу пару примеров, с которыми столкнулся на проекте недавно, после этого приведу еще пару небольших примеров относительно того что такое хорошо и что такое плохо в MySQL.
Sun купила MySQL
1 мин
Только сейчас наткнулся на новость о том, что Sun Microsystems купила MySQL AB за 1 миллиард долларов. Наверное это будет серьезным толчком в развитии этой СУБД. А вы как считаете, что за этим последует?
Поприветствуйте вашего старого нового друга
4 мин
Перевод
Сегодня разнообразные открытые СУБД встают лицом к лицу против массивных, неуклюжих и дорогостоящих «корпоративных» систем, таких как SQL Server и Oracle. Часто открытые СУБД прекрасно работают лучше закрытых систем, не уступая даже в функциональных возможностях.
Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.
Из всех открытых систем управления базами данных самой умной, производительной и функциональной системой является Postgres, которая заслуженно привлекает всё больше и больше внимания.
Документация MySQL уведена от лицензии GPL (баг в системе сборки)
2 мин
Разработчики MariaDB случайно заметили, что в промежутке от MySQL 5.5.30 к MySQL 5.5.31 в проекте изменился текст лицензии во всех файлах в каталоге man/.
Вместо прежнего краткого текста «Эта документация является свободным программным обеспечением, вы можете распространять и/или изменять её только под условиями лицензии GNU General Public License, как опубликовано Фондом свободного ПО; версия 2 лицензии» теперь длинное описание, начинающееся со слов: «Это программное обеспечение и сопутствующая документация распространяются под лицензионным соглашением, которое содержит ограничения на использование и разглашение и защищена законами об интеллектуальной собственности».
Вместо прежнего краткого текста «Эта документация является свободным программным обеспечением, вы можете распространять и/или изменять её только под условиями лицензии GNU General Public License, как опубликовано Фондом свободного ПО; версия 2 лицензии» теперь длинное описание, начинающееся со слов: «Это программное обеспечение и сопутствующая документация распространяются под лицензионным соглашением, которое содержит ограничения на использование и разглашение и защищена законами об интеллектуальной собственности».
Баг в MySQL получил на день рождения тортик
1 мин
Хорошей пятницы, Хабр!
Как многим известно, отдельные баги в MySQL не закрываются годами. Но все еще открытому багу #20786 «mysqldump always includes AUTO_INCREMENT» повезло больше других — на свое семилетие он хотя бы получил самый настоящий праздничный торт!
Страница бага
Как многим известно, отдельные баги в MySQL не закрываются годами. Но все еще открытому багу #20786 «mysqldump always includes AUTO_INCREMENT» повезло больше других — на свое семилетие он хотя бы получил самый настоящий праздничный торт!
Описание бага
[29 Jun 2006 22:31] Erik Kay
I've run into a change between 5.1.9 and 5.1.11 that's causing me problems. mysqldump now includes AUTO_INCREMENT=xxx in the table definition, even when you specify --no-data. This appears to be the new default behavior of SHOW CREATE TABLE, which I assume mysqldump is using under the covers.
I understand why this is useful for the purposes of backing up data, and why it would even be useful in some --no-data cases, but the bummer for me is that I now don't have a way to dump my schema cleanly for development purposes.
I've run into a change between 5.1.9 and 5.1.11 that's causing me problems. mysqldump now includes AUTO_INCREMENT=xxx in the table definition, even when you specify --no-data. This appears to be the new default behavior of SHOW CREATE TABLE, which I assume mysqldump is using under the covers.
I understand why this is useful for the purposes of backing up data, and why it would even be useful in some --no-data cases, but the bummer for me is that I now don't have a way to dump my schema cleanly for development purposes.
Страница бага
MySQL в миллион раз быстрее MemSQL
2 мин
Пару дней назад по мировой технологической прессе распространился пиар MemSQL — базы данных нового поколения от Никиты Шамгунова (shamg), которая якобы показывает скорость в 30 раз выше, чем MySQL и при этом «надёжна по дефолту» (durable by default), как сказано у них на сайте.
Представители MySQL не снизошли до ответа на эти очевидные маркетинговые лозунги. Но вот бывший сотрудник MySQL, Домас Митузас (Domas Mituzas), ныне специалист по базам данных в Facebook и Wikipedia, всё-таки не выдержал и решил разобраться, как именно нас обманывают — и ответить тем же, то есть показать примеры, где MemSQL работает в сотни, тысячи и даже миллион раз медленнее, чем MySQL.
Представители MySQL не снизошли до ответа на эти очевидные маркетинговые лозунги. Но вот бывший сотрудник MySQL, Домас Митузас (Domas Mituzas), ныне специалист по базам данных в Facebook и Wikipedia, всё-таки не выдержал и решил разобраться, как именно нас обманывают — и ответить тем же, то есть показать примеры, где MemSQL работает в сотни, тысячи и даже миллион раз медленнее, чем MySQL.
Масштабируемость реляционных БД
2 мин
Перевод
Q:
В Facebook используют MySQL зная, что он плохо масштабируется (или здесь какая-то особая магия?). Я хотел спросить, из каких соображений они выбрали MySQL? Используют ли JOIN'ы? И не планируют ли перейти на другую БД?
A:
Отвечает Adam D'Angelo, бывший CTO Facebook, сейчас он развивает свой стартап Quora:
- Если разбивать данные по разным серверам на уровне приложения, то масштабируемость MySQL не такая уж и большая проблема. На 2008 год, в Facebook [1] у нас было 1800 MySQL серверов для которых требовалось всего два администратора. Конечно, вы не сможете сделать JOIN с данными с разных серверов, но NoSQL-базы вам тоже этого не позволят. Нет никаких данных о том, что в Facebook используют Cassandr'у как основное хранилище, и, кажется, что единственное, для чего она там нужна — это поиск по входящим сообщениям. [2]
Развитие баз данных в Dropbox. Путь от одной глобальной базы MySQL к тысячам серверов
33 мин
Когда только Dropbox запустился, один пользователь на Hacker News прокомментировал, что реализовать его можно несколькими bash-скриптами с помощью FTP и Git. Сейчас такого сказать никак нельзя, это крупное облачное файловое хранилище с миллиардами новых файлов каждый день, которые не просто как-то хранятся в базе данных, а так, что любую базу можно восстановить на любую точку в течение последних шесть дней.
Под катом расшифровка доклада Славы Бахмутова (m0sth8) на Highload++ 2017, о том, как развивались базы данных в Dropbox и как они устроены сейчас.
О спикере: Слава Бахмутов — site reliability engineer в команде Dropbox, очень любит Go и иногда появляется в подкасте golangshow.com.
Содержание
Под катом расшифровка доклада Славы Бахмутова (m0sth8) на Highload++ 2017, о том, как развивались базы данных в Dropbox и как они устроены сейчас.
О спикере: Слава Бахмутов — site reliability engineer в команде Dropbox, очень любит Go и иногда появляется в подкасте golangshow.com.
Содержание
- Кратко об архитектуре Dropbox
- История развития баз данных и как устроена текущая архитектура Dropbox
- Простейшие операции над базами данных (фейловеры, бэкапы, клоны, промоушены)
- Автоматизация — что управляет всеми базами данных и запускает операции
- Мониторинг
- Тестирование, стейджинг и DRT
Защита от SQL-инъекций в PHP и MySQL
26 мин
Recovery Mode
К своему удивлению, я не нашёл на Хабре исчерпывающей статьи на тему защиты от инъекций. Поэтому решил написать свою.
Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось:
Всего два пункта.
Разумеется, практическая реализация этих правил нуждается в более подробном освещении.
Но у этого списка есть большое достоинство — он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил «прогонять пользовательский ввод через mysql_real_escape_string» или «всегда использовать подготовленные выражения», мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе).
Но вперёд, читатель — перейдём уже к подробному разбору.
Несколько пространный дисклеймер, не имеющий прямого отношения к вопросу
Давайте признаем факт: количество статей (и комментариев) на тему защиты от SQL-инъекций, появившихся на Хабре в последнее время, говорит нам о том, что поляна далеко не так хорошо истоптана, как полагают некоторые. Причём повторение одних и тех же ошибок наводит на мысль, что некоторые заблуждения слишком устойчивы, и требуется не просто перечисление стандартных техник, а подробное объяснение — как они работают и в каких случаях должны применяться (а в каких — нет).
Статья получилась довольно длинной — в ней собраны результаты исследований за несколько лет — но самую важную информацию я постараюсь компактно изложить в самом начале, а более подробные рассуждения и иллюстрации, а так же различные курьёзы и любопытные факты привести в конце. Также я постараюсь окончательно развеять множественные заблуждения и суеверия, связанные с темой защиты от инъекций.
Я не буду пытаться изображать полиглота и писать рекомендации для всех БД и языков разом. Достаточное количество опыта у меня есть только в веб-разработке, на связке PHP/MySQL. Поэтому все практические примеры и рекомендации будут даваться для этих технологий. Тем не менее, изложенные ниже теоретические принципы применимы, разумеется, для любых других языков и СУБД.
Сразу отвечу на стандартное замечание про ORM, Active record и прочие query builders: во-первых, все эти прекрасные инструменты рождаются не по мановению волшебной палочки из пены морской, а пишутся программистами, используя всё тот же грешный SQL. Во-вторых, будем реалистами: перечисленные технологии — хорошо, но на практике сырой SQL постоянно встречается нам в работе — будь то legacy code или развесистый JOIN, который транслировать в ORM — себе дороже. Так что не будем прятать голову в песок и делать вид, что проблемы нет.
Хоть я и постарался подробно осветить все нюансы, но, вполне возможно, некоторые из моих выводов могут показаться неочевидными. Я вполне допускаю, что мой контекст и контексты читателей могут различаться. И вещи, которые кажутся мне сами собой разумеющимися, не являются таковыми для некоторых читателей. В этом случае буду рад вопросам и уточнениям, которые помогут мне исправить статью, сделав её более понятной и информативной.
Статья получилась довольно длинной — в ней собраны результаты исследований за несколько лет — но самую важную информацию я постараюсь компактно изложить в самом начале, а более подробные рассуждения и иллюстрации, а так же различные курьёзы и любопытные факты привести в конце. Также я постараюсь окончательно развеять множественные заблуждения и суеверия, связанные с темой защиты от инъекций.
Я не буду пытаться изображать полиглота и писать рекомендации для всех БД и языков разом. Достаточное количество опыта у меня есть только в веб-разработке, на связке PHP/MySQL. Поэтому все практические примеры и рекомендации будут даваться для этих технологий. Тем не менее, изложенные ниже теоретические принципы применимы, разумеется, для любых других языков и СУБД.
Сразу отвечу на стандартное замечание про ORM, Active record и прочие query builders: во-первых, все эти прекрасные инструменты рождаются не по мановению волшебной палочки из пены морской, а пишутся программистами, используя всё тот же грешный SQL. Во-вторых, будем реалистами: перечисленные технологии — хорошо, но на практике сырой SQL постоянно встречается нам в работе — будь то legacy code или развесистый JOIN, который транслировать в ORM — себе дороже. Так что не будем прятать голову в песок и делать вид, что проблемы нет.
Хоть я и постарался подробно осветить все нюансы, но, вполне возможно, некоторые из моих выводов могут показаться неочевидными. Я вполне допускаю, что мой контекст и контексты читателей могут различаться. И вещи, которые кажутся мне сами собой разумеющимися, не являются таковыми для некоторых читателей. В этом случае буду рад вопросам и уточнениям, которые помогут мне исправить статью, сделав её более понятной и информативной.
Ещё только начав интересоваться темой защиты от инъекций, я всегда хотел сформулировать набор правил, который был бы одновременно исчерпывающим и компактным. Со временем мне это удалось:
Правила, соблюдение которых гарантирует нас от инъекций
- данные подставляем в запрос только через плейсхолдеры
- идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
Всего два пункта.
Разумеется, практическая реализация этих правил нуждается в более подробном освещении.
Но у этого списка есть большое достоинство — он точный и исчерпывающий. В отличие от укоренившихся в массовом сознании правил «прогонять пользовательский ввод через mysql_real_escape_string» или «всегда использовать подготовленные выражения», мой набор правил не является катастрофическим заблуждением (как первое) или неполным (как второе).
Но вперёд, читатель — перейдём уже к подробному разбору.
8123 байта хватит каждому
2 мин
Сегодня во время перевода одного сайта с таблиц MyISAM на InnoDB, у последних выяснилась одна интересна особенность. Запрос на изменение движка для двух таблиц возвращал странную ошибку «Got error 139 from storage engine». После поиска информации на эту тему, было выяснено, что данная ошибка возникает тогда, когда какая-либо строка таблицы не вмещается в половину страницы памяти, с которыми работает MySQL. Страницы эти равны 16 Кб, а половина, стало быть, 8 Кб.
Само по себе ограничение довольно странное, но на первый взгляд кажется трудно достижимым, ведь как известно, MySQL хранят текстовые данные в хранилище, отдельном от табличных строк. Оказалось, что это верно только на половину. На самом деле InnoDB хранит в отдельном хранилище только «излишки», к коим он не относит первые 768 байтов каждого текстового поля. Т.е. любой текст будет отъедать от длины строки столько байт, сколько он содержит, но не больше 768. Несложно подсчитать, что максимальное число текстовых полей длиной от 768 байт, которое можно безопасно хранить в одной таблице — 10. И действительно, если запустить пример, все пройдет гладко. Но стоит увеличить количество полей хотя бы на одно, и мы получим ту же ошибку, что и в начале.
Само по себе ограничение довольно странное, но на первый взгляд кажется трудно достижимым, ведь как известно, MySQL хранят текстовые данные в хранилище, отдельном от табличных строк. Оказалось, что это верно только на половину. На самом деле InnoDB хранит в отдельном хранилище только «излишки», к коим он не относит первые 768 байтов каждого текстового поля. Т.е. любой текст будет отъедать от длины строки столько байт, сколько он содержит, но не больше 768. Несложно подсчитать, что максимальное число текстовых полей длиной от 768 байт, которое можно безопасно хранить в одной таблице — 10. И действительно, если запустить пример, все пройдет гладко. Но стоит увеличить количество полей хотя бы на одно, и мы получим ту же ошибку, что и в начале.
Строгий режим MySQL и почему он должен быть включен
2 мин
В MySQL есть такой специальный режим, предназначенный для введения в базу неправильных данных. Например, чтобы вместо
Режим этот называется «обычный режим».
20000000000 вставлять в INT-поле 2147483647. Или наполнять базу несуществующими датами. Или обрезанными строками. Ну или мало ли для чего этот режим может тебе пригодится.Режим этот называется «обычный режим».
Ближайшие события
Хабраинтервью с Майклом Видениусом (MySQL)
7 мин
К сожалению, несмотря на то, что ваши вопросы Монти были отправлены задолго до конца декабря, ответить на них он сумел несколько позже запланированного срока, что, впрочем, не умаляет интересности и актуальности его ответов (англоязычный оригинал ответов Майкла на ваши вопросы можно скачать здесь (RTF-файл, 16,6 Кбайт); ниже дан наш перевод, он может быть не идеален, так что буду рад, если укажете на возможные ошибки).
Напомню, что Майкл «Монти» Видеинус — это один из основных разработчиков популярной СУБД MySQL, которую, в свою очередь, хочет заиметь Oracle Corporation. Такое положение дел Монти по понятным причинам совершенно не устраивает, в связи с чем он в прошлом году опубликовал у себя в блоге соответствующую заметку, обращаясь за помощью к комьюнити.
Итак, Монти, вы получили вопросы от Habrahabr.ru? Люди волнуются, что вы так долго не отвечаете.
Я только что заметил. Прошу прощения за задержку, добавлял поддержку иностранных языков на helpmysql.org, это заняло почти всё моё время в последние дни.
Как вы пришли к идее создания MySQL в 1994 году? Почему вообще решили этим заняться? Что не устраивало в существующих решениях?
MySQL была основана на более старой программе для баз данных Unireg, которую я начал разрабатывать в 1982-м. Это был генератор приложений на основе tty (screen). С помощью Unireg мы создавали прикладные программы для наших клиентов.
В 1993-м нам понадобилось обеспечить клиентам доступ к их базам Unireg через интернет. Чтобы решить эту проблему, я сделал поверх Unireg слой SQL (поскольку я полагал, что SQL будет легко встроить в скрипты HTML), а также драйвер ODBC.
Другими словами, первоначальной задачей MySQL было решение наших собственных проблем, чтобы предоставить клиентам доступ к данным.
В качестве альтернативного варианта мы рассматривали Sybase, но эта СУБД была недостаточно быстрой (по сравнению с Unireg) и её нельзя было легко встраивать в HTML-страницы.
Напомню, что Майкл «Монти» Видеинус — это один из основных разработчиков популярной СУБД MySQL, которую, в свою очередь, хочет заиметь Oracle Corporation. Такое положение дел Монти по понятным причинам совершенно не устраивает, в связи с чем он в прошлом году опубликовал у себя в блоге соответствующую заметку, обращаясь за помощью к комьюнити.
Итак, Монти, вы получили вопросы от Habrahabr.ru? Люди волнуются, что вы так долго не отвечаете.
Я только что заметил. Прошу прощения за задержку, добавлял поддержку иностранных языков на helpmysql.org, это заняло почти всё моё время в последние дни.
Как вы пришли к идее создания MySQL в 1994 году? Почему вообще решили этим заняться? Что не устраивало в существующих решениях?
MySQL была основана на более старой программе для баз данных Unireg, которую я начал разрабатывать в 1982-м. Это был генератор приложений на основе tty (screen). С помощью Unireg мы создавали прикладные программы для наших клиентов.
В 1993-м нам понадобилось обеспечить клиентам доступ к их базам Unireg через интернет. Чтобы решить эту проблему, я сделал поверх Unireg слой SQL (поскольку я полагал, что SQL будет легко встроить в скрипты HTML), а также драйвер ODBC.
Другими словами, первоначальной задачей MySQL было решение наших собственных проблем, чтобы предоставить клиентам доступ к данным.
В качестве альтернативного варианта мы рассматривали Sybase, но эта СУБД была недостаточно быстрой (по сравнению с Unireg) и её нельзя было легко встраивать в HTML-страницы.
Основы репликации в MySQL
10 мин
С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.
Полнотекстовый поиск в InnoDB
12 мин
Привет, Хабрачитатель!
Полнотекстовый поиск данных в InnoDB – это известная головная боль многих разработчиков под MySQL / InnoDB. Для тех, кто не в курсе дела я объясню. В типе таблиц MyISAM есть полноценный полнотекстовый поиск данных, однако сама таблица исторически имеет ограничения, которые являются принципиальными в отдельных проектах. В более «продвинутом» типе таблиц InnoDB полнотекстового поиска нет. Вот и приходится мириться бедным разработчикам либо с ограничениями MyISAM, либо с отсутствием поиска в InnoDB. Я хочу рассказать о том, какие есть способы организовать полноценный поиск в InnoDB без магии и исключительно штатными средствами. Также будет интересно сравнить скоростные характеристики каждого способа.
Полнотекстовый поиск данных в InnoDB – это известная головная боль многих разработчиков под MySQL / InnoDB. Для тех, кто не в курсе дела я объясню. В типе таблиц MyISAM есть полноценный полнотекстовый поиск данных, однако сама таблица исторически имеет ограничения, которые являются принципиальными в отдельных проектах. В более «продвинутом» типе таблиц InnoDB полнотекстового поиска нет. Вот и приходится мириться бедным разработчикам либо с ограничениями MyISAM, либо с отсутствием поиска в InnoDB. Я хочу рассказать о том, какие есть способы организовать полноценный поиск в InnoDB без магии и исключительно штатными средствами. Также будет интересно сравнить скоростные характеристики каждого способа.
MySQL: казнить нельзя помиловать
9 мин
Сайт и интернет-магазин «Эльдорадо» — это около 40 тысяч покупок ежедневно. Объяснять, что это значит для бизнеса компании, наверное, не надо.
Исторически магазин работает на движке Bitrix с огромным количеством кастомного кода и дополнений. В качестве хранилища выступает кластер MySQL с четырьмя мастер-серверами.
Монолитные приложения есть у значительного числа компаний, и работать с ними приходится очень многим. Способов борьбы с монолитом предостаточно, вот только про удачные, к сожалению, пишут мало. Надеюсь, что рассказ о том, как мы подпираем наш монолит (пока его не распилили) будет вам интересен.
Апокалипсис грядёт
1 мин
Есть такая проблема — в 2038м году количество секунд с начала эпохи Unix Time перевалит за величину signed int и исчезнет. Это как проблема 2000 года, только намного сложнее, потому что для неё нужно менять типы данных.
Так вот… в MySQL уже четырнадцать с половиной лет висит просьба починить функции UNIX_TIMESTAMP и FROM_UNIXTIME, которые не могут обрабатывать даты после 19 января 2038го. Это функции конвертации даты в Unixtime и наоборот.
Проверить это достаточно просто: попробуйте вот этот запрос.
Так вот… в MySQL уже четырнадцать с половиной лет висит просьба починить функции UNIX_TIMESTAMP и FROM_UNIXTIME, которые не могут обрабатывать даты после 19 января 2038го. Это функции конвертации даты в Unixtime и наоборот.
Проверить это достаточно просто: попробуйте вот этот запрос.
select unix_timestamp('2038-01-20');
Разбор PHP-задач и новый тест. Как получить оффер в Лондон в феврале
6 мин
Привет, Хабр!
В июле мы проводили рекрутинговое мероприятие для PHP-разработчиков, по результатам которого пять человек получили оффер в наш лондонский офис. Мы продолжаем быстро расти: Android- и iOS-команды с того времени стали на 11 человек больше, поэтому мы снова запускаем конкурс для PHP-разработчиков.
Правила те же: покажи высокий результат в тесте, успешно пройди интервью 10 или 11 февраля в Москве — получи оффер в лондонский офис Badoo.
Все расходы по приезду на интервью в Москву компания берёт на себя, равно как и всё связанное с дальнейшим переездом в Лондон: рабочие визы членам семьи, 10 000 фунтов стерлингов (≈ 770 000 рублей) на переезд, совершенствование английского, поиск жилья.
Чтобы выполнять тестовое задание было интереснее, по многочисленным просьбам (1, 2, 3) под катом мы разберём задачи с предыдущего мероприятия, рассмотрим их правильные решения, и я объясню, почему мы выбрали именно их, а также приведу некоторые примеры, статистику и варианты решений от кандидатов.
UPD: мероприятие завершено. По итогам к нам присоединились 7 человек.
Оптимизация запросов MySQL с использованием пользовательских переменных
14 мин
Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.