Newbie Guide: разбираемся с MVCC на простых примерах
Изоляция транзакций в СУБД — важный механизм, который позволяет пользователю получить согласованное состояние данных и работать с ними, не допуская конфликтов и снижения производительности. Организовать изоляцию нужного уровня можно несколькими способами, один из которых — MVCC (Multiversion Concurrency Control, многоверсионное управление конкурентным доступом).
Читать: https://habr.com/ru/companies/vk/articles/740108/
Изоляция транзакций в СУБД — важный механизм, который позволяет пользователю получить согласованное состояние данных и работать с ними, не допуская конфликтов и снижения производительности. Организовать изоляцию нужного уровня можно несколькими способами, один из которых — MVCC (Multiversion Concurrency Control, многоверсионное управление конкурентным доступом).
Читать: https://habr.com/ru/companies/vk/articles/740108/
От флешек к ДНК: разбираемся в новой технологии хранения данных
В ближайшие три года общее количество цифровых данных увеличится в три раза и достигнет 175 миллиардов терабайт. Надежно сохранить такое количество информации на жестких дисках и магнитных лентах будет практически невозможно, строительство дата-центров тоже не спасет ситуацию, поэтому ученые сейчас активно работают над технологией хранения данных в ДНК.
В этой статье мы расскажем, что из себя представляют ДНК-накопители, в чем их преимущества и недостатки, и по шагам разберем, как информацию сохранять в молекуле и извлекать из нее.
Читать: https://habr.com/ru/companies/itglobalcom/articles/743248/
В ближайшие три года общее количество цифровых данных увеличится в три раза и достигнет 175 миллиардов терабайт. Надежно сохранить такое количество информации на жестких дисках и магнитных лентах будет практически невозможно, строительство дата-центров тоже не спасет ситуацию, поэтому ученые сейчас активно работают над технологией хранения данных в ДНК.
В этой статье мы расскажем, что из себя представляют ДНК-накопители, в чем их преимущества и недостатки, и по шагам разберем, как информацию сохранять в молекуле и извлекать из нее.
Читать: https://habr.com/ru/companies/itglobalcom/articles/743248/
Кто мощнее в базах данных? Сравниваем производительность БД на серверах с ARM- и x86-процессорами
Всем привет! Ранее я разобрал и протестировал сервер с процессором ARM, который попал к нам в Selectel Lab. Сервер показал хорошие результаты по производительности в ряде классических тестов, но в этот раз захотелось проверить его в боевой задаче — в работе с базами данных. Быть может, архитектура ARM-процессора сделает всех конкурентов на этой территории?
Чтобы ответить на этот вопрос, протестировал ARM вместе с семеркой серверов разных конфигураций с процессорами Intel и AMD. В качестве баз данных для нашего эксперимента выбрал самые популярные — PostgreSQL и MySQL. Результаты тестов с графиками и комментариями — под катом. Надеюсь, они будут полезны вам при выборе сервера под БД.
Читать: https://habr.com/ru/companies/selectel/articles/740492/
Всем привет! Ранее я разобрал и протестировал сервер с процессором ARM, который попал к нам в Selectel Lab. Сервер показал хорошие результаты по производительности в ряде классических тестов, но в этот раз захотелось проверить его в боевой задаче — в работе с базами данных. Быть может, архитектура ARM-процессора сделает всех конкурентов на этой территории?
Чтобы ответить на этот вопрос, протестировал ARM вместе с семеркой серверов разных конфигураций с процессорами Intel и AMD. В качестве баз данных для нашего эксперимента выбрал самые популярные — PostgreSQL и MySQL. Результаты тестов с графиками и комментариями — под катом. Надеюсь, они будут полезны вам при выборе сервера под БД.
Читать: https://habr.com/ru/companies/selectel/articles/740492/
Есть 14 языков для хранения данных… Или как появился IEML
Велась как-то работа на одним движком для создания GUI, некоторого подобия Qt. Выделялся он тем, что конечный пользователь мог этот интерфейс кастомизировать с помощью конфига до самых мелочей.
Изначально в качества такого конфига был взят YAML, звучало разумно, простой для обывателя формат, справится, если не бабушка, то хотя бы слегка прошаренный геймер.
В процессе интеграции обнаружилось, что нам этого формата не хватает, да и некоторые другие его минусы стали проявляться. В итоге было решено создать свой формат.
Читать: https://habr.com/ru/articles/745682/
Велась как-то работа на одним движком для создания GUI, некоторого подобия Qt. Выделялся он тем, что конечный пользователь мог этот интерфейс кастомизировать с помощью конфига до самых мелочей.
Изначально в качества такого конфига был взят YAML, звучало разумно, простой для обывателя формат, справится, если не бабушка, то хотя бы слегка прошаренный геймер.
В процессе интеграции обнаружилось, что нам этого формата не хватает, да и некоторые другие его минусы стали проявляться. В итоге было решено создать свой формат.
Читать: https://habr.com/ru/articles/745682/
Сравнение производительности YDB, CockroachDB и YugabyteDB на бенчмарке YCSB
Привет! Меня зовут Евгений Иванов, я разработчик YDB. Мне очень нравится заниматься задачами, связанными с производительностью: бенчить, анализировать, оптимизировать. И в YDB мы придаем очень большое значения тому, чтобы быть эффективными. В этом посте я хочу представить Вашему вниманию перевод нашей свежей статьи "YCSB performance series: YDB, CockroachDB, and YugabyteDB".
Реализовать распределённую систему управления базами данных (СУБД), высокопроизводительную, масштабируемую и консистентную, — настоящий вызов. В YDB успешно с ним справились, и наши пользователи могут это подтвердить. Мы ещё не делились показателями нашей производительности на широкую аудиторию, но понимаем их значимость. Поэтому сегодня мы расскажем о результатах нашего исследования производительности.
YDB — это распределённая реляционная СУБД. Производительность распределённых транзакций в TPC-C и других сложных бенчмарках во многом зависит от реализации хранения данных по ключу. В этом посте посте мы сравним результаты тестов YCSB для YDB и двух других известных распределённых SQL-баз данных — CockroachDB и YugabyteDB. Спойлер: YDB превзойдёт конкурентов по многим нагрузкам YCSB.
Читать: https://habr.com/ru/companies/ydb/articles/740560/
Привет! Меня зовут Евгений Иванов, я разработчик YDB. Мне очень нравится заниматься задачами, связанными с производительностью: бенчить, анализировать, оптимизировать. И в YDB мы придаем очень большое значения тому, чтобы быть эффективными. В этом посте я хочу представить Вашему вниманию перевод нашей свежей статьи "YCSB performance series: YDB, CockroachDB, and YugabyteDB".
Реализовать распределённую систему управления базами данных (СУБД), высокопроизводительную, масштабируемую и консистентную, — настоящий вызов. В YDB успешно с ним справились, и наши пользователи могут это подтвердить. Мы ещё не делились показателями нашей производительности на широкую аудиторию, но понимаем их значимость. Поэтому сегодня мы расскажем о результатах нашего исследования производительности.
YDB — это распределённая реляционная СУБД. Производительность распределённых транзакций в TPC-C и других сложных бенчмарках во многом зависит от реализации хранения данных по ключу. В этом посте посте мы сравним результаты тестов YCSB для YDB и двух других известных распределённых SQL-баз данных — CockroachDB и YugabyteDB. Спойлер: YDB превзойдёт конкурентов по многим нагрузкам YCSB.
Читать: https://habr.com/ru/companies/ydb/articles/740560/
Как предложить рынку ИТ-продукт, если пользователи еще не знают, что он им нужен
Как показал небольшой ресерч, на Хабре представлено немало материалов об управлении развитием продукта. Много теории посвящено тому, как вывести свой проект на рынок, правильно позиционировать его и найти аудиторию. Но, как вы понимаете, когда дело доходит до практики, возникает целый ряд интересных нюансов. В этом посте в блоге ЛАНИТ я поделюсь своим опытом вывода на рынок продукта, для которого раньше не было ниши. Уверен, история создания нашего продукта с нуля окажется полезной тем, кто задумывается о продвижении своего собственного решения.
Читать: https://habr.com/ru/companies/lanit/articles/744696/
Как показал небольшой ресерч, на Хабре представлено немало материалов об управлении развитием продукта. Много теории посвящено тому, как вывести свой проект на рынок, правильно позиционировать его и найти аудиторию. Но, как вы понимаете, когда дело доходит до практики, возникает целый ряд интересных нюансов. В этом посте в блоге ЛАНИТ я поделюсь своим опытом вывода на рынок продукта, для которого раньше не было ниши. Уверен, история создания нашего продукта с нуля окажется полезной тем, кто задумывается о продвижении своего собственного решения.
Читать: https://habr.com/ru/companies/lanit/articles/744696/
Из SQL в NoSQL: меняем парадигму запросов
Пользовательский опыт напрямую зависит от скорости выполнения запросов к данным. Мы привыкли, что SQL базы данных строят оптимальный план запроса за нас. В случае многих NoSQL баз данных, оптимизация запроса ложится на разработчика. Меня зовут Жора и вместе с @yngvar_antonsson мы провели много времени за аудитом запросов у наших заказчиков. Сегодня мы расскажем про перфоманс, оптимизации и про тяжелые запросы на примере Tarantool. Будет интересно всем, кто уже работает или только собирается работать с Tarantool, а также тем, кто строит кластерные системы поверх своих БД.
Читать: https://habr.com/ru/companies/vk/articles/739540/
Пользовательский опыт напрямую зависит от скорости выполнения запросов к данным. Мы привыкли, что SQL базы данных строят оптимальный план запроса за нас. В случае многих NoSQL баз данных, оптимизация запроса ложится на разработчика. Меня зовут Жора и вместе с @yngvar_antonsson мы провели много времени за аудитом запросов у наших заказчиков. Сегодня мы расскажем про перфоманс, оптимизации и про тяжелые запросы на примере Tarantool. Будет интересно всем, кто уже работает или только собирается работать с Tarantool, а также тем, кто строит кластерные системы поверх своих БД.
Читать: https://habr.com/ru/companies/vk/articles/739540/
Без Tableau — как в МКБ выбирали новое BI-решение для работы
Меня зовут Александр Дорофеев, я директор по данным в МКБ. В этом посте я еще раз затрону тему импортозамещения софта на примере программ для визуализации данных. Раньше мы (думаю, как и многие из вас) использовали Tableau, но так как компания покинула российский рынок, мы вынуждены были выбрать новое решение.
О том, какие у нас были критерии выбора и что же мы в итоге выбрали — под катом. Возможно, вам пригодится наш опыт, если вы тоже стоит перед выбором нового BI‑софта.
Читать: https://habr.com/ru/companies/mkb/articles/745740/
Меня зовут Александр Дорофеев, я директор по данным в МКБ. В этом посте я еще раз затрону тему импортозамещения софта на примере программ для визуализации данных. Раньше мы (думаю, как и многие из вас) использовали Tableau, но так как компания покинула российский рынок, мы вынуждены были выбрать новое решение.
О том, какие у нас были критерии выбора и что же мы в итоге выбрали — под катом. Возможно, вам пригодится наш опыт, если вы тоже стоит перед выбором нового BI‑софта.
Читать: https://habr.com/ru/companies/mkb/articles/745740/
Балансируем между консистентностью и доступностью в распределённой системе: опыт Tarantool
Поговорим сегодня про выбор, перед которым встают разработчики всех распределённых систем: обеспечивать ли консистентность данных или доступность системы при различных внешних условиях — поломках, плановых отключениях узлов, — а также во время штатной эксплуатации. Теория нам даёт простые, но не всегда применимые на практике ответы: можно выбрать либо консистентность, либо доступность (теорема CAP), а когда проблем с сетью нет — то либо консистентность, либо низкие задержки (PACELC). За скобками остаётся вопрос о том, как делать этот выбор. Система как будто всегда должна быть CP или AP, а что происходит, если вдруг работающая CP-система должна начать вести себя как AP, или, наоборот, перейти обратно из AP в CP?
Читать: https://habr.com/ru/companies/vk/articles/738616/
Поговорим сегодня про выбор, перед которым встают разработчики всех распределённых систем: обеспечивать ли консистентность данных или доступность системы при различных внешних условиях — поломках, плановых отключениях узлов, — а также во время штатной эксплуатации. Теория нам даёт простые, но не всегда применимые на практике ответы: можно выбрать либо консистентность, либо доступность (теорема CAP), а когда проблем с сетью нет — то либо консистентность, либо низкие задержки (PACELC). За скобками остаётся вопрос о том, как делать этот выбор. Система как будто всегда должна быть CP или AP, а что происходит, если вдруг работающая CP-система должна начать вести себя как AP, или, наоборот, перейти обратно из AP в CP?
Читать: https://habr.com/ru/companies/vk/articles/738616/
Как эффективно настроить autovacuum в Postgres для 1С
Кто не любит убирать мусор? Думаю практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.
Навести порядок
Читать: https://habr.com/ru/articles/741566/
Кто не любит убирать мусор? Думаю практически все, а вот в Postgres это обязательный ритуал для эффективной работы. Как эффективно настроить уборку за 1С в Postgres можно прочитать в этой статье и еще раз задуматься о бесплатности Postgres.
Навести порядок
Читать: https://habr.com/ru/articles/741566/
Внедрение системы резервного копирования пользовательских данных в закрытый контур заказчика
В этой статье я расскажу, как мы выбирали и внедряли средства резервного копирования и восстановления пользовательских данных для закрытого контура заказчика в условиях ограниченности ресурсов, а также познакомлю с частью системного архитектурного стека нашего продукта.
Читать: https://habr.com/ru/companies/bimeister/articles/745792/
В этой статье я расскажу, как мы выбирали и внедряли средства резервного копирования и восстановления пользовательских данных для закрытого контура заказчика в условиях ограниченности ресурсов, а также познакомлю с частью системного архитектурного стека нашего продукта.
Читать: https://habr.com/ru/companies/bimeister/articles/745792/
Почему мы не торопимся применять новые технологии
В комментариях к постам про разбор аварии (тут и тут) было развёрнутое обсуждение про новые технологии в ИБП, которые можно внедрить. Коротко — мы не будем внедрять ничего ультрасверхсовременного. Потому что лучшая версия для знакомства с софтом — это 2.4. В случае MS ещё хорошо, когда за цифрами написано что-то вроде SP2. Потому что если пробовать на себе все новые технологии, то это, конечно, дико интересно и прогрессивно, но мешает бизнесу. У нас дефицит свободного времени и рук. Вот, собственно, несколько прикладных историй, почему мы не торопимся нырять в новые технологии.
Пример с новым железом, на котором может строиться вся инфраструктура, думаю, знаком всем, поэтому начну не с него, а с холивара про IPv6 против IPv4.
Протокол v6 невероятно хорош. Его писали думающие люди, он снимает море проблем интернета, он реально крут. Адреса IPv6 практически бесплатные. Они не кончаются. В свою очередь, IPv4 стоят совершенно неприличных уже денег (это вторая статья в себестоимости виртуальной машины после железа), постоянно дорожают — и, что гораздо хуже, не всегда можно взять в аренду нужное их количество. Бывает, что к нам заезжает крупный клиент, мы хотим арендовать ещё 256 адресов v4 — и блок освобождается не через 15 минут, а через несколько дней. То есть нам надо постоянно ковыряться с тем, чтобы они были.
Но при этом IPv6 ещё хуже с точки зрения реального применения. Вообще, я лично не совсем понимаю, кому сейчас он нужен. Многие наши коллеги, кто пользуется, говорят просто: «В РФ v6 нет и не будет в ближайшее время, наверное». А специалисты по ИБ ещё категоричнее: «Я его просто отрубаю от греха подальше».
Читать: https://habr.com/ru/companies/ruvds/articles/744958/
В комментариях к постам про разбор аварии (тут и тут) было развёрнутое обсуждение про новые технологии в ИБП, которые можно внедрить. Коротко — мы не будем внедрять ничего ультрасверхсовременного. Потому что лучшая версия для знакомства с софтом — это 2.4. В случае MS ещё хорошо, когда за цифрами написано что-то вроде SP2. Потому что если пробовать на себе все новые технологии, то это, конечно, дико интересно и прогрессивно, но мешает бизнесу. У нас дефицит свободного времени и рук. Вот, собственно, несколько прикладных историй, почему мы не торопимся нырять в новые технологии.
Пример с новым железом, на котором может строиться вся инфраструктура, думаю, знаком всем, поэтому начну не с него, а с холивара про IPv6 против IPv4.
Протокол v6 невероятно хорош. Его писали думающие люди, он снимает море проблем интернета, он реально крут. Адреса IPv6 практически бесплатные. Они не кончаются. В свою очередь, IPv4 стоят совершенно неприличных уже денег (это вторая статья в себестоимости виртуальной машины после железа), постоянно дорожают — и, что гораздо хуже, не всегда можно взять в аренду нужное их количество. Бывает, что к нам заезжает крупный клиент, мы хотим арендовать ещё 256 адресов v4 — и блок освобождается не через 15 минут, а через несколько дней. То есть нам надо постоянно ковыряться с тем, чтобы они были.
Но при этом IPv6 ещё хуже с точки зрения реального применения. Вообще, я лично не совсем понимаю, кому сейчас он нужен. Многие наши коллеги, кто пользуется, говорят просто: «В РФ v6 нет и не будет в ближайшее время, наверное». А специалисты по ИБ ещё категоричнее: «Я его просто отрубаю от греха подальше».
Читать: https://habr.com/ru/companies/ruvds/articles/744958/
Альтернатива есть! Обзор 6 российских СУБД для миграции
Привет, Хабр! Сегодня хочу коснуться наболевшей для многих российских компаний темы — замена зарубежного софта на доступное альтернативное. Так как я специализируюсь на системном ПО, все чаще я сталкиваюсь с подобными запросами по части СУБД.
Эта статья — мой обзор 6 СУБД из реестра отечественного ПО, которые можно использовать вместо MS SQL, Oracle и других. Каждую из них мы с командой К2Тех устанавливали и настраивали ручками. И в итоге убедились, что все они представляют собой действительно качественные продукты, на которых можно работать с большими объемами данных. Итак, представляем вам альтернативную «шестерку» СУБД под катом!
Будь как дома, путник!
Читать: https://habr.com/ru/companies/k2tech/articles/741980/
Привет, Хабр! Сегодня хочу коснуться наболевшей для многих российских компаний темы — замена зарубежного софта на доступное альтернативное. Так как я специализируюсь на системном ПО, все чаще я сталкиваюсь с подобными запросами по части СУБД.
Эта статья — мой обзор 6 СУБД из реестра отечественного ПО, которые можно использовать вместо MS SQL, Oracle и других. Каждую из них мы с командой К2Тех устанавливали и настраивали ручками. И в итоге убедились, что все они представляют собой действительно качественные продукты, на которых можно работать с большими объемами данных. Итак, представляем вам альтернативную «шестерку» СУБД под катом!
Будь как дома, путник!
Читать: https://habr.com/ru/companies/k2tech/articles/741980/
Мониторинг — это боль
И все мы выполняем его неправильно (в том числе и я).
Я должен признаться. Несмотря на то, что меня много раз нанимали в том числе и благодаря моему опыту работы с платформами мониторинга, я начал его ненавидеть. Инструменты мониторинга и наблюдаемости (observability) совершают тяжкий грех: обманом заставляют людей думать, что это простая задача. Очень легко мониторить маленькое приложение или сервис. Но почти ни одно из таких решений не масштабируется.
Вместо этого мониторинг превращается в бесконечную последовательность маленьких неудач. Метрики на какое-то время исчезают, логи перестают записываться на несколько часов, веб-UI для трассировок больше не работает. Мы настраиваем эти инструменты, готовясь, что сможем о них после этого забыть, но на самом деле они требуют постоянно растущих усилий по обслуживанию. Некоторые инструменты ломаются, и их больше никто не чинит. Я слишком часто приходил в новую компанию и видел, что в ней развёрнут нелюбимый мной поломанный Jaeger.
Такое ощущение, что сейчас как никогда много инструментов мониторинга, но вперёд мы не движемся. Похоже, вместо развития упор делается на увеличение объёма выходных данных приложений для роста доходов компаний, занимающихся мониторингом. Кажется, практически никакого прогресса не происходит с принципом передачи меньшего количества логов и метрик от клиента. Я создаю всё более сложные стеки для записи огромных объёмов данных, чтобы использовать их всё меньше и меньше.
В статье я расскажу о том, что, по моему мнению, нужно делать, а также поделюсь своими надеждами и мечтами. Прошу вас убедить меня, что я не прав и что есть более качественные решения.
Читать: https://habr.com/ru/companies/ruvds/articles/746086/
И все мы выполняем его неправильно (в том числе и я).
Я должен признаться. Несмотря на то, что меня много раз нанимали в том числе и благодаря моему опыту работы с платформами мониторинга, я начал его ненавидеть. Инструменты мониторинга и наблюдаемости (observability) совершают тяжкий грех: обманом заставляют людей думать, что это простая задача. Очень легко мониторить маленькое приложение или сервис. Но почти ни одно из таких решений не масштабируется.
Вместо этого мониторинг превращается в бесконечную последовательность маленьких неудач. Метрики на какое-то время исчезают, логи перестают записываться на несколько часов, веб-UI для трассировок больше не работает. Мы настраиваем эти инструменты, готовясь, что сможем о них после этого забыть, но на самом деле они требуют постоянно растущих усилий по обслуживанию. Некоторые инструменты ломаются, и их больше никто не чинит. Я слишком часто приходил в новую компанию и видел, что в ней развёрнут нелюбимый мной поломанный Jaeger.
Такое ощущение, что сейчас как никогда много инструментов мониторинга, но вперёд мы не движемся. Похоже, вместо развития упор делается на увеличение объёма выходных данных приложений для роста доходов компаний, занимающихся мониторингом. Кажется, практически никакого прогресса не происходит с принципом передачи меньшего количества логов и метрик от клиента. Я создаю всё более сложные стеки для записи огромных объёмов данных, чтобы использовать их всё меньше и меньше.
В статье я расскажу о том, что, по моему мнению, нужно делать, а также поделюсь своими надеждами и мечтами. Прошу вас убедить меня, что я не прав и что есть более качественные решения.
Читать: https://habr.com/ru/companies/ruvds/articles/746086/
Picodata: простое масштабирование Tarantool
Привет! Сегодня я хочу познакомить вас с ПО, которое мы разрабатываем в нашей компанией — кластерной СУБД и сервером приложений на языке Rust. Мы профессионально занимаемся созданием и эксплуатацией решений на основе Tarantool и с некоторых пор начали разработку своего ПО, о котором и пойдёт речь.
Picodata — это дальнейшее развитие истории Tarantool, в которой учтен опыт эксплуатации этой СУБД и предложены решения как архитектурных, так и функциональных недостатков открытой версии Tarantool. Также, наше ПО проще запускать, настраивать и поддерживать в рабочем состоянии благодаря единой точке входа и интеграции всего инструментария в одном исполняемом файле. Мы создавали Picodata как изначально кластерную СУБД, которой удобно пользоваться. Если не верите, что российская СУБД может быть удобной, попробуйте — в конце этой статьи есть раздел Практикум, где можно сразу же попробовать собрать кластер самому на паре-тройке виртуальных машин или на вашем локальном компьютере. Сейчас же будет немного теории о том, как вообще работает распределенный кластер, что именно не так в “ванильном” Tarantool и что нам пришлось сделать чтобы это исправить.
Погрузиться в детали
Читать: https://habr.com/ru/articles/742244/
Привет! Сегодня я хочу познакомить вас с ПО, которое мы разрабатываем в нашей компанией — кластерной СУБД и сервером приложений на языке Rust. Мы профессионально занимаемся созданием и эксплуатацией решений на основе Tarantool и с некоторых пор начали разработку своего ПО, о котором и пойдёт речь.
Picodata — это дальнейшее развитие истории Tarantool, в которой учтен опыт эксплуатации этой СУБД и предложены решения как архитектурных, так и функциональных недостатков открытой версии Tarantool. Также, наше ПО проще запускать, настраивать и поддерживать в рабочем состоянии благодаря единой точке входа и интеграции всего инструментария в одном исполняемом файле. Мы создавали Picodata как изначально кластерную СУБД, которой удобно пользоваться. Если не верите, что российская СУБД может быть удобной, попробуйте — в конце этой статьи есть раздел Практикум, где можно сразу же попробовать собрать кластер самому на паре-тройке виртуальных машин или на вашем локальном компьютере. Сейчас же будет немного теории о том, как вообще работает распределенный кластер, что именно не так в “ванильном” Tarantool и что нам пришлось сделать чтобы это исправить.
Погрузиться в детали
Читать: https://habr.com/ru/articles/742244/
Нативный способ шифрования данных в Helm
Привет, Хабр! Меня зовут Миняйлов Лев, я старший разработчик и DevOps-инженер Группы "Иннотех".
Хочу поделиться решением задачи шифрования чувствительных данных в Helm, использующим встроенные функции encryptAES/decryptAES.
Читать: https://habr.com/ru/companies/innotech/articles/746132/
Привет, Хабр! Меня зовут Миняйлов Лев, я старший разработчик и DevOps-инженер Группы "Иннотех".
Хочу поделиться решением задачи шифрования чувствительных данных в Helm, использующим встроенные функции encryptAES/decryptAES.
Читать: https://habr.com/ru/companies/innotech/articles/746132/
Кто управляет информацией — тот владеет миром: как сделать так, чтобы данные генерировали прибыль, а не убытки?
У всех компаний есть разнообразные данные: о клиентах, транзакциях, закупках, оборудовании, доходах и расходах. Но для одних компаний данные – драйвер роста, а другие несут убытки, полагаясь на них. Разница в том, что первые управляют информацией: знают, как и в какой форме она поступает, как ее внести в корпоративные системы, обогатить, и главное - как использовать, а вторые пускают эту работу на самотек и живут в зоопарке информационных систем без единой версии правды.
Это обзорный материал, я расскажу в нем об объектах основных данных, о том, по каким причинам часто возникают ошибки, какими инструментами улучшить качество данных и рассмотрю шаги конкретного проекта по внедрению НСИ.
Читать: https://habr.com/ru/articles/742910/
У всех компаний есть разнообразные данные: о клиентах, транзакциях, закупках, оборудовании, доходах и расходах. Но для одних компаний данные – драйвер роста, а другие несут убытки, полагаясь на них. Разница в том, что первые управляют информацией: знают, как и в какой форме она поступает, как ее внести в корпоративные системы, обогатить, и главное - как использовать, а вторые пускают эту работу на самотек и живут в зоопарке информационных систем без единой версии правды.
Это обзорный материал, я расскажу в нем об объектах основных данных, о том, по каким причинам часто возникают ошибки, какими инструментами улучшить качество данных и рассмотрю шаги конкретного проекта по внедрению НСИ.
Читать: https://habr.com/ru/articles/742910/
Японский SSD (sardine state disk)
В декабре 2018 японский студент-химик с ником ni28_xp опубликовал фотографию USB-накопителя, сделанной из анчоуса. Звучит максимально странно даже для Японии, не так ли?
Читать: https://habr.com/ru/companies/cloud4y/articles/746514/
В декабре 2018 японский студент-химик с ником ni28_xp опубликовал фотографию USB-накопителя, сделанной из анчоуса. Звучит максимально странно даже для Японии, не так ли?
Читать: https://habr.com/ru/companies/cloud4y/articles/746514/
Как сэкономить свои нервы и деньги компании на перестроении структуры больших таблиц без простоя в PostgreSQL
Привет! Меня зовут Васильев Виктор, я DBA в компании UIS и CoMagic. В этой статье на реальных примерах расскажу, как можно сэкономить время разработчика, администратора баз данных и ресурсы сервера(ов), используя утилиту pg_rebuild_table. Сопровождая большие, высоконагруженные системы, с бо’льшей вероятностью каждый сталкивался с кейсами, о которых будет рассказано дальше. Некоторые технические подробности пройду без детализации, чтобы сильно не усложнять и не делать статью очень громоздкой. Лучше отвечу на вопросы в комментариях.
Читать: https://habr.com/ru/articles/743438/
Привет! Меня зовут Васильев Виктор, я DBA в компании UIS и CoMagic. В этой статье на реальных примерах расскажу, как можно сэкономить время разработчика, администратора баз данных и ресурсы сервера(ов), используя утилиту pg_rebuild_table. Сопровождая большие, высоконагруженные системы, с бо’льшей вероятностью каждый сталкивался с кейсами, о которых будет рассказано дальше. Некоторые технические подробности пройду без детализации, чтобы сильно не усложнять и не делать статью очень громоздкой. Лучше отвечу на вопросы в комментариях.
Читать: https://habr.com/ru/articles/743438/
BI по-русски: что умеют BI-решения, доступные отечественному бизнесу
Мы в beeline cloud постоянно изучаем тренды рынка BI: как он меняется с развитием ИИ и ростом спроса на отечественный софт. А сегодня хотим рассказать о том, кто и зачем использует системы бизнес-аналитики, а также посмотреть на возможности ключевых игроков, представленных в России.
Читать: https://habr.com/ru/companies/beeline_cloud/articles/746720/
Мы в beeline cloud постоянно изучаем тренды рынка BI: как он меняется с развитием ИИ и ростом спроса на отечественный софт. А сегодня хотим рассказать о том, кто и зачем использует системы бизнес-аналитики, а также посмотреть на возможности ключевых игроков, представленных в России.
Читать: https://habr.com/ru/companies/beeline_cloud/articles/746720/
11 лет хостинга SaaS: история и мой опыт
Источник
Нашему ресурсу Tanda скоро исполняется 11 лет. По этому поводу один из моих читателей высказал идею, что было бы классно поразмышлять на тему опыта, который я получил за долгие годы управления этим приложением.
В итоге я просидел над этой статьёй целую вечность, потому что процессы развёртывания, хостинга и управления инфраструктурой в целом на протяжении десяти лет являлись, пожалуй, наиболее трудной и беспокойной частью моей работы. В основном причина в том, что я постоянно окунался в омут с головой и зачастую не понимал, что делал. К сожалению, когда у вас есть активное приложение, которое используют многие люди, вы не всегда находите время на подобающее изучение матчасти.
Изложенная в этой статье история разбита на несколько этапов, через которые мы прошли. Я написал её, чтобы те, кто окажется на аналогичном пути, могли миновать некоторые из его острых углов.
Читать: https://habr.com/ru/companies/ruvds/articles/743280/
Источник
Нашему ресурсу Tanda скоро исполняется 11 лет. По этому поводу один из моих читателей высказал идею, что было бы классно поразмышлять на тему опыта, который я получил за долгие годы управления этим приложением.
В итоге я просидел над этой статьёй целую вечность, потому что процессы развёртывания, хостинга и управления инфраструктурой в целом на протяжении десяти лет являлись, пожалуй, наиболее трудной и беспокойной частью моей работы. В основном причина в том, что я постоянно окунался в омут с головой и зачастую не понимал, что делал. К сожалению, когда у вас есть активное приложение, которое используют многие люди, вы не всегда находите время на подобающее изучение матчасти.
Изложенная в этой статье история разбита на несколько этапов, через которые мы прошли. Я написал её, чтобы те, кто окажется на аналогичном пути, могли миновать некоторые из его острых углов.
Читать: https://habr.com/ru/companies/ruvds/articles/743280/