По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
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 минут)?
Какой велосипед использовался дольше всего?
Какие пользователи, зарегистрированные или случайные, совершали больше поездок в оба конца?
Какой муниципалитет имеет наибольшую среднюю продолжительность?
Почитатей первую часть статьи про траблшутинг NAT/PAT на Cisco.
В этой части мы рассмотрим проблемы DHCP.
Урок 1
Вот новый сценарий, позвольте мне сначала объяснить его:
Зеленая зона - это наша локальная сеть, так что это наш NAT inside.
Красная область - это Интернет, поэтому это наш NAT outside.
Предполагается, что хост - это компьютер с шлюзом по умолчанию 192.168.12.2.
Наш маршрутизатор NAT подключен к маршрутизатору ISP.
Маршрутизатор ISP назначил нам подсеть 172.16.1.0 / 24, которую мы собираемся использовать для трансляции NAT.
BGP был настроен между NAT и маршрутизатором ISP для доступа к сети 192.168.34.0/24.
Предполагается, что веб-сервер прослушивает TCP-порт 80 и использует 192.168.34.3 в качестве шлюза по умолчанию.
Однако пользователи нашей локальной сети жалуются на то, что не могут подключиться к веб-серверу. Давайте проверим нашу конфигурацию NAT:
Мы можем убедиться, что трансляция работает:
Inside local IP-адрес нашего хоста.
Inside global находится один из IP-адресов из нашей подсети 172.16.1.0/24.
Outside local and global IP-адрес нашего веб-сервера
Эта трансляция выглядит хорошо, потому что все IP-адреса верные.
Мы видим, что маршрутизатор NAT научился достигать сети 192.168.34.0 / 24 через BGP.
Наш NAT-маршрутизатор может подключаться к веб-серверу, поэтому проблема с подключением отсутствует. Однако следует помнить одну важную вещь. Пакет IP, который производит маршрутизатор NAT, выглядит следующим образом:
IP-адрес получателя является нашим веб-сервером, и с ним нет проблем. Исходный IP-адрес - 192.168.23.2, и поскольку мы получили ответ, мы знаем, что маршрутизатор ISP знает, как достичь подсети 192.168.23.0 / 24. Это важно, поскольку подсеть 192.168.23.0 / 24 напрямую подключена к маршрутизатору ISP.
Однако, если мы отправляем эхо-запрос с хост-устройства, он преобразуется из-за NAT в IP-адрес в подсети 172.16.1.0/24. Пакет IP будет выглядеть так:
Вот что происходит, когда этот IP-пакет покидает маршрутизатор NAT и отправляется маршрутизатору ISP:
Маршрутизатор ISP получает IP-пакет и проверяет свою таблицу маршрутизации, знает ли он, куда отправлять трафик для сети 192.168.34.0 / 24.
Сеть 192.168.34.0/24 напрямую подключена к маршрутизатору ISP, поэтому она выполняет запрос ARP для MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
Веб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначения 172.16.1.
Поскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
Маршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находится сеть 172.16.1.0 / 24.
Маршрутизатор ISP не знает, где находится 172.16.1.0 / 24, и отбросит IP-пакет.
Если бы это была настоящая производственная сеть, у нас не было бы доступа к маршрутизатору ISP. Так как это эмуляция сети и устройств, к которой у нас есть доступ, поэтому давайте сделаем отладку!
ISP#debug ip packet 1
IP packet debugging is on for access list 1
ISP#conf t
ISP(config)#access-list 1 permit host 192.168.34.4
Сначала включим отладку IP-пакетов и используем список доступа, который соответствует IP-адресу веб-сервера.
Следующим шагом является то, что мы будем генерировать некоторый трафик с хост-устройства.
Это то, что будет производить маршрутизатор ISP. Он говорит нам, что понятия не имеет, куда отправить IP-пакет для 172.16.1.1 to...it является не маршрутизируемым и будет отброшен.
Так как же мы решим эту проблему? ISP-маршрутизатор требует сеть 172.16.1.0 /24 в таблице маршрутизации. Поскольку мы уже запустили BGP мы можем использовать его для объявления этой сети с нашего маршрутизатора NAT:
NAT(config)#ip route 172.16.1.0 255.255.255.0 null 0
NAT(config)#router bgp 1
NAT(config-router)#network 172.16.1.0 mask 255.255.255.0
Сначала мы создадим статическое правило, которое указывает сеть 172.16.1.0 / 24 на интерфейс null0. Мы делаю это потому, что невозможно объявлять то, чего у тебя нет. Следующий шаг-объявить эту сеть в BGP.
Пинг прошел проблема решена!
Итог урока: убедитесь, что ваши маршрутизаторы знают, как связаться с translated сетями.
Урок 2
Начнем с простого сценария. Маршрутизатор с левой стороны - это наш DHCP-клиент, а маршрутизатор с правой стороны - это наш DHCP-сервер. Клиент, однако, не получает никаких IP-адресов ... что может быть не так?
Сначала мы проверим, включен ли интерфейс на клиенте DHCP и настроен ли он для DHCP. И это действительно так.
Мы также должны убедиться, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. Пока все выглядит хорошо...
Если мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail, чтобы посмотреть, отправляет ли клиент DHCP сообщения об обнаружении DHCP.
Мы видим некоторые отладочные выходные данные, как показано выше. Это говорит о том, что наш DHCP-клиент отправляет сообщения DHCP Discover. Клиент, скорее всего, не является источником этой проблемы.
DHCPServer#show ip dhcp pool
Мы будем использовать команду show ip dhcp pool, чтобы проверить, существует ли пул DHCP. Вы видите, что у нас есть пул DHCP с именем "MYPOOL", и он настроен для подсети 192.168.12.0 / 24. Пока все выглядит хорошо.
Мы можем использовать команду show ip dhcp server statistics, чтобы узнать, что делает сервер DHCP. Вы видите, что он ничего не делает ... что это может значить?
Эта команда не часто применяется. show ip sockets показывает нам, на каких портах роутер слушает. Как вы видите, он не прослушивает никакие порты ... если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.
DHCPServer(config)#service dhcp
Включим сервис.
Так-то лучше! Теперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.
Как только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP ... проблема решена!
Итог урока: если все в порядке, убедитесь, что служба DHCP работает.
Урок 3
Взгляните на сценарий выше. У нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент для своего интерфейса FastEthernet0/0. Маршрутизатор с правой стороны настроен как DHCP-сервер. Помните, что DHCP-сообщения об обнаружении от клиентов транслируются, а не пересылаются маршрутизаторами. Вот почему нам требуется команда ip helper на маршрутизаторе в середине, именуемым как relay. Проблема в этом сценарии заключается в том, что клиент не получает IP-адреса через DHCP
Сначала мы проверим, что интерфейс настроен для DHCP. Мы определим это с помощью команды show ip interface brief.
DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown
Мы будем переводить интерфейс в режимы up и down для проверки, будет ли он отправлять сообщение DHCP Discover.
Мы видим, что сообщения DHCP Discover принимаются на DHCP-сервере. Это означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщения. Сообщения с предложениями DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Это дает нам понять, что что-то происходит...
DHCPServer#debug ip dhcp server packet
Включим отладку, чтобы увидеть, что происходит.
Мы видим, что наш DHCP-сервер пытается достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. Знает ли DHCP-сервер, как добраться до этого IP-адреса?
Как вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.
Чтобы доказать это, мы можем включить отладку
Здесь видим, что IP-адрес назначения 192.168.12.2 не является маршрутизируемым, и в результате IP-пакет будет отброшен. Давайте исправим эту проблему.
DHCPServer(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2
Мы добавим этот статический маршрут, чтобы исправить нашу проблему с подключением.
Через некоторое время вы должны увидеть, что клиент получает IP-адрес через DHCP.
Если вы оставили "debug ip dhcp server packet" включенным, вы увидите весь процесс DHCP:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Вот и все ... проблема решена!
Итог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как связаться с подсетью, в которой находится клиент.
3 часть статьи про FHRP траблшутинг на Cisco доступна по ссылке.
Чтобы понять NoSQL, нужно разобраться, что такое SQL и почему мы говорим ему No.
Итак, SQL (structured query language) расшифровывается как «язык структурированных запросов», и это язык запросов для управления данными в так называемых реляционных базах данных, или просто БД
В реляционных базах мы храним данные в таблицах, которые логически связаны между собой - отсюда и название - реляционные от слова relation, связь. Это один из самых популярных типов баз.
В этих таблицах есть строки и столбцы. В столбце таблицы хранится определенный тип данных, а в каждой ячейке – значение.
Строка же получается как набор связанных значений, которые относятся к одному объекту - мы видим что у крыла типа чайка длина 25 метров.
Ну и каждая строка в таблице может быть помечена каким то уникальным идентификатором, который называется первичным ключом (primary key). А затем при помощи него мы можем связать данные из нескольких таблиц, например в отдельной таблице, где он станет внешним ключом (foreign key).
В общем, как таблица в экселе, только данные могут быть связаны.
Что еще важно знать: реляционные БД требуют так называемую схему (schema) - описание структуры таблицы ее полей и ограничений. То есть если нам например нужно добавить или убрать столбец в таблице, то это изменение коснется всех данных внутри нее.
Также БД этого типа соответствуют так называемым принципам ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Надёжность), что вкратце означает, что при работе с базой, целостность и согласованность данных гарантирована, даже если возникли проблемы с сетью или железом, что полезно при работе с финансами, например.
В качестве примеров таких баз назовем: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL.
Разобрались. Теперь вернемся к NoSQL. Это тип баз данных, которые хранят данные в отличном от реляционных таблиц формате. Они узкоспециализированны для конкретных задач и нужны для улучшения производительности, масштабируемости и удобства в работе.
Базы данных "ключ-значение" (key-value)
Суть в том, что мы храним данные в таком виде: у нас есть уникальный ключ, который указывает на какое-то значение. А сама база - это совокупность этих пар. Вот так просто! Причем эти данные могут быть чем угодно, числом, строкой или даже другой парой ключ-значение потому что в отличии от реляционных баз данных они не имеют предопределенной структуры данных.
Многие БД такого типа хранят данные в памяти (RAM), в отличии от других баз, которые хранят данные на диске, что хоть и может ограничивать объем хранимых данных (хотя они требуют гораздо меньше памяти), но это обеспечивают просто невероятную скорость. Ну и раз это NoSQL то никаких сложных запросов, никаких связей друг с другом - мы просто записываем ключ и его значение, и получаем значение по ключу.
Где их использовать? Они отлично подходят для хранения кэша или пользовательских сессий. А в качестве самого простого примера можно назвать корзину в интернет магазине - где мы храним идентификатор пользователя, и сколько товаров он положил в корзину.
Самые популярные хранилки по типу “ключ - значение” это Redis, Memcached и DynamoDB.
Wide-column (columnstore базы данных, БД с широкими столбцами или колоночные БД)
Все также просто - берем key-value БД, и делаем так чтобы в значении мы могли хранить несколько столбцов сразу. Это позволяет удобно хранить связанную информацию. Похоже на реляционную БД, но только в отличии от нее, тут у нас нет схемы, поэтому мы можем хранить разные неструктурированные данные.
Такой тип БД подойдет для хранения логов, данных с умных холодильников и чайников, а также различных аналитических приложений, где данные хранятся в большом объеме. Netflix, например, хранит в таких таблицах историю просмотров пользователя.
В качестве примеров таких баз назовем Cassandra, Hbase и ClickHouse.
Базы данных документов или документориентированные БД (Document DB)
Подробнее про них можно прочитать в нашей отдельной статье.
Если предыдущие типы NoSQL БД обычно используются для специфических задач, то эти базы уже более универсальны, и могут стать основным местом хранения информации.
Здесь мы храним документы. Документ это набор нескольких пар ключ-значение, о которых мы говорили раньше, и раз это не SQL, то они неструктурированны и не требуют схему. Это значит, что мы можем легко добавлять и удалять поля в документе, в отличие от реляционных БД, где изменения затронули бы всю таблицу. Документы даже могут быть вложенными, и содержать в себе другие документы.
Данные хранятся в стандартных форматах, таких как XML, YAML и JSON. Такая форма хранения идеально подходит к объектам, которые используются в приложениях. Мы буквально сразу получаем полный объект который нам нужен, а в SQL нужно сначала приложить усилия и даже сделать несколько запросов и все собрать в необходимый вид.
Документы можно группировать друг с другом собирая их в коллекции, которые можно собирать в логическую иерархию, получая что-то по типу реляционных БД.
Это как шкаф на работе - в один ящик мы можем положить трудовые договоры, в другой - договоры с партнерами, а в третий договоры аренды.
Ничто нам не мешает сложить всё в одну кучу, но так удобнее. И вот эти ящики как раз и будут коллекциями в нашем случае. А отсутствие схемы позволяет нам положить в один ящик договоры, которые схожи логически, но имеют разную структуру внутри. Например, долгосрочный договор с сотрудником и договор с компанией. Коллекции есть не у всех БД такого типа, некоторые системы используют теги или древовидные иерархии.
Они часто используются для мобильных приложений и игр, блогов, интернет магазинов и всяких штук где у нас имеется много контента.
Самые популярные БД такого типа - MongoDB, Amazon DynamoDB, CouchDB.
Графовые БД (Graph DB)
Тут мы больше значения уделяем тому как данные связаны друг с другом, и эта БД лучше всего обрабатывает такие данные.
Тут у нас есть узлы, которые представляют данные и ребра (или соединения), которые описывают связь между этими данными. Помните как в реляционных базах мы записывали связь в отдельной таблице? Тут мы можем обойтись без нее, просто показав связь.
Такие базы просто необходимы для алгоритмов рекомендаций, социальных сетей, управления компьютерными сетями и маршрутизацией или даже обнаружения финансового мошенничества.
Самые популярные графовые базы: Neo4j и DGraph
Поисковые БД (Search-engine database)
Они, как понятно из названия, нужны для поиска данных из большого количества источников.
Работают они примерно также как и базы данных документов - мы добавляем документы с текстом внутри, а БД проанализирует весь текст в этих документах и создаст индексы для этого текста.
По сути это работает как указатели, которые ты видел в конце книги, где указывается какой-то термин и страница на которой он встречается.
И когда пользователь выполняет поиск, то сканируются только эти индексы, а не все документы в базе.
Ну и очевидно что они используются в качестве полнотекстового поиска, а также для хранения и анализа логов. Примеры - Elasticsearch, Solr, Algolia
Базы данных временных рядов (Time series database)
Это базы данных, оптимизированные для данных с отметками времени. Такое используется, для мониторинга систем, где мы храним значение времени и данные в этот момент. Например, загрузка сервера или количество подключений.
Примеры - InfluxDB и Prometheus
Многомодульные БД (multi-model)
Также существуют так называемые много-модульные БД (multi-model), которые поддерживают несколько моделей данных.
Например тот же рredis умеет и в ключ-значение, и документы с графами и даже временные данные обработает.