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

24

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

Какой размер я бы ожидал увидеть, как MySQL борется с этим. Сколько строк?

(Я знаю, что это будет зависеть от приложения и типа хранимых данных. То, что меня заинтересовало, было в основном базой данных генетики, поэтому будет иметь одну основную таблицу с 3 или 4 поисковыми таблицами. Основная таблица будет содержать среди другие вещи, ссылка на хромосому и координата позиции. Скорее всего, будет запрошено количество записей между двумя зельями в хромосоме, чтобы увидеть, что там хранится).

wobbily_col
источник
4
Вы, вероятно, не должны работать в предположении, что MySQL является верхним пределом для числа строк, которые может обработать реляционная база данных. Вы действительно задаете два вопроса: когда в MySQL заканчивается строка? и каковы пределы емкости SQL RDBMS? Что вы хотите ответить?
Blrfl

Ответы:

13

Насколько большие данные?

Есть два значимых порога:

  1. все данные помещаются в оперативную память
  2. все данные индекса помещаются в ОЗУ

С быстрыми твердотельными накопителями первый порог стал менее проблематичным, если у вас не сумасшедший высокий трафик.

кислотность

Одна из проблем, связанных с масштабированием СУБД, заключается в том, что по своей структуре они представляют собой ACID, что означает транзакции и блокировки на уровне строк (или даже уровень таблицы в некоторых старых / более простых СУБД). Это может быть ограничивающим фактором, если у вас много запросов, изменяющих много данных, запущенных одновременно. Решения NoSQL обычно используют модель конечной согласованности .

Как СУБД масштабируется по размеру данных?

Это не совсем верно, что СУБД не может масштабироваться в зависимости от размера данных, есть две альтернативы: вертикальное разделение и горизонтальное разделение (иначе говоря, разделение ).

Вертикальное разбиение в основном позволяет хранить несвязанные таблицы на отдельных серверах БД, поэтому размер каждого из них ниже пороговых значений, указанных выше. Это делает объединение этих таблиц с использованием простого SQL менее простым и менее эффективным.

Разделение означает распределение данных из одной таблицы между различными серверами на основе определенного ключа. Это означает, что для поиска вы знаете, какой сервер запрашивать на основе этого ключа. Однако это усложняет запросы, которые не являются поиском ключа шардинга.

В случае обоих видов разбиения, если вы пойдете на крайние меры, вы в основном окажетесь в той же ситуации, что и базы данных NoSQL.

