NewSQL

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

NewSQL (з англ. новий SQL) — клас сучасних реляційних СУБД, які прагнуть поєднати в собі переваги NoSQL і транзакційні вимоги класичних баз даних[1][2][3]. Даний термін був запропонований в 2011 році Метью Аслетом, аналітиком 451 Group. Потреба в даних системах виникла в першу чергу у компаній, що працюють з критичними даними (наприклад, фінансового сектора), яким були потрібні масштабовані рішення, в той час як рішення NoSQL не могли надати транзакцій і не відповідали вимогам надійності даних[4][5].

Класифікація NewSQL

[ред. | ред. код]

Класифікація заснована на різних підходах, прийнятих зберегти SQL інтерфейс, а також вирішити масштабованість і продуктивність, що є проблемами традиційних рішень OLTP.

Нові бази даних

[ред. | ред. код]

Основна маса БД NewSQL є in-memory БД. Головною особливістю таких БД є те, що вони зберігають основну масу даних не на жорстких дисках, а в оперативній пам'яті. Розробники впевнені, що зберігання даних на HDD, є одним з основних недоліків існуючих БД, оскільки, найвищу швидкість обробки і отримання даних забезпечить переміщення їх в ОЗП. Недолік ОЗП на одному сервері, компенсується кластером таких серверів з великої кількості вузлів. Також в таких БД передбачено періодичне резервне копіювання даних на жорсткий диск, щоб запобігати можливим втратам при відмові сервера.

Отже, NewSQL система розробляється повністю з нуля з метою досягнення масштабованості та продуктивності. Одним з ключових факторів у підвищенні продуктивності є використання оперативної пам'яті або нових видів дисків (флеш-пам'ять / SSD), які є сховищем первинних даних. Дане рішення може здійснюватися програмно (VoltDB, NuoDB) або на рівні заліза (Clustrix, Translattice). Прикладами розробок є Clustrix, NuoDB і Translattice (комерційні) і VoltDB (Open Source).

Новий рушій бази даних MySQL

[ред. | ред. код]

Щоб подолати проблеми масштабованості MySQL, було створено ряд рушіїв заснованих на MySQL. Позитивна сторона — використання інтерфейсу MySQL, але є погана сторона — не підтримуються міграція даних з інших баз даних (включаючи старий MySQL). Приклади реалізації — Xeround, GenieDB (комерційні); і Akiban, MySQL Група NDB і ін. (opensource).

Один з найпоширеніших — TokuDB. Він використовує індекси, розташовані на фрактальних деревах. Вони набагато швидші, ніж індекси на В-деревах, особливо при переповненні оперативної пам'яті, що викликає необхідність зчитувати їх з жорсткого диска.

Прозоре об'єднання в кластери

[ред. | ред. код]

Мається на увазі застосовування кластерів SQL з декількох фізичних вузлів для зберігання і обробки великих обсягів даних. Хоч такий підхід і залишає БД OLTP в своєму первісному вигляді, але дозволять досягти масштабованості і горизонтального угруповання. Всі виробничі СУБД об'єднують в кластер. Він є середнім шаром (middleware), який перенаправляє запити до потрібних вузлів (де зберігаються дані), групує дані і видає єдиний результат. При такому підході, для запитів існують обмеження щодо використання зовнішніх ключів і джоінів.

Тобто, ці рішення зберігають бази даних OLTP в своєму оригінальному вигляді, але забезпечують особливість розширення, з прозорим угрупованням, та гарантують масштабованість. Інший підхід повинен забезпечити прозорий sharding, щоб також поліпшити масштабованість. БД Schooner MySQL, Continuent Tungsten і ScalArc слідують першому підходу, тоді як ScaleBase і dbShards слідують другому підходу. Обидва підходи дозволяють повторне використання існуючих наборів і екосистеми, і уникають потреби переписати код або виконати будь-які міграції даних. Приклади реалізацій — ScalArc, Schooner MySQL, dbShards (комерційний) ScaleBase; і Continuent Tungsten (opensource).

Технічні характеристики рішень NewSQL

