Рідна підтримка JSON в MYSQL 5.7: які плюси і мінуси типу даних JSON в MYSQL?

У MySQL 5.7 додано новий тип даних для зберігання даних JSON у таблицях MySQL . Очевидно, це буде великою зміною в MySQL. Вони перерахували деякі переваги

Перевірка документа - у стовпці JSON можуть зберігатися лише дійсні документи JSON, тому ви отримуєте автоматичну перевірку ваших даних.

Ефективний доступ - Що ще важливіше, якщо ви зберігаєте документ JSON у стовпці JSON, він не зберігається як звичайне текстове значення. Натомість він зберігається в оптимізованому бінарному форматі, що дозволяє швидше отримати доступ до членів об’єкта та елементів масиву.

Ефективність - Покращіть ефективність запиту, створивши індекси значень у стовпцях JSON. Цього можна досягти за допомогою «функціональних індексів» у віртуальних колонках.

Зручність - додатковий вбудований синтаксис для стовпців JSON дуже природно інтегрувати запити документів у свій SQL. Наприклад (Features.feature - це стовпець JSON):SELECT feature->"$.properties.STREET" AS property_street FROM features WHERE id = 121254;

ОЦЕ ТАК ! вони включають деякі чудові функції. Тепер простіше маніпулювати даними. Тепер можна зберігати складніші дані у стовпці. Таким чином, MySQL зараз ароматизований NoSQL.

Тепер я можу уявити собі запит для даних JSON на кшталт

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN 
( 
SELECT JSON_EXTRACT(data,"$.inverted") 
FROM t1 | {"series": 3, "inverted": 8} 
WHERE JSON_EXTRACT(data,"$.inverted")<4 );

Тож чи можу я зберігати величезні невеликі стосунки в кількох json colum? Це добре? Чи порушує це нормалізація. Якщо це можливо, я думаю, він буде діяти як NoSQL у стовпці MySQL . Мені дуже хочеться дізнатися більше про цю особливість. Плюси і мінуси типу даних MySQL JSON.

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN ...

Використання стовпця всередині виразу або такої функції псує будь-який шанс запиту за допомогою індексу, який допоможе оптимізувати запит. Запропонований вище запит змушений виконати сканування таблиці.

Претензія про "ефективний доступ" вводить в оману. Це означає, що після того, як запит вивчає рядок з документом JSON, він може витягнути поле, не розбираючи текст синтаксису JSON. Але для пошуку рядків все ще потрібно сканування таблиці. Іншими словами, запит повинен вивчати кожен рядок.

За аналогією, якщо я шукаю телефонну книгу для людей з прізвищем "Білл", мені все одно доводиться читати кожну сторінку в телефонній книзі, навіть якщо прізвища були виділені, щоб зробити їх трохи швидше їх помітити.

MySQL 5.7 дозволяє визначити віртуальний стовпчик у таблиці, а потім створити індекс віртуального стовпця.

ALTER TABLE t1
  ADD COLUMN series AS (JSON_EXTRACT(data, '$.series')),
  ADD INDEX (series);

Тоді якщо ви запитуєте віртуальний стовпець, він може використовувати індекс і уникати сканування таблиці.

SELECT * FROM t1
WHERE series IN ...

Це приємно, але це напевно не вистачає сенсу використання JSON. Привабливою частиною використання JSON є те, що вона дозволяє додавати нові атрибути, не роблячи ALTER TABLE. Але виявляється, вам все одно потрібно визначити додатковий (віртуальний) стовпець, якщо ви хочете шукати поля JSON за допомогою індексу.

Але не потрібно визначати віртуальні стовпці та індекси для кожного поля в документі JSON - лише ті, які ви хочете шукати або сортувати. У JSON можуть бути й інші атрибути, які потрібно витягнути лише у списку вибору, наприклад:

SELECT JSON_EXTRACT(data, '$.series') AS series FROM t1
WHERE <other conditions>

Я б загалом сказав, що це найкращий спосіб використання JSON в MySQL. Тільки у списку вибору.

Коли ви посилаєтесь на стовпці в інших пунктах (ПРИЄДНУЙТЕСЯ, ДІЙ, ГРУПУВАТИ ВІД, ІМУЙТЕ, ЗАМОВЛЕННЯ), то ефективніше використовувати звичайні стовпці, а не поля в документах JSON.

Я представив розмову під назвою Як використовувати JSON в MySQL Неправильно на конференції Percona Live в квітні 2018 року. Оновити і повторити розмову на Oracle Code One восени.

Є інші проблеми з JSON. Наприклад, у моїх тестах на це потрібно 2-3 рази більше місця для зберігання документів JSON порівняно зі звичайними стовпцями, що зберігають ті самі дані.

MySQL активно просуває свої нові можливості JSON, значною мірою для того, щоб відвернути людей від міграції до MongoDB. Але зберігання даних, орієнтоване на документи, як MongoDB - це принципово нереляційний спосіб організації даних. Це відрізняється від реляційних. Я не кажу, що один кращий за інший, це просто інша техніка, яка підходить для різних типів запитів.

Ви повинні вибрати JSON, коли JSON робить ваші запити ефективнішими.

Не вибирайте технологію лише тому, що вона нова чи заради моди.

Редагувати: Реалізація віртуального стовпця в MySQL повинна використовувати індекс, якщо ваш пункт WHERE використовує точно такий же вираз, як і визначення віртуальної колонки. Тобто наступним слід використовувати індекс на віртуальному стовпчику, оскільки віртуальний стовпець визначенийAS (JSON_EXTRACT(data,"$.series"))

SELECT * FROM t1
WHERE JSON_EXTRACT(data,"$.series") IN ...

