Центр Развития Перспективных Технологий - компания разработчик системы мониторинга товаров. Как IT компания с большим количеством данных мы используем множество NoSQL решений в своей повседневной работе. Одним из таких решений является Apache Cassandra.

Суммарно, во всех кластерах Cassandra мы храним 0.4PB данных при общей емкости 0.9PB, стабильно производим 0.7млн операций записи и доступа к данным и 1.1млн когда необходимо разогнаться в трудные времена, при этом продолжаем непрерывно расширяться.

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

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

В 1930-х годах в Москве начался масштабный проект по переносу домов. Да-да, именно переносу – вызвано это было тем, что архитекторы претворяли в жизнь масштабные проекты, которым требовалось место, но его не было. Иногда на пути нового проекта стоял какой-нибудь дом. Любопытно, что во время его перемещения, жильцов не переселяли, а дом даже не отключали от инженерной инфраструктуры: в квартирах продолжал функционировать телефон, водопровод, электричество и канализация.

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

Статья для начинающих аналитиков-стажеров

Когда вводишь в поисковой запрос "Курсы для аналитика данных", то сразу в глаза бросается SQL, Phytnon, R и другие инструменты. Но в первую очередь аналитику данных помогли бы не только инструменты, а еще и определенные способы мышления цифрового детектива. На наглядном примере мы вместе протестируем витрину данных, выстроим логику развития событий, а далее применим SQL. Статья предназначена для junior аналитиков данных или тех, кто только знакомится с будущей профессией Data Analyst.

Одним из трендов при проектировании сервисов в последнее время выступает использование в качестве баз данных NoSQL-систем. Мы также стараемся идти в ногу со временем и, конечно же, имеем в своем IT-ландшафте несколько таких решений. Одно из них — шардированный кластер MongoDB. Эксплуатация этой СУБД сопряжена с проблемами производительности, архитектуры, взаимодействия и т.д. Удивительно, но факт - зачастую, все мы сталкиваемся с тем, что ошибаются разработчики самой СУБД. Кто бы мог подумать.., что после штатной перезагрузки узла конфигурационного сервера MongoDB в процессе обновления может произойти аварийное завершение работы сервиса базы данных и наш стенд превратится в «тыкву»!

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

Дисклеймер: нижеописанные события произошли после того, как была опубликована рекомендация производителя не использовать версию 4.4.4.