[ред. | ред. код]
  1. SQL як основний механізм для взаємодії.
  2. ACID підтримка транзакцій.
  3. Механізм управління без застосування блокувань, таким чином зчитувальні дані в реальному часі не знаходиться в протиріччі з записуючими, що виключає конфлікт.
  4. Архітектура, що забезпечує набагато вищу продуктивність вузла, ніж доступний з традиційних рішень RDBMS.
  5. Зручне масштабування, здатне керувати великою кількістю вузлів, і не переносити вузькі місця.

Архітектурний приклад

[ред. | ред. код]

Розглянемо архітектурний приклад одного з NewSQL рішень (dbShards). Він представлений на малюнку 1.

малюнок 1

Переваги і недоліки NewSQL

[ред. | ред. код]

Розглянемо переваги і недоліки NewSQL[6]

Переваги NewSQL

[ред. | ред. код]
  • Мінімальна складність додатків, а також повна транзакційна підтримка.
  • Знайомий SQL і стандартні інструменти.
  • Багато систем пропонують кластери типу NoSQL з більш традиційними моделями даних і запитів.

Недоліки NewSQL

[ред. | ред. код]
  • NewSQL не є універсальною, як традиційна система SQL.
  • Обсяг пам'яті може перевищувати кілька терабайт.
  • Пропонує тільки частковий доступ до багатьох інструментів традиційних SQL-систем.

Рішення

[ред. | ред. код]

Існують різні підходи до вирішення завдання створення бази даних. Основними з яких є:

Принципово нова архітектура

[ред. | ред. код]

Найбільш популярним підходом є створення принципово нових платформ для зберігання даних. Подібні рішення проектуються спочатку з розрахунком на розподілену архітектуру і багатопоточність. Прикладами даних систем є:

Нові механізми зберігання SQL

[ред. | ред. код]

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

  • Infobright
  • TokuDB
  • і більш не розроблювальний InfiniDB

Прозоре масштабування

[ред. | ред. код]

Дані системи додають новий середній шар, покликаний приховати розподілену суть збережених даних. Приклади:

Див. також

[ред. | ред. код]

Примітки

[ред. | ред. код]
  1. Aslett, Matthew (2011). How Will The Database Incumbents Respond To NoSQL And NewSQL? (PDF) (англ) . 451 Group. Архів оригіналу (PDF) за 10 січня 2014.
  2. Stonebraker, Michael. New Sql: An Alternative to Nosql and Old Sql For New Oltp Apps (англ.). Communications of the ACM Blog. Архів оригіналу за 20 червня 2011.
  3. Hoff, Todd. Google Spanner's Most Surprising Revelation: NoSQL is Out and NewSQL is In (англ.). Архів оригіналу за 26 вересня 2012.
  4. Aslett, Matthew (2010). What we talk about when we talk about NewSQL (англ.). 451 Group. Архів оригіналу за 5 вересня 2012.
  5. Lloyd, Alex. Building Spanner. Berlin Buzzwords. Архів оригіналу за 6 жовтня 2012.
  6. SQL VS. NOSQL VS. NEWSQL: FINDING THE RIGHT SOLUTION. Dataconomy. Архів оригіналу за 20 травня 2018.
  7. SAP HANA (англ.). SAP. Архів оригіналу за 26 липня 2014.
  8. Proctor, Seth (2013). Exploring the Architecture of the NuoDB Database, Part 1 (англ.). Архів оригіналу за 15 липня 2013.
  9. Proctor, Seth (2013). Exploring the Architecture of the NuoDB Database, Part 2 (англ.). Архів оригіналу за 27 квітня 2018.
  10. ActorDB a distributed SQL database (англ.). 2014. Архів оригіналу за 6 травня 2022.
  11. Trafodion: Transactional SQL-on-HBase (англ.). 2014. Архів оригіналу за 19 квітня 2018.
  12. cockroachdb/cockroach. GitHub. Архів оригіналу за 9 травня 2018.
  13. Zhang, Jinpeng. TiDB: Performance-tuning a distributed NewSQL database. InfoWorld (англ.). Архів оригіналу за 14 лютого 2019. Процитовано 7 березня 2018.
  14. Meet TiDB: An open source NewSQL database. Opensource.com (англ.). Архів оригіналу за 31 липня 2019. Процитовано 14 листопада 2018.
  15. Xu, Kevin. How TiDB combines OLTP and OLAP in a distributed database. InfoWorld (англ.). Архів оригіналу за 14 листопада 2018. Процитовано 14 листопада 2018.