Дані — це океан. Щоби ловити в ньому рибу, а не тонути, потрібно навчитися вибирати необхідні дані у конкретну секунду. З цим бізнесу допомагає мова SQL.
Максим Белько займається базами даних понад вісім років. Зараз він розробник в американській IT-компанії thredUP. Раніше працював у телеком-компаніях Lifecell та «Київстар». Максим розповів, чому робота з базами даних є обов'язковою умовою для будь-якого бізнесу, а шпигунські трилери про злом Пентагону — це казки.
Як використовувати SQL для масштабування бізнесу
У вас є ідея: купувати кавуни в Херсоні та продавати їх у Борисполі. Ви знаходите оптових продавців і того, хто привезе кавуни, дізнаєтесь про ціну. Починаєте продавати. Згодом купуєте вантажні машини та возите кавуни самі.
Де зафіксуєте контакти продавців та покупців, дані про машини? Найімовірніше, у телефоні чи Google-таблиці. А якщо постачальників, покупців та машин — десятки? А якщо почнете возити ще дині та квіти? Одного разу аркушів стане дуже багато, і розібратися в них буде дуже складно.
Вам знадобляться реляційні бази даних і те, що допоможе їх структурувати. Зазвичай бізнес купує коробкові рішення із підпискою. Але це тимчасовий вихід. Якоїсь миті ви захочете продавати і купувати за кордоном, з'являться представники — і треба буде видавати різні доступи до системи. Коробкового рішення буде замало.
При такому масштабуванні необхідна SQL — вона допоможе керувати базою даних, у якій всі процеси впорядковані. Знання SQL знадобиться, коли аркушів і рук не вистачає або загубилося замовлення. Тобто коли бізнес через хаос починає втрачати гроші.
Які завдання виконує система управління базами даних
Система управління базами даних (СУБД) — це те, що дозволяє отримувати інформацію з таблиць і дата-файлів. Вони зберігаються на диску операційної системи, а «діставати» їх допомагають реляційні бази даних.
«Реляційні бази даних» — набір таблиць з даними та ідентифікаторами. Це схоже на адресну книгу: ось Excel-таблиці — там імена абонентів та номери, які визначають місто абонента (ідентифікатори 1, 2...10). Перші таблиці з іменами за номером посилаються на таблицю з розшифровкою ідентифікаторів — так буде зрозуміле місто.
Завдяки цьому замість однієї громіздкої таблиці ми маємо багато маленьких і «легких», пов'язаних між собою таблиць. Так зменшуємо обсяг файлу з інформацією. Він займає менше місця на диску, час виконання запитів скорочується, система працює швидше.
Підключившись до бази даних через інтерфейс чи командний рядок, можна змінити чи витягти дані у зручному вигляді.
Як SQL допомагає бізнесу
У будь-якій ритейл-мережі — Auchan, Walmart, мережі аптек — безліч баз даних. Кожен, кому це потрібно, може «витягувати» та використовувати дані за допомогою SQL — мови структурованих запитів. Вона дозволяє виконувати запити різного типу. Наприклад, вивести список чеків за вчора дорожчих за певну суму і подивитися, на яких касах їх видавали.
Коли товар купили, привезли, відправили на зберігання чи продали, база даних оновлюється. Потрібно бути в курсі змін, щоби правильно на них реагувати. Якщо закінчується шоколадне морозиво, про це можна дізнатися, заглянувши до бази даних і вчасно його докупити.
Доступ до бази даних можуть мати багато аналітиків, але не всі розуміють, як писати запити, щоби бачити проміжні результати. Вони не можуть скласти ad-hoc звіти і чекають на перерахунки раз на тиждень від програмістів.
Але якщо аналітик показує програмістам, що знає про HAVING і SUM і вміє ними користуватися, довіри до нього буде більше, а доступ — ширшим (якщо компанія не забороняє).
Які висновки про внутрішні процеси дає SQL
SQL дозволяє «витягувати» будь-які дані будь-яких бізнесів — телеком-компаній, банків, перевізників. Але зробити це може не кожен. Щоб зануритися у бази даних, у користувача мають бути права та привілеї.
Телефонуйте, наприклад, мобільному оператору, а там кажуть: «Вітаю, Анно». Звідки вони знають ваше ім'я? Воно висвічується за номером телефону. Озвучуєте проблему — оператори роблять запит у базу даних, отримують відповіді в інтерфейсі на екрані.
Відповіді «виводить» бекенд, який безпосередньо звертається до бази даних і сам витягує інформацію. Він може подивитися, скільки грошей знялося, в результаті якої дії, як це поєднувалося з іншими. Дізнатися про дії можна лише щодо конкретного користувача — і лише те, що запропоновано адміністратором або базою даних.
Мене завжди смішить, коли у шпигунських фільмах хтось сідає за комп'ютер і за дві хвилини каже: «Все, я зламав Пентагон». Такого не буває. У базі даних купа зв'язків — потрібно багато часу, щоб зрозуміти, де яка таблиця і де що зберігається.
Приходячи на нові проєкти, ти два місяці тільки з усім знайомишся. Тобі кажуть: «Ось основна таблиця, п'ять колонок. Інші 15 дізнаєшся протягом наступного року». Немає діаграми на всю стіну, де розписано всі зв'язки.
Весь бізнес-контент у зручному форматі
Аналоги SQL
Мова SQL призначена для реляційних баз даних, а NoSQL — для нереляційних. Якщо база є реляційною, між таблицями є посилання. У нереляційній дані зберігаються в аркушах — дата-сетах із ключами зберігання.
Кожна з цих систем має свої переваги.
Там, де багато даних та запитів, потрібна SQL. Візьмемо телеком. Корпорація мобільного зв'язку має величезну кількість абонентів, і база даних NoSQL не впорається з таким обсягом інформації.
NoSQL — для всього, що зчитується та зберігається на ходу. Це проміжна база даних. Наприклад, заповнення кошика: заходимо на сайт, починаємо додавати покупки. Тут дані зберігаються у нереляційній базі. А коли замовлення зроблено, все переходить у реляційну.
SQL та NoSQL можуть існувати паралельно. Можливості передавати дані безпосередньо немає, але через мову програмування це реально. Припустимо, логіни та паролі зберігаються в нереляційній базі даних, а інформація про покупки та дисконти — у реляційній.
Безпека SQL для бізнесу
SQL застосовується до будь-якої сфери бізнесу, де є дані. Якщо дані секретні, потрібно захищати мережу.
Адміністратор встановлює базу даних на сервер у серверній, і тільки він розуміє, що саме там стоїть. Цього може не знати навіть програміст — він працює з персонального комп'ютера через інтернет/локальну мережу під логіном та паролем.
Іноді для роботи з базою даних логіну та паролю мало. Доступ до таблиць є, але інформація зашифрована. У банку часто кажуть: «Нікому не повідомляйте пароль». Паролі не читають навіть працівники — вони бачать кешовані кракозябрики. Увійти в базу, побачити номер банківської картки, пароль та кодове слово можливо, тільки якщо ви пройшли аутентифікацію.
На одному проєкті ми шифрували персональні дані за допомогою 64-бітного ключа, який знеособлює ім'я, по батькові та дату народження. В іншій базі даних зберігався ключ, що дозволяє ці дані дешифрувати. Це добре для безпеки, але погано для швидкості. Шифрування займає процесорний час.
Адміністратори банків розповідали мені, що їх викликали до відділення, де «все дуже повільно працювало». Виявлялося, що у всіх рівень доступу — суперкористувачі. Насамперед адміністратор забирав у користувачів-аналітиків адмінські права, потім призначав їх лише тим, кому це потрібно.
Хочеш доступ? Пиши службову записку з підтвердженням керівника. Привілеї видавали поступово, і це розв’язало проблеми з продуктивністю системи.
У базах даних Lifecell мільйони рядків — подій та дзвінків за день. Це дуже багато. Якщо 500 осіб мають доступ до цілої таблиці, система шукатиме дані по всій таблиці, а не за потрібний період. Помножте це на 500 людей. Якщо читання перевантажене іншим процесом, складно щось дописати, виникне конкуренція за «залізо» та пам'ять. Щоб уникнути перевантаження, завжди йдіть скороченим шляхом.
Аналітика та SQL
SQL не потрібна креативникам. Вона потрібна економістові у банку, який хоче стати провідним аналітиком. SQL аналізує дані, які найчастіше зберігаються у базі. Потрібно розуміти запити та вміти з ними працювати.
Аналітик може працювати без програмістів, доки дата-сетів, які вони підготували, достатньо для виконання завдань. Якщо недостатньо, він каже: «Мені потрібно бачити це, хочу, щоб дані будувалися за такими правилами». І озвучує бізнес-вимоги. Програміст каже: «Я створив вісім нових таблиць, між ними такий зв'язок. Вони доступні ось так, а нові з'являтимуться о 3:00 щодня».
Що потрібно, щоб опанувати SQL
Аби почати займатися SQL, достатньо базової школи математики та розуміння, як працюють таблиці Excel. Далі — курси, тренінги, мітапи, книги та вебінари. Чистим гуманітаріям опанувати цю сферу складно.
SQL — це все бекенд — те, чого ти не бачиш. За пів дня відеоуроку можна навчитися робити сайти — перший лендинг буде примітивним, дерев'яним, але буде. А тут усе за кадром. Вставив рядок, побачив «One row inserted» («Один рядок вставлено»). Щоб перевірити, потрібно написати запит, який виявить значення рядка з умовою.
Чого зараз не вистачає в SQL
Наразі бази даних переходять у хмари. Уже є Microsoft Azure, Amazon Redshift, Google BigQuery, які прискорюють передачу даних. Попередня компанія, в якій я працював, мала шість філій у всьому світі. Сервери стояли у Швейцарії та Китаї.
Коли Китай намагався отримати дані з швейцарського сервера (а це через інтернет), були затримки. Cloud-рішення дозволяють розподіляти інформацію. Запит у Європі «братиметься» з Гамбурга, в Америці — з Лас-Вегаса чи Сан-Франциско, а в Азії — з Китаю.
Але у хмарі можна зберігати не все. Не можна розміщувати телеком — занадто багато персональних даних. А якщо база зникне, компанії кінець. Якщо в телекомі щось не працює 20 хвилин, це погано (абоненти починають скаржитися). Пів дня — величезна проблема (починають йти). День — і оператор може закриватися.
Клауд-рішення важливі для таргетованої реклами. Коли заходите на сайт і дивитеся новий смартфон, його реклама переслідує вас у Facebook. Як це працює? Ваш профіль «проганяється» базою даних запитів — і щодня перераховується, де ви були і що робили.
Це вимагає високих потужностей, але не завжди. Щоби заощадити, продавець купить у хмарі нові сервери з більшим обсягом та потужностями, і впорається за 20 хвилин, заплативши тільки за них.
Бажаєте отримувати дайджест статей?
