Обновление

dev/architecture/CAP теорема.md

@@ -4,22 +4,15 @@ tags:
   - maturity/🌱
 date:
   - - 2024-03-12
-zero-link:
-  - "[[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]"
-parents: 
-linked: 
 ---
 ![[../../meta/files/images/Pasted image 20241103022605.png]]
 
 CAP теорема — это принцип, описывающий фундаментальные ограничения, с которыми сталкиваются распределённые вычислительные системы в контексте обеспечения следующих трёх свойств:
 - **Согласованность (Consistency)**: Каждый раз, когда данные читаются, возвращается самое последнее записанное значение или ошибка. С другими словами, операции с данными выглядят так, будто выполняются в некоторой строгой последовательности, одна за другой
-- **Доступность (Availability)**: Каждый запрос на получение или запись данных получает ответ, независимо от состояния системы, даже если некоторые части системы вышли из строя.
+- Доступность ([[../../../../_inbox/Availability|Availability]]): Каждый запрос на получение или запись данных получает ответ, независимо от состояния системы, даже если некоторые части системы вышли из строя.
 - **Устойчивость к разделению (Partition Tolerance)**: Система продолжает функционировать, даже если произошло "разделение" — потеря связи между узлами в распределённой сети. То есть система способна переносить произвольное число сообщений, которые задерживаются или теряются в сети.
 
 ==Согласно теореме CAP, в любой момент времени система может обеспечивать только два из этих трёх свойств.== Это означает, что при разработке системы приходится принимать компромисс между этими свойствами в зависимости от требований приложения и условий эксплуатации. Например, если для системы критически важна согласованность данных и её устойчивость к разделению, возможно придётся пожертвовать её доступностью в некоторых сценариях.
-
-
-
 ## Свободные заметки
 - Google заявляет, что их продукт Google Spanner якобы нарушает CAP теорему.
 ***

dev/architecture/highload/Балансировка нагрузки.md

@@ -2,6 +2,7 @@
 aliases:
   - балансировку нагрузки
   - Балансировщик нагрузки
+  - балансировщики нагрузки
 tags:
   - maturity/🌱
 date: 2024-06-13

dev/architecture/highload/Репликация master-master.md

@@ -17,7 +17,7 @@ linked:
 
 **Плюсы**:
 - Нет единой точки отказа
-- Дает максимальный [High Availability](High%20Availability.md).
+- Дает максимальный [Availability](../../../../../_inbox/Availability.md).
 - Легкий failover
 
 **Минусы:**

dev/architecture/highload/Репликация master-slave.md

@@ -19,7 +19,7 @@ linked:
 **Проблемы и недостатки:**
 - Мастер обязательно когда-нибудь упадет. И нужно будет как-то выбрать из slaves нового master.
 - Как и другие способы репликации не ускоряет операции вставки данных.
-- Этот способ никогда не даст 99,9999 [High Availability](High%20Availability.md).
+- Этот способ никогда не даст 99,9999 [Availability](../../../../../_inbox/Availability.md).
 
 Управление master-slave:
 - MHA (MySQL Master HA)

dev/architecture/highload/Репликация БД.md

@@ -20,7 +20,7 @@ linked:
 - Репликация не является [резервной копией БД](Резервные%20копии%20БД.md).
 - Обычно реализуются на базе [[../../database/Журнал БД|журнала БД]].
 - Плюсы:
-	- Помогает улучшить [High Availability](High%20Availability.md). Помогает при падении.
+	- Помогает улучшить [Availability](../../../../../_inbox/Availability.md). Помогает при падении.
 	- Ускоряет чтение данных
 - Проблемы:
 	- Не ускоряет запись в БД
@@ -36,7 +36,7 @@ linked:
 Репликация не отменяет первоначального копирования БД. Сначала нужно первый раз скопировать данные, а потом уже запустить репликацию.
 
 **Для чего делают репликацию?**
