Перейти до вмісту

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.

Image
малюнок 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. [Архівовано 2012-09-05 у Wayback Machine.]
  5. ↑ Lloyd, Alex. Building Spanner. Berlin Buzzwords. Архів оригіналу за 6 жовтня 2012. [Архівовано 2012-10-06 у Wayback Machine.]
  6. ↑ SQL VS. NOSQL VS. NEWSQL: FINDING THE RIGHT SOLUTION. Dataconomy. Архів оригіналу за 20 травня 2018.
  7. ↑ SAP HANA (англ.). SAP. Архів оригіналу за 26 липня 2014. [Архівовано 2014-07-26 у Wayback Machine.]
  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.
Отримано з https://uk.wikipedia.org/w/index.php?title=NewSQL&oldid=44017834