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-систем.

Рішення

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

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

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

• Spanner
• Clustrix
• OrientDB
• VoltDB
• MemSQL
• SQLFire і GemFire XD
• SAP HANA[7]
• FoundationDB
• NuoDB[8][9]
• TransLattice
• ActorDB[10]
• Trafodion[11]
• CockroachDB[12]
• TiDB[13][14][15]

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

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

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

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

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

• dbShards
• Scalearc
• ScaleBase

Див. також

• Обробка транзакцій
• Секція (бази даних)

Примітки

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.