Публикации, рассказывающие о хранилищах данных
В статье рассказывается о разработке портативного NAS с двумя дисками NVME на основе одноплатного компьютера. Даётся небольшая теория работы контроллера PCIe, рассказывается о проблемах интеграции своего модуля дисков, а также приводятся детали дизайна и результаты тестирования.
Для ЛЛ: RAID-5 совершенно не подходит для современных массивов из дисков на 5-10 Тб по нескольким причинам.
Хотя я живу в Копенгагене и в основном перемещаюсь по городу на велосипеде, у меня есть и машина, чтобы добираться до других частей страны. В Дании автомобили через каждые два года проходят обязательный официальный осмотр; я проходил его за свою жизнь несколько раз. Несколько лет назад механик, выполнявший осмотр, сообщил мне о том, что у машины неправильный номер кузова.
Я немного занервничал, потому что покупал машину с рук, и внезапно задался вопросом, действительно ли всё так, как я думал. Неужели я непреднамеренно купил краденную машину?
Но механик просто подошёл к своему компьютеру, чтобы исправить ошибку. И тогда у меня возникло совершенно другое опасение. Когда программируешь больше десятка лет, то учишься предвидеть разные типичные режимы отказа. Так как номер кузова — очевидный кандидат на должность естественного ключа, я заранее предвидел, что изменение этого номера будет или невозможно, или приведёт ко всевозможным каскадным эффектам, и в конечном итоге к уничтожению официальных записей, больше не признающих, что машина принадлежит мне.
По опыту нашей продуктовой команды разработки и поддержки, пользователи, оперирующие большими объемами данных компании часто используют несколько разрозненных кластеров Greenplum.
Мотивация такого решения может быть разной: организационная - разные команды-владельцы бизнес-данных выстраивают свои модели данных, обрабатывают их нужным для них образом; техническая - распределенные по различным датацентрам кластеры и т.п. Однако, рано или поздно возникает задача использовать данные из "соседних" хранилищ. Это могут быть как разовые сценарии единичных запросов, так и организация более сложных ETL-процессов. Реализация подобных механизмов опять-таки может быть разной со своими достоинствами и недостатками, исходя из возможностей и ограничений.
В этой статье рассматривается детали предлагаемой нами реализации коннектора для выполнения, так называемых, гетерогенных запросов в рамках разных кластеров ArenadataDB и/или Greenplum - задача, которой наша команда разработки занималась в 2023 году. Этот коннектор позволяет объединять в запросах разные кластеры ADB, но при этом пользоваться возможностями установления соединений между сегментами.
Но обо всем по порядку.
В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.
Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.
Эта история началась с того, что и мы с проблемами масштабирования столкнулись. Под хабракатом вы узнаете, как мы прошли через отрицание проблемы, гнев на Ceph, торг с CTO и разработку собственного решения. Как выбирали технологии, на какие грабли наступили, и что в итоге получилось.
Недавно мы выпустили новый сервис — объектное хранилище S3 на базе нашего облака. Запустили его на Ceph. Перед этим провели множество тестов. В частности, решили выяснить, как на практике Ceph справляется с мелкими объектами — проблемой любого S3. И вот что из этого вышло.
В этой статье я опишу наш путь реализации глобальных индексов в шардированной базе данных. Расскажу обо всех проблемах, с которыми столкнулись, и решениях, которые приняли, чтобы их обойти. Мы поговорим про реализацию на основе базы данных Tarantool, но общий подход применим и к другим шардированным базам данных без встроенной поддержки таких индексов, да и встроенная реализация часто строится по похожим принципам. Эта статья поможет разобраться в деталях, компромиссах и ограничениях работы глобальных индексов.
Всем привет! Меня зовут Газимагомед, я занимаюсь разработкой внутреннего распределённого профайлера Vision в Ozon. В этой статье я раскрою понятие профиля, расскажу о том, что такое распределённый профайлинг, чем отличается автоматический сбор профилей от ручного. А также рассмотрим проблемы, возникающие при построении профайлера. Что ж, усаживайтесь поудобнее, мы начинаем.
От любви до ненависти — один шаг, это история об этом. Если вы используете или планируете использовать холодное хранилище Selectel для бэкапа, выбросьте эту идею из головы НЕМЕДЛЕННО!
Я был привлечен дешевыми тарифами холодного хранилища Selectel и настроил на них архивацию данных из 1С.
Мне так понравилось холодное хранилище Selectel, что я рекомендовал его и настроил на него у трех своих клиентов архив 1С. Ничто не предвещало БЕДЫ.
Привет Хабр!
Сегодня познакомимся с ключевыми новинками в версии 5.5 нашего продукта «Кибер Инфраструктура». Кибер Инфраструктура — это универсальное решение, которое представляет собой мультипротокольное программно‑определяемое хранилище и платформу виртуализации в одном продукте.
Привет! Меня зовут Филипп Бочаров, я руководитель центра мониторинга и наблюдаемости в МТС Digital. Мы делаем распределённую трассировку, чтобы контролировать качество наших сервисов и предотвращать аварии. В этой статье разберём, как добиться понятной и прозрачной работы от сложных распределённых систем.
За время, прошедшее с прошлого доклада, количество обрабатываемых в единицу времени спанов выросло в несколько раз. Рассмотрим, какие архитектурные решения начали «поджимать», и как команда МТС их исправляла.
Привет, Хабр! Меня зовут Антон Аплемах, и я владелец продукта cloudfort в облачном провайдере beeline cloud. В блоге на Хабре и в нашем медиа мы рассказываем про open source, тренды в разработке программного обеспечения и облачные технологии. И сегодня я хочу поговорить про хранилища S3, запуск и настройка которых — нетривиальная задача. Какие услуги на основе объектных хранилищ использует бизнес (включая наш новый продукт cloudfort), и что учитывать при выборе решения.
CDC вам не «Centers for Disease Control and Prevention» а «Change data capture». В статье рассказано какие есть виды CDC и как реализовать один из CDC при помощи Debezium.
Долгожданный стандарт RFC9562 "Universally Unique IDentifiers (UUID)" с тремя новыми версиями идентификаторов UUID (6, 7 и 8) вместо малопригодного RFC4122 наконец-то вступил в силу. Я участвовал в разработке нового стандарта. Обзор стандарта можно посмотреть в статье.
Введенные новым стандартом идентификаторы седьмой версии UUIDv7 — это лучшее, что теперь есть для ключей баз данных и распределенных систем. Они обеспечивают такую же производительность, как и bigint. UUIDv7 уже реализованы в том или ином виде в основных языках программирования и в некоторых СУБД.
Сгенерированные UUIDv7 имеют все преимущества UUID и при этом упорядочены по дате и времени создания. Это ускоряет поиск индексов и записей в БД по ключу в формате UUID, значительно упрощает и ускоряет базы данных и распределенные системы. Неупорядоченность значений UUID прежде сдерживала использование UUID в качестве ключей и вынуждала разработчиков выдумывать собственные форматы идентификаторов или довольствоваться последовательными целыми числами в качестве ключей.
Черновик стандарта активно обсуждался на Хабре в апреле 2022 года в комментариях к статье "Встречайте UUID нового поколения для ключей высоконагруженных систем".
Разные участники разработки нового стандарта придерживались различных взглядов, и практически все обсуждавшиеся альтернативные варианты структуры UUIDv7 вошли в стандарт. Поэтому теперь перед разработчиками возникает вопрос, какую из множества возможных спецификаций UUIDv7 реализовывать и применять. Также для массового перехода на UUIDv7 нужна дополнительная функциональность, повышающая привлекательность UUIDv7 для разработчиков и бизнеса.
Предложенная мной ниже спецификация UUIDv7 с дополнительной функциональностью описывает максимально надежный и удобный вариант структуры UUIDv7 для самых сложных и высоконагруженных информационных систем. Функциональность упорядочена по приоритету реализации
Сегодня, когда объёмы данных постоянно растут, а терять их становится всё критичнее, использование внешнего накопителя часто становится необходимостью. У каждого из нас есть файлы, которыми мы дорожим — от рабочих документов до фотографий с домашними питомцами. При этом у жёстких дисков есть срок службы и вероятность отказа в самый неподходящий момент. У меня был подобный опыт с накопителем Seagate и ошибкой «муха СС». С тех пор я в обязательном порядке дублирую все важные файлы в облако и ещё на один диск.
Всем привет!
Как вы знаете, многие поставщики ПО ушли с российского рынка ввиду введённых санкций и многие компании столкнулись с необходимость заняться импортозамещением в кратчайшие сроки. Не стал исключением и наш заказчик. Целевой системой, на которое было принято решение мигрировать старое хранилище, стал Greenplum (далее GP) от компании Arenadata.
Этой статьей мы запускаем цикл материалов посвященных Greenplum. В рамках цикла мы разберем, как вообще устроен GP и как выглядит его архитектура. Постараемся выделить must have практики при работе с данным продуктом, а также обсудим, как можно спроектировать хранилище на GP, осуществлять мониторинг эффективности работы и многое другое. Данный цикл статей будет полезен как разработчикам БД, так и аналитикам.
Доступ к единой истории операций — функция, которую сегодня ожидают видеть пользователи любого современного интернет-банкинга. В приложениях Газпромбанка функция существует уже много лет, но некоторое время назад мы решили существенно её переработать. В этой статье я расскажу, что мы поменяли, как и почему мы решили это сделать, а также почему мы гордимся результатом.
Сразу оговорюсь, что не буду углубляться в технические детали и остановлюсь на подходе, который мы решили использовать. Иначе есть риск что статья превратится в километровое полотнище. А если возникнут вопросы, то либо отвечу на них в комментах, либо аккумулирую и попробую разобрать в следующей статье.
Привет, Хабр! Меня зовут Сергей Евсеев, сегодня я расскажу, как в Apache NiFi настраивается ETL-пайплайн на задаче с JSON’ами. В этом мне помогут инструменты Jolt и Avro. Пост пригодится новичкам и тем, кто выбирает инструмент для решения схожей задачи.
Что делает наша команда
Команда работает с данными по рекрутингу — с любой аналитикой, которая необходима персоналу подбора сотрудников. У нас есть различные внешние или внутренние источники, из которых с помощью NiFi или Apache Spark мы забираем данные и складируем к себе в хранилище (по умолчанию Hive, но есть еще PostgreSQL и ClickHouse). Этими же инструментами мы можем брать данные из хранилищ, создавать витрины и складывать обратно, предоставлять данные внутренним клиентам или делать дашборды и давать визуализацию.
Описание задачи
У нас есть внешний сервис, на котором рекрутеры работают с подбором. Сервис может отдавать данные через свою API, а мы эти данные можем загружать и складировать в хранилище. После загрузки у нас появляется возможность отдавать данные другим командам или работать с ними самим. Итак, пришла задача — нужно загрузить через API наши данные. Дали документацию для загрузки, поехали. Идем в NiFi, создаем пайплайн для запросов к API, их трансформации и складывания в Hive. Пайплайн начинает падать, приходится посидеть, почитать документацию. Чего-то не хватает, JSON-ы идут не те, возникают сложности, которые нужно разобрать и решить.
Ответы приходят в формате JSON. Документации достаточно для начала загрузки, но для полного понимания структуры и содержимого ответа — маловато.
Мы решили просто загружать все подряд — на месте разберемся, что нам нужно и как мы это будем грузить, потом пойдем к источникам с конкретными вопросами. Так как каждый метод API отдает свой класс данных в виде JSON, в котором содержится массив объектов этого класса, нужно построить много таких пайплайнов с обработкой разного типа JSON’ов. Еще одна сложность — объекты внутри одного и того же класса могут отличаться по набору полей и их содержимому. Это зависит от того, как, например, сотрудники подбора заполнят информацию о вакансии на этом сервисе. Этот API работает без версий, поэтому в случае добавления новых полей информацию о них мы получим только либо из данных, либо в процессе коммуникации.