-- [[../../../../../_inbox/High Availability|High Availability]]. Если один сервер выходит из строя, другие реплики продолжают обслуживать запросы, обеспечивая непрерывный доступ к данным.
+- [[../../../../../_inbox/Availability|Availability]]. Если один сервер выходит из строя, другие реплики продолжают обслуживать запросы, обеспечивая непрерывный доступ к данным.
 - **Масштабирование чтения**. Нагрузка на чтение может быть распределена между несколькими репликами, что улучшает производительность системы.
 - **Распределение нагрузки**. Сложные аналитические запросы для построения отчетов и асинхронное [резервное копирование БД](Резервные%20копии%20БД.md) могут выполняться на отдельных репликах, не нагружая основной сервер.
 - **Географическое распределение**. Реплики могут быть размещены ближе к пользователям в разных регионах, уменьшая задержки доступа к данным.
@@ -76,7 +76,7 @@ linked:
 ***
 ## Мета информация
 **Область**:: [[../../../meta/zero/00 HighLoad|00 HighLoad]], [[../../../meta/zero/00 DevOps|00 DevOps]], [[../../../meta/zero/00 Реляционная база данных|00 Реляционная база данных]]
-**Родитель**:: [[../../../../../source/курсы/otus/Архитектор высоких нагрузок 2019/Репликация|Репликация]]
+**Родитель**:: [[../../../../../source/курсы/otus/Архитектор высоких нагрузок 2019/Лекция. Репликация|Лекция. Репликация]]
 **Источник**:: 
 **Автор**:: 
 **Создана**:: [[2024-03-10]]

dev/architecture/highload/Репликация.md

@@ -2,6 +2,7 @@
 aliases:
   - зеркалирование
   - репликацию
+  - репликации
 tags:
   - maturity/🌱
 date:

dev/architecture/Архитектурная карта.md

@@ -0,0 +1,47 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-11-26
+---
+Архитектурные карты — это визуальное представление системы, ее структуры, связей и компонентов. Они служат инструментом для анализа, проектирования и коммуникации, упрощая понимание системы всеми заинтересованными сторонами: разработчиками, аналитиками, архитекторами и бизнес-заказчиками.
+
+Архитектурная карта может включать в себя несколько [[Архитектурная схема|архитектурных схем]].
+
+**Зачем нужны архитектурные карты?**
+- **Упрощение коммуникации**. Карты выступают общим языком между командами. Например, разработчики и бизнес могут быстрее обсуждать проблемы и принимать решения, опираясь на общее визуальное представление системы.
+- **Целостное видение системы**. Архитектурные карты помогают увидеть всю систему как единое целое, включая связи между компонентами и взаимодействие с внешними системами.
+- **Выявление “слепых зон”**. Визуализация выявляет незадокументированные связи, зависимости и потенциальные уязвимости.
+- **Анализ и планирование изменений**. Карты позволяют моделировать изменения, предсказывать их влияние и оценивать риски.
+
+  
+
+**Виды архитектурных карт**
+- **Концептуальные карты**. Они описывают общую идею системы и ее назначение.
+	- Упор на крупные блоки системы (например, модули или бизнес-процессы).
+	- Подходят для общения с бизнес-заказчиками.
+- **Логические карты**. Подробное описание структуры системы: модули, компоненты и их взаимодействие.
+	- Включают элементы архитектуры ПО, не зависящие от конкретной реализации.
+	- Используются для проектирования и анализа решений на уровне разработки.
+- **Физические карты**. Описывают конкретную реализацию системы: сервера, базы данных, сети и прочее.
+	- Применяются при развертывании и поддержке системы.
+	- Подходят для DevOps, инфраструктурных инженеров и архитекторов.
+
+**Как создавать и поддерживать карты?**
+- **Определите цель карты**. Например, если задача — объяснить бизнесу назначение системы, стоит сделать концептуальную карту.
+- **Используйте подходящие инструменты**. Для создания архитектурных карт популярны инструменты вроде Lucidchart, Draw.io, PlantUML и [[ArchiMate]].
+- **Обеспечьте актуальность**. Регулярно обновляйте карты при изменении системы, чтобы они оставались полезными и точными.
+- **Уточняйте уровень детализации**. Для разных целей нужны разные уровни абстракции. Например, высокоуровневый обзор для презентаций и более детальная схема для команды разработки.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-26]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Архитектурная схема.md

