Свойства больших данных и ограничения RDBMS

Записаться

Почему мы не используем для этих задач реляционные базы данных, что в них не так? До сих пор, а это, я думаю, около 30 лет, они в общем-то устраивали отрасль и росли, их скорость соответствовала скорости требований рынка и скорости роста объема данных. Давайте посмотрим на само определение BigData, то есть мы сейчас понимаем почему BigData и реляционные базы данных не то чтобы несовместимы, и но как минимум ставят вопросы о новых технологиях хранения. Стандартное определение BigData - это 3V: Volume — объем, Velocity — скорость, Variety - разнообразие либо реактивность данных. Есть еще одно определение, оно добавляет уже 5V, еще добавляет шестое. Одно из них Veracity, и понятно, почему оно появилась позже, это достоверность данных в том смысле, насколько данные чисты, сколько в них шума и насколько они вариативны и взаимоисключающи, насколько внутри есть такие данные, и сколько в этих данных отклонений и аномалий. Понятно, что эти вещи можно было понять только когда мы уже с предыдущими разобрались, справились со скоростью, с объемом и с вариативностью, и перешли к анализу. Вот здесь все вопросы о содержимом наших данных. Есть вопрос виртуализации, ну и конечно же еще одна V - это решили увязывать все остальные требования через ценность. Давайте не будем гнаться за объемом, за скоростью и за вариативностью, давайте понимать, какова ценность каждого из этих составляющих для бизнеса, что бизнес получает через эти свойства больших данных.

Теперь через призму реляционных данных посмотрим с чем справляются, с чем не справляются текущие базы. Вообще скорость - это то, из-за чего реляционные базы данных появились и главная ценность, которую они предоставляли. Они были адаптированы именно на быструю обработку больших данных, и решалось это в первую очередь структурированием, то есть понималось, что чем больше структуры в данных, тем более типизированными мы можем сделать внутренние процедуры обработки, тем более, если мы включим в наше понимание данных еще и стандарты на запросы, то все это даст скорость в лекционных базах. Мы говорим, что базы данных были адаптированы на скорость чтения, главная операция — это операция выборки по условию, и мы предполагаем, что операций чтения у нас на порядки или на несколько порядков больше, чем операций записи и изменений. Понятно, что скорость выборки обеспечивается за счет использования индексов, а само построение индексов - это как раз та затратная операция, это та стоимость реляционных баз данных, за счет которой они получают свои плюсы и преимущества. Сложности возникают тогда, когда мы увеличиваем скорость записи или скорость обновления данных. В этом случае индексы должны часто перестраиваться, оптимизировать свою структуру, чтобы работать быстро на операциях выборки и чтения. Мы сразу фиксируем, что как только у нас скорость записи выравнивается со скоростью чтения, а это именно та ситуация, где мы анализируем большие данные, то есть мы как аналитик в единственном числе анализируем очень много данных, которые поставляются различными приложениями или из разных источников. Достаточно много записей, и выборки делаются единичными приложениями, а не миллионом пользователей, например.

Следующее, на что нужно проверить возможности реляционных баз данных - это масштабирование. Реляционные базы данных и системы управления ими решали данную задачу, есть решение кластеризации таких баз, существует несколько типов решения. Различают вертикальное и горизонтальное масштабирование. Вертикальное масштабирование - это увеличение количества ресурсов: вычислительных, объема памяти, объема диска, перенос с диска данных в память, увеличенную память и тому подобные операции, горизонтальное масштабирование - это масштабирование количества машин или количества серверов. Здесь возникает первая проблема для реляционных баз данных - изначально они не были разработаны для того, чтобы иметь различные копии данных. Первое требование, которое к базам данных выставлялось - это то, что называется consistency или целостность, или согласованность данных. Если у нас есть некоторые данные, которые должны быть взаимосвязаны и взаимосогласованы, значит они должны быть согласованы всегда, а как только у нас появляется распределенность, например, по разным серверам, разным машинам, у нас возникает либо отложенное согласование этих данных и в какой-то момент времени данные не согласованы, либо большая задержка на то, чтобы внутри одной транзакции все данные согласовать. То есть первая проблема — масштабирование, и проблема масштабирования решалась чаще всего методом репликации - это когда у нас изменения производятся в одну базу и у нас есть много других баз, которые являются копией мастер-базы, и они служат для выдачи, то есть для операций чтения. Понятно, что репликация адаптирует именно операции чтения, но не операции записи.

И третье основное требование, Variety - разнообразность данных. Необходимо сказать, что это самая главная проблема реляционных баз данных. Что значит различные, что значит вариативность данных? Это значит, что если мы берём данные из разных источников и пытаемся их увязать, например данные об одном и том же объекте, но в одном источнике у нас будет информация об одних его атрибутах, а в другом источнике о других его атрибутах - это значит, что если мы создадим таблицу, которая содержит поля того и другого источника, то большинство записей в данной таблице будут содержать значение Null, то есть она будет содержать заполненные значения, скажем, из одного источника и значения Null из другого источника. И наоборот, будут строки, в которых будет значение заполненно из второго источника и Null из первого. Такие данные называют общим термином прореженные или Sparse, и это уже само по себе говорит о том, что мы не оптимально используем объемы диска в реляционной базе.

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

Здесь достаточно понятная картинка. Говорим, что современные данные - это не движение в сторону структурированности, а наоборот, движение в сторону неструктурированности данных, то есть данные имеют изначально непредсказуемую структуру, мы не знаем, какой в следующий момент будут обладать структурой данные. При этом мы должны продолжать их сохранять и писать процедуры обработки.