По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
SQL, произносится как "эс-кью-эль", является критическим инструментом для ученых в области данных. На самом деле, возможно, это самый важный язык для работы с данными. В этом руководстве для начинающих рассмотрим основы SQL. Начнем с ответа на простой вопрос: Что такое SQL? SQL (Structured Query Language) расшифровывается как язык структурированных запросов. Язык запросов - это своего рода язык программирования, предназначенный для облегчения получения конкретной информации из баз данных, именно это делает SQL. Проще говоря, SQL - это язык баз данных. Это важно, потому что большинство компаний хранят свои данные в базах данных. И хотя есть много типов баз данных (как MySQL, PostgreSQL, Microsoft SQL Server), большинство из них говорят на SQL, так что, взяв на вооружение основы SQL, вы сможете работать с любым из них. Даже если вы планируете выполнить анализ на другом языке, таком как Python, в большинстве компаний, скорее всего, потребуется использовать SQL для извлечения необходимых данных из базы данных компании. Согласно данным платформы Indeed на данный момент на только в США существует более 80 000 предложений по SQL. Давайте начнем с изучения SQL! В руководстве мы будем работать с набором данных сервиса обмена велосипедами Hubway, который включает в себя данные о более чем 1,5 миллионах поездок, совершенных через этот сервис. Мы начнем с того, что рассмотрим базы данных, каковы они и почему мы их используем, прежде чем начнем писать собственные запросы в SQL. Для изучения нам потребуется база, которую вы можете загрузить здесь: Скачать БД Основы SQL: реляционные базы данных Реляционная база данных - это база данных, которая хранит связанную информацию в нескольких таблицах и позволяет запрашивать информацию из нескольких таблиц одновременно. Легче понять, как это работает, продумав пример. Представьте, что у вас есть бизнес и вы хотите следить за информацией о продажах. В Excel можно настроить электронную таблицу со всей информацией, которую необходимо отслеживать, в виде отдельных столбцов: Номер заказа, дата, сумма к оплате, номер отслеживания отгрузки, имя, адрес и номер телефона клиента. Такое решение отлично подойдет для отслеживания информации, на начальных этапах работы, но, когда вы начнете получать повторные заказы от одного и того же клиента, вы обнаружите, что их имя, адрес и номер телефона хранятся в нескольких строках вашей электронной таблицы. По мере роста вашего бизнеса и увеличения количества отслеживаемых заказов эти избыточные данные займут ненужное место и, как правило, снизят эффективность вашей системы отслеживания продаж. Также могут возникнуть проблемы с целостностью данных. Например, нет гарантии, что для каждого поля будет установлен правильный тип данных или что имя и адрес будут каждый раз вводиться одинаково. При использовании реляционной базы данных, как и на приведенной выше схеме, можно избежать всех этих проблем. Можно настроить две таблицы: одну для заказов и одну для клиентов. Таблица "Клиенты" будет включать уникальный идентификационный номер для каждого клиента, а также имя, адрес и номер телефона, которые мы уже отслеживали. Таблица "Заказы" будет включать номер заказа, дату, сумму к оплате, номер отслеживания и вместо отдельного поля для каждой позиции данных клиента будет содержать столбец для идентификатора клиента. Это позволяет нам получить всю информацию о клиенте для любого заказа, но записи будут введены в базу только один раз, избегая при этом избыточных данных. С чем бы будем работать Начнем с открытия нашей базу данных. База данных имеет две таблицы, trips ( далее "поездки") и stations (далее "станции"). Давайте просто посмотрим на таблицу trips. Она содержит следующие столбцы: id - уникальное целое число, которое служит ссылкой на каждую поездку. duration - продолжительность поездки, измеренная в секундах; start_date - Дата и время начала поездки; start_station - целое число, соответствующее столбцу id в таблице stations для станции, на котором был арендован велосипед; end_date - Дата и время окончания поездки; end_station - Идентификатор станции, на которой завершилась поездка; bike_number - уникальный идентификатор Hubway для велосипеда, используемого в поездке; sub_type - тип подписки пользователя. "Зарегистрированный" для пользователей с членством, "Случайный" для пользователей без членства; zip_code - почтовый индекс пользователя (доступен только для зарегистрированных участников); birth_date - год рождения пользователя (доступен только для зарегистрированных участников); gender - пол пользователя (доступен только для зарегистрированных участников); Что мы анализируем Внизу перечислены вопросы, на которые мы должны ответить, используя информацию из БД и командами SQL, которые мы изучим чуть позже: Какова была продолжительность самого длительного путешествия? Сколько поездок совершили "зарегистрированные" пользователи? Какова средняя продолжительность поездки? Кто совершил более длительные поездки: зарегистрированные пользователи или гости? Какой велосипед использовался для большинства поездок? Какова средняя продолжительность поездок пользователей старше 30 лет? Команды SQL, которые мы будем использовать для ответа на эти вопросы: SELECT WHERE LIMIT ORDER BY GROUP BY AND OR MIN MAX AVG SUM COUNT Установка и настройка В данном руководстве мы будем использовать систему баз данных под названием SQLite3. SQLite стала частью Python начиная с версии 2.5, так что, если у вас установлен Python, почти наверняка уже в системе есть и SQLite. Python и библиотеку SQLite3 можно легко установить и настроить с помощью Anaconda, если они еще не установлены. Использование Python для запуска кода SQL позволяет импортировать результаты в датафрейм Pandas, что существенно облегчит отображение результатов в удобном для чтения формате. Это также означает, что мы сможем выполнить дальнейший анализ и визуализацию данных, которые мы получим из базы данных, хотя это будет выходить за рамки данного учебного пособия. Если же не хотите использовать или устанавливать Python, SQLite3 можно запустить из командной строки. Просто загрузите "предварительно скомпилированные двоичные файлы" с сайта SQLite3 и используйте следующую команду для открытия базы данных: ~$ sqlite hubway.db SQLite version 3.14.0 2016-07-26 15:17:14 Enter ".help" for usage hints.sqlite> Отсюда можно просто ввести запрос, который нужно выполнить, и увидеть возвращенные данные, в нашем окне терминала. Альтернативой использованию терминала является подключение к базе данных SQLite через Python. Это позволит нам использовать Jupyter для отображения результатов наших запросов в аккуратно отформатированной таблице. Для этого определим функцию, которая принимает наш запрос (сохраненный в виде строки) в качестве входных данных и показывает результат в виде форматированного датафрейма: import sqlite3 import pandas as pd db = sqlite3.connect('hubway.db') def run_query(query): return pd.read_sql_query(query,db) SELECT Первая команда, с которой мы будем работать - SELECT. SELECT будет основой почти каждого запроса, который мы напишем - он сообщает базе данных, какие столбцы мы хотим видеть. Можно указать столбцы по имени (разделенные запятыми) или использовать подстановочный знак * для возврата всех столбцов из таблицы. В дополнение к столбцам, которые мы хотим получить, мы также должны сообщить базе данных, из какой таблицы их получить. Для этого используется ключевое слово FROM, за которым следует имя таблицы. Например, если требуется просмотреть start_date и bike_number для каждой поездки в таблице trips, можно использовать следующий запрос: SELECT start_date, bike_number FROM trips; В этом примере мы начали с команды SELECT, чтобы база данных знала, что она должна найти некоторые данные. Затем мы сказали базе данных, что нас интересуют столбцы start_date и bike_number. Наконец, чтобы сообщить базе, что столбцы, которые мы хотим получить, являются частью таблицы trips мы использовали команду FROM. Важно знать, что при записи SQL-запросов необходимо заканчивать каждый запрос точкой с запятой (;). На самом деле не каждая база данных SQL требует этого, но такой стиль считается хорошим тоном создания запросов, поэтому лучше всего сформировать эту привычку. LIMIT Следующая команда, которую мы должны знать перед началом выполнения запросов к нашей базе данных Hubway, - LIMIT. LIMIT просто сообщает базе данных, сколько строк требуется вернуть. Запрос SELECT, который мы рассмотрели в предыдущем разделе, возвращает запрашиваемую информацию для каждой строки в таблице trips, но обычно это очень большое количество данных, в которых нет необходимости в данный момент. Если всех записей из БД нужно получить start_date и bike_number только для первых пяти поездок, к запросу следует добавить ключевое слово LIMIT следующим образом: SELECT start_date, bike_number FROM trips LIMIT 5; Мы просто добавили команду LIMIT, а затем число, представляющее количество строк, которые мы хотим вернуть. В данном примере мы использовали 5, но вы можете заменить их любым числом, чтобы получить соответствующий объем данных для проекта, над которым вы работаете. Мы будем много использовать LIMIT в наших запросах к базе данных Hubway в этом учебном пособии - таблица поездок содержит более 1,5 миллионов строк данных, и нам, конечно, не нужно отображать все. Давайте запустим наш первый запрос в базе данных Hubway. Сначала сохраним наш запрос в переменной типа "строка", а затем используем функцию, определенную ранее, чтобы отправить запрос к базе данных. Взгляните на следующий пример: query = 'SELECT * FROM trips LIMIT 5;' run_query(query) Этот запрос использует * в качестве подстановочного символа вместо указания возвращаемых столбцов. Это означает, что команда SELECT вернула нам каждый столбец из таблицы trips. Мы также использовали функцию LIMIT, чтобы ограничить вывод первыми пятью строками таблицы. Вы часто столкнетесь с ситуацией, когда программисты в своих запросах ключевые слова будут писать с заглавной буквы. Это негласное соглашение, которому мы будем следовать в этом учебном пособии, хотя это в основном вопрос предпочтения. Просто заглавная буква облегчает чтение кода, но на самом деле она никак не влияет на его функциональность. Если вы предпочитаете писать запросы строчными буквами, они будут выполняться правильно. В предыдущем примере были возвращены все столбцы из таблицы поездок. Если бы нас интересовали только длительность и дата начала, подстановочный символ можно было бы заменить на названия столбцов следующим образом: query = 'SELECT duration, start_date FROM trips LIMIT 5' run_query(query) ORDER BY Последняя команда, которую мы должны знать, прежде чем мы сможем ответить на первый из наших вопросов, - ORDER BY. Эта команда позволяет отсортировать базу данных по указанному столбцу. Чтобы использовать его, просто укажите имя столбца, по которому требуется выполнить сортировку. По умолчанию, ORDER BY сортирует результаты по возрастанию. Если требуется указать порядок сортировки базы данных, можно добавить ключевое слово ASC для сортировки по возрастанию или DESC - по убыванию. Например, если требуется отсортировать вывод из таблицы поездок от самой короткой по продолжительности до самой длинной, в запрос можно добавить следующую строку: ORDER BY duration ASC Вооружившись командами SELECT, LIMIT и ORDER BY мы теперь можем попытаться ответить на наш первый вопрос: какова была продолжительность самой длительной поездки? Чтобы ответить на этот вопрос, полезно разбить его на разделы и определить, какие команды нам потребуются для каждой части. Сначала нам нужно извлечь информацию из столбца duration таблицы поездок. Затем, чтобы найти, какая поездка самая длинная, мы можем отсортировать столбец длительности в порядке убывания. Итак, чтобы сформировать запрос, который получит нужную нам информацию, мы можем следовать следующей последовательности: Использовать SELECT для извлечения столбца duration FROM таблицы trips. Использовать ORDER BY для сортировки по столбцу duration и ключевое слово DESC для сортировки в порядке убывания. Использовать LIMIT, чтобы ограничить вывод 1 строкой Использование этих команд таким образом вернет одну строку с наибольшей длительностью, что даст нам ответ на наш вопрос. Еще одна деталь, которую следует отметить - по мере увеличения длины запроса, чтобы облегчить чтение кода, лучше разделять запрос на несколько строк. Это, как и в случае с заглавным шрифтом, вопрос личного предпочтения. Это не влияет на выполнение кода (система считывает код от начала до точки с запятой), но может сделать запросы более четкими и простыми для выполнения. В Python можно разделить строку на несколько строк, используя тройные кавычки. Давайте выполним запрос и выясним, сколько длилась самая длинная поездка. query = ''' SELECT duration FROM trips ORDER BY duration DESC LIMIT 1; ''' run_query(query) Теперь мы знаем, что самая длинная поездка длилась 9999 секунд, или чуть более 166 минут. С максимальным значением 9999, однако, мы не знаем, действительно ли это длина самого длинного рейса или база данных была настроена только для разрешения четырехзначного номера. Если это правда, то более длительные поездки сокращаются базой данных до четырех символов. В результате ожидаемо увидеть много поездок длительностью 9999 секунд. Чтобы убедиться, что все отрабатывает корректно, попробуем выполнить тот же запрос, что и раньше, но изменим LIMIT так, чтобы вернуть 10 наибольших по длительности поездок: query = ''' SELECT durationFROM trips ORDER BY duration DESC LIMIT 10 ''' run_query(query) Судя по выводу, в базе нет кучи поездок продолжительностью 9999, а это означает, что база ничего не отсекает. Но все еще трудно сказать, является ли это реальной длиной поездки или только максимально допустимое значение. Hubway взимает дополнительную комиссию за поездки длительностью более 30 минут (кто-то, продержавший велосипед в течение 9999 секунд, должен был бы заплатить дополнительные 25 долларов в виде комиссии), поэтому вполне вероятно, что разработчики решили обойтись 4-мя цифрами для отслеживания большинства поездок. WHERE Предыдущие команды отлично подходят для извлечения отсортированной информации для определенных столбцов, но что делать, если существует определенное подмножество данных, которые мы хотим просмотреть? Вот здесь на помощь приходит WHERE. Команда WHERE позволяет использовать логический оператор для указания строк, которые должны быть возвращены. Например, можно использовать следующую команду, чтобы вернуть каждую поездку, выполненную велосипедом с ID B00400: WHERE bike_number = "B00400" Наверное, уже заметили, что в этом запросе используем кавычки. Это потому, что bike_number хранится в виде строки. Если столбец содержит числовые типы данных, необходимость в кавычках отпадает. Давайте напишем запрос, который использует WHERE для возврата каждого столбца в таблице поездок для каждой строки длительностью больше 9990 секунд: query = ''' SELECT * FROM trips WHERE duration > 9990; ''' run_query(query) Как мы видим, этот запрос вернул 14 различных поездок, каждая продолжительностью 9990 секунд или более. Что-то, что выделяется в этом запросе, что все, кроме одного из результатов имеет sub_type "Случайный". Возможно, это свидетельствует о том, что "Зарегистрированные" пользователи больше осведомлены о дополнительных сборах за длительные поездки. Может быть, Хабуэй мог бы лучше передать свою политику ценообразования случайным пользователям, чтобы помочь им избежать чрезмерных расходов. Мы уже видим, что даже SQL запрос начального уровня может помочь нам ответить на бизнес-вопросы и найти информацию в наших данных. Возвращаясь к WHERE, мы также можем объединить несколько логических тестов в нашем предложении WHERE, используя AND или OR. Если, например, в нашем предыдущем запросе мы хотели получить только поездки длительностью более 9990 секунд, которые также имеют sub_type Registered, мы могли бы использовать оператор AND для указания обоих условий. Вот еще одна личная рекомендация: используйте круглые скобки, чтобы разделить каждый логический блок, как показано в коде ниже. Это не обязательно для работы кода, но круглые скобки упрощают понимание запросов по мере их усложнения. Давайте сейчас запустим этот запрос. Мы уже знаем, что это должно вернуть только один результат, так что должно быть легко проверить, что мы получили его правильно: query = ''' SELECT * FROM trips WHERE (duration >= 9990) AND (sub_type = "Registered") ORDER BY duration DESC; ''' run_query(query) Следующий вопрос, который мы изложили в начале статьи, - "Сколько поездок было совершено "зарегистрированными" пользователями?" Чтобы ответить на него, мы могли бы выполнить тот же запрос, что и выше, и изменить выражение WHERE, чтобы вернуть все строки, где sub_type равно "Registered", а затем подсчитать их. На самом деле SQL имеет встроенную команду COUNT для такого рода подсчетов, так что напрягать глаза нам не придется. COUNT позволяет выполнять вычисления в базе данных и избавить нас от проблем с написанием дополнительных сценариев для подсчета результатов. Чтобы использовать его, мы просто включаем COUNT (column_name) вместо (или в дополнение к) столбцов, которые мы хотим выбрать, как указано ниже: SELECT COUNT(id) FROM trips В данном случае не имеет значения, какой столбец мы выбираем для подсчета, потому что каждый столбец должен иметь данные для каждой строки в нашем запросе. Но иногда запрос может иметь отсутствующие (или "нулевые") значения для некоторых строк. Если мы не уверены, содержит ли столбец значения null, мы можем запустить COUNT для столбца id - столбец id никогда не имеет значение null, поэтому мы можем быть уверены, что наш счетчик не пропустит ничего. Мы также можем использовать COUNT (1) или COUNT (*) для подсчета каждой строки в нашем запросе. Стоит отметить, что иногда может потребоваться выполнение COUNT для столбца со значениями NULL. Например, может потребоваться узнать, сколько строк в нашей базе данных имеют пустые значения для указанного столбца. Давайте посмотрим на запрос, который позволит ответить на наш вопрос. Мы можем использовать SELECT COUNT (*) для подсчета общего количества возвращенных строк и WHERE sub_type = "Registered", чтобы убедиться, что мы подсчитываем только поездки, сделанные зарегистрированными пользователями. query = ''' SELECT COUNT(*)FROM trips WHERE sub_type = "Registered"; ''' run_query(query) Этот запрос сработал и вернул ответ на наш вопрос. Но заголовок столбца не особенно показателен. Если кто-то еще посмотрит на эту таблицу, он не сможет понять, что это значит. Если мы хотим сделать наши результаты более читаемыми, мы можем использовать ключевое слово AS, чтобы дать нашему выводу псевдоним. Давайте снова запустим предыдущий запрос, но дадим query = ''' SELECT COUNT(*) AS "Total Trips by Registered Users" FROM trips WHERE sub_type = "Registered"; ''' run_query(query) Функции агрегирования COUNT не единственный математический трюк, которым располагает SQL. Мы также можем использовать функции SUM, AVG, MIN и MAX для возврата суммы, среднего значения, минимума и максимума столбца соответственно. Эти функции наряду с COUNT называются функциями агрегирования. Итак, чтобы ответить на наш третий вопрос "Какова была средняя продолжительность поездки?", мы можем использовать функцию AVG для столбца duration (и, еще раз, использовать AS, чтобы дать нашему выходному столбцу более описательное имя): query = ''' SELECT AVG(duration) AS "Average Duration" FROM trips; ''' run_query(query) Получается, что средняя продолжительность поездки составляет 912 секунд, что составляет около 15 минут. Это имеет смысл, так как мы знаем, что Hubway взимает дополнительную плату за поездки в течение 30 минут. Сервис рассчитан на то, чтобы участники брали велосипеды на короткие дистанции, односторонние поездки. Как насчет нашего следующего вопроса, какие пользователи выполняют более длительные поездки? Мы уже знаем один способ ответить на этот вопрос - мы могли бы запустить два запроса SELECT AVG (duration) FROM trips добавив ключевое слово WHERE, которые ограничивают вывод для "зарегистрированных" и для "случайных" пользователей по отдельности. Но давайте сделаем это по-другому. SQL имеет в своем арсенале функцию и для ответа на этот вопрос в одном запросе с помощью команды GROUP BY. GROUP BY GROUP BY разделяет строки на группы на основе содержимого определенного столбца и позволяет выполнять агрегирующие функции для каждой группы. Чтобы лучше понять, как это работает, давайте посмотрим на столбец gender. Каждая строка может иметь одно из трех возможных значений в столбце пола "Мужской", "Женский" или "Нулевой" (отсутствует; у нас нет гендерных данных для случайных пользователей). Когда мы используем GROUP BY, база данных будет разделять каждую из строк на разные группы на основе значения в столбце пола, примерно так же, как мы можем разделить колоду карт по мастям. Это можно представить, как две группы, в одной все представители мужского пола, в другой - женского. Как только у нас будут две отдельные кучи, база данных будет выполнять любые агрегирующие функции в нашем запросе по каждой из них по очереди. Например, если бы мы использовали COUNT, запрос подсчитывал бы количество строк в каждой группе и возвращал бы значение для каждого по отдельности. Давайте посмотрим, как именно написать запрос, чтобы ответить на наш вопрос о том, кто совершает более длительные поездки: зарегистрированные пользователи или случайные. Как и в случае с каждым из наших запросов, мы начнем с SELECT, чтобы сообщить базе данных, какую информацию мы хотим получить. В этом случае нам нужны sub_type и AVG (duration). Мы также включим GROUP BY sub_type, чтобы разделить наши данные по типу подписки и вычислить средние значения зарегистрированных и случайных пользователей по отдельности. Вот как выглядит код, когда мы складываем все вместе: query = ''' SELECT sub_type, AVG(duration) AS "Average Duration" FROM trips GROUP BY sub_type; ''' run_query(query) Это большая разница! В среднем зарегистрированные пользователи совершают поездки продолжительностью около 11 минут, в то время как случайные пользователи тратят почти 25 минут на поездку. Зарегистрированные пользователи, вероятно, совершают более короткие и частые поездки, возможно, в рамках поездок на работу. Случайные пользователи, с другой стороны, тратят в два раза больше времени на поездку. Вполне возможно, что случайные пользователи, как правило, приезжие (например, туристы), которые более склонны совершать более длительные поездки, чтобы убедиться, что они обойдут и увидят все достопримечательности. Как только мы обнаружим эту разницу в данных, компания сможет исследовать ее, чтобы лучше понять, что данная разница вызвана Однако давайте продолжим. Наш следующий вопрос был: "Какой велосипед использовался для большинства поездок?" Мы можем ответить на это с помощью очень похожего запроса. Взгляните на следующий пример и посмотрите, можете ли вы выяснить, что делает каждая строка - мы пройдем ее шаг за шагом после этого, чтобы вы могли проверить, правильно ли вы получили: query = ''' SELECT bike_number as "Bike Number", COUNT(*) AS "Number of Trips" FROM trips GROUP BY bike_number ORDER BY COUNT(*) DESC LIMIT 1; ''' run_query(query) Как видно из выходных данных, велосипедные B00490 взяли больше всего поездок. Давайте рассмотрим, как получили данное значение: Первая строка - это предложение SELECT, указывающее базе данных, что мы хотим получить столбец bike_number и число всех строк в БД. В запросе также используется AS для указания базе данных отображать каждый столбец с более понятным названием. Во второй строке используем FROM, чтобы указать, что данные, которые мы ищем, находятся в таблице поездок. В третьей строке прибегли к хитрости. Тут используется команда GROUP BY, чтобы указать функции COUNT в первой строке подсчитать каждое значение для bike_number отдельно. В четвертой строке у нас есть функция ORDER BY, чтобы отсортировать таблицу в порядке убывания и убедиться, что наш наиболее используемый велосипед находится на самом верху. Наконец, мы используем LIMIT, чтобы ограничить вывод одной строкой, которая, как мы знаем, будет велосипедом, который использовался в наибольшем количестве поездок из-за того, как мы сортировали данные на четвертой строке. Арифметические операторы Наш последний вопрос немного сложнее других. Мы хотим знать среднюю продолжительность поездок зарегистрированных участников в возрасте старше 30 лет. Мы могли бы просто найти год, в котором родились 30-летние, а затем подставить это значение. Но есть более элегантным решение - использование арифметических операций непосредственно в нашем запросе. SQL позволяет использовать +, -, * и/для выполнения арифметической операции над всем столбцом одновременно. query = ''' SELECT AVG(duration) FROM trips WHERE (2017 - birth_date) > 30; ''' run_query(query) JOIN До сих пор мы рассматривали запросы, которые извлекают данные только из таблицы поездок. Однако одна из причин, по которой SQL настолько эффективен, заключается в том, что он позволяет извлекать данные из нескольких таблиц в одном запросе. Наша база данных по обмену велосипедами содержит вторую таблицу, станции. Таблица stations содержит информацию о каждом терминале в сети Hubway и включает столбец id, на который ссылается таблица trips. Прежде чем мы начнем работать с некоторыми реальными примерами из этой базы данных, давайте посмотрим на гипотетическую базу данных отслеживания заказов из более ранних. В этой базе данных были две таблицы, заказы и клиенты, и они были связаны столбцом customer_id. Допустим, мы хотели написать запрос, который вернул order_number и name для каждого заказа в базе данных. Если они оба были сохранены в одной таблице, можно было бы использовать следующий запрос: SELECT order_number, name FROM orders; К сожалению, столбец order_number и столбец name хранятся в двух разных таблицах, поэтому необходимо добавить несколько дополнительных команд. Давайте подумаем о дополнительных командах, которые должна знать база данных, прежде чем она сможет вернуть нужную информацию: В какой таблице находится столбец order_number? В какой таблице находится столбец name? Как информация в таблице заказов связана с информацией в таблице клиентов? Чтобы ответить на первые два из этих вопросов, мы можем включить имена таблиц для каждого столбца в нашу команду SELECT. Способ сделать это - просто написать имя таблицы и имя столбца, разделив их символом точки ".". Например, вместо SELECT order_number мы бы написали SELECT orders.order_number, customers.name. Добавление здесь имен таблиц помогает базе данных находить столбцы, которые мы ищем, указывая, в какой таблице искать каждый из них. Чтобы сообщить базе данных, как соединяются таблицы заказов и клиентов, мы используем JOIN и ON. JOIN указывает, какие таблицы должны быть соединены, а ON указывает, какие столбцы в каждой таблице связаны. Мы будем использовать внутреннее соединение, что означает, что команда вернет только те строки, где столбцы, указанные в ON, совпадают. В этом примере мы хотим использовать JOIN для любой таблицы, которую мы не включили в команду FROM. Таким образом, мы можем либо использовать FROM orders INNER JOIN customers, либо FROM customers INNER JOIN orders. Как мы уже обсуждали ранее, эти таблицы связаны между собой столбцом customer_id в каждой таблице. Поэтому используем ON, чтобы сообщить базе данных, что эти два столбца ссылаются на одно и то же: ON orders.customer_ID = customers.customer_id Еще раз используем "." чтобы база данных знала, в какой таблице находится каждый из этих столбцов. Итак, когда мы сложим все это вместе, мы получим запрос, который выглядит следующим образом: SELECT orders.order_number, customers.name FROM orders INNER JOIN customers ON orders.customer_id = customers.customer_id Этот запрос вернет номер каждого заказа в базе данных наряду с именем клиента, который сделал данные заказ. Возвращаясь к нашей базе данных Hubway, мы теперь можем написать несколько запросов, чтобы увидеть JOIN в действии. Прежде чем начать, мы должны взглянуть на остальные столбцы в таблице станций. Вот запрос, чтобы показать нам первые 5 строк, чтобы мы могли увидеть, как выглядит таблица станций: query = ''' SELECT * FROM stations LIMIT 5; ''' run_query(query) id - уникальный идентификатор для каждой станции (соответствует столбцам start_station и end_station в таблице поездок); station - название станции; municipality - муниципалитет, в котором находится станция (Бостон, Бруклин, Кембридж или Сомервилл); lat - Широта станции; lng - долгота станции; А вот вопросы, на которые мы должны ответить, исследовав данные из базы: Какие станции чаще всего используются для поездок в оба конца? Сколько поездок начинается и заканчивается в разных муниципалитетах? Как и прежде, мы попытаемся ответить на некоторые вопросы основываясь на данных, первый вопрос: "Какая станция является наиболее частой отправной точкой?" Давайте шаг за шагом сформируем запрос для ответа на этот вопрос: Сначала мы используем SELECT для возврата столбца station из таблицы станций и COUNT для получения числа строк. Далее мы указываем таблицы, которые мы хотим объединить JOIN, и указываем базе данных соединить их столбцом ON start_station из таблицы поездок и столбцом id в таблице станций. Затем переходим к основной части нашего запроса - мы группируем по столбцу станция таблицы станций (GROUP BY station), чтобы наш COUNT подсчитал количество поездок для каждой станции отдельно Наконец, мы можем отсортировать по нашим COUNT ORDER BY COUNT LIMIT и ограничить вывод для управления количеством результатов. query = ''' SELECT stations.station AS "Station", COUNT(*) AS "Count" FROM trips INNER JOIN stations ON trips.start_station = stations.id GROUP BY stations.station ORDER BY COUNT(*) DESC LIMIT 5; ''' run_query(query) Если вы знакомы с Бостоном, вы поймете, почему это самые популярные станции. Южный вокзал является одной из главных пригородных железнодорожных станций в городе, Чарльз-стрит проходит вдоль реки недалеко от некоторых красивых живописных маршрутов, а улицы Бойлстон и Бикон находятся прямо в центре вблизи офисных зданий. Следующий вопрос, который мы рассмотрим, - какие станции чаще всего используются для поездок туда и обратно? Мы можем использовать тот же запрос, что и раньше. Мы будем выбирать те же выходные столбцы и присоединять таблицы таким же образом, но на этот раз мы добавим условие WHERE, чтобы ограничить наш COUNT поездками, где start_station совпадает с end_station. query = ''' SELECT stations.station AS "Station", COUNT(*) AS "Count" FROM trips INNER JOIN stations ON trips.start_station = stations.id WHERE trips.start_station = trips.end_station GROUP BY stations.station ORDER BY COUNT(*) DESC LIMIT 5; ''' run_query(query) Как мы видим, ряд станций из этого списка аналогичен предыдущему списку, но их количество значительно ниже. Самые загруженные станции те же самые, но более низкие цифры в целом дают возможность предполагать, что люди обычно используют велосипеды Hubway, чтобы добраться от точки A до точки B, а не ездить на велосипеде некоторое время, прежде чем вернуться туда, где они начали. Здесь есть одно существенное отличие - Эспланд, который не был одной из самых загруженных станций по результатам нашего первого запроса, кажется самым загруженным для поездок туда и обратно. Почему? Что ж, картина стоит тысячи слов. Это, безусловно, выглядит как хорошее место для велопробега: На следующий вопрос: сколько поездок начинается и заканчивается в разных муниципалитетах? Этот вопрос делает заставляет нас двигаться дальше. Мы хотим знать, сколько поездок начинается и заканчивается в другом муниципалитете. Чтобы достичь этого, нам нужно присоединить таблицу поездок к таблице станций дважды. Один раз по столбцу start_station, а затем по столбцу end_station. Для этого необходимо создать псевдоним для таблицы станций, чтобы можно было различать данные, относящиеся к start_station, и данные, относящиеся к end_station. Мы можем сделать это точно так же, как присваивали псевдонимы отдельным столбцам, чтобы они отображались с более интуитивным именем, используя AS. Например, чтобы присоединить таблицу станций к таблице поездок с помощью псевдонима "start", можно использовать следующий код. Затем мы можем объединить "start" с именами столбцов с помощью "." для ссылки на данные, полученные из этого конкретного JOIN (вместо второго JOIN, где мы объединим таблицы по end_station столбец): INNER JOIN stations AS start ON trips.start_station = start.id Вот как будет выглядеть последний запрос при его выполнении. Обратите внимание, что мы использовали " " для представления "не равно", но != также будет работать. query = ''' SELECT COUNT(trips.id) AS "Count" FROM trips INNER JOIN stations AS start ON trips.start_station = start.id INNER JOIN stations AS end ON trips.end_station = end.id WHERE start.municipality end.municipality; ''' run_query(query) Это показывает, что около 300 000 из 1,5 миллионов поездок (или 20%) закончились в другом муниципалитете, - еще одно доказательство того, что люди в основном используют велосипеды Hubway для относительно коротких путешествий, а не более длительных поездок между городами. Если вы зашли так далеко, поздравляю! Вы начали осваивать основы SQL. Мы рассмотрели ряд важных команд, а также агрегирующие и арифметические функции. Они дадут вам прочную основу для развития по мере того, как вы продолжите свой путь в изучении SQL. Что дальше? После завершения данного руководства по SQL можно будет выбрать базу данных, которую вы найдете интересной, и написать запросы для извлечения информации из неё. Хорошим первым шагом может быть продолжение работы с базой данных Hubway, чтобы узнать, чего еще интересного можно достать из этой базы. Вот несколько вопросов, на которые вы можете попытаться ответить: Сколько поездок понесли дополнительные сборы (длились дольше 30 минут)? Какой велосипед использовался дольше всего? Какие пользователи, зарегистрированные или случайные, совершали больше поездок в оба конца? Какой муниципалитет имеет наибольшую среднюю продолжительность?
img
Компания Juniper является очень крупным производителем сетевого оборудования в мире - после Cisco and Huawei. После того как вы купили, установили и скоммутировали новое оборудование, возникает вопрос о его правильной настройке. Преимуществом коммутаторов от производителя Juniper, в основном, является возможность объединения до шести коммутаторов в одно единое устройство с надежным и удобным управлением портами, сохраняя стабильную и бесперебойную работу сети. Настройка сетевого интерфейса Настройка QoS (качество обслуживания) Virtual Chassis (объединение коммутаторов) Реализация возможности сброса до заводских настроек Настроив данные компоненты, вы сможете реализовать работу сети с использованием в ней большого количества устройств для осуществления передачи трафика. Настройка сетевого интерфейса Интерфейс коммутатора отвечает за реализацию передачи данных между сетью и пользователем, что и является главной задачей коммутатора. Его конфигурация осуществляется с помощью следующих строк кода: root> configure Entering configuration mode [edit] root# edit interfaces [edit interfaces] root# Конфигурация L3: [edit interfaces] root# set em0 unit 0 family inet address 100.0.0.1/30 Где: Em0 - физический интерфейс, а Family inet - позволяет выбрать протокол интерфейса. Команда "show" позволит из Configuration Mode проверить результат вашей настройки: [edit interfaces] root# show em0 { unit 0 { family inet { address 100.0.0.1/30; } } } [edit interfaces] Теперь примените настройки с помощью следующей команды: root# commit commit complete С помощью команды ping осуществим проверку конфигурации: root> ping 100.0.0.2 rapid PING 100.0.0.2 (100.0.0.2): 56 data bytes !!!!! --- 100.0.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.402/0.719/1.306/0.343 ms Конфигурация L2 root> configure Entering configuration mode [edit] root# edit interfaces em0 [edit interfaces em0] Необходимо задать дуплекс на интерфейсе: [edit interfaces em0] root# set link-mode full-duplex [edit interfaces em0] root# Примечание: L2 - устройства, работающие на канальном уровне, при этом коммутатором занимается фреймами. А L3 взаимодействуют с IP-адресами и осуществляют маршрутизацию. Конфигурация L3 включает большее число параметров за счет расширенного функционала. Настройка Virtual Chassis После правильной настройки интерфейса, следует перейти к объединению коммутаторов, которое позволит облегчить управление устройствами, а также повысить надежность работы сети, за счет взаимозаменяемости устройств. Следует отметить, что коммутаторы Juniper не имеют отдельным порт VCP, поэтому придется настраивать обычный интерфейс в качестве VCP. Конфигурация VCP вручную: Включите все коммутаторы, также вам понадобятся их заводская маркировка, которую следует записать. Для примера используем следующие: CT0216330172 CV0216450257 Включите коммутатор, который будет выполнять функцию master switch, после чего сделайте сброс настройка с помощью следующей строки кода: request system zeroize Перезагрузив систему, выполните следующие строки: ezsetup set system host-name sw_master set system domain-name metholding.int set system domain-search metholding.int set system time-zone Europe/Moscow set system root-authentication plain-text-password set system name-server 10.10.6.26 set system name-server 10.10.6.28 set system services ssh protocol-version v2 set system ntp server 10.10.1.130 version 4 set system ntp server 10.10.1.130 prefer set vlans Management description 10.10.45.0/24 set vlans Management vlan-id 100 set vlans Management l3-interface vlan.1 set interfaces vlan unit 1 family inet address 10.10.45.100/24 set routing-options static route 0.0.0.0/0 next-hop 10.10.45.1 set interfaces ge-0/0/47 unit 0 family ethernet-switching port-mode trunk set interfaces ge-0/0/47 unit 0 family ethernet-switching vlan members Management Активируем preprovisioned configuration mode: set virtual-chassis preprovisioned Вносим серийные номера оборудования: set virtual-chassis member 0 serial-number CT02/16330172 role routing-engine set virtual-chassis member 1 serial-number CV0216450257 role routing-engine set virtual-chassis no-split-detection Проверьте результат, с помощью следующей строки: root@sw-master> show virtual-chassis status Обнулите конфигурацию и включайте остальные коммутаторы: request system zeroize Раздел virtual-chassis в конфигурации должен быть пустой, а для подстраховки, используйте команду: delete virtual-chassis Настроим порты VCP для каждого коммутатора. Для данного примера, соедините коммутаторы портами ge-0/0/0 и ge-0/0/1 соответственно. Теперь задайте эти строки кода на каждом из коммутаторов: request virtual-chassis vc-port set pic-slot 0 port 0 request virtual-chassis vc-port set pic-slot 0 port 1 --------------------ВЫВОД---------------------------- root> show interfaces terse Interface Admin Link Proto Local Remote vcp-255/0/0 up up vcp-255/0/0.32768 up up vcp-255/0/1 up up vcp-255/0/1.32768 up up ge-0/0/2 up down ge-0/0/2.0 up down eth-switch Теперь два коммутатора объединились, проверить можно с помощью команды: show virtual-chassis status show virtual-chassis vc-port Если вы захотите добавить дополнительных участников к virtual-chassis, вам будет необходимо очистить конфигурацию нового коммутатора: show interfaces terse | match vcp Если есть, их надо удалить с командой: request virtual-chassis vc-port delete pic-slot 0 port 0 Внесите серийный номер дополнительного устройства: set virtual-chassis member 2 serial-number CT0217190258 role line-card Настройка портов VCP в новом коммутаторе, в котором мы соединяем следующими портами - ge-0/0/0 и ge-0/0/1: request virtual-chassis vc-port set pic-slot 0 port 0 request virtual-chassis vc-port set pic-slot 0 port 1 Теперь проверьте их наличие: show interfaces terse | match vcp НастройкаQoS Технология QoS используется для распределение используемого трафика и ранжирование на классы с различным приоритетом. Технология необходима для увеличения вероятности пропускания трафика между точками в сети. Сейчас мы рассмотрим деление потока трафика с приоритетом на ip-телефонию и видеоконференцсвязь на коммутаторе и использованием настроек по умолчанию class-of-service (CoS). Допустим, что ip-телефоны подключены к коммутатору, а для маркировки ip-пакетов от ip-PBX и других ip-телефонов используются следующие показания DSCP: 46 - ef - медиа (RTP) 24 - cs3 - сигнализация (SIP, H323, Unistim) 32 - cs4 - видео с кодеков (RTP) 34 - af41 - видео с телефона, софтового клиента, кодека (RTP) 0 - весь остальной трафик без маркировки. DSCP - является самостоятельным элементом в архитектуре сети, описывающий механизм классификации, а также Обеспечивающий ускорение и снижение задержек для мультимедийного трафика. Используется пространство поля ToS, являющийся компонентом вспомогательным QoS. Теперь требуется dscp ef и af отнести к необходимым внутренним классам expedited-forwarding и assured-forwarding. За счет конфигурации classifiers, появляется возможность создания новых классов. ex2200> show configuration class-of-service classifiers dscp custom-dscp { forwarding-class network-control { loss-priority low code-points [ cs6 cs7 ]; } forwarding-class expedited-forwarding { loss-priority low code-points ef; } forwarding-class assured-forwarding { loss-priority low code-points [ cs3 cs4 af41 ]; } } ex2200> show configuration class-of-service schedulers sc-ef { buffer-size percent 10; priority strict-high; } sc-af { shaping-rate 20m; buffer-size percent 10; } sc-nc { buffer-size percent 5; priority strict-high; } sc-be { shaping-rate percent 80; buffer-size { remainder; } } Наименования можно выбрать произвольно, но а процент выделенных буферов - в соответствии с необходимостью. Ключевым приоритетом работы QoS является определение трафика с ограничением пропускающей полосы в зависимости от потребности в ней. Шедулеры сопоставляются в соответствии с внутренними классами, в результате которого scheduler-map и classifier необходимо применяется ко всем интерфейсам, используя и описывая их в качестве шаблона. К интерфейсу возможно применять специфические настройки, подразумевающие возможность написания всевозможных scheduler и scheduler-maps для различных интерфейсов. Конечная конфигурация имеет следующий вид: ex2200> show configuration class-of-service classifiers { dscp custom-dscp { forwarding-class network-control { loss-priority low code-points [ cs6 cs7 ]; } forwarding-class expedited-forwarding { loss-priority low code-points ef; } forwarding-class assured-forwarding { loss-priority low code-points [ cs3 cs4 af41 ]; } } } host-outbound-traffic { forwarding-class network-control; } interfaces { ge-* { scheduler-map custom-maps; unit 0 { classifiers { dscp custom-dscp; } } } ae* { scheduler-map custom-maps; unit 0 { classifiers { dscp custom-dscp; } } } } scheduler-maps { custom-maps { forwarding-class network-control scheduler sc-nc; forwarding-class expedited-forwarding scheduler sc-ef; forwarding-class assured-forwarding scheduler sc-af; forwarding-class best-effort scheduler sc-be; } } schedulers { sc-ef { buffer-size percent 10; priority strict-high; } sc-af { shaping-rate 20m; buffer-size percent 10; } sc-nc { buffer-size percent 5; priority strict-high; } sc-be { shaping-rate percent 80; buffer-size { remainder; } } } Перед использованием данной настройки, проверьте командой commit check. А при наличии следующей ошибки, следует учесть следующее: [edit class-of-service interfaces] 'ge-*' One or more "strict-high" priority queues have lower queue-numbers than priority "low" queues in custom-maps for ge-*. Ifd ge-* supports strict-high priority only on higher numbered queues. error: configuration check-out failed В итоге мы не можем указать приоритет "strict-high" только для 5-ой очереди, когда у 7-ой останется приоритет "low". При этом можно решить проблему следующим образом: настроить для network-control приоритет "strict-high". Применив конфигурацию, определенный процент фреймов в очередях будет потеряна. Требуется обнулить счетчики, проверить счетчики дропов через некоторое время, где переменные значения не равны нулю. clear interfaces statistics all show interfaces queue | match dropped | except " 0$" При росте счетчиков дропа в конфигурации есть ошибка. Если вы пропустили описание в class-of-service interfaces шаблоном или в явном виде, то трафик в классах со стопроцентной вероятностью дропнется. Правильная работа выглядит следующим образом: ex2200> show interfaces queue ge-0/0/22 Physical interface: ge-0/0/22, Enabled, Physical link is Up Interface index: 151, SNMP ifIndex: 531 Forwarding classes: 16 supported, 4 in use Egress queues: 8 supported, 4 in use Queue: 0, Forwarding classes: best-effort Queued: Transmitted: Packets : 320486 Bytes : 145189648 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Queue: 1, Forwarding classes: assured-forwarding Queued: Transmitted: Packets : 317 Bytes : 169479 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Queue: 5, Forwarding classes: expedited-forwarding Queued: Transmitted: Packets : 624 Bytes : 138260 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Queue: 7, Forwarding classes: network-control Queued: Transmitted: Packets : 674 Bytes : 243314 Tail-dropped packets : 0 RL-dropped packets : 0 RL-dropped bytes : 0 Переход к заводским настройкам Если вам избавится от вашей конфигурации, которая работает некорректно вы можете сбросить настройки до заводских параметров. Советуем использовать данную функции, предусмотренную производителем оборудования, в случае реальной сложности в поиске ошибки, выполнив конфигурацию заново, вы можете заметно сэкономить свое время. Самый простой способ, это ввод следующей команды: load factory defaults После ввода команды, система оповестит Вас о том, что в данный момент будет осуществлена активация заводских настроек по умолчанию. А с помощью привычной команды "commit" активируем настройки и перезагружаемся. Мы рассмотрели базовые настройки коммутаторов Juniper, позволяющих создание надежной и гибкой сети для различных нужд.
img
Теперь вы знаете, как работают глобальные префиксы и подсети, а как насчет ID интерфейса? Мы еще не говорили о назначении IPv6-адресов нашим хостам. Назначение адресов хостам почти то же самое, что и для IPv4: Адреса должны быть уникальными для каждого хост; Вы не можете использовать префиксный адрес в качестве адреса хоста. Ранее мы писали про основы работы протокола IPv6 (Internet Protocol version 6). Вы можете настроить IPv6-адрес вручную вместе со шлюзом по умолчанию, DNS-сервером и т. д. или ваши хосты могут автоматически получить IPv6-адрес либо через DHCP, либо через что-то новое, называемое SLAAC (Stateless Address Autoconfiguration). Вот пример IPv6 адресов, которые вы могли бы выбрать для топологии, которая показана выше: Для интерфейсов роутера предлагаю использовать наименьшие числа, так как они легко запоминаются. В этом примере показан уникальный global unicast IPv6-адрес для каждого устройства. Это все, что касается global unicast адресов, так же мы должны рассмотреть уникальные локальные одноадресные адреса. Уникальные локальные адреса работают так же, как и частные адреса IPv4. Вы можете использовать эти адреса в своей собственной сети, если не собираетесь подключаться к Интернету или планируете использовать IPv6 NAT. Преимущество уникальных локальных адресов заключается в том, что вам не нужно регистрироваться в специализированном органе, чтобы получить дополнительные адреса. Вы можете распознать эти адреса, потому что все они начинаются с FD в шестнадцатеричном формате. Есть еще несколько правил, которым вы должны следовать, если хотите использовать уникальные локальные адреса: Убедитесь, что FD - это первые два шестнадцатеричных символ; Вам нужно составить 40-битный глобальный ID, вы можете выбрать все, что вам нравится; Добавьте 40-битный глобальный ID после "FD", чтобы создать 48-битный префикс; Следующие 16 бит должны использоваться для подсетей Это оставляет вам последние 64 бита для использования идентификатора интерфейса. Вот как выглядит уникальный локальный адрес: Это дает нам уникальный локальный адрес, который мы можем использовать в наших собственных сетях. Подсети global unicast адресов или уникальных локальных адресов точно такие же, за исключением того, что на этот раз мы сами создаем префикс вместо того, чтобы провайдер назначил нам глобальный префикс. Глобальный ID может быть любым, что вам нравится, с 40 битами у вас будет 10 шестнадцатеричных символов для использования. Вы можете выбрать что-то вроде 00 0000 0001, поэтому, когда вы поставите перед ним "FD", у вас будет префикс FD00:0000:0001::/48. Вы можете удалить некоторые нули и сделать этот префикс короче, он будет выглядеть так: FD00:0:1:: / 48 Теперь вы можете добавить различные значения за префиксом, чтобы сделать уникальные подсети: FD00:0:1:0000::/6; FD00:0:1:0001::/6; FD00:0:1:0002::/6; FD00:0:1:0003::/6; FD00:0:1:0004::/6; FD00:0:1:0005::/6; FD00:0:1:0006::/6; FD00:0:1:0007::/6; FD00:0:1:0008::/6; FD00:0:1:0009::/6; FD00:0:1:000A::/6; FD00:0:1:000B::/6; FD00:0:1:000C::/6; FD00:0:1:000D::/6; FD00:0:1:000E::/6; FD00:0:1:000F::/6; FD00:0:1:0010::/6; FD00:0:1:0011::/6; FD00:0:1:0012::/6; FD00:0:1:0013::/6; FD00:0:1:0014::/6; И так далее. Когда вы выполняете лабораторные работы, можно использовать простой глобальный ID. В конечном итоге вы получите короткий и простой в запоминании префикс. Для производственных сетей лучше использовать глобальный ID, чтобы он был действительно уникальным. Возможно, однажды вы захотите подключить свою сеть к другой сети, или, возможно, вам придется объединить сети. Когда обе сети имеют один и тот же глобальный идентификатор, вам придется изменить IPv6-адрес для объединённой сети. В случае, если глобальные идентификаторы отличаются, Вы можете просто объединить их без каких-либо проблем. Настройка на маршрутизаторе В оставшейся части этой статьи мы рассмотрим, как можно настроить IPv6 на наших роутерах. Если вы хотите настроить IPv6 адрес на роутере у вас есть два варианта: Вручную настроить 128-битный IPv6-адрес; Использовать EUI-64; Сначала я покажу вам, как вручную настроить IPv6-адрес, а затем объясню, что такое EUI-64. Вот что необходимо выполнить: OFF1(config)#interface fastEthernet 0/0 OFF1(config-if)#ipv6 address 2001:1234:5678:abcd::1/64 Вам нужно использовать команду ipv6 address, а затем вы можете ввести адрес IPv6. Префикс, который я использую, - это 2001:1234:5678:abcd, и этот роутер будет иметь в качестве своего адреса "хоста" "1". Если хотите Вы также можете ввести полный IPv6-адрес: OFF1(config)#interface fastEthernet 0/0 OFF1(config-if)#ipv6 address 2001:1234:5678:abcd:0000:0000:0000:0001/64 Эта команда будет иметь точно такой же результат, что и команда, введенная ранее. Мы можем проверить подсеть и IPv6-адрес следующим образом: OFF1#show ipv6 interface fa0/0 FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C000:18FF:FE5C:0 No Virtual link-local address(es): Global unicast address(es): 2001:1234:5678:ABCD::1, subnet is 2001:1234:5678:ABCD::/64 Данный вывод информации отображает global unicast адрес и нашу подсеть. Есть еще одна важная вещь, когда мы настраиваем IPv6 на роутере. По умолчанию роутер не будет пересылать никакие пакеты IPv6 и не будет создавать таблицу маршрутизации. Чтобы включить "обработку" пакетов IPv6, нам нужно включить его: OFF1(config)#ipv6 unicast-routing Большинство команд "ip" будут работать, просто попробуйте "ipv6" вместо этого и посмотрите, что он делает: OFF1#show ipv6 interface brief FastEthernet0/0 [up/up] FE80::C000:18FF:FE5C:0 2001:1234:5678:ABCD::1 OFF1#show ipv6 route connected IPv6 Routing Table - 3 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external C 2001:1234:5678:ABCD::/64 [0/0] via ::, FastEthernet0/0 Теперь вы знаете, как настроить IPv6-адрес вручную и как его проверить. После, почитайте о том, как настроить IPv6 с EUI-64 на Cisco.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59