Интерес к технологиям больших данных постоянно растет, а сам термин становится все более популярным; многие хотят об этом поговорить, обсудить перспективы и возможности в этой сфере.
Однако мало кто уточняет, какие компании представлены на этом рынке, не описывают решения этих компаний, а также не говорят о методах, лежащих в основе решений Big Data. Область информационных технологий, связанных с хранением и обработкой данных, на сегодняшний день претерпела значительные изменения и представляет собой быстрорастущий рынок, а значит лакомый кусок для многих всемирно известных и небольших, только начинающих, компаний в этой сфере.
Типичная крупная компания имеет несколько десятков операционных баз данных, в которых хранятся данные об операционной деятельности компании (операции, товарно-материальные запасы, балансы и т. д.), необходимые аналитикам для бизнес-анализа.
Поскольку сложные, неожиданные запросы могут привести к непредсказуемой нагрузке на оперативные базы данных, предпринимаются усилия по ограничению запросов аналитиков к таким базам данных.
Кроме того, аналитикам нужны исторические данные, а также данные из нескольких источников.
Чтобы предоставить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных — корпоративные информационные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки систем принятия решений.
Хранилища данных также служат источником для оценки эффективности маркетинговых кампаний, прогнозирования, поиска новых возможных рынков и аудиторий для продаж, а также всевозможного анализа предыдущих периодов деятельности компании.
Как правило, хранилище данных представляет собой предметно-ориентированную базу данных, построенную на временной основе, т.е.
все изменения данных отслеживаются и фиксируются с течением времени, что позволяет отслеживать динамику событий.
Хранилища данных также хранят долгосрочные данные — это значит, что они никогда не удаляются и не перезаписываются — добавляются только новые данные, это необходимо для изучения динамики изменения данных во времени.
Наконец, хранилища данных в большинстве случаев объединяются с несколькими источниками, например.
Данные поступают в хранилище данных из нескольких источников, и перед попаданием в хранилище эти данные проверяются на целостность и достоверность.
В феврале 2012 года исследовательско-консалтинговая компания Gartner представила свой аналитический отчет по хранилищам данных.
Для целей настоящего отчета хранилище данных определяется как СУБД, которая управляет и обслуживает одну или несколько логических баз данных в хранилище.
Кроме того, СУБД хранилища данных должна поддерживать реляционную модель данных, а также должна иметь возможность предоставлять доступ к данным через программные интерфейсы, чтобы сторонние аналитические приложения могли воспользоваться данными, расположенными в хранилище данных.
Помимо этого, СУБД хранилища данных должна иметь механизмы, изолирующие разные типы нагрузок друг от друга, а также управляющие различными параметрами доступа пользователей в рамках одного экземпляра данных.
Поскольку одним из требований Gartner к хранилищам данных в этом аналитическом отчете была поддержка реляционной модели данных, решения на базе платформы Apache Hadoop не вошли в список кандидатов для рассмотрения в этом отчете.
Кроме того, Apache Hadoop не совсем соответствует требованиям, предъявляемым к современным хранилищам данных, поскольку имеет низкую скорость выполнения сложных аналитических запросов по сравнению с другими решениями, представленными в этом отчете, и, очевидно, не может выполнять задачи, поставленные компаниями перед современными хранилищами данных.
хранилища данных.
Несмотря на это, платформа Apache Hadoop является быстро развивающимся проектом и, возможно, в будущем решения на базе этой платформы займут свое место рядом с решениями других производителей.
Также хотелось бы отметить, что Apache Hadoop не предназначен для анализа данных в реальном времени — это решение для хранения неструктурированных данных с возможностью анализа этих данных в будущем, что не отвечает требованиям компаний иметь возможность для быстрого анализа данных для хранилищ данных.
Кроме того, парадигма MapReduce не подходит для всего класса аналитических задач, которые возникают перед аналитиками.
Однако большинство решений, обсуждаемых в этой статье, поддерживают интеграцию с Apache Hadoop. По результатам анализа, проведенного в этом отчете, Гарднер составил так называемый «магический квадрант», где разместил компании по полям этого квадрата.
В этой статье я хотел бы подробнее рассмотреть решения компаний, находящихся в правом верхнем углу магического квадранта Gartner. Точнее, не на самих решениях, а на тех свойствах решений, которые позволили им выйти в лидеры и проанализировать эти свойства, а также оценить их применимость в будущем.
Прежде чем мы посмотрим, что общего между лидерами в сфере хранилищ данных, имеет смысл поближе взглянуть на решение Oracle, поскольку оно в целом отличается от своих конкурентов.
Для хранилищ данных Oracle предлагает использовать свою аппаратную платформу Exadata Database Machine X2-2. Однако это только оборудование — лицензии на Oracle Database приобретаются отдельно.
Чтобы добиться максимальной производительности и отказоустойчивости, необходимо приобрести отдельные лицензии для Oracle Real Application Clusters и секционирования.
Oracle утверждает, что этот тип хранилища данных может использоваться одновременно как OLTP-системой, так и решением DW. Это утверждение справедливо в ограниченном числе случаев — зачастую существование разных типов нагрузок на одной платформе приводит к неоптимальной производительности обеих.
Архитектура Exadata подразумевает разделение на два типа серверов – это вычислительные узлы Exadata Database Server X2-2, где расположена СУБД Oracle Database, и узлы Exadata Storage Server, хранящие данные.
Точнее, на сервере хранения данных Exadata размещено программное обеспечение сервера хранения данных Exadata, которое включает в себя так называемые «Cell Services», что, в свою очередь, позволяет использовать технологию «Smart Scan».
«Умное сканирование» берет на себя практически всю работу по простому поиску и извлечению данных, тем самым освобождая вычислительные узлы от лишней нагрузки.
Такая архитектура позволяет Oracle выполнять балансировку нагрузки и уменьшать объем данных, передаваемых между двумя типами узлов, но имеет существенный недостаток, а точнее ограниченную масштабируемость, не позволяющую масштабировать платформу Exadata линейно.
Это приводит к тому, что после определенного момента добавление новых узлов не приносит существенного прироста производительности и в то же время является достаточно дорогостоящей операцией, поскольку оборудование и программное обеспечение Oracle стоят дорого.
Таким образом, можно сделать вывод, что решения Oracle для хранилищ данных не смогут оправдать будущие ожидания компаний, хотя и обеспечивают приемлемую производительность на данный момент. То, что Oracle находится на втором месте после Teradata, связано, на мой взгляд, с агрессивной маркетинговой политикой Oracle, а также с тем, что многие клиенты, уже использующие Oracle, решили консолидировать свои базы данных на аппаратной платформе Oracle, тем самым снизив затраты на обслуживание.
и поддержку, не жертвуя при этом производительностью.
Поэтому у Oracle нет тех возможностей, которые есть у других лидеров в этом обзоре, но, несмотря на это, большой опыт разработки баз данных и огромное количество клиентов позволили находиться в секторе.
Обзор Oracle Exadata и раскрытие ее недостатков со стороны Teradata То же самое можно сказать и о компании Microsoft, которая представлена на рынке решениями СУБД SQL Server 2008 R2 Business Data Warehouse и Fast Track Data Warehouse. По сути, эти решения лишены достаточной технической функциональности по сравнению с конкурентами, но в то же время предлагают множество маркетинговых возможностей.
Продажи Microsoft во многом основаны на демпинговой политике, а также игре на том, что на рынке много специалистов, знакомых с этими решениями, их обучение не должно занимать много времени, качество и доступность поддержки производителя.
Немаловажно и то, что решения Microsoft можно быстро и эффективно интегрировать в существующую инфраструктуру большинства компаний.
Благодаря большому количеству клиентов, а также развитой сети партнеров и реселлеров, Microsoft на сегодняшний день сумела добиться хороших продаж.
Несмотря на это, существующие решения Microsoft технологически отстают от конкурентов, что приводит к убеждению, что они не смогут в будущем конкурировать с решениями других производителей.
Вдобавок к этому, Microsoft не меняет своей традиции и выпускает продукты с большим количеством ошибок, а также надолго затягивает исправление этих ошибок, что также не способствует распространению продуктов Microsoft. Решение Microsoft PDW, выпущенное в ноябре 2010 года, не имеет ни одного обзора как система, используемая для промышленного использования.
Это говорит о том, что никому не удалось заставить данное решение работать более-менее стабильно, удовлетворяя текущие потребности компаний.
Однако в этой статье мне бы хотелось рассмотреть те самые особенности, которые позволили решениям других лидеров оставаться впереди и надеяться, что в будущем они смогут удовлетворить постоянно растущие потребности компаний.
Прежде чем продолжить, хорошо бы понять, какое из решений поставляется в виде программного обеспечения, а какое — в виде заранее настроенного аппаратно-программного комплекса.
Предварительно настроенный программно-аппаратный комплекс исключает процедуру настройки и настройки, сокращая время, необходимое для его внедрения, но его стоимость значительно выше.
Решение, поставляемое в виде программного обеспечения, позволяет самостоятельно выбрать аппаратную платформу и не переплачивать за оборудование, а также дает возможность легко увеличить производительность и емкость за счет добавления новых серверов в будущем.
В этом списке можно выделить IBM Netezza, которая поставляется в виде фирменного оборудования, а именно на блейд-серверах IBM. Это означает зависимость от производителя, точнее от IBM, т.е.
если возникнет необходимость расширения, вам придется обращаться в IBM и приобретать у нее дополнительное оборудование и лицензии.
Кроме того, процесс расширения IBM Netezza нетривиален и требует длительного процесса миграции, во время которого система должна находиться в простое – это приводит к простоям и потере времени.
Вопрос о зависимости от поставщика также применим к решениям Oracle и Teradata. Некоторые решения могут поставляться как аппаратно, так и программно:
СХД | Программное обеспечение | Аппаратное обеспечение |
ЭМС Гринплум | Икс | Икс |
HP Вертика | Икс | |
IBM InfoSphere Warehouse (DB2) | Икс | |
IBM Нетезза | Икс | |
СУБД Microsoft SQL Server 2008 R2 BDW | Икс | |
СУБД Microsoft SQL Server 2008 R2 PDW | Икс | |
СУБД Microsoft SQL Server 2008 R2 FTDW | Икс | |
Oracle Эксадата | Икс | |
Сибэйс IQ | Икс | |
База данных Терадата 14 | Икс |
IBM InfoSphere Warehouse — это DB2 10 LUW (Linux, Unix, Windows) с возможностями DPF (Database Partitioning Feature), соответственно, она имеет те же возможности, что и DB2 10, но в дополнение к ним может быть развернута с использованием архитектуры MPP.
Архитектура MPP
Массивно-параллельная архитектура (Massive Parallel Processing, MPP) — это класс параллельных вычислительных систем, состоящих из множества узлов, где каждый узел представляет собой автономную единицу, независимую от других.Если мы применим это определение к области хранилищ данных, то его значение лучше всего отражает термин «распределенные базы данных».
Каждый узел распределенной базы данных представляет собой полноценную СУБД, работающую независимо от остальных.
Сама распределенная база данных представляет собой совокупность независимых автономных узлов, соединенных сетью связи.
Все данные в такой сети распределяются между узлами равномерно, т.е.
каждый узел хранит свой, уникальный фрагмент данных, однако логически представляющий единую базу данных.
Для пользователя распределенная база данных выглядит как единая база данных, не разделенная на части.
При доступе к распределенной СУБД запрос выполняется параллельно всеми узлами базы данных, осуществляя поиск и получение только своего уникального фрагмента данных, что позволяет существенно увеличить скорость доступа к данным.
Преимущества такой архитектуры очевидны – линейная масштабируемость, обеспечивающая стабильные и прогнозируемые параметры производительности и развития системы.
Тенденция в области хранилищ данных с точки зрения архитектуры такова, что в будущем останутся только решения на базе MPP-архитектуры, поскольку они позволяют обрабатывать огромные объемы информации на стандартном оборудовании.
Недостаток также очевиден — для удовлетворения функциональных требований ACID система должна получать ответ от каждого узла, поэтому сеть связи между узлами должна иметь высокую пропускную способность, а также отказоустойчивость.
Реально для современных хранилищ данных вполне достаточны существующие стандарты передачи данных (10 Гигабит), а с внедрением стандарта 100 Гигабит проблема скорости передачи между узлами исчезнет вообще, поскольку узким местом станет дисковая подсистема.
(тоже не факт, поскольку In-memory БД для хранения данных используют оперативную память).
Пионером в области MPP-архитектуры для хранилищ данных стала компания Teradata, которая представила первую систему с такой архитектурой в 1984 году.
С тех пор Teradata прошла большой путь, накопила много полезного опыта в этой области и заслуженно занимает лидирующие позиции.
.
В 2000-е годы появились решения с похожей архитектурой от других производителей: EMC Greenplum, HP Vertica, Sybase IQ, IBM Netezza, IBM InfoSphere Warehouse и Microsoft PDW. Следует отметить, что архитектура MPP может существовать в двух вариантах: ничего не разделяемого и не разделяемого всего.
В первом случае каждый узел не разделяет системные ресурсы с другими узлами, распределяя и используя необходимые ему ресурсы самостоятельно.
Во втором случае узел использует общие ресурсы, обращаясь к некоторому механизму для получения необходимых ему ресурсов.
У каждого подхода есть свои преимущества и недостатки — несовместное использование не позволяет достаточно эффективно использовать все ресурсы, в любом случае некоторые из них остаются бездействующими.
Shared Everything использует ресурсы более эффективно, но требует механизма межпроцессной координации при использовании общих ресурсов, что приводит к дополнительному времени, необходимому для такой координации при распределении ресурсов.
Системные ресурсы здесь — это оперативная память и дисковая подсистема.
Oracle и Microsoft пошли своим путем, используя в своих разработках архитектуру SMP (Symmetric Multiprocessing).
Данная архитектура характеризуется тем, что с одной базой данных работают несколько процессов.
Чтобы увеличить скорость доступа к данным, Oracle и Microsoft рекомендуют использовать секционирование, разделив таблицу на несколько логических секций и тем самым разделив данные на более мелкие части.
Этот подход помогает, если нам нужно выбрать небольшую часть данных в таблице, но неэффективен, если нам нужно использовать для анализа большую часть данных, содержащихся в таблице (так называемое полное сканирование), что имеет место при традиционное проектирование хранилища данных «звезда» или «снежинка» неизбежно.
Для лучшего понимания принципов, на которых основано каждое решение, приведу таблицу:
СХД | СМП | МПП | |
Ничего не поделилось | Поделился всем | ||
ЭМС Гринплум | Икс | ||
HP Вертика | Икс | ||
IBM InfoSphere Warehouse (DB2) | Икс | ||
IBM Нетезза | Икс | ||
СУБД Microsoft SQL Server 2008 R2 BDW | Икс | ||
СУБД Microsoft SQL Server 2008 R2 PDW | Икс | ||
СУБД Microsoft SQL Server 2008 R2 FTDW | Икс | ||
Oracle Эксадата | Икс | ||
Сибэйс IQ | Икс | ||
База данных Терадата 14 | Икс |
Именно архитектура MPP наиболее подходит для хранилищ данных, так как обеспечивает линейную масштабируемость, позволяя увеличивать емкость хранилища данных в соответствии с постоянно растущими требованиями.
Однако ряд решений из верхнего правого квадранта Магического квадранта Gartner объединяет еще одна характеристика, которая помогает повысить скорость доступа к данным и, соответственно, сделать их доступными для аналитиков как можно быстрее.
Хранение столбцов
Идея хранения данных в столбцах, а не в строках, не нова и исходит от Sybase, выпустившей в 1996 году Sybase IQ, первую в мире базу данных, поддерживающую столбчатое хранение данных.В основу этой идеи легло то, что нагрузка на хранилище данных и оперативные базы данных кардинально различна по своей природе.
Если для OLTP-систем характерны частые небольшие транзакции, которые в основном выполняют операции вставки/обновления, то нагрузка на хранилище данных характеризуется тем, что основными операциями являются чтение больших объемов данных, часто с использованием агрегации.
Таким образом, если для OLTP-систем построчное хранение является оптимальным, так как при добавлении новой строки нам выгоднее записать ее на диск за один проход, то для хранилищ данных такое хранение неэффективно.
Например, если мы храним данные построчно, то для таблицы, состоящей из 10 столбцов, при выборе, где указаны только три столбца, нам придется читать все 10 столбцов, что крайне неэффективно, так как нам не нужны данные из остальные 7 столбцов.
В этом же примере, если вы используете столбчатую модель хранения данных, то данные будут читаться только из тех столбцов, которые были указаны в запросе, что сокращает количество операций чтения в несколько раз.
Поскольку большинство запросов, выполняемых в хранилище данных, используют лишь несколько столбцов таблицы, оптимально хранить данные в виде столбцов.
Почему-то крупнейшие игроки рынка СХД — Oracle, Microsoft и IBM — скромно умалчивают об этом при сравнении с конкурентами, туманно обещая поддержку столбчатого хранения данных когда-нибудь в будущем.
Эта скромность может привести к тому, что решения этих компаний вообще не будут рассматриваться в будущем.
Также следует отметить, что решения некоторых компаний, в частности EMC Greenplum и Teradata, поддерживают полиморфную модель хранения данных, т.е.
некоторые данные могут храниться в виде строк, а некоторые — в виде столбцов.
Это сделано для того, чтобы можно было создавать таблицы, где транзакционная нагрузка будет аналогична OLTP, т.е.
будет много мелких операций «добавления/изменения» данных.
Чтобы понять, какую модель хранения данных использует каждое решение, вот таблица:
СХД | Рядно-ориентированный | Столбцово-ориентированный |
ЭМС Гринплум | Икс | Икс |
HP Вертика | Икс | |
IBM InfoSphere Warehouse (DB2) | Икс | |
IBM Нетезза | Икс | |
СУБД Microsoft SQL Server 2008 R2 BDW | Икс | |
СУБД Microsoft SQL Server 2008 R2 PDW | Икс | |
СУБД Microsoft SQL Server 2008 R2 FTDW | Икс | |
Oracle Эксадата | Икс | |
Сибэйс IQ 15 | Икс | |
База данных Терадата 14 | Икс | Икс |
Каждый столбец в каждой таблице Sybase IQ должен быть проиндексирован, иначе оптимизатор вернет сообщение об ошибке при выполнении запроса.
В Sybase IQ 15 по умолчанию для всей таблицы создается индекс, это так называемый Fast Projection Default Index. В целом идея индексирования данных нашла горячую поддержку в сердцах разработчиков Sybase IQ, результатом чего стало создание 10 различных типов индексов и рекомендаций по их использованию везде и всегда.
Рекомендуется создавать несколько индексов по таблице или даже столбцу в зависимости от типа и характера данных, а также с учетом того, в каком качестве тот или иной столбец будет использоваться в запросе, т.е.
будет ли он принимать участие в запросе.
агрегировать с другими столбцами или играть роль предиката.
После анализа запросов и создания необходимых индексов Sybase IQ обещает высокую производительность как для произвольных запросов, так и для запросов с интенсивным использованием данных.
Несмотря на некоторые преимущества, которые дает этот подход, Sybase IQ, как известно, медленно загружает данные, поскольку поддержание большого количества индексов является дорогостоящей операцией.
HP Vertica пошла дальше всех в идее столбчатого хранения данных, реализовав так называемые проекции, которые представляют собой, если использовать терминологию Oracle, материализованные представления, отсортированные по одному или нескольким столбцам.
Материализованные представления в HP Vertica, состоящие из одного или нескольких столбцов таблицы, минимизируют количество операций чтения для запросов, в которых столбцы для чтения заранее определены.
Используемые в HP Vertica проекции действительно позволяют добиться более высоких скоростей чтения по сравнению с конкурентами, однако имеют существенные недостатки – хранение избыточного объема данных, поскольку некоторые столбцы присутствуют в нескольких проекциях одновременно.
Неготовность к спонтанным, произвольным запросам, приводящая к длительному ожиданию ответа, не добавляет достоинств решению HP Vertica. Честно говоря, HP Vertica позволяет добиться хорошей производительности под конкретные запросы только после выяснения всех обстоятельств предстоящей нагрузки и длительного этапа подготовки прогнозов.
Механизм проецирования, используемый в HP Vertica, заставил создателей этого решения прибегнуть к разработке уникального механизма загрузки данных.
Прежде всего, нужно сказать, что хранилище данных в HP Vertica разделено на две области — Write-Optimized Column Store (WOS) и Read-Optimized Column Store (ROS).
Прежде чем данные достигают ROS, они проходят через область WOS, где специальный процесс, называемый Tuple Mover, сортирует данные, сжимает их и помещает в соответствующие проекции в ROS. Непрозрачность этого механизма не позволяет нам понять, какие данные были загружены, а какие нет. Один из трюков, который любят показывать инженеры HP Vertica, — мгновенная загрузка данных, т.е.
команда на загрузку нескольких сотен гигабайт или нескольких терабайт данных выполняется практически мгновенно — это неправда, ведь данные сначала попадают в WOS, и только после того, как он будет обработан процессом перемещения кортежей, он попадает в область ROS. Загрузка данных для решений других компаний выглядит гораздо прозаичнее — это механизм параллельной загрузки данных через внешние таблицы, который позволяет работать с плоскими файлами как с обычными таблицами.
Этот механизм поддерживается Oracle Exadata, IBM InfoSphere Warehouse, IBM Netezza, EMC Greenplum и Sybase IQ. Высочайшую скорость загрузки данных обеспечивает EMC Greenplum за счет параллельной загрузки между всеми логическими узлами хранилища данных; Oracle Exadata немного отстает от него из-за своей SMP-архитектуры.
Скорость загрузки данных отличается в несколько раз в худшую сторону у тех решений, которые требуют предварительной сортировки данных - это IBM Netezza (Zone Maps), дорогостоящие операции с индексами - пресловутый Sybase IQ, про IBM DB2, к сожалению, не знаю.
Для загрузки данных Microsoft использует компонент SQL Server под названием SQL Server Integration Services (SSIS), который представляет собой не что иное, как редизайн знакомых служб преобразования данных (DTS), которые существуют в SQL Server с седьмой версии.
С помощью этого инструмента с помощью графического пользовательского интерфейса и подсказок мастера можно создать так называемый «Пакет служб интеграции», который можно использовать в дальнейшем для дальнейшей загрузки данных.
Имея опыт использования DTS в Microsoft SQL Server 2000, могу сказать, что стабильность проблем не вызывала (если данные были «чистыми», без мусора), но скорость оставляла желать лучшего.
Набор утилит для загрузки/выгрузки данных, используемый в Teradata, выгодно отличается от конкурентов.
Эти утилиты, интегрированные в одну платформу под названием Teradata Parallel Transporter, предоставляют богатую функциональность, позволяющую загружать/выгружать данные, не блокируя запросы пользователей, выполняющих запросы.
Полученные результаты
Gartner оценил поставщиков в «Магическом квадранте» в соответствии с их текущим положением на рынке хранения данных.Однако это не означает, что позиции лидеров относительно друг друга не изменятся в будущем.
Все решения в секторе-лидере обладают механизмами отказоустойчивости, средствами резервного копирования и восстановления, а также поддерживают тот или иной стандарт SQL. Однако если углубиться в функционал каждого решения, то можно обнаружить следующее: HP Vertica не поддерживает хранимые процедуры, функции и другие языки.
IBM Netezza не поддерживает индексы, что часто приводит к полному сканированию, не поддерживает секционирование таблиц, а также имеет медленную скорость загрузки данных из-за необходимости предварительной сортировки данных.
О недостатках других решений было сказано выше.
Это не означает, что все эти решения не обладают достоинствами, позволяющими им служить хранилищами данных.
Однако, если производители не устранят текущие недостатки этих решений в будущем, они рискуют потерять место лидеров отрасли.
Есть две компании, чьи решения лучше всего соответствуют будущим потребностям рынка хранения данных.
Это решение от Teradata и EMC Greenplum. Архитектура MPP с концепцией Shared Nothing, полиморфной моделью хранения данных (хранилище данных столбцов и строк), а также богатым функционалом поможет им сохранить свои позиции в будущем.
Маркетинговая политика, проводимая этими компаниями, несколько отличается друг от друга, что позволяет им совместно существовать на рынке хранения данных, одновременно устраняя жесткую конкуренцию между решениями.
Teradata продается в виде предварительно настроенного аппаратно-программного комплекса и по стоимости сопоставима с Oracle Exadata, т.е.
находится в верхнем ценовом диапазоне.
Высокая цена Teradata обусловлена тем, что компания не пытается унифицировать свое решение, предлагая свое видение каждому новому заказчику.
Не доверяя процесс внедрения сторонним компаниям, Teradata до недавнего времени разрабатывала и реализовывала концепцию хранилища данных для каждого нового клиента самостоятельно, поэтому цикл внедрения у Teradata достаточно длительный, а цена на обслуживание и поддержку достаточно высокая.
EMC Greenplum может поставляться как в виде программного обеспечения, так и в виде предварительно настроенного аппаратно-программного комплекса, а цена этого решения сопоставима с HP Vertica и IBM Netezza, но, в то же время, у Greenplum нет большинства недостатки, присущие решениям HP и IBM. EMC, имея широкую сеть партнеров и дистрибьюторов, старается распространять через них решение Greenplum, что позволяет появиться техническим специалистам по этому продукту.
В последующем это может привести к тому, что на рынке труда можно будет найти готовых специалистов и тем самым снизить затраты на разработку и поддержание собственного хранилища данных.
EMC в последнее время также следит за сферой больших данных, стараясь не отставать от новейших тенденций и где-то внедрять свои — свидетельством тому является мероприятие Data Science Summit 2012, проводимое EMC в Лас-Вегасе.
Тем самым EMC пытается привлечь внимание ведущих специалистов по большим данным к проблемам, существующим в этой области, а также выслушать новые идеи и мысли.
Отсюда можно сделать вывод, что присутствие и расширение EMC на рынке хранения данных является стратегической целью для компании, и развитие идей, заложенных в Greenplum, не остановится в ближайшем будущем.
Подводя итог, можно сказать, что Greenplum полностью соответствует требованиям, предъявляемым к современным хранилищам данных, и является одним из лучших решений наряду с Teradata, оставляя далеко позади своих конкурентов.
Отчет Gartner DWH Теги: #Большие данные #dwh #хранилище данных #greenplum #Vertica #teradata #netezza #gartner #sql #Big Data
-
Компиляция Gcc Из Исходников
19 Oct, 24 -
Блог Шарфика
19 Oct, 24 -
6 Мифов О Финтех-Развитии
19 Oct, 24 -
Жизненный Цикл Viewcontroller В Ios6
19 Oct, 24