За винятком того, я виявив, перевіривши цю функцію, що вона НЕ працює з якоїсь причини, якщо вираз є функцією JSON-екстрагування. Він працює для інших типів виразів, тільки не для функцій JSON.

Наступне з MySQL 5.7 повертає сексуальне зображення з JSON для мене добре:

Використання типу даних JSON у MySQL має дві переваги перед зберіганням рядків JSON у текстовому полі:

Перевірка даних Документи JSON будуть автоматично підтверджені, а недійсні документи дадуть помилку. Вдосконалений внутрішній формат зберігання. Дані JSON перетворюються у формат, який дозволяє швидко читати доступ до даних у структурованому форматі. Сервер може шукати субекти або вкладені значення за ключем або індексом, що забезпечує додаткову гнучкість та продуктивність.

...

Спеціалізовані смаки магазинів NoSQL (БД документів, сховища ключових значень та графічні БД), ймовірно, є кращими варіантами для конкретних випадків їх використання, але додавання цього типу даних може допомогти вам зменшити складність вашої технології стеку. Ціна пов'язана з базами даних MySQL (або сумісними). Але це не проблема для багатьох користувачів.

Зверніть увагу на мову підтвердження документів, оскільки це важливий фактор. Я думаю, акумулятор тестів потрібно виконати для порівняння двох підходів. Ці два буття:

1. Mysql з типами даних JSON
2. Mysql без

Зараз у мережі є неглибокі слайди на тему mysql / json / performance від того, що я бачу.

Можливо, ваша посада може стати центром для цього. Або, можливо, продуктивність - це думка, не впевнений, і ви просто раді не створювати купу таблиць.

Нещодавно я потрапив у цю проблему і підсумовую такий досвід:

1, Немає способу вирішити всі питання. 2, Ви повинні правильно використовувати JSON.

Один випадок:

У мене є таблиця з іменем:, CustomFieldі вона повинна мати два стовпці: name, fields. nameце локалізований рядок, він повинен містити такий вміст:

{
  "en":"this is English name",
  "zh":"this is Chinese name"
   ...(other languages)
}

І fieldsмає бути таким:

[
  {
    "filed1":"value",
    "filed2":"value"
    ...
  },
  {
    "filed1":"value",
    "filed2":"value"
    ...
  }
  ...
]

Як бачите, і те, nameі теfields можуть бути збережені у форматі JSON, і це працює!

Однак якщо я використовую nameдля пошуку в цій таблиці дуже часто, що мені робити? Використовувати JSON_CONTAINS, JSON_EXTRACT...? Очевидно, що це не гарна ідея зберегти її як JSON більше, ми повинні зберегти її до незалежної таблиці:CustomFieldName .

З вищенаведеного випадку, я думаю, ви повинні пам’ятати про ці ідеї:

1. Чому MYSQL підтримує JSON?
2. Чому ви хочете використовувати JSON? Чи потрібна була ваша логіка бізнесу? Або є щось інше?
3. Ніколи не лінуйся

Дякую

З мого досвіду, реалізація JSON принаймні в MySql 5.7 не дуже корисна через низьку продуктивність. Ну, це не так вже й погано для читання даних та перевірки. Однак модифікація JSON у 10-20 разів повільніше для MySql, ніж для Python або PHP. Давайте уявимо дуже простий JSON:

{ "name": "value" }

Припустимо, ми повинні перетворити його на щось подібне:

{ "name": "value", "newName": "value" }

Ви можете створити простий скрипт з Python або PHP, який буде вибирати всі рядки та оновлювати їх по одному. Ви не змушені робити одну величезну транзакцію за неї, тому інші програми зможуть використовувати таблицю паралельно. Звичайно, ви також можете зробити одну величезну транзакцію, якщо хочете, тому ви отримаєте гарантію, що MySql виконає "все або нічого", але інші програми, швидше за все, не зможуть використовувати базу даних під час виконання транзакцій.

У мене таблиця 40 мільйонів рядків, і сценарій Python оновлює її за 3-4 години.

Тепер у нас є MySql JSON, тож нам більше не потрібен Python або PHP, ми можемо зробити щось подібне:

UPDATE `JsonTable` SET `JsonColumn` = JSON_SET(`JsonColumn`, "newName", JSON_EXTRACT(`JsonColumn`, "name"))

Це виглядає просто і відмінно. Однак його швидкість у 10-20 разів повільніше, ніж версія Python, і це єдина транзакція, тому інші програми не можуть паралельно змінювати дані таблиці.

Отже, якщо ми хочемо просто дублювати ключ JSON в таблиці 40 мільйонів рядків, нам взагалі не потрібно використовувати таблицю протягом 30-40 годин. Він не має сенсу.

Щодо читання даних, з мого досвіду прямий доступ до поля JSON через JSON_EXTRACTin WHEREтакож надзвичайно повільний (набагато повільніше, ніж TEXTу LIKEнеіндексованому стовпчику). Віртуальні згенеровані стовпці працюють набагато швидше, однак, якщо ми заздалегідь знаємо нашу структуру даних, нам не потрібен JSON, ми можемо замість цього використовувати традиційні стовпці. Коли ми використовуємо JSON там, де це дійсно корисно, тобто коли структура даних невідома або часто змінюється (наприклад, налаштування спеціальних плагінів), створення віртуальних стовпців регулярно для будь-яких можливих нових стовпців не виглядає гарною ідеєю.

Python та PHP роблять валідацію JSON як шарм, тому сумнівно, чи взагалі потрібна перевірка JSON на MySql. Чому б також не перевірити документи XML, Microsoft Office або перевірити правопис? ;)