Обновление Дельта BI. ChatGPT, PixelPerfect, коннекторы и визуализации
Совсем недавно вышло обновление платформы для бизнес-аналитики Дельта BI с решениями, прорывными для всей отрасли. Учитывая нашу реальность и недоступность глобальных продуктов, обновление ощутимо увеличивает отрыв Дельта BI от ближайших конкурентов на российском рынке. Показываем и рассказываем, почему.
Читать: https://habr.com/ru/articles/749996/
Совсем недавно вышло обновление платформы для бизнес-аналитики Дельта BI с решениями, прорывными для всей отрасли. Учитывая нашу реальность и недоступность глобальных продуктов, обновление ощутимо увеличивает отрыв Дельта BI от ближайших конкурентов на российском рынке. Показываем и рассказываем, почему.
Читать: https://habr.com/ru/articles/749996/
Introducing the Oracle Database Error Help Portal
The Oracle Database Error Help Portal documents all Oracle Database errors, their Causes and the recommended Action for users. It is available under https://docs.oracle.com/error-help/db/
Read: https://blogs.oracle.com/database/post/error-help-portal
The Oracle Database Error Help Portal documents all Oracle Database errors, their Causes and the recommended Action for users. It is available under https://docs.oracle.com/error-help/db/
Read: https://blogs.oracle.com/database/post/error-help-portal
Скорая сервисная помощь: найти и исправить ошибку в коде продукта ушедшего вендора решений для голосовой аналитики
Это история о том, как уход вендора чуть не лишил бизнес голосовой аналитики, как наша сервисная команда занималась реверс-инжинирингом на проекте с SLA 4 часа, искала и исправляла ошибки в коде базы данных с огромным числом зависимостей, обнаружила за собой слежку, избавилась от нее и сохранила отношения с клиентом.
Пятница, утро. Через неделю должен начаться мой долгожданный отпуск, на душе мир и покой. Но когда ты сотрудник сервисной поддержки, ты как спасатель должен быть готов в любую минуту оказаться в совершенно других жизненных обстоятельствах.
Читать: https://habr.com/ru/companies/croc/articles/735442/
Это история о том, как уход вендора чуть не лишил бизнес голосовой аналитики, как наша сервисная команда занималась реверс-инжинирингом на проекте с SLA 4 часа, искала и исправляла ошибки в коде базы данных с огромным числом зависимостей, обнаружила за собой слежку, избавилась от нее и сохранила отношения с клиентом.
Пятница, утро. Через неделю должен начаться мой долгожданный отпуск, на душе мир и покой. Но когда ты сотрудник сервисной поддержки, ты как спасатель должен быть готов в любую минуту оказаться в совершенно других жизненных обстоятельствах.
Читать: https://habr.com/ru/companies/croc/articles/735442/
Книга «SQL Server. Наладка и оптимизация для профессионалов»
Привет, Хаброжители!
Исчерпывающий обзор лучших практик по устранению неисправностей и оптимизации производительности Microsoft SQL Server. Специалисты по базам данных, в том числе разработчики и администраторы, научатся выявлять проблемы с производительностью, системно устранять неполадки и расставлять приоритеты при тонкой настройке, чтобы достичь максимальной эффективности.
Автор книги Дмитрий Короткевич — Microsoft Data Platform MVP и Microsoft Certified Master (MCM) — расскажет о взаимозависимостях между компонентами баз данных SQL Server. Вы узнаете, как быстро провести диагностику системы и найти причину любой проблемы. Методы, описанные в книге, совместимы со всеми версиями SQL Server и подходят как для локальных, так и для облачных конфигураций SQL Server.
Читать: https://habr.com/ru/companies/piter/articles/735424/
Привет, Хаброжители!
Исчерпывающий обзор лучших практик по устранению неисправностей и оптимизации производительности Microsoft SQL Server. Специалисты по базам данных, в том числе разработчики и администраторы, научатся выявлять проблемы с производительностью, системно устранять неполадки и расставлять приоритеты при тонкой настройке, чтобы достичь максимальной эффективности.
Автор книги Дмитрий Короткевич — Microsoft Data Platform MVP и Microsoft Certified Master (MCM) — расскажет о взаимозависимостях между компонентами баз данных SQL Server. Вы узнаете, как быстро провести диагностику системы и найти причину любой проблемы. Методы, описанные в книге, совместимы со всеми версиями SQL Server и подходят как для локальных, так и для облачных конфигураций SQL Server.
Читать: https://habr.com/ru/companies/piter/articles/735424/
Репликация сегментов в OpenSearch
Многие наши коллеги всё больше смотрят в сторону OpenSearch, который постепенно обрастает всё новыми и новыми функциями. В телеграм-канале мы уже публиковали пост с описанием обновлений в версии 2.7, среди которых есть репликация сегментов (есть ещё и поиск по снэпшотам, но о нём как-нибудь в другой раз). Репликация сегментов — это альтернатива репликации документов. При репликации документов все ноды-реплики выполняют ту же операцию индексирования, что и основная нода. При репликации сегментов только основная нода выполняет операцию индексирования, создавая файлы сегментов, которые далее копируются на каждую ноду-реплику. При такой схеме репликации нагрузка по индексированию ложится только на основную ноду, освобождая ресурсы на репликах для использования под другие операции. В этом посте мы расскажем о концепции репликации сегментов, преимуществах и недостатках по сравнению с репликацией документов. Велком ту подкат.
Читать: https://habr.com/ru/articles/733730/
Многие наши коллеги всё больше смотрят в сторону OpenSearch, который постепенно обрастает всё новыми и новыми функциями. В телеграм-канале мы уже публиковали пост с описанием обновлений в версии 2.7, среди которых есть репликация сегментов (есть ещё и поиск по снэпшотам, но о нём как-нибудь в другой раз). Репликация сегментов — это альтернатива репликации документов. При репликации документов все ноды-реплики выполняют ту же операцию индексирования, что и основная нода. При репликации сегментов только основная нода выполняет операцию индексирования, создавая файлы сегментов, которые далее копируются на каждую ноду-реплику. При такой схеме репликации нагрузка по индексированию ложится только на основную ноду, освобождая ресурсы на репликах для использования под другие операции. В этом посте мы расскажем о концепции репликации сегментов, преимуществах и недостатках по сравнению с репликацией документов. Велком ту подкат.
Читать: https://habr.com/ru/articles/733730/
SQL миграции в Postgres. Часть 2
В первой части мы рассмотрели базовые операции, такие как добавление новых атрибутов, создание индексов и ограничений и т.д.
Эта статья посвящена двум более сложным миграциям:
- обновление большой таблицы
- разделение таблицы на две
Рассмотрим подходы, которые позволяют провести миграции с минимальным простоем для приложения.
Читать: https://habr.com/ru/articles/736458/
В первой части мы рассмотрели базовые операции, такие как добавление новых атрибутов, создание индексов и ограничений и т.д.
Эта статья посвящена двум более сложным миграциям:
- обновление большой таблицы
- разделение таблицы на две
Рассмотрим подходы, которые позволяют провести миграции с минимальным простоем для приложения.
Читать: https://habr.com/ru/articles/736458/
Расследуем фантомные чтения с диска в Linux
Не так давно один из наших пользователей сообщил нам о случае странного использования оборудования. Он при помощи нашего клиента ILP (InfluxDB Line Protocol) вставлял строки в свою базу данных QuestDB, но вместе с операциями записи на диск также наблюдались существенные объёмы чтения с диска. Этого никак не ожидаешь от нагрузки, рассчитанной только на запись, поэтому нам нужно было докопаться до причины этой проблемы. Сегодня мы поделимся этой историей, полной взлётов и падений, а также магии ядра Linux.
Читать: https://habr.com/ru/companies/ruvds/articles/736538/
Не так давно один из наших пользователей сообщил нам о случае странного использования оборудования. Он при помощи нашего клиента 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/
Всем привет!
На связи Михаил, и я продолжаю делиться историями про рефакторинг одного из сервисов облачной платформы #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/
Допустим, вам нужно перенести хранилище данных из одного кластера в другой. А выключать его нельзя, потому что это может вызвать незначительный (или значительный) коллапс сервисов, которые с ним работают. В статье мы расскажем о не самом очевидном и популярном способе переноса 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/
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/
Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а также можем предоставить оптимальную конфигурацию для системы, которая передана на эксплуатацию или требует масштабирования. Это может быть кластер 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 — это очень простая и быстрая операция и выполняется мгновенно. Даже для таблиц с миллионами строк она длится миллисекунды. Тем не менее, у некоторых своих клиентов мы столкнулись с очень странной ситуацией, когда производительность системы проседает из‑за того, что запросы с очисткой временных таблиц могут длиться десятки секунд (не миллисекунд, а секунд!). А учитывая количество запросов с временными таблицами в ИТ‑системе на 1С:Предприятие, это время в совокупности становится просто огромным.
Читать: https://habr.com/ru/companies/softpoint/articles/739112/
Этой статьей мы начинаем цикл разбора нетривиальных случаев в нашей практике оптимизации производительности ИТ‑систем. Возможно, кому‑то они пригодятся, так как решения будут нестандартные. Возможно, кто‑то узнает свою ситуацию и поделится своими решениями или наведет на интересную мысль. Ведь, коллективный разум — это сила!
Не секрет, что самой популярной и массовой платформой в России для создания ИТ‑систем для бизнеса является 1С:Предприятие 8.х. На ней разработано огромное количество отраслевых и самописных решений.
Хочу обратить внимание на одну особенность работы приложений 1С, а именно, очень интенсивную работу с временными таблицами СУБД. Подобной интенсивной работы с tempDB, наверное, нет ни в одном тиражном решении в мире.
После завершения пакетного запроса платформа автоматически удаляет временную таблицу, отдавая серверу СУБД команду
<truncate, чтобы освободить ресурсы под следующий запрос. TRUNCATE — это очень простая и быстрая операция и выполняется мгновенно. Даже для таблиц с миллионами строк она длится миллисекунды. Тем не менее, у некоторых своих клиентов мы столкнулись с очень странной ситуацией, когда производительность системы проседает из‑за того, что запросы с очисткой временных таблиц могут длиться десятки секунд (не миллисекунд, а секунд!). А учитывая количество запросов с временными таблицами в ИТ‑системе на 1С:Предприятие, это время в совокупности становится просто огромным.
Читать: https://habr.com/ru/companies/softpoint/articles/739112/
👍1
Tarantool 2.11 LTS: Рассказываем про новые возможности администрирования и безопасности
Привет. Меня зовут Владимир Салыкин, я директор по продукту Tarantool. Мы выпустили Tarantool 2.11 LTS — стабильный релиз с долгим циклом поддержки. Работа над ним началась в мае 2022 года, и сейчас релиз включает в себя более тысячи коммитов от 42 авторов. Мы все много работали над решением основных проблем с обслуживанием и администрированием, с которыми ранее сталкивались наши пользователи.
В этой статье мы хотим рассказать про ключевые фичи, которые были добавлены в релизе.
Читать: https://habr.com/ru/companies/vk/articles/739134/
Привет. Меня зовут Владимир Салыкин, я директор по продукту 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/
Как начать работу с 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/
Как внедрить 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/
Изоляция транзакций в СУБД — важный механизм, который позволяет пользователю получить согласованное состояние данных и работать с ними, не допуская конфликтов и снижения производительности. Организовать изоляцию нужного уровня можно несколькими способами, один из которых — 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/
Всем привет! Ранее я разобрал и протестировал сервер с процессором 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/
Будущее 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/
Две системы, которые я хорошо знаю (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/
Чем заменить на санкционном безрыбье системы хранения данных 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/
Каждый день человечество генерирует порядка 330 млн терабайт данных. Хотя по оценкам экспертов Google всего 10% из них являются свежими и оригинальными, даже копии копий нужно где-то хранить. И эта задача имеет ряд нюансов. Здесь уместно провести аналогию с известным транспортным парадоксом: чем больше дорог строится, тем больше образуется автомобилей, чтобы заполнить их (постулат Льюиса — Могриджа).
Недостаточно построить очень много дата-центров. Один из наиболее очевидных способов сэкономить на хранении данных — это архивирование файлов и сжатие изображений. Есть и другие подходы, которые помогают записать больше данных на диск и быстрее их обрабатывать.
Читать: https://habr.com/ru/companies/cloud_mts/articles/737514/