- Обзор систем хранения данных
- Что такое Realm?
- Realm изнутри и почему он такой быстрый
- Сравнение производительности мобильных баз данных
- Практика использования
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Андрей Федоренчик- «Высоконагруженная система с аналитикой на InfoBright»Tanya Denisyuk
Наша рекламная сеть прошла путь от 1М до 150M показов в сутки. На этом пути пришлось столкнуться с проблемами при логировании и анализе больших объемов данных. В итоге отказались от использования NonSQL базы данных и выбрали column-based InfoBright. В своем докладе я расскажу, как мы накапливаем, храним, обрабатываем и анализируем сотни гигабайт информации в день c использованием InfoBright.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Андрей Федоренчик- «Высоконагруженная система с аналитикой на InfoBright»Tanya Denisyuk
Наша рекламная сеть прошла путь от 1М до 150M показов в сутки. На этом пути пришлось столкнуться с проблемами при логировании и анализе больших объемов данных. В итоге отказались от использования NonSQL базы данных и выбрали column-based InfoBright. В своем докладе я расскажу, как мы накапливаем, храним, обрабатываем и анализируем сотни гигабайт информации в день c использованием InfoBright.
Антон Щербаков, Отказоустойчивость на примере aviasales — почему даже если на...Tanya Denisyuk
В докладе на примере системы метапоиска aviasales будет рассмотрен переход от монолитной архитектуры RoR приложения к многозвенной системе внутренней разработки на базе tornado/python в целях ослабления зависимостей между подсистемами, упрощения контроля за потоком данных и изоляции потенциальных аварийных ситуаций.
Будут рассмотрены побочные эффекты этого перехода, такие как устойчивость к пиковым нагрузкам, упрощение схемы выкатки обновлений и сокращение потребляемых машинных ресурсов.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
NAS, Predictions, Preloading, Presudo-Isomorphism / Охрименко Алексей (Acronis)Ontico
На примере фреймворка COD.js ( c React as View Layer ) и топовых продуктов фирмы Acronis мы увидим, каких удивительных результатов можно добиться используя:
1) NAS — неблокирующее состояние приложения;
2) Predictions — дизайн-паттерн, позволяющий предсказывать состояния системы и производить так называемую "latency conpensation" — технику, которую очень любят в Game Dev;
3) Preloading — стандартную и всем знакомую технику, у которой есть пара интересных способов применения, заслуживающих внимания;
4) Presudo-Isomorphism — очень хитрую технику, которую так активно использует Facebook.
Все это будет показано на примере реальных продуктов. С простыми и понятными примерами, которые можно будет применить в любом продукте.
Реалтайм статистика скорости работы нативных и веб-приложений у реальных поль...Ontico
Расскажу, как сделана статистика и аналитика скорости работы (UX) приложений badoo (web, mobile-web, ios, android, windows).
Общие концепции и примеры, что и как измерять.
Как собирать данные со 100% пользователей проекта и выдержать нагрузку.
Как из open-source решений собрать систему сбора и визуализации статистики для своего проекта.
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Многие сайты измеряют время формирования странички, хотя на самом деле надо измерять время у пользователя. Тут рассказывается как это делать, и почему доставка страничек может занимать 10 секунд, при ping 100ms
Михаил Табунов, Аналитическая платформа на несколько миллиардов событий в месяцTanya Denisyuk
Доклад про:
– развитие архитектуры этой системы, как менялись и как будут меняться требования к такого рода системам
– анализ подходящих под эту систему БД, с их проблемами, и опытом реальной эксплуатации
– почему мы остановились на MongoDB, со всеми минусами и плюсами
– немного про команду, трудозатраты и поддержку
– как мы используем эту систему и как она помогает растить наши продукты
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Zabbix в Badoo или о чем не пишут в мануале, Илья Аблеев (Badoo)Badoo Development
Доклад с Zabbix Meetup.
Рассказали про:
• Сколько инстансов используем, зачем, какая конфигурация и нагрузка, какие дополнительные тулзы используем.
• Деплой скриптов/конфигов/обновлении.
• Флоу появления новых сущностей в мониторинге: хостов, проверок, графиков в заббикс. Самописный дискавери (серверов, сервисов): почему свой и что он умеет.
• Штуки для удобства: нотификации на рабочий стол, быстрая навигация по графикам.
Антон Щербаков, Отказоустойчивость на примере aviasales — почему даже если на...Tanya Denisyuk
В докладе на примере системы метапоиска aviasales будет рассмотрен переход от монолитной архитектуры RoR приложения к многозвенной системе внутренней разработки на базе tornado/python в целях ослабления зависимостей между подсистемами, упрощения контроля за потоком данных и изоляции потенциальных аварийных ситуаций.
Будут рассмотрены побочные эффекты этого перехода, такие как устойчивость к пиковым нагрузкам, упрощение схемы выкатки обновлений и сокращение потребляемых машинных ресурсов.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Эволюция процесса деплоя в проекте / Денис Яковлев (2ГИС)Ontico
Если наш проект — это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готового кода в боевое окружение.
В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилиты, библиотеки и т.д.), новые сущности (балансеры, кэшы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем, нежели решений, люди ошибаются чаще и т.д.
В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.
NAS, Predictions, Preloading, Presudo-Isomorphism / Охрименко Алексей (Acronis)Ontico
На примере фреймворка COD.js ( c React as View Layer ) и топовых продуктов фирмы Acronis мы увидим, каких удивительных результатов можно добиться используя:
1) NAS — неблокирующее состояние приложения;
2) Predictions — дизайн-паттерн, позволяющий предсказывать состояния системы и производить так называемую "latency conpensation" — технику, которую очень любят в Game Dev;
3) Preloading — стандартную и всем знакомую технику, у которой есть пара интересных способов применения, заслуживающих внимания;
4) Presudo-Isomorphism — очень хитрую технику, которую так активно использует Facebook.
Все это будет показано на примере реальных продуктов. С простыми и понятными примерами, которые можно будет применить в любом продукте.
Реалтайм статистика скорости работы нативных и веб-приложений у реальных поль...Ontico
Расскажу, как сделана статистика и аналитика скорости работы (UX) приложений badoo (web, mobile-web, ios, android, windows).
Общие концепции и примеры, что и как измерять.
Как собирать данные со 100% пользователей проекта и выдержать нагрузку.
Как из open-source решений собрать систему сбора и визуализации статистики для своего проекта.
Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh / Миша Кир...Ontico
Разговор в докладе пойдёт о веб-программировании.
При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.
Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.
Хочу поделиться со слушателями своим личным опытом разработки с использованием подобной связки. Планирую рассказать о плюсах и минусах такого подхода.
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Многие сайты измеряют время формирования странички, хотя на самом деле надо измерять время у пользователя. Тут рассказывается как это делать, и почему доставка страничек может занимать 10 секунд, при ping 100ms
Михаил Табунов, Аналитическая платформа на несколько миллиардов событий в месяцTanya Denisyuk
Доклад про:
– развитие архитектуры этой системы, как менялись и как будут меняться требования к такого рода системам
– анализ подходящих под эту систему БД, с их проблемами, и опытом реальной эксплуатации
– почему мы остановились на MongoDB, со всеми минусами и плюсами
– немного про команду, трудозатраты и поддержку
– как мы используем эту систему и как она помогает растить наши продукты
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...Ontico
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Zabbix в Badoo или о чем не пишут в мануале, Илья Аблеев (Badoo)Badoo Development
Доклад с Zabbix Meetup.
Рассказали про:
• Сколько инстансов используем, зачем, какая конфигурация и нагрузка, какие дополнительные тулзы используем.
• Деплой скриптов/конфигов/обновлении.
• Флоу появления новых сущностей в мониторинге: хостов, проверок, графиков в заббикс. Самописный дискавери (серверов, сервисов): почему свой и что он умеет.
• Штуки для удобства: нотификации на рабочий стол, быстрая навигация по графикам.
JS Fest 2019. Игорь Березин и Николай Крещенко. Эволюция архитектуры многогра...JSFestUA
За 3 года существования, “Koyfin” претерпел множество изменений.
Проект прошел путь от MVP до сложной системы сбора и обработки большого количества финансовых данных с десятками микросервисов и тоннами логики. Как жить, когда проект содержит огромное количество репозиториев, микросервисы отправляют и читают из шины тысячи разношерстных сообщений в минуту и кажется, что от попыток за всем уследить скоро взорвется голова? Как поддерживать консистентность, скорость, отказоустойчивость и при этом сохранять гибкость?
Мы рассмотрим с Вами основные проблемы, с которыми мы столкнулись, и поделимся результатами творческих мук в поиске их решения. Расскажем об инструментах и техниках, которые помогают нам каждый день
Разработка API для большого, нагруженного сервисаendeveit
Рассказ о том, что творилось с проектами kolesa.kz и krisha.kz в 2011-2012 годах и что происходит сейчас, как мы создавали с нуля API и впоследствии переезжали на него, как на лету меняли хранилища данных, как боролись с нагрузками и воевали за надежность, расскажу о граблях на которые наступили и как их можно было бы избежать.
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Similar to Moбильная база данных Realm. Прошло ли время SQLite? (20)
6. Pure SQLite
● Сложность эффективного
использования
● Мапинг и извлечение данных
● Управление миграциями
● Многопоточный доступ
Но зато, БЫСТРО
7. Core Data
● Большой порог вхождения, для
новичков
● Много шаблонного кода
● Хитрая передача данных между
потоками
● Непрозрачные операции
● iOS only
● Производительность
12. Конкурентный доступ: state 1
READ
ID NAME NOTES
1 Alex c++ developer
2 Jim java developer
3 Bill php developer
13. Конкурентный доступ: state 2
UPD
ID NAME NOTES
1 Alex c++ developer
2 Jim ios developer
3 Bill php developer
14. Конкурентный доступ: state 1
DEL
ID NAME NOTES
1 Alex c++ developer
2 Jim java developer
3 Bill php developer
15. Конкурентный доступ: state 3
READ
ID NAME NOTES
1 Alex c++ developer
2 Jim ios developer
3 Bill php developer
16. MVCC
● Multi Version Concurrency Control
● Одновременный доступ с разных
потоков
● Каждая транзакция имеет свой
слепок базы данных
● Изоляция изменений
● Минимальные накладные расходы
23. MVCC
● Запись выполняется только
дописыванием
● Обеспечивает доступ из разных
потоков
● Запись не блокирует чтение
● Безопасность исходных данных
● Производительность
24. Ссылки
● Realm это огромное b+ дерево
● Получить объекты по связи To-One или To-
many это дешевые операции
● Связи это просто указатели
● Дешевая навигация по объектам
31. Запросы
● Все базовые операторы, вложенные запросы
● Поддержка операций с коллекциями @min, @max,
@sum, @count, @avg
● Операторы работы с массивами и множествами
● Подзапросы по связям
