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

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

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


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

The MongoDB for VS Code Extension Is Now Generally Available

Read: https://www.mongodb.com/blog/post/mongodb-vs-code-extension-now-generally-available

Introducing the Certified MongoDB Atlas Connector for Power BI

Read: https://www.mongodb.com/blog/post/introducing-certified-mongodb-atlas-connector-power-bi

Using JSON documents and don’t know what you’re looking for? 23c Search Indexes to the rescue

Oracle has powerful capabilities for handling JSON. It also has flexible capabilities for full-text searching, like keyword search, phrase search, or proximity search. We're going to see how these capabilities meet in the JSON search index to provide the powerful functionality of full text search in an optimized manner for all your JSON documents

Read: https://blogs.oracle.com/database/post/23c-search-index

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



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

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


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

MariaDB Enterprise 10.6.12-8 now available

Read: https://mariadb.com/?p=36420

How to Handle Seasonal Database Load

Read: https://mariadb.com/?p=36423

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

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


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

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

Чем заменить на санкционном безрыбье системы хранения данных 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/

Accelerating to T+1 - Have You Got the Speed and Agility Required to Meet the Deadline?

Read: https://www.mongodb.com/blog/post/accelerating-t-plus-one-have-you-got-speed-agility-required-meet-deadline

Develop MongoDB Applications with Oracle Autonomous Database on Dedicated Exadata Infrastructure

The blog post showcases the Oracle Database API for MongoDB, enabling integration between MongoDB and Autonomous Database. It highlights the benefits of leveraging ADB's converged capabilities, provides configuration instructions, and demonstrates MongoDB collection migration. The post emphasizes using familiar MongoDB tools while harnessing the power of a converged database, enabling SQL on JSON collections.

Read: https://blogs.oracle.com/database/post/adb-d-mongodb-api

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

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


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

Чей 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/

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

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

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

Ошибка 1. Неправильное определение primary key

Одна из наиболее распространенных ошибок, которую можно совершить при работе с базой данных Cassandra, — неправильное определение primary key.

Primary key в Cassandra состоит из двух частей: partition key и clustering key. Первый определяет, как данные будут распределены по узлам кластера, а второй — как они будут упорядочены внутри partition.

Неправильное определение partition key может привести к тому, что данные будут неэффективно распределены по узлам кластера. Это может привести к «перегреву» последних и неравномерному распределению нагрузки.

Кроме того, ошибка в выборе partition key чревата дублированием данных и увеличением объема записываемых.

Если clustering key определить неправильно, данные внутри partition будут неэффективно упорядочены. Например, запросы на чтение данных могут занимать больше времени, чем нужно, из-за необходимости сортировки данных на уровне приложения.


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

How Edenlab Built a High-Load, Low-Code FHIR Server to Deliver Healthcare for 40 Million Plus Patients

Read: https://www.mongodb.com/blog/post/edenlab-built-high-load-low-code-fhir-server-deliver-healthcare-forty-million-patients

Obsidian — Мой сетап

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

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

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

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

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

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

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

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

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

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

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

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

Autonomous Database Observability (Part 2)

Autonomous Database provides detailed Observability via Oracle Cloud Infrastructure (OCI) services for database monitoring. In Part 1 of this blog series we covered the tools and services available from Oracle to observe and monitor Autonomous Databases (ADB). In this second and final part of the blog series we're covering relevant and popular open source third party tools and services used by developers for observability (now including the database): Prometheus and Grafana.

Read: https://blogs.oracle.com/database/post/autonomous-database-observability-2

Странное поведение MS SQL Server 2019: длительные операции TRUNCATE

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

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

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

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


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