в статье ничего не говориться про уникальность преимуществ.
Я вижу преимущество решения в «коробочности», в архитектуре хранилища, которое проектировалось под хранение структурированных и неструтурированных данных, в круто проработанных и долгоживущих ACID транзакциях, в рамках которых можно менять не только данные, но и их схему, а так же структуру файловой системы, гибкости в настройке прав и управлении квотами.
Но это никак не отменяет того, что есть множество других прекрасных решений, особенно для компаний, у которых нет такого обьема данных и их пользователей.
Конечно это так и есть много крутых инструментов, которые можно использовать поверх s3. Но все наши задачи прекрасно решаются в YTsaurus и мыслей о миграции куда-либо нет.
Хранение в YTsaurus по стоимости хранения не проигрывает (по нашему опыту выигрывает, но у меня нет бенчмарков) s3, есть Spark и ClickHouse over YTsaurus, которые прекрасно работают. YT спроектирован таким образом, чтобы в нем было удобно жить огромной компании целиком, с изоляцией ресурсов, гибкими правами доступа и минимумом затрат на администрирования для пользователей.
Kafka — это не база данных, а очередь. В ней не хранят данные, а с помощью нее передают данные из системы A в систему B, делают стримминговую обработку (Kafka Streams).
А что значит компактные базы данных Greenplum и ClickHouse? И то, и другое подходит для того, чтобы хранить и обрабатывать терабайты, десятки терабайт, а то и сотни терабайт данных.
Да, именно такой вариант. Если что-то надо срочно для бизнеса, то можно форсить рабочий процесс, а не начинать работать мимо процесса, CI, тестов и всего прочего, что делает разработку надежнее.
На своих проектах я стараюсь добиться того, чтобы накат, в том числе и bugfix-ов и hotfix-ов, был не болью, а быстрым и понятным процессом.
Лично я на подобные случаи стараюсь иметь несколько вариантов решения:
1) механизм релиза-хотфикса, который можно катить в любое время и который не блокируется текущими доработками
2) механизм для запуска миграций
Оба варианта выше в любом выкатываются из репозитория и предварительно проходят Code Review.
Еще хочу заметить, что бывает так, что даже во внутренней разработке может не быть доступа на запись в прод-базу у разработчиков, например, из-за требований внутреннего или внешнего аудита.
Подписываюсь под каждым словом автора: преподаю в МГТУ с 2011-го, работал в несколько крупных российских IT компаниях. Из-за бюрократических проблем и отсутствия нормальной системы образования — каждый год хочется уйти.
в статье ничего не говориться про уникальность преимуществ.
Я вижу преимущество решения в «коробочности», в архитектуре хранилища, которое проектировалось под хранение структурированных и неструтурированных данных, в круто проработанных и долгоживущих ACID транзакциях, в рамках которых можно менять не только данные, но и их схему, а так же структуру файловой системы, гибкости в настройке прав и управлении квотами.
Но это никак не отменяет того, что есть множество других прекрасных решений, особенно для компаний, у которых нет такого обьема данных и их пользователей.
Конечно это так и есть много крутых инструментов, которые можно использовать поверх s3. Но все наши задачи прекрасно решаются в YTsaurus и мыслей о миграции куда-либо нет.
Хранение в YTsaurus по стоимости хранения не проигрывает (по нашему опыту выигрывает, но у меня нет бенчмарков) s3, есть Spark и ClickHouse over YTsaurus, которые прекрасно работают. YT спроектирован таким образом, чтобы в нем было удобно жить огромной компании целиком, с изоляцией ресурсов, гибкими правами доступа и минимумом затрат на администрирования для пользователей.
По поводу мотивации его разработки есть статья Максима Бабенко от 2016-го года: https://habr.com/ru/companies/yandex/articles/311104/.
А что значит компактные базы данных Greenplum и ClickHouse? И то, и другое подходит для того, чтобы хранить и обрабатывать терабайты, десятки терабайт, а то и сотни терабайт данных.
На своих проектах я стараюсь добиться того, чтобы накат, в том числе и bugfix-ов и hotfix-ов, был не болью, а быстрым и понятным процессом.
1) механизм релиза-хотфикса, который можно катить в любое время и который не блокируется текущими доработками
2) механизм для запуска миграций
Оба варианта выше в любом выкатываются из репозитория и предварительно проходят Code Review.
Еще хочу заметить, что бывает так, что даже во внутренней разработке может не быть доступа на запись в прод-базу у разработчиков, например, из-за требований внутреннего или внешнего аудита.