Репликация сегментов в OpenSearch

Многие наши коллеги всё больше смотрят в сторону OpenSearch, который постепенно обрастает всё новыми и новыми функциями. В телеграм-канале мы уже публиковали пост с описанием обновлений в версии 2.7, среди которых есть репликация сегментов (есть ещё и поиск по снэпшотам, но о нём как-нибудь в другой раз). Репликация сегментов — это альтернатива репликации документов. При репликации документов все ноды-реплики выполняют ту же операцию индексирования, что и основная нода. При репликации сегментов только основная нода выполняет операцию индексирования, создавая файлы сегментов, которые далее копируются на каждую ноду-реплику. При такой схеме репликации нагрузка по индексированию ложится только на основную ноду, освобождая ресурсы на репликах для использования под другие операции. В этом посте мы расскажем о концепции репликации сегментов, преимуществах и недостатках по сравнению с репликацией документов. Велком ту подкат.


Читать: https://habr.com/ru/articles/733730/

SQL миграции в Postgres. Часть 2

В первой части мы рассмотрели базовые операции, такие как добавление новых атрибутов, создание индексов и ограничений и т.д.

Эта статья посвящена двум более сложным миграциям:

- обновление большой таблицы
- разделение таблицы на две

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


Читать: https://habr.com/ru/articles/736458/

Расследуем фантомные чтения с диска в Linux

Не так давно один из наших пользователей сообщил нам о случае странного использования оборудования. Он при помощи нашего клиента ILP (InfluxDB Line Protocol) вставлял строки в свою базу данных QuestDB, но вместе с операциями записи на диск также наблюдались существенные объёмы чтения с диска. Этого никак не ожидаешь от нагрузки, рассчитанной только на запись, поэтому нам нужно было докопаться до причины этой проблемы. Сегодня мы поделимся этой историей, полной взлётов и падений, а также магии ядра Linux.


Читать: https://habr.com/ru/companies/ruvds/articles/736538/

Как мы распиливаем монолит без даунтайма

Всем привет!

На связи Михаил, и я продолжаю делиться историями про рефакторинг одного из сервисов облачной платформы #CloudMTS. В прошлый раз я рассказывал о том, как мы аккуратно раскладывали по папочкам код в соответствии с принципами чистой архитектуры. Сегодня поговорим о решении, которое позволяет нам распиливать монолит по кусочкам без простоев.
Вместо дисклеймера
Переход от монолита к микросервисной архитектуре — задача непростая. Особенно когда приложение уже в продуктиве. Пускаться в эту историю, потому что микросервисы — это стильно и молодежно, плохая затея. Стартуйте только тогда, когда преимущества трансформации будут очевидны и перевесят возможные издержки.
Наши причины перехода были следующими:
1. В монолите концентрировалось большое количество бизнес-процессов, которые охватывали сразу несколько потребителей: пользователей облачной платформы, сейлз-менеджеров (через CRM-систему), администраторов, обработчиков метрик. Получилась такая одна большая точка отказа сразу для 4 групп бизнес-процессов.
2. Каждый бизнес-процесс потребляет свой объем ресурсов. Например, для обработки метрик нужно 5 подов (чтобы запараллелить и ускорить обработку), для администрирования хватит и одного. Так как у нас все в одном сервисе, при масштабировании монолита мы будем ориентироваться на самый «прожорливый» бизнес-процесс. Часть ресурсов будет просто простаивать.
3. Хотелось добиться гранулярности, чтобы независимо писать и деплоить код для каждого бизнес-процесса. И не переживать, что какие-то изменения в одном бизнес-процессе неожиданно отрикошетят в соседний.



Читать: https://habr.com/ru/companies/cloud_mts/articles/736688/

Как настроить миграцию etcd между облачными кластерами Kubernetes и избежать простоев

Допустим, вам нужно перенести хранилище данных из одного кластера в другой. А выключать его нельзя, потому что это может вызвать незначительный (или значительный) коллапс сервисов, которые с ним работают. В статье мы расскажем о не самом очевидном и популярном способе переноса etcd из одного облачного кластера Kubernetes в другой. Такой способ поможет избежать простоя и связанных с ним последствий. Согласно стартовым условиям, оба кластера находятся в облаке, а потому нам предстоит столкнуться с некоторыми ограничениями и трудностями — им мы уделим особое внимание.

Примечание: Сразу оговорим, что речь идет про миграцию не того etcd, в котором Kubernetes хранит все состояние кластера. В статье описана миграция отдельной инсталляции etcd, которая используется сторонними приложениями и находится внутри кластера k8s.


