Дилер, закупивший продукцию Filum на сумму 10 000 руб., получает сертификат Ozon на 1 000 руб. в подарок. Для участия в маркетинговой программе необходимо ...
Уважаемые партнеры! Приглашаем вас принять участие в маркетинговой акции - закупайте в Merlion технику для кухни VITEK и Rondell (кофеварки, кофемашины, кофемолки) и ...
Уважаемые партнеры! Приглашаем вас принять участие в маркетинговой акции – закупайте в Merlion оперативную память и накопители SSD Patriot и получите бонус до 2,5% от ...
Уважаемые партнеры! Приглашаем вас принять участие в маркетинговой акции - закупайте в Merlion планшеты DIGMA и DIGMA PRO и получите бонус 15 000 руб. за каждые 500 000 руб. закупок ...
Уважаемые партнеры! Приглашаем вас принять участие в маркетинговой акции по сетевому оборудованию DIGMA. Период действия акции: с 1 ноября по 31 декабря 2024 г. За ...
Предприятия сталкиваются с реальностью, которую несут с собой большие, поступающие в быстром темпе и меняющиеся по форме и содержанию данные. Если раньше ИТ-отделы управляли небольшим числом систем, то теперь имеют дело с сотнями систем и петабайтами данных. В интеллектуально развитых компаниях знают, что управление большими объемами структурированных и неструктурированных данных, вместе составляющих большие данные, имеет чрезвычайную важность для современных бизнес-операций и более комплексного бизнес-анализа. Проблема состоит в том, что реляционные базы данных — доминирующая технология хранения и управления данными — не приспособлены для работы с большими данными. Фактически реляционные базы данных сохраняют тот облик, который они имели более 30 лет назад, когда они впервые появились ... читать далее.
Почему реляционные базы данных плохо подходят для больших данных. К числу причин, почему реляционные базы данных не очень пригодны для больших данных, относятся их ограниченность по масштабированию и слабые возможности для анализа неструктурированных данных. Другие причины приведены далее.
Реляционные базы данных не приспособлены к изменениям. Данные в реляционных базах данных расположены по строкам и столбцам, где каждая строка образует отдельную запись и каждый столбец описывает уникальные атрибуты. Моделирование данных должно происходить заранее и может занимать месяцы, а то и годы в зависимости от создаваемой системы и стоить миллионы долларов. После этого внесение в нее изменений требует больших затрат времени и ресурсов. Большие данные постоянно видоизменяются, и для них нужна гибкая и податливая платформа.
Они не проектировались для работы с разнообразными данными. Реляционные базы данных не предназначены для работы со структурированными данными разнообразных форм и размеров. И это при том, что структурированные данные составляют лишь малый процент данных, с которыми компании имеют дело. У них также имеется огромный объем неструктурированных данных, обрабатывать которые реляционные БД не умеют. Реляционные базы данных можно конфигурировать для ввода разных данных, но лишь путем громоздких изменений, дополнительно усложняющих схему данных, или способами, которые не позволяют полноценно использовать эти данные.
Они не рассчитаны на масштабируемость, адаптируемость и гибкость. Каждый день приносит новые прогнозы в отношении дальнейшего роста объемов данных. Таким же образом должны расширяться и базы данных, но реляционные БД не рассчитаны на рост по требованию. Поставщкии реляционных баз данных придумали много функций, заполняющих этот пробел, например разделяемое хранение данных, обработку in-memory, улучшенное использование копий и распределенное кэширование. Но какие бы новшества не вводились, реляционные базы данных попросту не рассчитаны на масштабы, с которыми оперирует современный бизнес. Попытка масштабировать их обычно ведет к закупкам все более дорогого оборудования и перерывам в работе для внесения изменений.
Они не предназначены для смешанных рабочих нагрузок. Когда говорят о смешанных рабочих нагрузках, обычно подразумевают способность системы поддерживать операционные и аналитические рабочие нагрузки. В середине 1990-х произошло разделение баз данных с их оптимизацией либо для операционных нагрузок, либо для аналитических, что привело к созданию разнотипных витрин и хранилищ данных, магазинов референсных данных и архивов. Сложности в работе с реляционными базами данных сегодня изнуряют сотрудников ИТ-отделов, нуждающихся в более простых и гибких решениях, способных в любой момент времени выдавать информацию многочисленным пользователям в различных формах.
Они не сочетаются с разработкой современных приложений. Современные приложения создаются с использованием объектно-ориентированных языков программирования, рассматривающих структуры данных как “объекты”, которые содержат данные и код. Этот способ оперирования данными очень отличается от того, какой принят в реляционных БД. Чтобы обойти это несоответствие, разработчики пользуются техникой так называемого объектно-реляционного отображения (ORM), предполагающей работу с бизнес-правилами и логикой и генерацию наиболее разумного представления данных с точки зрения создаваемого приложения. Однако, как известно, использование ORM чревато появлением дополнительных сложностей при создании приложений, потерей в их производительности и повышением вероятности появления дефектного кода.
В них не предусмотрено отслеживание времени. Отслеживание изменений данных во времени (временной аспект информации) никогда не предусматривалось в исходной модели реляционных БД. Способы управления временем в них и составления SQL-запросов с временны́м элементом развились в возможность отвечать на вопросы об истории того, когда происходили события, но реализация этого функционала у разных вендоров все еще различна, что может затруднять разработку приложений. Управление “двувременными” данными, когда отслеживается время наступления событий и время записи информации о них, является еще большим камнем преткновения для реляционных баз данных. Предприятиям требуется точная выдаваемая по запросу история своих данных, что часто связано с необходимостью соблюдения законодательных требований и выполнения углубленного анализа, однако этому слишком мешают ограничения реляционных БД.
Они не эффективны в выдаче результатов поиска с учетом их релевантности. Реляционная база данных не способна ранжировать информацию по релевантности, как это делает поисковая машина типа Google, и лишь возвращает простой список результатов в порядке следования значений. Но если база данных обрабатывает только значения, информация, заключенная в любом неструктурированном тексте, игнорируется. По этой причине предприятия не могут получить необходимую им релевантную информацию. Например, организации не только хотят знать, “какие лекарства пациент принимал до 2005 г.”, но также получать ответы на более сложные вопросы типа “какие лекарства пациент принимал до 2005 г. с упорядочиванием их по частоте упоминания в назначениях врачей”. Реляционная база данных не умеет отвечать на такие вопросы, потому что не обладает необходимым для этого сложным механизмом индексации.
Их функционал корпоративного уровня не может быть использован для работы с большими данными. В течение десятилетий реляционные базы данных предоставляли беспримерный уровень безопасности, надежности и управляемости данных, что критически важно для нынешней бизнес-среды. Проблема в том, что все это теряет смысл, если такие БД нельзя использовать в работе с большими данными. Рынок сегодня предлагает другие варианты, которые действительно пригодны для обработки больших данных и при этом отвечают требованиям корпоративных структур, предъявляемым к система поддержки критически важных приложений.
Как NoSQL может заполнить пробелы, присущие реляционным БД. Для хранения больших данных и эффективного управления ими многие компании используют базы данных класса NoSQL. Этим БД не присущи строго предопределенные схемы реляционных баз данных, и они обладают гораздо большей гибкостью и масштабируемостью. Базы данных NoSQL не предназначены исключительно для работы с большими данными, но отлично подходят для этого. В число поставщиков NoSQL-СУБД входят Couchbase, Datastax, ReThinkDB, Cassandra, MongoDB, FoundationDB, MariaDB, MarkLogic, Basho и другие компании. Они предлагают решения и поддержку, соответствующие разным уровням требований корпоративных структур. Компаниям следует тщательно оценивать NoSQL-предложения с точки зрения функций безопасности, обеспечиваемого уровня готовности, средств аварийного восстановления и управления, необходимых в корпоративных средах.