@@ -0,0 +1,57 @@
+---
+aliases:
+  - архитектурные схемы
+  - архитектурных схем
+tags:
+  - maturity/🌱
+date: 2024-11-26
+---
+Архитектурная схема — это детализированное визуальное представление структуры и функционирования системы. Она помогает понять, как устроена система, какие компоненты входят в её состав и как они взаимодействуют друг с другом.
+
+**Основная цель архитектурной схемы**
+- **Технической документации** — фиксации текущего состояния системы.
+- **Разработки и тестирования** — схемы позволяют командам лучше понимать структуру системы и её компоненты.
+- **Оптимизации и масштабирования** — упрощают анализ узких мест и прогнозирование последствий изменений.
+- **Устранения ошибок** — помогают найти и исправить проблемы благодаря наглядности взаимодействий.
+
+**Виды архитектурных схем**
+- **Модульная схема**. Отображает модули системы и их взаимодействия.
+	- Применяется для анализа высокоуровневой структуры ПО.
+	- Удобна на этапе проектирования или реструктуризации системы.
+- **Компонентная схема**. Фокусируется на более детальном описании архитектуры компонентов и их связей.
+	- Используется для анализа взаимозависимостей и проектирования новых компонентов.
+- **Схема потоков данных (Data Flow Diagram)**. Показывает, как данные перемещаются между модулями и компонентами. Полезна для проектирования интеграции и анализа производительности.
+- **Инфраструктурная схема** Описывает физическую реализацию системы: сервера, сети, базы данных и т.д. Используется для DevOps и управления инфраструктурой.
+
+**Основные элементы архитектурной схемы**
+- **Компоненты** — отдельные части системы, такие как модули, сервисы или базы данных.
+- **Интерфейсы** — точки взаимодействия между компонентами (например, API).
+- **Связи** — связи или зависимости между компонентами, указывающие на передачу данных или управление.
+- **Процессы и потоки данных** — движения информации внутри системы.
+
+**Как создать архитектурную схему?**
+- **Определите цель**. Зачем создается схема? Для документации, обсуждения с командой или анализа системы? От цели зависит уровень детализации.
+- **Соберите информацию**. Перечислите все компоненты системы, их взаимодействия и внешние зависимости.
+- **Выберите инструмент**. Для создания схем можно использовать инструменты, такие как Draw.io, PlantUML, Lucidchart или Visio.
+- **Обеспечьте ясность**. Убедитесь, что схема легко читается, избегайте избыточной детализации. Используйте условные обозначения и комментарии.
+- **Актуализируйте схему**. При изменении системы своевременно вносите изменения в схему, чтобы она оставалась полезной.
+
+**Пример архитектурной схемы**
+Представьте распределённую систему с микросервисной архитектурой. Архитектурная схема может включать:
+- Микросервисы (компоненты) и их функции.
+- API и форматы данных для взаимодействия между сервисами.
+- Потоки данных между сервисами и базами данных.
+- Инфраструктуру развёртывания (например, кластер Kubernetes, базы данных, брокеры сообщений).
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-26]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Брокер сообщений.md

@@ -2,6 +2,7 @@
 aliases:
   - брокерами сообщений
   - очереди сообщений
+  - брокеры сообщений
 tags:
   - maturity/🌱
 date: 2024-07-02

dev/architecture/Зависимости микросервисов.md