Читать: https://habr.com/ru/companies/flant/articles/737204/

Как в 3 раза снизить затраты на отказоустойчивую инфраструктуру, переехав с Hazelcast на Redis

Redis на хайпе. Но мы переехали на него с Hazelcast не из-за этого, а потому, что в какой-то момент осознали, что не замечать сколько инцидентов у нас возникает из-за Hazelcast, дальше невозможно. Сегодня расскажу вам замечательную историю как мы всем Альфа-Мобайлом сменяли одну технологию на другую.


Читать: https://habr.com/ru/companies/alfa/articles/737630/

Невредные советы по Cassandra — как избежать ошибок?

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а также можем предоставить оптимальную конфигурацию для системы, которая передана на эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.

В материале я расскажу именно об Apache Cassandra: какие ошибки можно совершить при ее использовании, на что стоит обратить внимание и чем лучше не пренебрегать.


Читать: https://habr.com/ru/companies/digitalleague/articles/738908/

Записки оптимизатора 1С (часть 1). Странное поведение MS SQL Server 2019: длительные операции TRUNCATE

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

Не секрет, что самой популярной и массовой платформой в России для создания ИТ‑систем для бизнеса является 1С:Предприятие 8.х. На ней разработано огромное количество отраслевых и самописных решений.

Хочу обратить внимание на одну особенность работы приложений 1С, а именно, очень интенсивную работу с временными таблицами СУБД. Подобной интенсивной работы с tempDB, наверное, нет ни в одном тиражном решении в мире.

После завершения пакетного запроса платформа автоматически удаляет временную таблицу, отдавая серверу СУБД команду <truncate, чтобы освободить ресурсы под следующий запрос.

TRUNCATE — это очень простая и быстрая операция и выполняется мгновенно. Даже для таблиц с миллионами строк она длится миллисекунды. Тем не менее, у некоторых своих клиентов мы столкнулись с очень странной ситуацией, когда производительность системы проседает из‑за того, что запросы с очисткой временных таблиц могут длиться десятки секунд (не миллисекунд, а секунд!). А учитывая количество запросов с временными таблицами в ИТ‑системе на 1С:Предприятие, это время в совокупности становится просто огромным.


Читать: https://habr.com/ru/companies/softpoint/articles/739112/

Tarantool 2.11 LTS: Рассказываем про новые возможности администрирования и безопасности

Привет. Меня зовут Владимир Салыкин, я директор по продукту Tarantool. Мы выпустили Tarantool 2.11 LTS — стабильный релиз с долгим циклом поддержки. Работа над ним началась в мае 2022 года, и сейчас релиз включает в себя более тысячи коммитов от 42 авторов. Мы все много работали над решением основных проблем с обслуживанием и администрированием, с которыми ранее сталкивались наши пользователи.

В этой статье мы хотим рассказать про ключевые фичи, которые были добавлены в релизе.


Читать: https://habr.com/ru/companies/vk/articles/739134/

Погрузиться в Redis — материалы, которые помогут начать работу

Как начать работу с Redis командам, у которых мало опыта в администрировании СУБД? Можно попробовать создать кластеры Redis в облаке. Или же сначала «вкатиться» в тему и поближе познакомиться с экосистемой — на этот случай мы подготовили подборку литературы. В списке — свежие издания и классика, которую стоит прочитать каждому начинающему Redis-разработчику.

Кому будет интересно: например, вам нужна среда для разработки программ и приложений, или поддержки работы интернет-магазинов с их пиковыми нагрузками во время сезонных или тематических акций. Статья также пригодится компаниям с большим количеством офисов в разных регионах и командам, которым необходимо обрабатывать транзакции в режиме реального времени.


Читать: https://habr.com/ru/companies/cloud_mts/articles/739952/

Оптимизация Change Data Capture в БД Oracle

Как внедрить Change Data Capture в Oracle и при этом не отдать все ресурсы

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

А для решения проблем хранения и обработки больших объемов данных возникает потребность в их репликации из классического хранилища-источника в аналитическое хранилище для проведения аналитики без влияния на продуктивную эксплуатацию. Для обеспечения актуальности данных в аналитическом хранилище, их необходимо обновлять их при изменении операционных данных источника. Однако, простая перезагрузка данных - неэффективна, так как обычно изменяется только небольшая часть исходных данных. Поэтому в качестве решения предлагается использовать инкрементную загрузку данных с использованием паттерна "Change Data Capture", которая будет актуализировать аналитическое хранилище посредством периодического обновления данных, которые были изменены.


