Я работаю в компании STM Labs, где мы строим большие высоконагруженные системы класса Big Data. Эта статья написана по мотивам моего выступления на конференции Saint Highload 2023. Хочу рассказать вам увлекательную историю про то, как мы искали лучшее решение по синхронизации аналитического и оперативного хранилищ в реальном времени. Нам важно было сделать это без потерь, потому что на кону стояли сотни и более терабайт данных.
Сразу обозначу, чего в этой статье не будет:
• Я не буду подробно говорить о типах СУБД и их различиях.
• Я не буду делать обзор аналитических СУБД. Тут каждый выбирает сам.
• Я не буду подробно останавливаться на архитектуре, отказоустойчивости и масштабировании СУБД MongoDB.
• Я не буду делать обзор отличий OLAP и OLTP.
• Я не буду делать обзор и сравнение реализаций CDC в различных СУБД.
Меня зовут Виталий Киреев, я руководитель R&D в SpaceWeb. В начале прошлого года мы внедрили IPFS-технологию в работу своего хостинга, и все наши клиенты получили возможность размещать контент в IPFS-сети. Решились на такой шаг не сразу: IPFS — технология пока еще экспериментальная, к ней и у R&D-команды полно вопросов.
В статье расскажем об основных принципах устройства IPFS, обсудим преимущества и недостатки. А еще поделимся, зачем вообще классическому хостинг-провайдеру было внедрять IPFS-технологию и с какими трудностями мы столкнулись в процессе. Статья будет полезна тем, кто только начинает знакомиться с IPFS или планирует использовать технологию для своих проектов.
Решили сравнить СБИС и 1С по трем критериям: простоте операций, удобству интерфейса и дополнительным фичам. Рассказываем, какая система лучше и кому она подойдёт.
Привет, Хабр.
В одном из наших недавних постов мы немного затронули тему автоматизации, которую мы активно продвигаем в наших продуктах. По различным каналам мы получили много положительных откликов и дополнительных вопросов о том, как можно использовать наши API для различных интеграций.
В рейтинге наиболее популярных «хотелок» – интеграция системы хранения данных с внешними отечественными или opensource продуктами: системы мониторинга, системы управления и планирования ёмкостей или сложные автоматизированные метрокластеры с классическим набором серверов приложений, СУБД и систем виртуализации.
Решив, что краткого упоминания о REST API в системах хранения данных АЭРОДИСК явно недостаточно, в этой статье мы расскажем о том, как автоматизировать создание классических репликации, конфигурации метрокластера и управлять переключением сайтов с использованием REST API и Python. А послушать про это можно будет на вебинаре «ОколоИТ», который пройдёт 12 марта в 15:00 – регистрируйтесь по ссылке.
Для запуска и эксплуатации высоконагруженных ИТ-решений с петабайтами данных в активе, нужно проработанное решение, позволяющее гибко управлять ресурсами. Одним из критичных аспектов этого решения, является разделение Compute & Storage — разделение ресурсов инфраструктуры под вычисление и хранение соответственно. Если не реализовать такое разделение в крупном проекте, инфраструктура рискует превратиться в «чемодан без ручки» — эффективность использования ресурсов будет низкой, а сложность управления ресурсами и средами будет высока. На примере команды SberData и их корпоративной аналитической платформы я расскажу, когда требуется разделение Compute & Storage и как это реализовать максимально нативно.
Статья подготовлена по мотивам доклада на VK Data Meetup «Как разделить Compute & Storage в Hadoop и не утонуть в лавине миграций».
Продолжаем серию постов про то как построить своё собственное облако в экосистеме Kubernetes. В прошлой статье мы разобрали как можно подготовить базовый дистрибутив Kubernetes на базе Talos Linux и Flux CD. Теперь нам предстоит обсудить возможность запуска виртуальных машин и всего что для этого необходимо, а это в первую очередь хранилище и сеть.
Мы поговорим про такие технологии как KubeVirt, LINSTOR и Kube-OVN
Для начала мне стоит рассказать зачем вообще нужны виртуальные машины, почему бы нам не ограничиться только-лишь контейнерами?
Всё дело в том, что контейнеры в ядре Linux не дают должного уровня изоляции. Несмотря на то, что с каждым годом ситуация становится всё лучше, тем не менее довольно часто мы сталкиваемся с уязвимостями, позволяющими покинуть песочницу контейнера и повысить свои привилегии в системе.
Ошибки в построении DWH возникают не только в результате того, что первоначально не были учтены возможные изменения в бизнес-процессах, потребностях и целях компании, но и из-за некорректного выбора стека технологий и СУБД.
Порядок хранения данных выбирается в соответствии с разными сценариями работы - запросами, разным объемом данных, количеством транзакций, необходимостью обновлений данных.
В статье читайте о СУБД Greenplum и о том, в каких случаях строить хранилища на ее основе.
В статье я расскажу о том, как мы построили систему для получения, анализа и сохранения утечек паролей. Рассмотрим архитектуру нашей системы, опишем основные компоненты и расскажем о нашем опыте использования ScyllaDB для задач оперативной загрузки большого количества накопленных утечек.
Когда-то файлы хранили на дискетах, потом на дисках, потом на флэшках. Закончилось всё облаками. Тогда встал ряд различных вопросов по надёжности и приватности. С одной стороны можно просто доверить файлы гуглу или яндексу, но тогда о приватности можно забыть. C другой стороны можно завести собственное облачное хранилище, будь то дорогое железное решение от Synology, или оперсорсное на арендованной vps на nextcloud, но тут требуется вовлечение, что бы облако оставалось в рабочем состоянии (следить за апдейтами, своевременно обновлять оборудование, поддерживать резервное железо). Вместе с развитием блокчейна и развитием децентрализованных технологий web 3.0, появились и облачные хранилища, обещающие приватность, доступность и низкую цену. Предлагаю к рассмотрению 2 проекта, которые появились более 10 лет назад, и до сих пор существуют - Filecoin и Storj.
Эта статья — продолжение истории про разработку Ansible-модулей для взаимодействий с системами хранения данных (СХД) через API, которое удовлетворяет спецификации Swordfish. Эти модули в перспективе облегчат управление парком СХД от разных производителей.
Чтобы тестировать работоспособность созданных модулей, нужен настоящий сервер СХД (или тестовый mock-сервер), который предоставляет необходимый REST API. Получить настоящий сервер от производителя СХД — сложная задача, которая требует финансовых и временных затрат на получение программно-аппаратного обеспечения. В случае open-source разработки такая опция доступна не всем командам.
Компания SNIA, разработчик спецификации Swordfish, подумала об этом и предоставляет разработчикам свободно распространяемый mock-сервер — Swordfish API Emulator. В рамках проекта Лаборатории YADRO на базе СПбПУ Петра Великого мы протестировали его в работе. В статье расскажем, как он устроен и как с ним взаимодействовать в задачах.
• Гравастары: альтернативная теория чёрных дыр
• Самая голодная чёрная дыра из когда-либо найденных съедает по солнцу каждый день
• Создан диск размером с DVD, способный вместить 1 миллион фильмов
• Учёные заявили о прорыве в области искусственного интеллекта, позволяющем генерировать безграничную энергию чистого термоядерного синтеза
• Уэбб разглядел нейтронную звезду в остатках сверхновой, взорвавшейся в 1987-м году
Перенос файлов от одного облачного провайдера S3 к другому должен был обойтись нам примерно в 133 000 рублей. Вместо этого, мы заплатили за него около 29 000 рублей. Как можно в 5 раз удешевить этот процесс – рассказываем в статье.
В настоящее время очень широкое распространение получили решения, основанные на self-hosting'e. При этом, под этим термином понимается идеология и практика, предусматривающая размещение веб-сервисов на собственных серверах, например домашних, вместо использования стороннего хостинга, как коммерческого, так и бесплатного.
Преимущества такого решения очевидны: это во первых полный контроль над данными, во вторых возможность организовать работу на той операционной системе и в той среде к которой вы привыкли, а в третьих на том железе, которое вам доступно и которое подчас намного мощнее того, что предлагает сторонний хостинг.
Но недостатки такого подхода тоже есть, и часто основной недостаток в том, что для предоставления доступа к вашим сетевым ресурсам вы должны обеспечить ряд условий: работающий сервер, статический IP, правильная настройка NAT в части маршрутизации пакетов и обеспечения безопасности. И если с первым вопросом более-менее ситуация решаемая, то остальные вопросы подчас становятся нерешаемыми в силу ряда причин, начиная от особенностей провайдеров, заканчивая тем сетевым железом, которое есть в распоряжении пользователя. Хорошо, если это будет какое то решение, основанное на RouterOS или OpenWRT, которое еще надо уметь настроить, что подчас совсем не просто. Но это может быть и какой то роутер начального уровня (или, что еще хуже провайдерское оборудование), которое крайне ограничено в своем функционале, на котором настроен свой NAT, которое может находится за NAT провайдера с «серым» IP. Поэтому популярные решения для self-hosted ресурсов вроде NextCloud становятся не такими уж и популярными как бы того хотелось.
Vertica - одна из первых широко используемых MPP баз на просторах айти ландшафта СНГ. Колоночное хранение, быстрые запросы на миллиардах строк, легендарные sort-merge джойны, которых нет больше ни у кого, позволяющие запускать свои грибницы. Но нынче на дворе 2024 год: как компания Vertica сменила уже 2 (или трех) владельцев, доступ к веб ресурсам с территории РФ ограничен, поддержка брошена, а вокруг нас процветают облака или как минимум кубернетисы во всех ипостасях.
И все же начиная с версии 10.1 компания представила интересную возможность для тех, кто уже крепко подсел на эту иглу - движок Eon. Описывая в двух словах, это та же самая по скорости база данных, но использующая общее хранилище - S3 (во всех своих ипостасях от вендорских AWS, GCS до онпрем вариантов) или HDFS. К тому же есть отличная завлекалочка - бесплатное использование кластера размером до 1 ТБ и до 3 нод вычисления. Статья является итогом тестирования технологии, и результаты тестирования какие-то не очень веселые.
Привет, Хабр! Меня зовут Никита Ильин, я занимаюсь разработкой архитектуры BI-платформы Visiology. Сегодня мы поговорим про оптимизацию ClickHouse — ведущей СУБД, которую все чаще используют для решения задач аналитики на больших объемах данных. В этой статье я расскажу, почему важно оптимизировать ClickHouse, в каких направлениях это можно делать, и почему разумный подход к размещению информации, кэшированию и индексированию особенно важен с точки зрения производительности BI-платформы. Также мы поговорим о том, к каким нюансам нужно готовиться, если вы решаете оптимизировать CH самостоятельно, сколько времени и сил может потребовать этот процесс и почему мы решили “зашить” в новый движок ViQube 2 десятки алгоритмов автоматической оптимизации.