Vartec
источник
9
Oracle, PostgreSQL, MySQL, MS SQL Server и Sybase способны выполнять соединения между таблицами на удаленных серверах без необходимости выполнения какой-либо работы клиентом.
Blrfl
4
Насчет "целых данных в ОЗУ" помните, что речь идет о реальном рабочем наборе. Часто базы данных больше памяти, но к большинству из них редко обращаются, имея их на диске не так уж и плохо, если в памяти находятся индексы, часто выбираемые строки и т. Д.
johannes
2
@vartec Итак, вы хотите отбросить мою двухлетнюю почту из моей почтовой базы данных, поскольку я ищу ее только раз в месяц, тогда как мой основной рабочий набор - это только последние десять писем?
Йоханнес
3
@wobbily_col подсказка: это не так. если вы не заботитесь о стабильности, надежности или долговечности. в этом случае вы можете отключить множество вещей, которые делают одно намного быстрее другого, или наоборот, если хотите. угадайте, какие настройки по умолчанию на каждом? (конечно, MySQL тоже не является вершиной безопасности данных ...)
Хавьер
1
@vartec "Автоматический шардинг" хорош там, где это применимо. Но вдруг вы больше не можете объединять все данные вместе - о, подождите, вы на самом деле не можете сделать это с базой данных документов, в которой поиск по всем данным или создание отчетов становится утомительным ... да, базы данных документов имеют свое место, когда модель данных и операции совпадают, то же самое для других систем ... количество данных само по себе не имеет значения (я знаю достаточно экземпляров MySQL, которые успешно работают с данными в терабайтовом регионе ... и проекты с
ошибками
13

Я не думаю, что размер данных является единственным фактором. «Модель данных» также является очень важной частью.

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

ИМХО, модель данных играет более важную роль, чем размер данных при рассмотрении решения NoSQL или RDBMS.

Chiron
источник
9
В точку. все эти "большие данные" бла бла хрень говорят о маркетинге и вся "NoSQL для больших данных!" вещи тоже. NoSQL хорош для больших наборов данных, потому что он быстрее, чем традиционная RDBMS, но он быстрее из-за огромных компромиссов функций, которые он делает. Многие модели данных значительно пострадают с учетом этих компромиссов, в то время как некоторые будут функционировать нормально. Нужно знать, что вы теряете при переходе на NoSQL, и использовать только NoSQL для данных, которые могут понести такие потери.
Джимми Хоффа
1
Хотя это правда, это не ответ на заданный вопрос.
vartec
Это не только НЕ ответ, но и НЕ верный. Вы можете создать документ в виде таблицы в базе данных SQL, просто используя тип данных JSON, и заставить базу данных SQL сиять над NoSQL.
Евгений Афанасьев
6

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

У SQL есть проблемы с некоторыми видами анализа, но для запуска проблемы не требуется много данных. Например, рассмотрим одну таблицу со столбцом, который ссылается на другие строки на основе уникального ключа. Как правило, это может быть использовано для создания древовидной структуры. Вы можете написать быстрые операторы SQL, которые ссылаются на соответствующую строку. Или связанный ряд связанный ряд. На самом деле вы можете сделать любое конкретное количество прыжков. Но если для каждой строки вы хотите выбрать поле в первой связанной строке в цепочке, которое удовлетворяет некоторому критерию, то это усложняется.

Рассмотрим таблицу местоположений офисов на уровне страны, провинции / штата, округа, города и деревни, где каждый офис ссылается на офис, которому подчиняется. Нет никаких гарантий, что в отделении отчетности каждого офиса будет только один уровень. Для выбранного набора офисов, не всех на одном уровне, вы хотите перечислить связанный национальный офис каждого из них. Это требует циклов SQL-операторов и займет много времени даже сегодня. (Я имел обыкновение получать 30 секунд на выбор из 30 офисов, но это было давно - и переход на хранимые процедуры помог немного.)

Таким образом, альтернатива состоит в том, чтобы поместить всю структуру в один большой блок данных, пометить его и сохранить. Если вы хотите проанализировать данные, считайте все это в память за один раз, устанавливая указатели для отслеживания структуры, и вы можете обработать пару миллионов офисов в мгновение ока.

Ничто из этого не имеет большого отношения к количеству данных. Ключом является характер организации данных. Если реляционная структура помогает, тогда вам нужна RDBMS. Если нет, то какое-то объемное хранилище будет быстрее от небольшого до четырех миллиардов раз.

Обратите внимание, что если один из этих наборов данных станет слишком большим, чтобы поместиться в память, ваша база данных, отличная от SQL, больше не будет работать. Другая проблема - когда вам нужны данные из более чем одного блока одновременно; Вы можете сделать это, если и только если все блоки помещаются в память одновременно. И пользователь должен ждать, пока вы загрузите их.

Если ваша реляционная база данных вызовет у вас проблемы, она сделает это до того, как вы добавите в нее много данных. Единственная проблема масштабирования, с которой вы можете столкнуться, связана с вашей программой, когда блок данных, который вы собираете для базы данных nosql - если вам нужно ее использовать - становится слишком большим для нее. (Читайте об ошибках нехватки памяти. Новые языки иногда делают странные вещи с памятью.)

RalphChapin
источник
0

Я думаю, что первая причина, по которой стоит обратиться к NoSQL или распределенному решению, - не столько размер всех данных, сколько размер таблиц. Что хорошо для распределенных решений, так это для разделения таблиц по разным узлам, тогда, когда вам нужно запросить таблицы, каждый узел будет обрабатывать свою часть таблицы.

СУБД могут сделать это, но для этого была создана новая волна баз данных NoSQL. Oracle, MSSQL, MySQL взяли свою централизованную модель и настроили ее, чтобы она работала в распределенной среде. Однако они все еще придерживаются строгих правил ACID, в то время как некоторые из новых баз данных не придерживаются строгих правил, таких как использование возможной согласованности.

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

DFord
источник
0

Также стоит упомянуть, что ваша модель данных имеет большое влияние на вещи. Если вам нужно создать какую-то форму древовидной структуры (то есть у вас есть внешний ссылочный внешний ключ в таблице, который содержит указанный внешний ключ в составном первичном ключе), вам, вероятно, следует взглянуть на это в некоторой форме базы данных, которая обрабатывает эти типы данных действительно хорошо (например, mongodb или couchdb).

Как и другие люди сказали, что вы также должны принимать во внимание то, что происходит в вашем приложении. если вам действительно нужен ACID для нескольких таблиц, тогда вам действительно нужно придерживаться СУБД, но если у вас есть что-то, где вы можете иметь несколько устаревших данных, и вам нужна гибкость схемы NoSQL (назовите ее без схемы, если хотите, но все еще имеет некоторую форму неявной схемы), тогда вы можете рассмотреть возможность захвата хранилища NoSQL ( http://www.10gen.com/customers/craigslist вот пример того, почему Craigslist переключился ... но по общему признанию, они архивируют ~ 10 ТБ данные, которые, как я знаю, совсем не вписываются в размер базы данных вашего малого и среднего размера. Но случай использования может быть полезен).

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

harageth
источник
0

Mongoможет быть установлен на нескольких компьютерах / узлах. PostgreSQLне предоставляет встроенный инструмент для шардинга, однако Citus рядом.

MongoDB поддерживает базы данных до 64 терабайт, а размер документа составляет 16 мегабайт.

В MySQL лимит базы данных составляет 256 терабайт, максимальный размер таблицы - 64 терабайта, а предел записи - 4 гигабайта.

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

Евгений Афанасьев
источник