Читать: https://habr.com/ru/articles/740136/

Newbie Guide: разбираемся с MVCC на простых примерах

Изоляция транзакций в СУБД — важный механизм, который позволяет пользователю получить согласованное состояние данных и работать с ними, не допуская конфликтов и снижения производительности. Организовать изоляцию нужного уровня можно несколькими способами, один из которых — MVCC (Multiversion Concurrency Control, многоверсионное управление конкурентным доступом).


Читать: https://habr.com/ru/companies/vk/articles/740108/

Кто мощнее в базах данных? Сравниваем производительность БД на серверах с ARM- и x86-процессорами

Всем привет! Ранее я разобрал и протестировал сервер с процессором ARM, который попал к нам в Selectel Lab. Сервер показал хорошие результаты по производительности в ряде классических тестов, но в этот раз захотелось проверить его в боевой задаче — в работе с базами данных. Быть может, архитектура ARM-процессора сделает всех конкурентов на этой территории?

Чтобы ответить на этот вопрос, протестировал ARM вместе с семеркой серверов разных конфигураций с процессорами Intel и AMD. В качестве баз данных для нашего эксперимента выбрал самые популярные — PostgreSQL и MySQL. Результаты тестов с графиками и комментариями — под катом. Надеюсь, они будут полезны вам при выборе сервера под БД.


Читать: https://habr.com/ru/companies/selectel/articles/740492/

У HDD нет будущего? Погодите, не так быстро…

Будущее HDD зависит от того, кого спросить. Есть адепты SSD, которые не видят в «устаревшей» технологии HDD никаких перспектив. Действительно, SSD прогрессируют гораздо быстрее: это касается и технологического прогресса, и стоимости. Если экстраполировать нынешние темпы развития отрасли, то создаётся впечатление, что SSD вытеснят HDD во всех сферах применения в ближайшие десятилетия.

Но по факту этого не происходит.


Читать: https://habr.com/ru/companies/ruvds/articles/736924/

Мёртв ли последовательный ввод-вывод в эпоху накопителей NVMe?



Две системы, которые я хорошо знаю (Apache BookKeeper и Apache Kafka) проектировались в эпоху дисковых накопителей: жёстких дисков, или HDD. Жёсткие диски хорошо справляются с последовательным вводом-выводом, но не очень хороши в произвольном вводе-выводе из-за относительно большого времени поиска. Неудивительно, что и Kafka, и BookKeeper проектировались с расчётом на последовательный ввод-вывод.

И Kafka, и BookKeeper — это распределённые системы логирования, поэтому можно представить, что последовательный ввод-вывод будет стандартным режимом для системы хранения логов с возможностью только дополнения. Но последовательный и произвольный ввод-вывод находятся в спектре, где на одном краю расположен чисто последовательный, а на другом — чисто произвольный ввод-вывод. Если у вас есть пять тысяч файлов, которые вы дописываете небольшими циклическими операциями записи, и выполняете fsync, то это не такой уж последовательный паттерн доступа, он находится ближе к произвольному вводу-выводу. То есть если вы только дополняете логи, это не означает автоматически, что вы получаете последовательный ввод-вывод.


Читать: https://habr.com/ru/companies/ruvds/articles/737284/

Мир. Труд. Майпу. Или как мы тестировали китайскую СХД

Чем заменить на санкционном безрыбье системы хранения данных Dell, HPE, Huawei и других покинувших нас вендоров? Мы уже долго изучаем этот вопрос и протестировали большинство доступных альтернатив enterprise-уровня.

И что думаете? Кажется, нашли приемлемое решение — СХД китайского вендора Maipu с привычными функциями, перспективными возможностями и не только. Мы привезли его в лабораторию и первыми на российском рынке протестировали — срочно делимся впечатлениями и результатами.


Читать: https://habr.com/ru/companies/k2tech/articles/737564/

Когда данных слишком много… как оптимизировать хранение

Каждый день человечество генерирует порядка 330 млн терабайт данных. Хотя по оценкам экспертов Google всего 10% из них являются свежими и оригинальными, даже копии копий нужно где-то хранить. И эта задача имеет ряд нюансов. Здесь уместно провести аналогию с известным транспортным парадоксом: чем больше дорог строится, тем больше образуется автомобилей, чтобы заполнить их (постулат Льюиса — Могриджа).

