Уважаемые партнеры! Приглашаем вас принять участие в маркетинговой программе по мультимедийному оборудованию, которую мы проводим совместно с вендорами из портфеля Treolan. Чтобы присоединиться к группе партнеров-путешественников, необходимо выполнить ряд условий за период проведения промо. Мы ...
Уважаемые партнеры! Merlion приглашает вас принять участие в маркетинговой акции по мелкой бытовой технике Hyundai и Starwind. Период действия акции: 1 – 30 апреля 2024. Закупите комплект «утюг + пылесос Hyundai или Starwind» на сумму от 200 000 до 750 000 рублей (накопительно за ...
В Merlion действует акция «Мини ПК с макси выгодой!». В марте и апреле при закупке каждого мини ПК iRU серии 310H6ITF начисляется 1000 Ситилинк-бонусов. Условие действует при закупке от 5 штук, накопительно в период действия акции. Период действия акции: 01 марта - 30 апреля 2024 г. Список фокусных ...
В Merlion действует акция «Мини ПК с макси выгодой!». В марте и апреле при закупке мини ПК iRU серии 310H6ITF в количестве от 5 штук (накопительно в период действия акции), начисляется 1000 Ситилинк-бонусов. Список фокусных позиций, описание и подробные условия - на странице акции ...
Предприятия сталкиваются с реальностью, которую несут с собой большие, поступающие в быстром темпе и меняющиеся по форме и содержанию данные. Если раньше ИТ-отделы управляли небольшим числом систем, то теперь имеют дело с сотнями систем и петабайтами данных. В интеллектуально развитых компаниях знают, что управление большими объемами структурированных и неструктурированных данных, вместе составляющих большие данные, имеет чрезвычайную важность для современных бизнес-операций и более комплексного бизнес-анализа. Проблема состоит в том, что реляционные базы данных — доминирующая технология хранения и управления данными — не приспособлены для работы с большими данными. Фактически реляционные базы данных сохраняют тот облик, который они имели более 30 лет назад, когда они впервые появились. Организации, сфокусированные на больших данных, больше не могут полагаться на однотипную реляционную модель; они должны обратить свой взор на новые базы данных, более подходящие для современных рабочих нагрузок. «Когда разрабатывались первые реляционные базы данных, данные представлялись компактными, лаконичными, структурированными и статичными, и это определяло единственный способ их хранения, — пояснил порталу eWeek Мэтт Аллен, старший управляющий продуктовыми решениями компании MarkLogic, специализирующейся на СУБД класса NoSQL. — Сегодняшние данные представляют собой все что угодно, только не это». Далее поясняется, почему реляционные базы данных не годятся для обработки ... читать далее.
Почему реляционные базы данных плохо подходят для больших данных. К числу причин, почему реляционные базы данных не очень пригодны для больших данных, относятся их ограниченность по масштабированию и слабые возможности для анализа неструктурированных данных. Другие причины приведены далее.
Реляционные базы данных не приспособлены к изменениям. Данные в реляционных базах данных расположены по строкам и столбцам, где каждая строка образует отдельную запись и каждый столбец описывает уникальные атрибуты. Моделирование данных должно происходить заранее и может занимать месяцы, а то и годы в зависимости от создаваемой системы и стоить миллионы долларов. После этого внесение в нее изменений требует больших затрат времени и ресурсов. Большие данные постоянно видоизменяются, и для них нужна гибкая и податливая платформа.
Они не проектировались для работы с разнообразными данными. Реляционные базы данных не предназначены для работы со структурированными данными разнообразных форм и размеров. И это при том, что структурированные данные составляют лишь малый процент данных, с которыми компании имеют дело. У них также имеется огромный объем неструктурированных данных, обрабатывать которые реляционные БД не умеют. Реляционные базы данных можно конфигурировать для ввода разных данных, но лишь путем громоздких изменений, дополнительно усложняющих схему данных, или способами, которые не позволяют полноценно использовать эти данные.
Они не рассчитаны на масштабируемость, адаптируемость и гибкость. Каждый день приносит новые прогнозы в отношении дальнейшего роста объемов данных. Таким же образом должны расширяться и базы данных, но реляционные БД не рассчитаны на рост по требованию. Поставщкии реляционных баз данных придумали много функций, заполняющих этот пробел, например разделяемое хранение данных, обработку in-memory, улучшенное использование копий и распределенное кэширование. Но какие бы новшества не вводились, реляционные базы данных попросту не рассчитаны на масштабы, с которыми оперирует современный бизнес. Попытка масштабировать их обычно ведет к закупкам все более дорогого оборудования и перерывам в работе для внесения изменений.
Они не предназначены для смешанных рабочих нагрузок. Когда говорят о смешанных рабочих нагрузках, обычно подразумевают способность системы поддерживать операционные и аналитические рабочие нагрузки. В середине 1990-х произошло разделение баз данных с их оптимизацией либо для операционных нагрузок, либо для аналитических, что привело к созданию разнотипных витрин и хранилищ данных, магазинов референсных данных и архивов. Сложности в работе с реляционными базами данных сегодня изнуряют сотрудников ИТ-отделов, нуждающихся в более простых и гибких решениях, способных в любой момент времени выдавать информацию многочисленным пользователям в различных формах.
Они не сочетаются с разработкой современных приложений. Современные приложения создаются с использованием объектно-ориентированных языков программирования, рассматривающих структуры данных как “объекты”, которые содержат данные и код. Этот способ оперирования данными очень отличается от того, какой принят в реляционных БД. Чтобы обойти это несоответствие, разработчики пользуются техникой так называемого объектно-реляционного отображения (ORM), предполагающей работу с бизнес-правилами и логикой и генерацию наиболее разумного представления данных с точки зрения создаваемого приложения. Однако, как известно, использование ORM чревато появлением дополнительных сложностей при создании приложений, потерей в их производительности и повышением вероятности появления дефектного кода.
В них не предусмотрено отслеживание времени. Отслеживание изменений данных во времени (временной аспект информации) никогда не предусматривалось в исходной модели реляционных БД. Способы управления временем в них и составления SQL-запросов с временны́м элементом развились в возможность отвечать на вопросы об истории того, когда происходили события, но реализация этого функционала у разных вендоров все еще различна, что может затруднять разработку приложений. Управление “двувременными” данными, когда отслеживается время наступления событий и время записи информации о них, является еще большим камнем преткновения для реляционных баз данных. Предприятиям требуется точная выдаваемая по запросу история своих данных, что часто связано с необходимостью соблюдения законодательных требований и выполнения углубленного анализа, однако этому слишком мешают ограничения реляционных БД.
Они не эффективны в выдаче результатов поиска с учетом их релевантности. Реляционная база данных не способна ранжировать информацию по релевантности, как это делает поисковая машина типа Google, и лишь возвращает простой список результатов в порядке следования значений. Но если база данных обрабатывает только значения, информация, заключенная в любом неструктурированном тексте, игнорируется. По этой причине предприятия не могут получить необходимую им релевантную информацию. Например, организации не только хотят знать, “какие лекарства пациент принимал до 2005 г.”, но также получать ответы на более сложные вопросы типа “какие лекарства пациент принимал до 2005 г. с упорядочиванием их по частоте упоминания в назначениях врачей”. Реляционная база данных не умеет отвечать на такие вопросы, потому что не обладает необходимым для этого сложным механизмом индексации.
Их функционал корпоративного уровня не может быть использован для работы с большими данными. В течение десятилетий реляционные базы данных предоставляли беспримерный уровень безопасности, надежности и управляемости данных, что критически важно для нынешней бизнес-среды. Проблема в том, что все это теряет смысл, если такие БД нельзя использовать в работе с большими данными. Рынок сегодня предлагает другие варианты, которые действительно пригодны для обработки больших данных и при этом отвечают требованиям корпоративных структур, предъявляемым к система поддержки критически важных приложений.
Как NoSQL может заполнить пробелы, присущие реляционным БД. Для хранения больших данных и эффективного управления ими многие компании используют базы данных класса NoSQL. Этим БД не присущи строго предопределенные схемы реляционных баз данных, и они обладают гораздо большей гибкостью и масштабируемостью. Базы данных NoSQL не предназначены исключительно для работы с большими данными, но отлично подходят для этого. В число поставщиков NoSQL-СУБД входят Couchbase, Datastax, ReThinkDB, Cassandra, MongoDB, FoundationDB, MariaDB, MarkLogic, Basho и другие компании. Они предлагают решения и поддержку, соответствующие разным уровням требований корпоративных структур. Компаниям следует тщательно оценивать NoSQL-предложения с точки зрения функций безопасности, обеспечиваемого уровня готовности, средств аварийного восстановления и управления, необходимых в корпоративных средах.
