Как программист реляционных баз данных (большую часть времени) я читал статьи о том, как реляционные базы данных не масштабируются, и о таких решениях NoSQL, как MongoDB. Поскольку большинство баз данных, которые я разработал до сих пор, были небольшими или средними, у меня никогда не было проблем, которые не были бы решены с помощью некоторой индексации, оптимизации запросов или редизайна схемы.
Какой размер я бы ожидал увидеть, как MySQL борется с этим. Сколько строк?
(Я знаю, что это будет зависеть от приложения и типа хранимых данных. То, что меня заинтересовало, было в основном базой данных генетики, поэтому будет иметь одну основную таблицу с 3 или 4 поисковыми таблицами. Основная таблица будет содержать среди другие вещи, ссылка на хромосому и координата позиции. Скорее всего, будет запрошено количество записей между двумя зельями в хромосоме, чтобы увидеть, что там хранится).
источник
Ответы:
Насколько большие данные?
Есть два значимых порога:
С быстрыми твердотельными накопителями первый порог стал менее проблематичным, если у вас не сумасшедший высокий трафик.
кислотность
Одна из проблем, связанных с масштабированием СУБД, заключается в том, что по своей структуре они представляют собой ACID, что означает транзакции и блокировки на уровне строк (или даже уровень таблицы в некоторых старых / более простых СУБД). Это может быть ограничивающим фактором, если у вас много запросов, изменяющих много данных, запущенных одновременно. Решения NoSQL обычно используют модель конечной согласованности .
Как СУБД масштабируется по размеру данных?
Это не совсем верно, что СУБД не может масштабироваться в зависимости от размера данных, есть две альтернативы: вертикальное разделение и горизонтальное разделение (иначе говоря, разделение ).
Вертикальное разбиение в основном позволяет хранить несвязанные таблицы на отдельных серверах БД, поэтому размер каждого из них ниже пороговых значений, указанных выше. Это делает объединение этих таблиц с использованием простого SQL менее простым и менее эффективным.
Разделение означает распределение данных из одной таблицы между различными серверами на основе определенного ключа. Это означает, что для поиска вы знаете, какой сервер запрашивать на основе этого ключа. Однако это усложняет запросы, которые не являются поиском ключа шардинга.
В случае обоих видов разбиения, если вы пойдете на крайние меры, вы в основном окажетесь в той же ситуации, что и базы данных NoSQL.
источник
Я не думаю, что размер данных является единственным фактором. «Модель данных» также является очень важной частью.
Страницы каталога электронной коммерции (Solr, ElasticSearch), данные веб-аналитики (Riak, Cassandra), цены на акции (Redis), связи отношений в социальных сетях (Neo4J, FleetDB) - это только некоторые примеры, когда решение NoSQL действительно блестяще.
ИМХО, модель данных играет более важную роль, чем размер данных при рассмотрении решения NoSQL или RDBMS.
источник
Если реляционные базы данных не масштабируются, ничего не происходит. Не беспокойтесь о проблемах масштабирования.
У SQL есть проблемы с некоторыми видами анализа, но для запуска проблемы не требуется много данных. Например, рассмотрим одну таблицу со столбцом, который ссылается на другие строки на основе уникального ключа. Как правило, это может быть использовано для создания древовидной структуры. Вы можете написать быстрые операторы SQL, которые ссылаются на соответствующую строку. Или связанный ряд связанный ряд. На самом деле вы можете сделать любое конкретное количество прыжков. Но если для каждой строки вы хотите выбрать поле в первой связанной строке в цепочке, которое удовлетворяет некоторому критерию, то это усложняется.
Рассмотрим таблицу местоположений офисов на уровне страны, провинции / штата, округа, города и деревни, где каждый офис ссылается на офис, которому подчиняется. Нет никаких гарантий, что в отделении отчетности каждого офиса будет только один уровень. Для выбранного набора офисов, не всех на одном уровне, вы хотите перечислить связанный национальный офис каждого из них. Это требует циклов SQL-операторов и займет много времени даже сегодня. (Я имел обыкновение получать 30 секунд на выбор из 30 офисов, но это было давно - и переход на хранимые процедуры помог немного.)
Таким образом, альтернатива состоит в том, чтобы поместить всю структуру в один большой блок данных, пометить его и сохранить. Если вы хотите проанализировать данные, считайте все это в память за один раз, устанавливая указатели для отслеживания структуры, и вы можете обработать пару миллионов офисов в мгновение ока.
Ничто из этого не имеет большого отношения к количеству данных. Ключом является характер организации данных. Если реляционная структура помогает, тогда вам нужна RDBMS. Если нет, то какое-то объемное хранилище будет быстрее от небольшого до четырех миллиардов раз.
Обратите внимание, что если один из этих наборов данных станет слишком большим, чтобы поместиться в память, ваша база данных, отличная от SQL, больше не будет работать. Другая проблема - когда вам нужны данные из более чем одного блока одновременно; Вы можете сделать это, если и только если все блоки помещаются в память одновременно. И пользователь должен ждать, пока вы загрузите их.
Если ваша реляционная база данных вызовет у вас проблемы, она сделает это до того, как вы добавите в нее много данных. Единственная проблема масштабирования, с которой вы можете столкнуться, связана с вашей программой, когда блок данных, который вы собираете для базы данных nosql - если вам нужно ее использовать - становится слишком большим для нее. (Читайте об ошибках нехватки памяти. Новые языки иногда делают странные вещи с памятью.)
источник
Я думаю, что первая причина, по которой стоит обратиться к NoSQL или распределенному решению, - не столько размер всех данных, сколько размер таблиц. Что хорошо для распределенных решений, так это для разделения таблиц по разным узлам, тогда, когда вам нужно запросить таблицы, каждый узел будет обрабатывать свою часть таблицы.
СУБД могут сделать это, но для этого была создана новая волна баз данных NoSQL. Oracle, MSSQL, MySQL взяли свою централизованную модель и настроили ее, чтобы она работала в распределенной среде. Однако они все еще придерживаются строгих правил ACID, в то время как некоторые из новых баз данных не придерживаются строгих правил, таких как использование возможной согласованности.
Не существует определенного количества данных, по которым вы должны выбирать одно из другого. Что необходимо принимать во внимание, это потребности базы данных и объем использования, которое она получает. Базы данных NoSQL могут быстрее обрабатывать большие наборы данных, тогда как реляционные базы данных дают вам уверенность, что ваши данные верны с принципами ACID.
источник
Также стоит упомянуть, что ваша модель данных имеет большое влияние на вещи. Если вам нужно создать какую-то форму древовидной структуры (то есть у вас есть внешний ссылочный внешний ключ в таблице, который содержит указанный внешний ключ в составном первичном ключе), вам, вероятно, следует взглянуть на это в некоторой форме базы данных, которая обрабатывает эти типы данных действительно хорошо (например, mongodb или couchdb).
Как и другие люди сказали, что вы также должны принимать во внимание то, что происходит в вашем приложении. если вам действительно нужен ACID для нескольких таблиц, тогда вам действительно нужно придерживаться СУБД, но если у вас есть что-то, где вы можете иметь несколько устаревших данных, и вам нужна гибкость схемы NoSQL (назовите ее без схемы, если хотите, но все еще имеет некоторую форму неявной схемы), тогда вы можете рассмотреть возможность захвата хранилища NoSQL ( http://www.10gen.com/customers/craigslist вот пример того, почему Craigslist переключился ... но по общему признанию, они архивируют ~ 10 ТБ данные, которые, как я знаю, совсем не вписываются в размер базы данных вашего малого и среднего размера. Но случай использования может быть полезен).
Имейте в виду, что системы NoSQL не обязательно существуют для замены RDMS, но во многих случаях вы можете дополнить свою RDBMS идеей Polyglot Persistence и вы можете хранить большую часть своих данных в RDBMS, но в определенных нишевых случаях вы можете разгрузить некоторые из ваших данные в той или иной форме хранилища NoSQL.
источник
Mongoможет быть установлен на нескольких компьютерах / узлах.PostgreSQLне предоставляет встроенный инструмент для шардинга, однако Citus рядом.MongoDB поддерживает базы данных до 64 терабайт, а размер документа составляет 16 мегабайт.
В MySQL лимит базы данных составляет 256 терабайт, максимальный размер таблицы - 64 терабайта, а предел записи - 4 гигабайта.
PostgreSQL не имеет ограничений на базу данных (4 терабайта где-то существует для тестирования), и он имеет ограничение в 1 гигабайт для размера любого одного поля в таблице и снова 64 терабайта максимального размера для таблицы.
источник