Недостаточно построить очень много дата-центров. Один из наиболее очевидных способов сэкономить на хранении данных — это архивирование файлов и сжатие изображений. Есть и другие подходы, которые помогают записать больше данных на диск и быстрее их обрабатывать.



Читать: https://habr.com/ru/companies/cloud_mts/articles/737514/

Чей DAX сильнее? …или почему каждый пользователь должен влиять на развитие платформы

Привет, Хабр! В этом посте мне хотелось бы поговорить о том, каким образом мы развиваем платформу, и откуда появляются новые функции в Visiology. В большей степени сейчас это касается развития поддержки DAX в третьей версии платформы. Но сама практика появилась не на пустом месте, и сегодня мы как раз обсудим, как команда разработчиков выбирает, какие новые фичи стоит включить в Visiology, зачем мы запустили сбор кейсов для реализации на DAXе, и что можно увидеть на вебинарах Visiology, которые посвящены развитию аналитического движка в Visiology 3.


Читать: https://habr.com/ru/companies/visiology/articles/738456/

Kafka за 20 минут. Ментальная модель и как с ней работать

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.


Читать: https://habr.com/ru/companies/sbermarket/articles/738634/

Obsidian — Мой сетап

Вот я и дописал свою четвёртую статью на хабр (А ведь в начале года поставил себе цель написать хотя бы одну статью, а тут аппетит пришёл во время еды и вот четвёртая). Предыдущие раз, два и три.

Вообще бесит когда в современном мире пишут статьи-гайды или снимают видео-гайды, где самое интересное в конце. "Вы сначала дайте посмотреть что я приобрету прочитав вашу статью или посмотрев видео, а я уже приму решение смотреть или нет".

Поэтому вот сразу ссылка на мой сетап хранилища Обсидиана на гитхабе (о котором и пойдёт речь в данной статье), можно сразу его качать и тыкаться самому и если что-то не понятно подглядывать в статью. (Надо распаковать zip-файл в папку, а потом открыть открыть обсидиан и при выборе хранилища выбрать эту папку, куда распаковали zip-файл. Если у вас одно хранилище, то тогда жмём в левом нижнем углу кнопку сейфа)

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

В этом хранилище используются 10 плагинов, основные:

- Calendar - для календаря справа.

- Dataview - для статистики и для проектов.

- Tasks - для задач.

- Templater - для шаблонов и чтобы нужные заметки с запросами создавались в нужных папках и с нужными данными в запросах.

К такой настройке я шёл целый год используя обсидиан, постоянно дорабатывал её и искал "совершенство", в ней собраны разные подходы из разных статьей и книг (GTD, 7 навыков, Джедайские техники, Атомные привычки), данные подходы большинству могут быть знакомы. Но есть метод, до которого я дошёл сам и до этого я нигде его не встречал (возможно просто не попадался) - это метод одной задачи.

Disclaimer1: Мой сетап не претендует на "идеальность", в нём найдутся минусы и неудобности. Я выношу его на общее обсуждение в том числе для того, чтобы кто-то мог предложить ту или иную доработку тут в комментариях, а так же для того, чтобы новички могли сходу вкатиться в этот чудесный обсидиановый мир.
Disclaimer2: Обычно обсидиан ассоциируют с Zettelkasten, графами и прочими атомарными заметками. Я в своём подходе этого не использую, возможно еще не дорос, возможно мой подход немного про другое. В этой статье я пишу не про это.
Погнали вкатываться в обсидиановый мир

Читать: https://habr.com/ru/articles/735858/

Внутреннее устройство DRBD: алгоритмы работы отказоустойчивого хранилища

Глубокое понимание внутреннего устройства DRBD позволяет более тонко настраивать работу системы и правильно планировать ресурсы. К счастью, у команды DRBD уже есть отличная документация, которая довольно подробно разбирает эту тему. Мы опирались на нее в своей работе, и решили перевести и выложить в открытом доступе 17-ю главу — как удобную шпаргалку по внутреннему устройству DRBD. Так что это не обычная статья, а перевод части официальной документации (исходная нумерация разделов сохранена).
В этой главе представлена информация о внутренних алгоритмах и структурах DRBD. Она довольно подробно рассматривает внутреннюю работу DRBD, но делает это не настолько глубоко, чтобы служить справочником для разработчиков. Для этой цели рекомендуем обратиться к материалам, перечисленным в разделе Publications, и, естественно, к комментариям в исходном коде DRBD.


Читать: https://habr.com/ru/companies/flant/articles/733770/