@@ -0,0 +1,56 @@
+---
+aliases:
+  - связи микросервисов
+tags:
+  - maturity/🌱
+date: 2024-11-26
+---
+В [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисной архитектуре]] каждый [[Микросервис|сервис]] имеет зависимости, которые можно разделить на **входящие** и **исходящие**:
+- **Входящие зависимости** — это другие сервисы или клиенты, которые полагаются на данный сервис для выполнения своих задач.
+- **Исходящие зависимости** — это внешние системы или микросервисы, от которых данный сервис зависит для выполнения своих функций.
+## Входящие зависимости
+Сервисы с высокой входящей зависимостью обычно выполняют функции, на которых завязаны многие другие компоненты. Отказ такого сервиса может привести к масштабным сбоям, поэтому требуется масштабируемость, мониторинг и резервирование.
+
+Чем больше входящих зависимостей, тем выше вероятность перегрузки сервиса, особенно в моменты пиковых запросов. Например, сервис авторизации, на который завязаны все остальные микросервисы.
+## Исходящие зависимости
+Сервисы с множеством исходящих зависимостей сильно зависят от доступности и стабильности внешних систем.
+
+Чем больше исходящих зависимостей, тем сложнее проводить изолированные тесты сервиса. Для таких случаев требуются mock-объекты или тестовые среды.
+
+Высокое число исходящих зависимостей может замедлять работу сервиса из-за сетевых задержек, ограничения пропускной способности или API-лимитов.
+## Типы микросервисов на основе зависимостей
+- **Центральные (Hub)**
+	- Много входящих зависимостей, мало исходящих.
+	- Выполняют ключевые функции, от которых зависят другие.
+	- Пример: [[API Gateway]] или сервис аутентификации.
+- **Агрегаторы**
+	- Много исходящих зависимостей, среднее число входящих.
+	- Сбор и обработка данных из множества источников.
+	- Пример: сервис аналитики или отчётности.
+- **Специализированные (Leaf)**
+	- Мало входящих и исходящих зависимостей.
+	- Выполняют автономные задачи, минимально влияя на другие части системы.
+	- Пример: сервис генерации отчетов.
+- **Мосты (Bridge)**
+	- Баланс между входящими и исходящими зависимостями.
+	- Соединяют разные домены или внешние API с внутренними сервисами.
+- Пример: сервис интеграции с внешней платежной системой.
+## Рекомендации
+- **Минимизируйте исходящие зависимости**. Ограничьте количество внешних систем, от которых зависит сервис. Агрегируйте зависимости, чтобы уменьшить количество прямых связей.
+- **Делайте отказоустойчивые сервисы с высокой входящей зависимостью**. Используйте [[кэширование]], [[highload/Балансировка нагрузки|балансировщики нагрузки]] и [[highload/Горизонтальное масштабирование|горизонтальное масштабирование]], чтобы снизить риски.
+- **Используйте асинхронные коммуникации**. Асинхронные подходы (например, через [[Брокер сообщений|брокеры сообщений]]) помогают уменьшить плотность зависимостей и снизить нагрузку.
+- **Мониторьте зависимости**. Отслеживайте состояние входящих и исходящих зависимостей с помощью [[Архитектурная схема|архитектурных схем]], чтобы своевременно выявлять узкие места и проблемы.
+- **Сегментируйте систему** Разделение архитектуры на домены помогает уменьшить плотность зависимостей и сделать систему более управляемой.
+***
+## Мета информация
+**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-26]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Идемпотентность.md

@@ -3,6 +3,8 @@ aliases:
   - идемпотентны
   - идемпотентной
   - идемпотентности
+  - идемпотентную
+  - идемпотентные
 tags:
   - maturity/🌱
 date: 2024-09-11

dev/architecture/Микросервис.md

@@ -9,10 +9,14 @@ tags:
 date: 2024-11-24
 ---
 Идеальный микросервис:
-- [[Single Responsibility Principle|Единственная ответственность]]
+- [[Single Responsibility Principle|Единственная ответственность]] и [[Bounded Context|Ограниченный контекст]]. Микросервисы часто строятся вокруг ограниченных контекстов. Один контекст может соответствовать одному микросервису, что упрощает его разбиение, разработку и поддержку. Однако, важно помнить, что ограниченный контекст — это не архитектурный паттерн, а концепция предметной области. Поэтому очень часто за обработку данных одного контекста отвечает множество сервисов.
-- [[Bounded Context|Ограниченный контекст]]. Микросервисы часто строятся вокруг ограниченных контекстов. Один контекст может соответствовать одному микросервису, что упрощает его разбиение, разработку и поддержку. Однако, важно помнить, что ограниченный контекст — это не архитектурный паттерн, а концепция предметной области. Поэтому очень часто за обработку данных одного контекста отвечает множество сервисов.
+- Низкая [[Связанность|связанность]] и высокая [[связность]]
-- [[Связанность]] и [[связность]]
+
-- Принцип проектирования пакетов/сборок
+- [[Зависимости микросервисов]]
+## Заметки
+- Сервис имеет входящие и исходящие зависимости на другие сервисы. Чем более общий сервис мы строим, тем меньше входящих зависимостей должно быть, то есть сервис не должен зависеть от других сервисов. Например, сервис хранения настроек других сервисов или сервис хранения файлов, он практически не должны зависеть от других сервисов.
+
+
 ***
 ## Мета информация
 **Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]

dev/database/Колоночная база данных.md

