В 2021 году я начал свой самый длительный тест, задача которого в том, чтобы узнать, как снижается ёмкость обычных батареек через несколько лет хранения и насколько можно верить производителям, указывающим сроки хранения батареек до 12 лет.
Рубрика «хранение»
Ёмкость батареек через четыре года хранения
2025-09-18 в 6:33, admin, рубрики: батарейки, емкость, тест, хранение, энергияПочему в 2025-м мы всё ещё слышим «бип» HDD
2025-09-07 в 13:02, admin, рубрики: hdd, ruvds_статьи, ssd, данные, Компьютерное железо, Накопители, хранение, хранение данных
Черкаш-код: изобретение и внедрение
2023-11-15 в 8:22, admin, рубрики: папки, структура, хранение, черкаш, Штрих
Почему при Covid-19 увеличилась переподписка, и как это проверить
2020-06-17 в 6:57, admin, рубрики: COVID-19, Блог компании КРОК Облачные сервисы, данные, облака, облачные сервисы, переподписка, скрипты, хранение, хранение данных
Photo by Victor Rodriguez on Unsplash
Часто мы получаем от клиентов (включая даже крупных) сообщения, в которых сквозит общий мотив: «У %provider_name% нам не хватало 192 ядер, а у вас и 120 достаточно. Почему так?». Причем в последнее время из-за пандемии таких запросов стало больше. То ли потому что клиенты вышли в онлайн и почувствовали нехватку ресурсов из-за ажиотажного спроса и у других клиентов тоже, то ли потому что некоторые провайдеры из-за все того же высокого спроса на услуги стали плотнее «упаковывать» в облаке заказчиков.
Вот эта переподписка, которая обострилась, судя по всему, из-за Covid-19, сейчас волнует очень многих облачных пользователей. Поэтому мы постараемся ответить на наиболее распространенные вопросы и рассказать про инструмент, который позволит проверить наличие переподписки у вашего провайдера.
Может показаться, что эта тема уже не раз поднималась на Хабре и за его пределами, а статья будет полезной только совсем зеленым новичкам. Но мы не писали бы этот материал, если бы предполагаемый уровень осведомленности клиентов об этом явлении совпадал с реальным.
Читать полностью »
Бокс-непросыпайка для SMD и прочей мелочевки
2020-05-06 в 15:05, admin, рубрики: diy или сделай сам, коробка, самоделки, хранение, Электроника для начинающих
Написанием данной околотематической статьи побудили меня затянувшиеся изоляционные меры и сопутствующие им скука и желание себя чем-то занять. Прошу отнестись как к «пятничной развлекательной» статье. Но, может быть кому то будет и полезно! Никаких ардуин, только фанера и силикон!
Читать полностью »
Обезл***вание д***ных — это не просто рандомизация
2020-03-03 в 7:02, admin, рубрики: алгоритм, база данных, банк, безопасность, Блог компании ТЕХНОСЕРВ, данные, информационная безопасность, маскировка, обезличивание, разработчик, СУБД, тестировщик, тесты, финансы, хранение, хранение данных
В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.
Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.
Так вот, не будет.
Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.
Обычная ситуация, что разработчик первой версии системы уже десять лет как умер или уехал, а системы ядра, запущенные в старом гипервизоре внутри нового гипервизора (чтобы обеспечить совместимость) ещё в проде.
То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных. Читать полностью »
Массивно-параллельная база данных Greenplum — короткий ликбез
2020-01-29 в 7:06, admin, рубрики: greenplum, mpp, архитектура, безопасность, Блог компании КРОК Облачные сервисы, данные, заказчик, контейнеризация, облачные сервисы, СУБД, хранение, хранение данных
Для Hadoop и Greenplum есть возможность получить готовый SaaS. И если Хадуп — известная штука, то Greenplum (он лежит в основе продукта АrenadataDB, про который далее пойдёт речь) — интересная, но уже менее «на слуху».
Arenadata DB — это распределённая СУБД на базе опенсорсного Greenplum. Как и у других решений MPP (параллельной обработки данных), для массивно-параллельных систем архитектура облака далека от оптимальной. Это может снижать производительность аж до 30 % (обычно меньше). Но, тем не менее, эту проблему можно нивелировать (о чём речь пойдёт ниже). Кроме того, стоит покупать такую услугу из облака, часто это удобно и выгодно в сравнении с развёртыванием собственного кластера.
В гайдах явно указывается on-premise, но сейчас многие осознают масштаб удобства облака. Все понимают, что некая деградация производительности будет, но это настолько всё равно супер по удобству и скорости, что уже есть проекты, где этим жертвуют на каких-то этапах вроде проверки гипотез.
Если у вас есть хранилище данных больше 1 ТБ и транзакционные системы — не ваш профиль по нагрузке, то ниже — рассказ, что можно сделать как вариант. Почему 1 ТБ? Начиная с этого объёма использование MPP эффективнее по соотношению производительность/стоимость, если сравнивать с классическими СУБД. Читать полностью »
Как я организовал хранение фотографий
2019-04-08 в 11:51, admin, рубрики: howto, Лайфхаки для гиков, Накопители, организация работы, фото, фотографии, Фототехника, хранение, хранение данныхПривет! Каждый из нас хранит какую-нибудь информацию, некоторые для этого используют секретики и лайфхаки. Лично я люблю понажимать кнопку фоторужья и сегодня хотел бы поделиться своим опытом хранения информации, к которому я шёл-шёл и пришёл.
Сразу предупрежу: под катом нет «серебряной пули», которая умножит на 0 проблему хаоса в файлах на ваших устройствах. И даже ни строчки про нейросети, распознавание чего-либо кем-либо и прочие нанотехнологии. Под катом — немного текста и дубовая табличка, которую ещё и заполнять придётся вручную =) Но которая работает.
Читать полностью »
Как мы перевозили дата-центр западной компании в РФ из-за закона о персданных
2016-02-25 в 6:45, admin, рубрики: Блог компании КРОК, дата-центр, ит-инфраструктура, миграция, обработка, ПД, персональные данные, рф, Серверное администрирование, ФЗ-152, хранение, хранение данных, цодУ зарубежных компаний история с ИТ-инфраструктурой очень простая: они как росли себе на Западе, так там всё и осталось. В России, как правило, нет даже инженеров, а все сервисы предоставляются откуда-нибудь из Ирландии, Франкфурта, Бостона или других городов, где находится головная организация и её дата-центры.
Драматически ситуация поменялась после вступления в силу поправок к ФЗ-152, гласящих, что персональные данные российских граждан нужно записывать, систематизировать, хранить и обрабатывать с использованием баз данных, находящихся исключительно в нашей стране. Некоторые компании приняли решение поднимать дата-центры в Москве, чтобы не терять бизнес. В нашем случае получилось примерно так (изменены некоторые компоненты и названия, так как есть соглашение о неразглашении — иностранцы, что вы хотите):
Сложностей море, например, такие:
- Полное отсутствие ИТ-персонала в российском офисе, занимающегося миграцией систем и управлением всего проекта в целом — нужно общаться с сетевиками из Европы или США и разработчиками, например, из Шанхая.
- Мало поднять прокси-структуру — нужно реально по факту обрабатывать данные в России. А, значит, в Москве (или в другом городе, но, как правило, действие происходит в столице) должен быть развёрнут инстанс CMS, почты, прикладного ПО для работы с продажами, бухгалтерия и так далее.
- Нужно перевезти всё это быстро и без существенных простоев, а потом ещё и поддерживать в плане инфраструктуры (приклад в данном случае поддерживают «родные» ИТ-команды).
CEPH-кластер: хронология работ по апгрейду нашего файлового хранилища на новую архитектуру (56Gb-s IB)
2016-02-11 в 6:36, admin, рубрики: ceph, s3, SDS, Блог компании КРОК, виртуализация, высокая производительность, ит-инфраструктура, кластер, облако, СХД, хранение, хранение данных 
Запустив наше облако, мы стали предоставлять сервис хранения, аналогичный S3 Амазона (с совместимым API, чтобы российские заказчики могли использовать стандартные клиенты для работы с S3, изменив только endpoint для подключения). Основная задача сервиса — хранение снапшотов виртуальных машин и различных файлов клиентов. Амазон был взят за образец, куда надо развиваться, и в начале 2014 года стало понятно, что имеющееся файловое хранилище устарело, заказчики требовали современных фичей, недоступных у нас и так нравящихся им у AWS. Но доработка существующего решения светила огромными трудозатратами, поэтому было принято решение построить новое S3-совместимое хранилище с нуля.
Дальше — долгий процесс поиска и сравнений имеющихся решений, потом тесты на производительность и отказоустойчивость решения, написание кипы бумаг, затем — несколько неудачных тестовых миграций, исправления багов в архитектуре, работа над полученными ошибками и итоговая фоновая онлайн-миграция всех данных через два месяца работы.
Это было чертовски долго, но всё прошло спокойно.Читать полностью »