Рубрика «хранение данных» - 2
Диск — это просто куча битов
2023-08-01 в 13:00, admin, рубрики: linux, ruvds_перевод, биты, Блог компании RUVDS.com, жесткие диски, Компьютерное железо, оперативная память, файловая система, хранение данных
Доводилось ли вам слышать утверждение, что диск или память — это «просто куча битов?»
Не знаю точно, откуда эта идея пошла, но она вполне разумна и в некоторой степени рассеивает таинственный ореол вокруг компьютеров. Например, она опровергает теорию о том, что внутри моего ПК живёт очень плоский эльф.
Оказывается нет, в нём находятся биты, закодированные в электрических компонентах.
И всё же компьютеры по-прежнему хранят в себе загадочность. Что это за биты? Что они означают? Можем ли мы с ними поиграться, спарсить их, понять?
Далее я покажу вам, что всё это определённо возможно! Ради вашего развлечения я засуну руку в свой ПК, вытащу оттуда кучку битов, и мы их с вами изучим.Читать полностью »
Мониторинг — это боль
2023-07-05 в 13:39, admin, рубрики: Cortex, prometheus, ruvds_перевод, thanos, Блог компании RUVDS.com, логи, метрики, отладка, Программирование, трассировка, хранение данных
И все мы выполняем его неправильно (в том числе и я).
Я должен признаться. Несмотря на то, что меня много раз нанимали в том числе и благодаря моему опыту работы с платформами мониторинга, я начал его ненавидеть. Инструменты мониторинга и наблюдаемости (observability) совершают тяжкий грех: обманом заставляют людей думать, что это простая задача. Очень легко мониторить маленькое приложение или сервис. Но почти ни одно из таких решений не масштабируется.
Вместо этого мониторинг превращается в бесконечную последовательность маленьких неудач. Метрики на какое-то время исчезают, логи перестают записываться на несколько часов, веб-UI для трассировок больше не работает. Мы настраиваем эти инструменты, готовясь, что сможем о них после этого забыть, но на самом деле они требуют постоянно растущих усилий по обслуживанию. Некоторые инструменты ломаются, и их больше никто не чинит. Я слишком часто приходил в новую компанию и видел, что в ней развёрнут нелюбимый мной поломанный Jaeger.
Такое ощущение, что сейчас как никогда много инструментов мониторинга, но вперёд мы не движемся. Похоже, вместо развития упор делается на увеличение объёма выходных данных приложений для роста доходов компаний, занимающихся мониторингом. Кажется, практически никакого прогресса не происходит с принципом передачи меньшего количества логов и метрик от клиента. Я создаю всё более сложные стеки для записи огромных объёмов данных, чтобы использовать их всё меньше и меньше.
В статье я расскажу о том, что, по моему мнению, нужно делать, а также поделюсь своими надеждами и мечтами. Прошу вас убедить меня, что я не прав и что есть более качественные решения.
Читать полностью »
Почему мы не торопимся применять новые технологии
2023-07-04 в 11:01, admin, рубрики: IPv6, NVMe, ruvds_статьи, Блог компании RUVDS.com, ит-бизнес, системное администрирование, управление проектами, хостинг, хранение данных, цод
В комментариях к постам про разбор аварии (тут и тут) было развёрнутое обсуждение про новые технологии в ИБП, которые можно внедрить. Коротко — мы не будем внедрять ничего ультрасверхсовременного. Потому что лучшая версия для знакомства с софтом — это 2.4. В случае MS ещё хорошо, когда за цифрами написано что-то вроде SP2. Потому что если пробовать на себе все новые технологии, то это, конечно, дико интересно и прогрессивно, но мешает бизнесу. У нас дефицит свободного времени и рук. Вот, собственно, несколько прикладных историй, почему мы не торопимся нырять в новые технологии.
Пример с новым железом, на котором может строиться вся инфраструктура, думаю, знаком всем, поэтому начну не с него, а с холивара про IPv6 против IPv4.
Протокол v6 невероятно хорош. Его писали думающие люди, он снимает море проблем интернета, он реально крут. Адреса IPv6 практически бесплатные. Они не кончаются. В свою очередь, IPv4 стоят совершенно неприличных уже денег (это вторая статья в себестоимости виртуальной машины после железа), постоянно дорожают — и, что гораздо хуже, не всегда можно взять в аренду нужное их количество. Бывает, что к нам заезжает крупный клиент, мы хотим арендовать ещё 256 адресов v4 — и блок освобождается не через 15 минут, а через несколько дней. То есть нам надо постоянно ковыряться с тем, чтобы они были.
Но при этом IPv6 ещё хуже с точки зрения реального применения. Вообще, я лично не совсем понимаю, кому сейчас он нужен. Многие наши коллеги, кто пользуется, говорят просто: «В РФ v6 нет и не будет в ближайшее время, наверное». А специалисты по ИБ ещё категоричнее: «Я его просто отрубаю от греха подальше». Читать полностью »
Выбор структур данных для самописного текстового редактора
2023-06-26 в 13:00, admin, рубрики: c++, data structures, ruvds_перевод, vscode, Алгоритмы, Блог компании RUVDS.com, красно-черные деревья, Программирование, структуры данных, текстовые редакторы, хранение данных
Программирование текстовых редакторов может быть очень интересной и сложной задачей. Типы задач, которые должны решать текстовые редакторы, варьируются от тривиальных до невероятно трудных. Недавно я занимался переработкой внутренних структур данных редактора, над которым я работаю. В частности, самой фундаментальной для любого текстового редактора структуры данных: текста.
Ресурсы
Прежде чем мы приступим к разбору того, что я сделал, важно упомянуть очень полезные ресурсы для создания собственного текстового редактора:
- Build Your Own Text Editor — наверно, самый фундаментальный пост о создании текстового редактора с нуля, который я видел. Это превосходный туториал на случай, если вы хотите начать писать собственный текстовый редактор. Стоит заметить, что в редакторе из этого туториала в качестве внутренней структуры для текста используется, по сути, вектор строк.
- Text Editor: Data Structures — отличный обзор множества структур данных, которые можно использовать при реализации текстового редактора. (Спойлер: как минимум одна из них будет рассмотрена в моём посте)
- Плейлист Ded (Text Editor) на YouTube — это потрясающая серия, в которой @tscoding фиксирует процесс создания с нуля текстового редактора. Эти видео стали для меня источником вдохновения.
Зачем?
Если в сети есть так много хороших ресурсов о создании собственного текстового редактора (не говоря уже о том, что уже существует множество феноменальных текстовых редакторов), то зачем я это пишу? На то есть несколько причин:
- Я хотел заняться проектом, непохожим ни на один свой прошлый.
- Я хотел создать инструмент, которым смогу пользоваться.
- Мне всегда хотелось глубже разобраться с созданием собственных структур данных.
Отвечаю на вопросы после аварии
2023-06-26 в 7:01, admin, рубрики: ruvds_статьи, авария, Блог компании RUVDS.com, вопросы, управление проектами, хостинг, хранение данных, цод
Вот тут пост про нашу аварию на прошлых выходных. Там всё было по горячим следам, потом я обещал подробнее ответить на вопросы. Отвечаю. Самое главное, пожалуй, что бы я хотел донести, — в комментариях к первому посту было очень много советов, что можно сделать, чтобы избежать такой же аварии. Но большинство из этого мы делать не будем. Потому что это ошибка выжившего: защищаться надо от вероятных рисков, а не от крайне маловероятных, где совпадает сразу пять факторов. Точнее, можно и от них, но есть критерий экономической обоснованности.
Но давайте обо всём по порядку.
— Сколько клиентов пострадало?
— На три часа и более в одном ЦОДе отключилось 7–10 % из 14 наших, то есть менее 0,5 % от общего числа клиентов хостинга (точнее, хостов). Тем не менее мы очень подробно рассказываем про эту аварию, потому что она вызвала очень много вопросов. Читать полностью »
Эффект внутреннего JSON
2023-06-09 в 6:00, admin, рубрики: json, svn, костыли и велосипеды, Программирование, Системы управления версиями, хранение данныхЕму сказали, что он будет работать над веб-сайтами и иметь дело с JavaScript, Node.js, JSON и тому подобным. Звучало вполне логично для веб-разработки; странным был только комментарий нетехнического собеседователя, что всё «построено на основе Subversion»; Джейк решил, что просто чего-то недопонял.
Его поставили на проект, в котором использовался собственный «JSON-based Domain Specific Language» компании, или JDSL. Его начальник посоветовал ему изучить копию проекта, на который его назначили, и дал неделю-две на освоение. «Если возникнут вопросы, просто спрашивай, кого угодно, но, судя по твоему опыту, проблем у тебя возникнуть не должно».
Читать полностью »
Восстановление исходного кода старой игры с ленточного накопителя
2023-06-06 в 13:00, admin, рубрики: frogger, ruvds_перевод, Блог компании RUVDS.com, Восстановление данных, Игры и игровые консоли, лента, ленточные накопители, старое железо, старые игры, хранение данных
Моя история
Мне досталась лента с готовой версией игры Frogger 2: Swampy's Revenge. В детстве я очень любил эту серию игр.
Считалось, что эта лента — единственная резервная копия исходного кода готовой игры, игровых ресурсов и других данных разработки.
Как вы можете понять, эта находка в случае её восстановления оказалась бы бесценной. Но как же вообще считать/записать данные на ленту? Зачем вообще использовались ленточные накопители?
В 1999/2000 годах средний размер жёсткого диска составлял примерно 10 ГБ, к тому же они не славятся долгим сроком службы.
Очень привлекательным предложением были ленточные накопители OnStream, потому что имели картриджи по 50 ГБ (25 ГБ без сжатия) и к тому же стоили дешевле большинства жёстких дисков!
Ленты отлично подходят для резервного копирования, а при правильном хранении могут иметь долгий срок службы. К тому же можно купить ленточный накопитель, который вставлялся в компьютер как CD-привод или привод гибких дисков.
Читать полностью »
Мёртв ли последовательный ввод-вывод в эпоху накопителей NVMe?
2023-05-24 в 13:00, admin, рубрики: hdd, NVMe, ruvds_перевод, ssd, Блог компании RUVDS.com, Компьютерное железо, последовательный доступ, произвольный доступ, хранение данных, хранилища данных
Две системы, которые я хорошо знаю (Apache BookKeeper и Apache Kafka) проектировались в эпоху дисковых накопителей: жёстких дисков, или HDD. Жёсткие диски хорошо справляются с последовательным вводом-выводом, но не очень хороши в произвольном вводе-выводе из-за относительно большого времени поиска. Неудивительно, что и Kafka, и BookKeeper проектировались с расчётом на последовательный ввод-вывод.
И Kafka, и BookKeeper — это распределённые системы логирования, поэтому можно представить, что последовательный ввод-вывод будет стандартным режимом для системы хранения логов с возможностью только дополнения. Но последовательный и произвольный ввод-вывод находятся в спектре, где на одном краю расположен чисто последовательный, а на другом — чисто произвольный ввод-вывод. Если у вас есть пять тысяч файлов, которые вы дописываете небольшими циклическими операциями записи, и выполняете fsync, то это не такой уж последовательный паттерн доступа, он находится ближе к произвольному вводу-выводу. То есть если вы только дополняете логи, это не означает автоматически, что вы получаете последовательный ввод-вывод.
Читать полностью »