При якому розмірі даних стає вигідним перехід від SQL до NoSQL?

Як програміст реляційних баз даних (більшість часу) я читав статті про те, як реляційні бази даних не масштабуються, і рішення NoSQL, такі як MongoDB. Оскільки більшість розроблених до цього часу баз даних були невеликими до середнього масштабу, у мене ніколи не було проблеми, яка не була вирішена деяким індексуванням, оптимізацією запитів чи переробленням схеми.

Якого розміру я б очікував, щоб з MySQL боролися. Скільки рядків?

(Я знаю, що це буде залежати від програми та типу даних, що зберігаються. Одне, що мене отримало, - це в основному генетична база даних, тому матиме одну головну таблицю з 3 або 4 таблицями пошуку. Основна таблиця міститиме серед інші речі, посилання на хромосому та координату позиції. Ймовірно, буде отримано запит на кількість записів між двома зіллями на хромосомі, щоб побачити, що там зберігається).

Наскільки великі дані?

Є два суттєвих пороги:

1. цілі дані вписуються в ОЗП
2. цілі дані індексу вписуються в оперативну пам'ять

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

Кислотність

Однією з проблем зі масштабуванням RDBMS є те, що за своєю конструкцією вони є ACID, що означає транзакції та блокування рівня рядків (або навіть рівень таблиці у деяких старих / простіших RDBMS). Це може бути обмежуючим фактором, якщо у вас є багато запитів, що змінюють багато даних, що працюють одночасно. Рішення NoSQL зазвичай підходять для моделі узгодженості .

Як масштабувати RDBMS за розміром даних?

Не зовсім вірно, що RDBMS не може масштабувати за розміром даних, є дві альтернативи: вертикальний розділ і горизонтальний розділ (він же шардинг).

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

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

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

Я не думаю, що розмір даних є єдиним фактором. "Модель даних" також є дуже важливою частиною.

Сторінки каталогу електронної комерції (Solr, ElasticSearch), дані веб-аналітики (Riak, Cassandra), ціни на акції (Redis), зв’язки відносин у соціальних мережах (Neo4J, FleetDB) - лише деякі приклади, коли рішення NoSQL справді світить.

IMHO, модель даних має важливішу роль, ніж розмір даних при розгляді рішення NoSQL або RDBMS.

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

У SQL є проблеми з деякими видами аналізу, але для запускання проблеми не потрібно багато даних. Наприклад, розглянемо єдину таблицю зі стовпцем, що посилається на інші рядки на основі унікального ключа. Зазвичай це може бути використане для створення структури дерева. Ви можете писати швидкі оператори SQL, які посилаються на відповідний рядок. Або пов'язаний рядок пов'язаного рядка. Насправді ви можете робити будь-яку конкретну кількість стрибків. Але якщо для кожного рядка ви хочете вибрати поле на першому спорідненому рядку в ланцюжку, яке відповідає деякому критерію, то воно ускладнюється.

Розгляньте таблицю місць розташування офісів на рівні країни, провінції / штату, округу, міста та села, при цьому кожен офіс посилається на офіс, про який він повідомляє. Там немає ні гарантії того, що звітність в офісі кожен офіс знаходиться тільки один рівень вгору. Для вибраного набору офісів, не всіх на одному рівні, потрібно перелічити національний офіс кожного з них. Для цього потрібні петлі SQL-статей і це займе багато часу навіть сьогодні. (Раніше я отримував 30 секунд на вибір 30 офісів, але це було давно - і перехід на збережені процедури трохи допоміг.)

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

Ніщо з цього не має великого відношення до кількості даних. Ключовим є характер організації даних. Якщо реляційний макет допомагає, то RDBMS - це те, що ви хочете. Якщо ні, то якесь об'ємне сховище буде що-небудь від трохи до квадрильйона разів швидше.

