FairCom DB — серый кардинал в мире баз данных
1979 год. СССР запускает свой первый океанографический спутник, французы успешно испытывают первую ракету в семействе Arian, а в недрах лабораторий Министерства обороны США завершают создание языка программирования Ада. В этом же году Уильям Л. Фэйрмэн (William L. Fairman) регистрирует частную компанию FairСom, ставшую пионером в отрасли разработки программного обеспечения.
«Ну и что?» — спросите вы. Какая-то странная компания, о которой даже Wikipedia ничего не знает. Упоминания есть, а отдельной страницы нет. Вроде бы делает базу данных FairСom DB. Кажется, что ничего интересного. Но это только на первый взгляд. А что, если мы вам скажем, что эта база данных обеспечивает работу экстренной службы 911, через неё проходят все планы полётов в воздушном пространстве США, а также записываются все котировки на фондовом рынке в режиме реального времени? Подробности — под катом.
Читать: https://habr.com/ru/companies/ru_mts/articles/745736/
1979 год. СССР запускает свой первый океанографический спутник, французы успешно испытывают первую ракету в семействе Arian, а в недрах лабораторий Министерства обороны США завершают создание языка программирования Ада. В этом же году Уильям Л. Фэйрмэн (William L. Fairman) регистрирует частную компанию FairСom, ставшую пионером в отрасли разработки программного обеспечения.
«Ну и что?» — спросите вы. Какая-то странная компания, о которой даже Wikipedia ничего не знает. Упоминания есть, а отдельной страницы нет. Вроде бы делает базу данных FairСom DB. Кажется, что ничего интересного. Но это только на первый взгляд. А что, если мы вам скажем, что эта база данных обеспечивает работу экстренной службы 911, через неё проходят все планы полётов в воздушном пространстве США, а также записываются все котировки на фондовом рынке в режиме реального времени? Подробности — под катом.
Читать: https://habr.com/ru/companies/ru_mts/articles/745736/
Без Tableau — как в МКБ выбирали новое BI-решение для работы
Меня зовут Александр Дорофеев, я директор по данным в МКБ. В этом посте я еще раз затрону тему импортозамещения софта на примере программ для визуализации данных. Раньше мы (думаю, как и многие из вас) использовали Tableau, но так как компания покинула российский рынок, мы вынуждены были выбрать новое решение.
О том, какие у нас были критерии выбора и что же мы в итоге выбрали — под катом. Возможно, вам пригодится наш опыт, если вы тоже стоит перед выбором нового BI-софта.
Читать: https://habr.com/ru/companies/mkb/articles/745740/
Меня зовут Александр Дорофеев, я директор по данным в МКБ. В этом посте я еще раз затрону тему импортозамещения софта на примере программ для визуализации данных. Раньше мы (думаю, как и многие из вас) использовали Tableau, но так как компания покинула российский рынок, мы вынуждены были выбрать новое решение.
О том, какие у нас были критерии выбора и что же мы в итоге выбрали — под катом. Возможно, вам пригодится наш опыт, если вы тоже стоит перед выбором нового BI-софта.
Читать: https://habr.com/ru/companies/mkb/articles/745740/
Внедрение системы резервного копирования пользовательских данных в закрытый контур заказчика
В этой статье я расскажу, как мы выбирали и внедряли средства резервного копирования и восстановления пользовательских данных для закрытого контура заказчика в условиях ограниченности ресурсов, а также познакомлю с частью системного архитектурного стека нашего продукта.
Читать: 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/
Странная архитектура
Странная архитектура - небольшой рассказ с претензией на юмор как пост-ковидный период разбирал проблемы на новой работе.
Читать: https://habr.com/ru/articles/745914/
Странная архитектура - небольшой рассказ с претензией на юмор как пост-ковидный период разбирал проблемы на новой работе.
Читать: https://habr.com/ru/articles/745914/
Шпаргалка по SQL, которая выручает меня на собесах
Привет, Хабр!
Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.
Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)
Читать: https://habr.com/ru/articles/745948/
Привет, Хабр!
Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.
Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)
Читать: https://habr.com/ru/articles/745948/
Мониторинг — это боль
И все мы выполняем его неправильно (в том числе и я).
Я должен признаться. Несмотря на то, что меня много раз нанимали в том числе и благодаря моему опыту работы с платформами мониторинга, я начал его ненавидеть. Инструменты мониторинга и наблюдаемости (observability) совершают тяжкий грех: обманом заставляют людей думать, что это простая задача. Очень легко мониторить маленькое приложение или сервис. Но почти ни одно из таких решений не масштабируется.
Вместо этого мониторинг превращается в бесконечную последовательность маленьких неудач. Метрики на какое-то время исчезают, логи перестают записываться на несколько часов, веб-UI для трассировок больше не работает. Мы настраиваем эти инструменты, готовясь, что сможем о них после этого забыть, но на самом деле они требуют постоянно растущих усилий по обслуживанию. Некоторые инструменты ломаются, и их больше никто не чинит. Я слишком часто приходил в новую компанию и видел, что в ней развёрнут нелюбимый мной поломанный Jaeger.
Такое ощущение, что сейчас как никогда много инструментов мониторинга, но вперёд мы не движемся. Похоже, вместо развития упор делается на увеличение объёма выходных данных приложений для роста доходов компаний, занимающихся мониторингом. Кажется, практически никакого прогресса не происходит с принципом передачи меньшего количества логов и метрик от клиента. Я создаю всё более сложные стеки для записи огромных объёмов данных, чтобы использовать их всё меньше и меньше.
В статье я расскажу о том, что, по моему мнению, нужно делать, а также поделюсь своими надеждами и мечтами. Прошу вас убедить меня, что я не прав и что есть более качественные решения.
Читать: https://habr.com/ru/companies/ruvds/articles/746086/
И все мы выполняем его неправильно (в том числе и я).
Я должен признаться. Несмотря на то, что меня много раз нанимали в том числе и благодаря моему опыту работы с платформами мониторинга, я начал его ненавидеть. Инструменты мониторинга и наблюдаемости (observability) совершают тяжкий грех: обманом заставляют людей думать, что это простая задача. Очень легко мониторить маленькое приложение или сервис. Но почти ни одно из таких решений не масштабируется.
Вместо этого мониторинг превращается в бесконечную последовательность маленьких неудач. Метрики на какое-то время исчезают, логи перестают записываться на несколько часов, веб-UI для трассировок больше не работает. Мы настраиваем эти инструменты, готовясь, что сможем о них после этого забыть, но на самом деле они требуют постоянно растущих усилий по обслуживанию. Некоторые инструменты ломаются, и их больше никто не чинит. Я слишком часто приходил в новую компанию и видел, что в ней развёрнут нелюбимый мной поломанный Jaeger.
Такое ощущение, что сейчас как никогда много инструментов мониторинга, но вперёд мы не движемся. Похоже, вместо развития упор делается на увеличение объёма выходных данных приложений для роста доходов компаний, занимающихся мониторингом. Кажется, практически никакого прогресса не происходит с принципом передачи меньшего количества логов и метрик от клиента. Я создаю всё более сложные стеки для записи огромных объёмов данных, чтобы использовать их всё меньше и меньше.
В статье я расскажу о том, что, по моему мнению, нужно делать, а также поделюсь своими надеждами и мечтами. Прошу вас убедить меня, что я не прав и что есть более качественные решения.
Читать: https://habr.com/ru/companies/ruvds/articles/746086/
PyMongoArrow Now Generally Available
Read: https://www.mongodb.com/blog/post/pymongoarrow-now-generally-available
Read: https://www.mongodb.com/blog/post/pymongoarrow-now-generally-available
Нативный способ шифрования данных в 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/
Oracle Sharding: Enterprise-Grade Distributed Database
Oracle Sharding distributes segments of a data set across many databases (shards) on different computers, on-premises, or in the cloud, allowing for horizontal scaling, improved performance, and fault tolerance. It enables globally distributed, linearly scalable, multi-model databases.
Read: https://blogs.oracle.com/database/post/oracle-shardingenterprisegrade-distributed-database
Oracle Sharding distributes segments of a data set across many databases (shards) on different computers, on-premises, or in the cloud, allowing for horizontal scaling, improved performance, and fault tolerance. It enables globally distributed, linearly scalable, multi-model databases.
Read: https://blogs.oracle.com/database/post/oracle-shardingenterprisegrade-distributed-database
Oracle
Oracle Sharding:Enterprise-Grade Distributed Database
Oracle Sharding distributes segments of a data set across many databases (shards) on different computers, on-premises, or in the cloud, allowing for horizontal scaling, improved performance, and fault tolerance. It enables globally distributed, linearly scalable…
Operating at Scale Using Resource Tags
Read: https://www.mongodb.com/blog/post/operating-at-scale-using-resource-tags
Read: https://www.mongodb.com/blog/post/operating-at-scale-using-resource-tags
Impactive Makes ESG Integration and Stewardship Reporting Easier for Investment Firms
Read: https://www.mongodb.com/blog/post/impactive-makes-esg-integration-stewardship-reporting-easier-investment-firms
Read: https://www.mongodb.com/blog/post/impactive-makes-esg-integration-stewardship-reporting-easier-investment-firms
MongoDB Partners with NCS to Drive Transformation for ASEAN Businesses and Build Innovative AI Tools
Read: https://www.mongodb.com/blog/post/mongodb-partners-ncs-drive-transformation-asean-businesses-build-innovative-ai-tools
Read: https://www.mongodb.com/blog/post/mongodb-partners-ncs-drive-transformation-asean-businesses-build-innovative-ai-tools
Visma Proceedo Migrates to MariaDB unlocking more than 2x better response times and cost savings
Read: https://mariadb.com/?p=36870
Read: https://mariadb.com/?p=36870
Японский 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/
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/
How Telcos Drive Mission-Critical Innovation and Cost Savings Through Automation
Read: https://www.mongodb.com/blog/post/telcos-drive-mission-critical-innovation-cost-savings-automation
Read: https://www.mongodb.com/blog/post/telcos-drive-mission-critical-innovation-cost-savings-automation
Из цикла ETL: Python для аналитики ad hoc из BigQuery
Рассказали, как создавать запросы с помощью BigQuery API – библиотеки, упрощающей обращение с хранилищем, как записывать и читать данные.
Читать: «Из цикла ETL: Python для аналитики ad hoc из BigQuery»
Рассказали, как создавать запросы с помощью BigQuery API – библиотеки, упрощающей обращение с хранилищем, как записывать и читать данные.
Читать: «Из цикла ETL: Python для аналитики ad hoc из BigQuery»
Tproger
Из цикла ETL: Python для аналитики ad hoc из BigQuery
Рассказали, как создавать запросы с помощью BigQuery API – библиотеки, упрощающей обращение с хранилищем, как записывать и читать данные.
[recovery mode] Какие технологии использует Российская медицина? (ручка/клей/оборотка) Часть первая
Я врач хирург, работаю в одной из гос клиник России, и попробую Вам изложить, есть ли электронные карты пациентов, базы данных с мкб, есть ли клинические рекомендации, и как помогает компьютер в жизни штатного врача стационара и поликлиники.
Читать: https://habr.com/ru/articles/747158/
Я врач хирург, работаю в одной из гос клиник России, и попробую Вам изложить, есть ли электронные карты пациентов, базы данных с мкб, есть ли клинические рекомендации, и как помогает компьютер в жизни штатного врача стационара и поликлиники.
Читать: https://habr.com/ru/articles/747158/
Многомерные базы данных
Многомерные базы данных (МБД) представляют собой эффективные инструменты для организации и анализа больших объемов данных в сфере аналитики. Они представляют данные в форме кубов, где каждая ось представляет собой отдельное измерение, а значения представляются в виде ячеек. Концепция МБД зародилась в конце 1970-х годов.
Многомерные базы данных отличаются от обычных реляционных баз данных тем, что они специально оптимизированы для работы с аналитическими запросами и агрегированными данными. В отличие от традиционных баз данных, где данные хранятся в виде таблиц, в МБД основное внимание уделяется анализу данных и созданию быстрых и эффективных запросов.
Читать: https://habr.com/ru/companies/otus/articles/747204/
Многомерные базы данных (МБД) представляют собой эффективные инструменты для организации и анализа больших объемов данных в сфере аналитики. Они представляют данные в форме кубов, где каждая ось представляет собой отдельное измерение, а значения представляются в виде ячеек. Концепция МБД зародилась в конце 1970-х годов.
Многомерные базы данных отличаются от обычных реляционных баз данных тем, что они специально оптимизированы для работы с аналитическими запросами и агрегированными данными. В отличие от традиционных баз данных, где данные хранятся в виде таблиц, в МБД основное внимание уделяется анализу данных и созданию быстрых и эффективных запросов.
Читать: https://habr.com/ru/companies/otus/articles/747204/
Мониторинг PostgreSQL. Необходимость в информативных счётчиках ресурсов и трассировки
В данной статье хочу поднять тему, которая представляет собой одну большую боль для администраторов, разработчиков и тестировщиков высоконагруженных (и не очень) систем под управлением PostgreSQL. Даже не «боль», а «БОЛЬ»!
Удивительно, что за почти 30 лет существования PostgreSQL не появилось нормальных инструментов для получения вменяемых счетчиков и трассировок. Все, кто работают с MS SQL Server используют профайлер. Это обязательный и привычный инструмент, который позволяет вылавливать запросы, интересные нам в рамках исследования. Вылавливать как все запросы без разбора, так и какие-то единичные запросы, которые удовлетворяют правилам отбора. Кроме того, можно настроить не одну трассу, а столько сколько нужно, с разными фильтрами. Эти трассы содержат очень богатый набор измерений для анализа: – Reads физические и логические; Writes; SPID, Процессорное время; план запроса (хэш плана), количество строк и т.д.
Многие компании стали всерьез рассматривать СУБД PostgreSQL как замену MSSQL и сталкиваются с тем, что возможностей для ее мониторинга просто нет – она как черный ящик, в котором наощупь вылавливаешь какую-ту информацию и пытаешься систематизировать ее хоть как-то.
Читать: https://habr.com/ru/companies/softpoint/articles/747322/
В данной статье хочу поднять тему, которая представляет собой одну большую боль для администраторов, разработчиков и тестировщиков высоконагруженных (и не очень) систем под управлением PostgreSQL. Даже не «боль», а «БОЛЬ»!
Удивительно, что за почти 30 лет существования PostgreSQL не появилось нормальных инструментов для получения вменяемых счетчиков и трассировок. Все, кто работают с MS SQL Server используют профайлер. Это обязательный и привычный инструмент, который позволяет вылавливать запросы, интересные нам в рамках исследования. Вылавливать как все запросы без разбора, так и какие-то единичные запросы, которые удовлетворяют правилам отбора. Кроме того, можно настроить не одну трассу, а столько сколько нужно, с разными фильтрами. Эти трассы содержат очень богатый набор измерений для анализа: – Reads физические и логические; Writes; SPID, Процессорное время; план запроса (хэш плана), количество строк и т.д.
Многие компании стали всерьез рассматривать СУБД PostgreSQL как замену MSSQL и сталкиваются с тем, что возможностей для ее мониторинга просто нет – она как черный ящик, в котором наощупь вылавливаешь какую-ту информацию и пытаешься систематизировать ее хоть как-то.
Читать: https://habr.com/ru/companies/softpoint/articles/747322/