@@ -0,0 +1,50 @@
+---
+aliases:
+  - Columnar Databases
+tags:
+  - maturity/🌱
+date: 2024-11-26
+---
+**Колоночные базы данных** (Columnar Databases) — это системы управления базами данных, которые хранят данные столбцами, а не строками, как в традиционных реляционных базах данных. Этот подход имеет важные преимущества в задачах аналитики и обработки больших объемов данных.
+
+Вместо того чтобы хранить данные построчно, как это делает реляционная база данных
+
+![[../../meta/files/images/Pasted image 20241126185848.png]]
+
+колоночные базы данных хранят данные в виде отдельных столбцов.
+
+![[../../meta/files/images/Pasted image 20241126185910.png]]
+
+
+Колоночные базы данных широко используются в системах, где важно быстро анализировать большие объемы данных. Примеры:
+- [[../../../../source/доклады/00 ClickHouse|ClickHouse]] — быстрая аналитика и построение отчетов.
+- **Amazon Redshift** — облачные хранилища данных.
+- Apache [[Cassandra]] и **HBase** — большие распределенные хранилища.
+
+**Преимущества**
+- **Ускорение аналитических запросов**: При агрегациях и фильтрациях задействуются только те столбцы, которые участвуют в запросе. При этом данные одного типа лежат последовательно. Это значительно сокращает объем данных, которые нужно считывать с диска.
+- **Эффективное сжатие данных**: Данные в одном столбце имеют схожую природу (например, возраст — целые числа), что позволяет применять более эффективные алгоритмы сжатия, такие как RLE (Run Length Encoding) или Dictionary Encoding.
+- **Снижение нагрузки на I/O**: Извлечение только нужных столбцов уменьшает объем операций ввода-вывода.
+
+**Недостатки**
+- **Меньшая эффективность для транзакционных операций**: Записи и обновления, которые влияют на большое количество столбцов, требуют больше операций, чем в реляционных базах.
+- **Усложнение работы с несжатыми или разреженными данными**: Если данные столбца не поддаются сжатию или содержат много пропусков, преимущества колоночного подхода снижаются.
+- **Требования к особенностям использования**: Колоночные базы данных не подходят для [[Online Transaction Processing|OLTP]], так как их структура оптимизирована под аналитические нагрузки ([[Online Analytical Processing|OLAP]]).
+
+Они применяются:
+- В бизнес-аналитике (BI), где важны агрегации и построение отчетов.
+- В системах мониторинга, где обрабатываются метрики (логирование, мониторинг систем).
+- В рекомендационных системах для анализа больших массивов пользовательских данных.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
+**Родитель**:: [[../Тип хранилища данных|Тип хранилища данных]]
+**Источник**:: 
+**Создана**:: [[2024-11-26]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/database/Таблицы сателиты.md

@@ -72,7 +72,7 @@ client_id | address | city | country | start_date | end_date | is_current | reco
 **Создана**:: [[2024-11-25]]
 **Автор**:: 
 ### Дополнительные материалы
-- 
+- [Введение в Data Vault / Хабр](https://habr.com/ru/articles/348188/)
 
 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

dev/fundamental/Сжатие данных.md

@@ -1,5 +1,6 @@
 ---
 aliases:
+  - Компрессия данных
 tags:
   - maturity/🌱
 date: 2024-09-14

dev/java/Сохранение HeapDump.md

@@ -0,0 +1,32 @@
+---
+aliases:
+  - HeapDumpOnOutOfMemoryError
+  - HeapDumpPath
+tags:
+  - maturity/🌱
+date: 2024-11-25
+---
+При запуске Java-приложения с помощью следующей команды:
+```shell
+/app/jdk/bin/java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/oom.bin -jar your-app.jar
+```
+
+параметры `-XX:+HeapDumpOnOutOfMemoryError` и `-XX:HeapDumpPath=/dumps/oom.bin` позволяют автоматически сохранить heap dump в файл `/dumps/oom.bin` при возникновении ошибки `OutOfMemoryError`.
+
+**Рекомендации:**
+- Убедитесь, что каталог `/dumps` существует.
+- Проверьте, что у процесса Java есть права на запись в этот каталог.
+- Если каталог отсутствует или недостаточно прав, heap dump может не сохраниться.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Java разработка|00 Java разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-25]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/Посмотренные доклады по разработке.md

@@ -4,7 +4,8 @@ tags:
   - maturity/🌱
 date: 2024-11-05
 ---
-- [[2024-11-24]]. (6/10) [Гранулярность микросервисов. Как мелко нарезать? / Руслан Сафин (Byndyusoft) - YouTube](https://www.youtube.com/watch?v=x1xqlXnyXp8)
+- [[2024-11-25]]. (5/10) [[../../../source/курсы/_toc/Архитектор высоких нагрузок - OTUS 2019|Архитектор высоких нагрузок - OTUS 2019]]. OLAP и OLTP (часть 1)
+- [[2024-11-24]]. (3/10) [Гранулярность микросервисов. Как мелко нарезать? / Руслан Сафин (Byndyusoft) - YouTube](https://www.youtube.com/watch?v=x1xqlXnyXp8)
 - [[2024-11-05]]. (4/10) [Топ ошибок со стороны разработки при работе с PostgreSQL / Алексей Лесовский (Data Egret) - YouTube](https://www.youtube.com/watch?v=HjLnY0aPQZo&t=17s)
 - [[2024-11-05]]. (7/10) [Владимир Ситников — B-Tree индексы в базах данных на примере Spring Boot-приложений, PostgreSQL, JPA - YouTube](https://www.youtube.com/watch?v=y-Wtyvme4gE)
 - [[2024-11-05]]. (8/10) [Владимир Ситников — B-tree индексы в базах данных на примере PostgreSQL - YouTube](https://www.youtube.com/watch?v=mnEU2_cwE_s)

dev/Тип хранилища данных.md

@@ -5,7 +5,7 @@ tags:
 date: 2024-11-24
 ---
 - [[../meta/zero/00 Реляционная база данных|Реляционная база данных]]. Каждая строка представляет собой уникальную запись, каждый столбец является полем в записи.
-- Колонночная база данных. Хранят данные по столбцам. Оптимизированы для выполнения сложных аналитических запросов на больших наборах данных.
+- [[database/Колоночная база данных|Колоночная база данных]]. Хранят данные по столбцам. Оптимизированы для выполнения сложных аналитических запросов на больших наборах данных.
 - Документная база данных. Данные полуструктурированы и закодированы в форматах, таких как JSON, BSON или XML.
 - Графовая база данных. Сущности представлены в виде узлов, а отношения между ними — в виде рёбер. Теория графов используется для хранения и выполнения запросов.
 - [[Key-Value хранилище]]. Каждое значение в базе данных ассоциируется с уникальным ключом.
@@ -26,5 +26,6 @@ date: 2024-11-24
 <!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 - [[00 Реляционная база данных]]
 - [[Key-Value хранилище]]
+- [[Колоночная база данных]]
 <!-- SerializedQuery END -->
 

meta/files/images/comp/Pasted image 20241126185848.png.md5

@@ -0,0 +1 @@
+2a8401cc4b3675f9538a2a130f10beb9

meta/files/images/comp/Pasted image 20241126185910.png.md5

@@ -0,0 +1 @@
+9ceab57616ec783835f4de949dc03fa4

meta/files/images/webp/Pasted image 20241126185848.webp.md5

@@ -0,0 +1 @@
+2a8401cc4b3675f9538a2a130f10beb9

meta/files/images/webp/Pasted image 20241126185910.webp.md5

@@ -0,0 +1 @@
+9ceab57616ec783835f4de949dc03fa4

meta/zero/00 HighLoad.md

@@ -76,7 +76,7 @@ aliases:
 - Защита от [DDOS](DDOS.md)
 - Защита от [Slashdot-эффект](Slashdot-эффект.md)
 
-- [High Availability](High%20Availability.md)
+- [Availability](../../../../_inbox/Availability.md)
 - [Reliability](Reliability.md)
 - [Disaster recovery](Disaster%20recovery.md)
 

meta/zero/00 Архитектура ИС.md

@@ -20,5 +20,7 @@ aliases:
 - [[00 HighLoad|HighLoad]]
 
 - [[../../dev/system-design/Протоколы коммуникаций|Протоколы коммуникаций]]
+## Заметки
+- На проекте вести архитектурные карты, где указаны связи между сервисами
 ## Полезное
 - [GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.](https://github.com/ByteByteGoHq/system-design-101)