Пример специальной базы данных °

    0
    54


    Спонсируемый Помните, когда единственная база данных в городе была реляционной? Все изменилось за 20 лет. Сегодня почтенная старая система управления реляционными базами данных (СУБД) по-прежнему доминирует, но рынок также заполнен новыми типами баз данных, предназначенными для различных видов работ.

    Концепции баз данных существовали раньше, чем РСУБД, в форме иерархических и сетевых баз данных и даже в более ранней форме в виде коллекций перфокарт. Но на самом деле реляционная концепция Э. Ф. Кодда, опубликованная в 1970 году, положила начало эре современных вычислений баз данных. Его концепция таблиц и строк аккуратно отделила логическую модель данных от основного физического хранилища и привела к появлению целого ряда механизмов баз данных с середины семидесятых годов.

    РСУБД была полностью подходящей для большинства приложений на протяжении десятилетий, но семена перемен уже были посеяны. Всего за год до того, как Кодд опубликовал свою первую статью, Стэнфордский исследовательский институт и Калифорнийский университет в Лос-Анджелесе обменялись первым в истории сообщением в Интернете. Это в конечном итоге изменило бы все, создав Интернет, который навсегда изменил бы вычисления, увеличивая масштаб и объем приложений.

    За последние несколько десятилетий Интернет привел к появлению новых требований к данным и скорости, которые сделали реляционные системы менее подходящими для многих приложений. Сегодня многим приложениям необходимо работать с терабайтами данных, поддерживая миллионы пользователей по всему миру. Традиционные реляционные системы не справляются с этим масштабом, сохраняя при этом производительность.

    Операторы гипермасштабирования были одними из первых, кто заметил, как реляционные продукты становятся тонкими по швам. Amazon, которая с самого начала полагалась на СУБД Oracle, начала замечать напряжение. «Реляционные базы данных Amazon начали работать на пределе своих возможностей в 2004 году, когда объем транзакций гиганта электронной коммерции резко увеличился», – объясняет Эдин Зулич, менеджер старшего архитектора решений (SA) и специалист по базам данных NoSQL в AWS.

    «При более внимательном рассмотрении шаблонов доступа к данным и того, как эти базы данных использовались, выяснилось, что в большинстве случаев мы использовали довольно простой шаблон доступа« ключ-значение », – вспоминает он. «Это породило идею, что, возможно, мы сможем создать более масштабируемую базу данных, которая будет хорошо работать для этих случаев использования».

    Компания приступила к разработке собственной базы данных с ключом-значением Dynamo в 2004 году после того, как Oracle начала выдыхаться. В 2007 году он опубликовал документ, в котором описал свой опыт. Затем он продолжил внутреннее совершенствование базы данных, прежде чем в 2012 году выпустить ее как службу базы данных «ключ-значение» Amazon DynamoDB.

    Сосредоточение внимания на структуре «ключ-значение» позволило AWS оторваться от жесткой структуры, на которой основаны реляционные таблицы. «Данные имеют вес», – говорит Цулич, добавляя, что системы, организованные таким образом, сложнее масштабировать. Зачем снижать производительность сложных объединений, если можно просто хранить вместе нужные записи?

    «По сути, речь идет об организации данных, которая эффективна для ваших шаблонов чтения и записи», – объясняет он. “Если я храню данные корзины покупок, я всегда буду следить за тем, чтобы данные данной корзины находились в одном месте. Таким образом, мне не нужно отправлять запрос на несколько разных узлов, а затем собирать эту корзину вместе. Вот что произошло бы, если бы вы сделали это с реляционной базой данных ».

    Развертывание правильной базы данных для работы

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

    «Мы можем создавать сервисы в высокомодульном, несвязанном виде. Это идет рука об руку с концепцией микросервисов как способа создания приложений, в отличие от того, что мы сейчас называем монолитными приложениями», – говорит он.

    Тогда задача состоит в том, чтобы связать эти базы данных вместе, чтобы получить единый агрегированный источник истины. Один из способов решить эту проблему – использовать управляемые событиями архитектуры, которые реплицируют данные между хранилищами данных, продолжает Цурих. В DynamoDB разработчики могут подключаться к журналу транзакций и реплицировать данные в реальном времени по мере появления изменений.

    AWS также встроила поддержку DynamoDB, а также свои реляционные источники Amazon RDS и Amazon Aurora в предварительную версию AWS Glue Elastic Views. Эта служба интеграции данных отслеживает изменения данных в этих исходных хранилищах данных, а затем объединяет их в единое представление с помощью запросов SQL, которые обновляют целевую базу данных.

    По мере роста масштабов облачных приложений растет и спрос на DynamoDB. Помимо масштабируемости транзакций, база данных предназначена для обработки большого количества подключений. Все, что обслуживает одновременно большое количество пользователей, от приложений мобильного банкинга до таких клиентов, как Snapchat, выиграет от внесения изменений, объясняет Цурих. Магазины с ключом-значением также обслуживают приложения с нестабильной нагрузкой, такие как розничная торговля, в которых могут наблюдаться большие всплески объемов в определенные периоды, например в праздничные дни.

    Бурный рост специализированных типов баз данных

    Базы данных типа “ключ-значение” – это лишь один из видов альтернативного хранилища данных, который появился в дополнение к традиционным реляционным механизмам. Хотя реляционные схемы отлично подходят для структурированных табличных записей с четко определенными типами полей, которые не меняются со временем, они не лучший выбор для типов данных, используемых во многих современных приложениях. Различные приложения, от геопространственного до интеллектуального анализа текста, проверили пределы модели Кодда.

    По крайней мере, еще в начале девяностых поставщики СУБД, такие как Sybase, пытались поддерживать другие типы данных с помощью надстроек к реляционному механизму. В конце концов, идея базы данных, специально созданной для специализированных случаев использования, получит поддержку, особенно когда люди решатся на варианты использования, выходящие за рамки простого создания-чтения-обновления-удаления (CRUD).

    Этот акцент на специализированных моделях баз данных открыл новые возможности для сектора баз данных, и многие компании запустили базы данных NoSQL, которые отказались от реляционной модели для различных подходов. Amazon Web Services (AWS) был среди них, запустив управляемые механизмы баз данных для различных сценариев использования. Вот некоторые из наиболее распространенных типов:

    Базы данных документов (например, Amazon DocumentDB) – Полезно для каталогов, систем управления контентом, профилей пользователей, персонализации и мобильных устройств.

    Они хранят свои данные в документах в виде плоских файлов, обычно в формате JSON, который является языком общения многих разработчиков веб-приложений при передаче данных через API. Базы данных документов также гораздо менее жесткие, чем реляционные модели, когда дело доходит до обновления схем.

    Базы данных графов (например, Amazon Neptune) – Полезны для обнаружения мошенничества, социальных сетей, происхождения данных и графов знаний. Эти базы данных, популярные во всех социальных сетях, работают с наборами данных, которые содержат большое количество соединений между их узлами.

    Они документируют связи между записями (узлами) как грани, что позволяет им фиксировать взаимосвязи в масштабе. Они хороши для запросов, охватывающих сложные сети.

    Базы данных временных рядов (например, Amazon Timestream) – Полезно для DevOps, мониторинга приложений, промышленной телеметрии и приложений IoT.

    Они предназначены для потоковой передачи данных с отметками времени, которые могут поступать из источников, включая датчики Интернета вещей или крупные финансовые приложения. Обычно они записывают эти данные в формате только для добавления и сосредотачиваются на запросах, ссылающихся на временные интервалы.

    Базы данных бухгалтерской книги (например, база данных Amazon Quantum Ledger) – Полезно для финансов, производства, страхования, отдела кадров и расчета заработной платы, розничной торговли и цепочек поставок.

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

    Базы данных с широкими столбцами (например, Amazon Keyspaces) – Полезно для ведения журнала транзакций, приложений Интернета вещей, финансов и других приложений, где высокая доступность критически важна.

    Apache Cassandra – одна из самых известных баз данных с широкими столбцами. Эта модель данных поддерживает столбчатые базы данных, в которых данные хранятся с использованием семейств столбцов, а не традиционных таблиц реляционных баз данных. Структуры с широкими столбцами отлично подходят для хранения больших объемов данных, а также поддерживают структуры распределенных баз данных, в которых данные реплицируются между разными серверами для обеспечения низкой задержки и высокой доступности.

    Данные в столбцах можно исключать для каждой записи и легко добавлять в схемы базы данных при необходимости. Они подходят для очень быстрых запросов к базе данных и не страдают от тех же ограничений скорости, что и запросы к неиндексированным реляционным столбцам.

    Amazon Keyspaces – это управляемая база данных, поддерживающая приложения Cassandra.

    Базы данных в памяти (например, Amazon Elasticache) – Полезно для приложений с малой задержкой, которым необходимо работать в реальном или близком к реальному времени, включая назначение ставок в реальном времени, кеширование и списки лидеров.

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

    Использование базы данных, подходящей для работы, может дать результаты, которые нелегко достичь с помощью обычных реляционных моделей. Одним из примеров является Neptune, база данных графиков Amazon.

    Marinus Analytics, компания, которая использует технологические решения, чтобы помочь жертвам правоохранительных органов пресекать торговлю людьми, в 2019 году развернула движок для улучшения своего программного обеспечения Traffic Jam, которое выявляет закономерности в предполагаемой торговле людьми.

    Реляционные базы данных позволяют выполнять запросы только с одной степенью разделения за раз, что затрудняет прохождение цепочек отношений, охватывающих несколько объектов (в данном случае классифицированные рекламные объявления с высокой вероятностью трафика). Marinus Analytics смогла обеспечить более глубокие запросы и более быструю модель доступа с помощью Neptune, в сочетании с более быстрой моделью доступа, которая сокращает время запросов с минут до секунд, что позволило правоохранительным органам находить новые связи между преступными группировками. Программа помогла идентифицировать более 3800 жертв торговли людьми.

    Переопределение базы данных для различных типов использования немного похоже на создание автомобилей для определенных типов пользователей. Вы не стали бы использовать внедорожник для шоссейных гонок, и вы не возьмете гоночную машину F1 для ежемесячной покупки продуктов. Благодаря постоянному развитию технологий баз данных вы можете получить и то, и другое. А благодаря облаку вы можете подготовить их, когда они вам понадобятся.

    При поддержке AWS

    Предыдущая статьяБлагодаря легендарной приверженности Alphabet к продуктам нам не терпится увидеть, чего добьется его робототехнический бизнес Intrinsic °
    Следующая статья5 лучших врагов, чтобы фармить души в Demon’s Souls (и 5, от которых больше проблем, чем оно того стоит)
    Виктор Попанов
    Эксперт тестовой лаборатории. Первый джойстик держал в руках в возрасте 3 лет. Первый компьютер, на котором „работал” был с процессором Intel i386DX-266. Тестирует оборудование для издания ITBusiness. Будь то анализ новейших гаджетов или устранение сложных неполадок, этот автор всегда готов к выполнению поставленной задачи. Его страсть к технологиям и приверженность качеству делают его бесценным помощником в любой команде.