С давних времен человечество занималось тем, что накапливало информацию, анализировало и хранило её в каком-либо виде, чтобы потом передать потомкам. Эволюция нашего сознания смогла стать возможной во многом благодаря именно этому — новому поколению людей не надо было постигать то, что уже было постигнуто до них. Начиная с древнейших носителей информации – египетских папирусов и шумерских табличек с клинописью, человечество накапливало всё больший и больший объем информации. В истории человечества были времена, когда в результате войн и катаклизмов часть уже накопленных знаний уничтожалась или исчезала, и тогда прогресс останавливался, а человечество отбрасывалось назад в своем развитии. Настоящей революцией и прорывом стало открытие технологии массового книгопечатания, которое позволило распространять информацию на большую аудиторию, что в свою очередь привело к взрывному росту в науках, искусстве, а также вывело сознание всего человечества на более высокий уровень. Развитие технологий в ХХ веке привело к появлению новых носителей информации – перфокарты, перфоленты, жёсткие магнитные диски и т.п. Всё большие и большие объемы информации переносились из гроссбухов на электронные носители. Возникла потребность в организации и управлении доступа к этим данным – так появились первые СУБД.
Реляционная модель данных, предложенная в 1970 году Э.Ф. Коддом, надолго задала тенденцию в развитии баз данных и позволила полностью отвечать требованиям бизнеса до сегодняшнего момента. С 1970 года реляционные базы данных прошли большой путь и приняли много вызовов, встававших на их пути. Постоянно растущие объемы данных привели к появлению методов, способных обеспечить более быстрый доступ к необходимым данным – индексы, хранение данных в отсортированном виде и т.п. Эти методы вполне успешно справлялись со своей задачей, да и до сих пор не потеряли своей актуальности. Однако стремительное увеличение объемов носителей информации и удешевление стоимости хранения данных привело к тому, что объемы баз данных в десятки терабайт не являются уже чем-то необычным и воспринимаются, как обычное явление. Бизнес не может допустить, чтобы эти данные лежали «мертвым грузом», так как всё возрастающая конкуренция в мире заставляет его искать новые подходы к освоению сферы своей деятельности, ведь по крылатому выражению – «Кто владеет информацией, тот владеет миром». Если говорить о времени, то счет идет не на дни, или даже часы, а скорее на минуты – кто сможет быстро получить необходимую информацию, тот и выиграет.
Но не все современные базы данных готовы к новым объемам – старые методы уже не настолько эффективны. Главный компонент, который «тормозит» всю базу данных в целом — это устройство хранения информации. К сожалению, именно возможности жесткого диска встали сейчас на дальнейшем пути развития способов получения полезной информации из огромного набора данных в десятки терабайт. На сегодняшний момент технологии не поспевают за ростом объема данных, который необходимо анализировать. Flash-диски достаточно дороги, и обладают существенными недостатками, в частности, ресурс записи, препятствующими их использованию в качестве корпоративных устройств хранения информации для баз данных. В этой статье я предлагаю обсудить методы, использующиеся современными аналитическими базами данных для преодоления недостатков существующих технологий. Также хочется оставить обсуждение богатого различными разновидностями семейства баз данных NoSQL для отдельной статьи, дабы не вводить неразбериху в существующие подходы. Всё-таки базы данных с моделью NoSQL пока являются достаточно экзотичными для традиционных аналитических систем, хотя и завоевывали некоторую популярность в отдельных задачах. Основной интерес все же вызывают базы данных с традиционной реляционной моделью данных, отвечающие требованиям ACID и предназначенные для аналитики Больших Данных – как они отвечают на современный вызов.
Совершенно понятно, что данные, используемые аналитическими базами данных, должны быть соответственным образом подготовлены и упорядочены, так как из хаоса сложно выделить какие-либо закономерности. Однако из этого правила есть исключения, о которых мы поговорим позже, в рамках может быть другой статьи. Допустим, что данные подготовлены каким-либо ETL процессом и загружены в хранилище данных. Какие образом современные аналитические БД могут обеспечить такую скорость доступа к данным, которая позволила бы им не тратить несколько дней на чтение нескольких терабайт или десятков терабайт.
Massive Parallel Processing
Массово параллельная архитектура строится из отдельных узлов, где каждый узел имеет свой собственный процессор, память, а также средства коммуникации, позволяющие ему общаться с другими узлами. Отдельным узлом в данном случае является отдельная база данных, работающей в совокупности со всеми остальными. Таким образом, если спуститься на ступеньку ниже, мы увидим процесс или совокупность процессов, представляющий собой базу данных, и выполняющий свою, отдельную задачу, привнося свой вклад в общее дело. Благодаря тому, что каждый узел имеет свою инфраструктуру (процессор и память), мы не упираемся в традиционные ограничения, характерные для баз данных, представляющие по своей сути единственный узел с доступом ко всему объему хранимых данных. Здесь же, каждый узел хранит свою порцию данных и работает с ней, предоставляя максимально быстрый доступ. Как распределить весь объем данных равномерно по всем узлам – это тема для отдельного обсуждения.
Теоретически, для каждого узла мы можем предоставить свой собственный процессор и дисковую память, таким образом, максимальная скорость чтения данных будет равна сумме всех скоростей чтения для устройств хранения информации, позволяя достигнуть нам приемлемых результатов, относительно времени ответа тех запросов, где необходимо проанализировать сверхбольшие объемы информации. Практически, для достижения большей утилизации на одном сервере живут несколько узлов, разделяя между собой ресурсы.
Очевидно, что для баз данных, строящихся по такой архитектуре, один из узлов или каждый из них должен уметь принять запрос от пользователя, распределить его на все оставшиеся узлы, дождаться от них ответа и передать этот ответ пользователю в качестве результата выполнения его запроса.
Преимущества такой архитектуры лежат на поверхности – это практически линейная масштабируемость. Причем, масштабируемость как в горизонтальном, так и в вертикальном виде.
Недостатками является то, что необходимо приложить значительные усилия для создания программного обеспечения, позволяющего использовать все преимущество такой архитектуры, именно этим обуславливается высокая стоимость таких продуктов.
Аналитические реляционные базы данных, использующие MPP:
1. EMC Greenplum
Одно из лучших решений, обладающее мощной набором функциональных возможностей, предоставляющих возможность сконфигурировать его под любые задачи.
2. Teradata
Известное решение, хорошо зарекомендовавшее себя на рынке. Высокая стоимость по сравнению с конкурентами, не обусловленная значительными преимуществами.
3. HP Vertica
Достоинства решения являются в тоже время и его недостатками. Большой объем избыточных (дублированных) данных, который необходимо хранить, направленность на узкий круг задач, отсутствие некоторых важных функциональных возможностей.
4. IBM Netezza
Интересное и довольно быстрое решение. Недостатками является то, что это полностью аппаратное решение, построенное на проприетарной платформе, частично устаревшей. Есть вопросы, касающиеся масштабируемости.
По каждому решению можно составить отдельный обзор, если у читателей возникнет интерес в дальнейшем. Как бы то ни было, именно эти четыре продукта задают тенденцию в секторе MPP решений с shared nothing архитектурой. На их примере мы можем наблюдать вектор развития дальнейших технологий, направленных на обработку сверхбольших объемов данных. Появился совершенно новый класс баз данных, предназначенных именно для обработки десятков терабайт.
Однако, появилось и второе направление, позволяющее обойти ограничения, связанные с возможностями жестких дисков.
IMDB
In-memory database – это базы данных, работающие с данными, находящимися полностью в оперативной памяти. Как известно, оперативная память обладает быстродействием на порядок превосходящим обычные жесткие диски, тем самым предоставляя высокопроизводительное устройство хранения данных с огромной скоростью чтения, а также записи. Несмотря на это, желающих хранить свои данные полностью в оперативной памяти пока немного. Это связано с тем, в первую очередь, что стоимость такой памяти намного выше, чем стоимость жестких дисков. Немаловажным фактором является и то, что все данные пропадают, как только отключается электричество. Долгое время базы данных, работающие с данными в оперативной памяти, были вспомогательными и исполняли роль буфера, хранящего кратковременные данные, необходимые лишь для оперативной обработки. Тем не менее, снижение стоимости этого вида памяти подстегнули интерес к базам данных такого вида. Считается, что вхождение в область Больших Данных начинается с терабайт. До последнего времени, среди баз данных такого типа не было решений, которое могло бы работать с достаточно большим объемом. Однако, в 2011 году, SAP представил свою базу данных HANA, которая поддерживала до 8 терабайт несжатых данных. Теоретически, используя сжатие, объем используемых данных можно поднять до 40 терабайт. Другим представителем технологии IMDB выступает решение TimesTen от Oracle. Оба решения обладают большими функциональными возможностями и представляют собой наиболее развитые продукты в области In-Memory RDBMS.
Таким образом, компании готовы принять вызов, бросаемый Big Data. Уже придуманы и опробованы решения, позволяющие за приемлемое время получить ответ на вопросы, задаваемые аналитиками, маркетологами и руководителями базам данных, использующим накопленную за десятилетия информацию. Образовываются новые классы базы данных, предназначенные для обработки сверхбольших объемов данных. Разрабатываются новые методы для повышения скорости доступа к данным.
В тоже время, современные реалии показывают, что реляционные базы данных не могут быть решениями «всё-в-одном». Именно поэтому, кроме хранилища данных, выполняющего функцию хранения и обработки больших объемов информации, в компании должны присутствовать и OLTP базы данных, предназначенные для ведения операционной деятельности компании.
Автор: donjenya
