С уважением, я прочитал несколько статей в Интернете, в которых показано, что реляционные базы данных имеют проблемы с масштабированием и не подходят для использования в больших данных. Специально в облачных вычислениях, где данные большие. Но я не мог найти хороших веских причин, почему он не масштабируется много, по поиску в Google. Не могли бы вы объяснить мне ограничения реляционных баз данных, когда дело доходит до масштабируемости?
Спасибо.
Реляционные базы данных предоставляют надежные, зрелые услуги в соответствии со свойствами ACID. Мы получаем обработку транзакций, эффективное ведение журналов для обеспечения восстановления и т.д. Это основные службы реляционных баз данных, и те, в которых они хороши. Их сложно настроить, и их можно рассматривать как узкое место, особенно если они вам не нужны в конкретном приложении (например, для обслуживания контента веб-сайта с низкой важностью; в этом случае, например, широко используемый MySQL не обеспечивает транзакцию обработка с механизмом хранения по умолчанию, и, следовательно, не удовлетворяет ACID). Многие проблемы "больших данных" не требуют таких строгих ограничений, например, веб-аналитика, веб-поиск или обработка траекторий движущихся объектов, поскольку они уже включают неопределенность по своей природе.
При достижении пределов данного компьютера (память, ЦП, диск: данные слишком велики или обработка данных слишком сложна и затратна), хорошая идея - распространение службы. Многие реляционные базы данных и базы данных NoSQL предлагают распределенное хранилище. В этом случае, однако, ACID оказывается трудным для удовлетворения: теорема CAP несколько напоминает, что доступность, согласованность и допуск раздела не могут быть достигнуты одновременно. Если мы откажемся от ACID (удовлетворяющего, например, BASE), масштабируемость может быть увеличена. Смотрите этот пост, например. для категоризации методов хранения в соответствии с CAP.
Другим узким местом может быть гибкая и умная типизированная реляционная модель сама с операциями SQL: во многих случаях более простой модели с более простыми операциями будет достаточно и более эффективно (например, нетипизированные хранилища значений ключей). Общая построчная физическая модель хранения также может быть ограничивающей: например, она не оптимальна для сжатия данных.
Однако существуют быстрые и масштабируемые ACID-совместимые реляционные базы данных, в том числе новые, такие как VoltDB, поскольку технология реляционных баз данных является зрелой, хорошо изученной и широко распространенной. Нам просто нужно выбрать подходящее решение для данной проблемы.
Представьте себе два разных типа перекрестка.
У одного есть светофоры или полицейские, регулирующие движение, движение на перекрестке ограничено скоростью, и там сторожевой таймер регистрирует, какой именно автомобиль ехал на перекрестке, в какое время точно и в каком направлении он шел.
У другого нет никого из этого и всех, кто прибывает на перекресток с любой скоростью, которую он управляет, просто погружается и хочет пройти как можно быстрее.
Первый - это любой традиционный движок базы данных. Перекресток - это сами данные. Автомобили - это транзакции, которые хотят получить доступ к данным. Светофор или полицейский - это СУБД. Наблюдатель держит журналы и журналы.
Последний тип двигателя NOACID.
Оба имеют точку насыщения, и в этот момент прибывающие автомобили вынуждены запускать очередность в точках входа. Оба имеют максимальную пропускную способность. Этот порог находится на более низком значении для первого типа перекрестка, и причина должна быть очевидной.
Однако преимущество прежнего типа перекрестка должно быть очевидно. Меньше возможностей для несчастных случаев. На втором типе перекрестка вы можете ожидать, что несчастные случаи не произойдут только в том случае, если плотность движения будет намного ниже, чем теоретическая максимальная пропускная способность перекрестка. И в переводе на механизмы управления данными это означает гарантию последовательных и согласованных результатов, которые могут поставлять только прежний тип перекрестка (классический движок базы данных, будь то реляционный или сетевой или иерархический).
Аналогию можно продолжить дальше. Представьте, что произойдет, если произойдет несчастный случай. Что касается второго типа перекрестка, основной проблемой будет, вероятно, как можно быстрее очистить дорогу, чтобы движение могло возобновиться, и когда это будет сделано, какая информация по-прежнему доступна для расследования, кто вызвал несчастный случай и как? Ничего. Это не будет известно. Перекресток открыт, только ожидая следующего происшествия. На регулируемом перекрестке есть полицейский, регулирующий движение, который видел, что произошло, и может свидетельствовать. Там журналы, в которых указывается, какой автомобиль вошел в какое время точно, с какой точки входа точно, с какой скоростью точно, имеется много материала для проверки, чтобы определить первопричину аварии. Но, конечно, ничто из этого не приходит бесплатно.
Цветной достаточно, как объяснение?
Одна точка, о которой я не думаю, думает, что разбор SQL имеет значительные накладные расходы.
Это одна из причин, по которой подготовленные заявления настолько полезны. Тем не менее, в приложениях стиля CGI (краткое время выполнения, много экземпляров), таких как большинство приложений PHP, подготовленные операторы еще нужно разобрать один раз.
Часто сами серверы баз данных на самом деле достаточно быстры, и это просто, что в SQL-анализе возникают накладные расходы. У Yoshinori Matsunobu есть замечательная статья о внедрении handlerSocket, коннектора noSQL для MySQL + InnoDB, который может якобы достичь 750 000 запросов в секунду для поиска первичных ключей, что лучше, чем 420 000 запросов в секунду, которые он заявил для memcached.
Возьмем простейший пример: вставьте строку с сгенерированным идентификатором. Поскольку идентификаторы должны быть уникальными в таблице, база данных должна каким-то образом блокировать какой-то постоянный счетчик, чтобы ни один другой INSERT не использовал одно и то же значение. Таким образом, у вас есть два варианта: либо разрешить только одному экземпляру писать данные, либо распределить блокировку. Оба решения являются основными примерами бутылок - и это самый простой пример!