Зауважте, що якщо один із цих наборів даних стає занадто великим, щоб вміститися в пам'яті, ваша база даних, що не належать до SQL, більше не працює. Інша проблема - коли вам потрібні дані з декількох блоків одночасно; ви можете це зробити, якщо і лише тоді, коли всі блоки вписуються в пам'ять відразу. І користувачеві доводиться чекати, поки ви завантажуєте їх.

Якщо ваша реляційна база даних викличе у вас проблеми, це зробить це, перш ніж ви вкладете в неї багато даних. Єдина проблема з масштабуванням, яка може виникнути, - це з вашою програмою, коли блок даних, який ви збираєте для БД nosql - якщо вам доведеться його використовувати - стає для нього занадто великим. (Читайте на помилках, що не знаходяться в пам'яті. Новіші мови іноді роблять дивні речі з пам'яттю.)

Я думаю, що перша причина переходу на рішення NoSQL або Distributed - це не стільки розмір усіх даних, скільки розмір таблиць. Те, що добре розподіленими рішеннями, - це розбиття таблиць на різні вузли, тоді, коли потрібно запитувати таблиці, кожен вузол обробляє свою частину таблиці.

RDBMS можуть це зробити, але для цього була побудована нова хвиля баз даних NoSQL. Oracle, MSSQL, MySQL взяли свою централізовану модель і налаштували її, щоб вона працювала в розподіленому середовищі. Однак вони все ще дотримуються суворих правил ACID, хоча деякі нові бази даних не дотримуються суворих правил, таких як можлива послідовність.

Немає встановленого обсягу даних, де слід вибирати одне над іншим. Необхідно враховувати потреби бази даних та обсяг використання, який вона отримує. Бази даних NoSQL можуть обробляти більші набори даних швидше, тоді як реляційні бази даних надають вам впевненості, що ваші дані правильні з принципами ACID.

Можливо, варто також згадати, що ваша модель даних має великий вплив на речі. Якщо вам потрібно створити певну структуру дерева (тобто у вас є самостійний посилання на зовнішній ключ таблиці, який містить зазначений зовнішній ключ у складеному первинному ключі), ви, ймовірно, повинні подивитися на це в якійсь формі бази даних, яка обробляє ці типи даних дуже добре (наприклад, mongodb або couchdb).

Як і інші люди сказали, ви також повинні врахувати, що відбувається у вашій заяві. якщо вам дійсно потрібна кислота в декількох таблицях, тоді вам дійсно потрібно дотримуватися RDBMS, але якщо у вас є щось, де ви можете мати трохи несвіжі дані, і вам потрібна гнучкість схеми NoSQL (називайте це без схеми, якщо вам подобається, але це все ще є певна форма неявної схеми), то ви можете розглянути можливість захоплення магазину NoSQL ( http://www.10gen.com/customers/craigslist ось приклад того, чому Craigslist перейшов на перегляд ... але, правда, вони архівують ~ 10 ТБ дані, які, наскільки я знаю, зовсім не вписуються у ваш розмір бази даних від невеликого до середнього розміру, але корисний випадок використання).

Майте на увазі, що системи NoSQL не обов'язково існують для заміни RDMS, але в багатьох випадках ви можете доповнити RDBMS за допомогою ідеї Polyglot Persistence, і ви можете зберігати більшість своїх даних у RDBMS, але в конкретних нішевих випадках ви можете завантажувати частину своїх дані до якоїсь форми магазину NoSQL.

Mongoможна встановити на декількох комп'ютерах / вузлах. PostgreSQLне забезпечує вбудований інструмент для заточування, проте цитус є навколо.

MongoDB підтримує бази даних до 64 терабайт, а розмір документа - 16 мегабайт.

MySQL має ліміт баз даних 256 терабайт, максимальний розмір 64 терабайт для таблиці та ліміт запису в 4 гігабайти

PostgreSQL не має обмежень для бази даних (4 терабайти існує десь для тестування), і вона має обмеження в 1 гігабайт для розміру будь-якого одного поля в таблиці, і знову 64 терабайти максимальний розмір для таблиці.