Проект «Одноклассники» Mail.Ru Group, Андрей ПаньгинEYevseyeva
Презентация с технической секции #BitByte - фестиваля профессионального развития, который прошел 19 мая в Санкт-Петербурге.
Андрей Паньгин, Ведущий инженер проекта компании Mail.Ru Group «Одноклассники»: «Незаурядная Java как инструмент разработки высоконагруженного сервера».
Особенности архитектуры распределённого хранилища в Dropbox / Слава Бахмутов ...Ontico
Так как я работаю в позиции SRE (site reliability engineer), то более подробно затрону вопросы того, как мы добились годового durability 99.9999999999% и доступности более 99.99%:
- Изоляция
-- Физическая
--- Хранение данных в разных стойках, датацентрах, с разными версиями оборудования и вендорами.
--- Бэкапы вне основной инфраструктуры.
-- Логическая
--- Слабая связанность компонентов.
--- Не давать падению одного мастера (в зукипере или базе) утащить за собой всю зону.
-- Операционная
--- Процесс релиза.
--- Инструменты деплоя, сборки, хелзчекинга и т.д.
--- Контроль доступа.
- Защита данных
-- Восстановление
--- Восстановление после опасных операций (удаление).
-- Охрана данных и валидация операций
----в том числе от операторов.
- Контроль
-- Все совершают ошибки, нужно уметь детектировать их.
-- Метрики, SRE, OnCall.
-- Различные системы детектирование проблем, не связанные между собой, на каждом уровне систем (хост, кластер, ячейка, дата центр, внешние).
-- Тестирование
--- Disaster recovery testing.
- Автоматизация
-- Быстрое восстановление.
-- Быстрая реакция на события (нет времени реагировать вручную).
-- (introduce autoremedeation systems).
Проект «Одноклассники» Mail.Ru Group, Андрей ПаньгинEYevseyeva
Презентация с технической секции #BitByte - фестиваля профессионального развития, который прошел 19 мая в Санкт-Петербурге.
Андрей Паньгин, Ведущий инженер проекта компании Mail.Ru Group «Одноклассники»: «Незаурядная Java как инструмент разработки высоконагруженного сервера».
Особенности архитектуры распределённого хранилища в Dropbox / Слава Бахмутов ...Ontico
Так как я работаю в позиции SRE (site reliability engineer), то более подробно затрону вопросы того, как мы добились годового durability 99.9999999999% и доступности более 99.99%:
- Изоляция
-- Физическая
--- Хранение данных в разных стойках, датацентрах, с разными версиями оборудования и вендорами.
--- Бэкапы вне основной инфраструктуры.
-- Логическая
--- Слабая связанность компонентов.
--- Не давать падению одного мастера (в зукипере или базе) утащить за собой всю зону.
-- Операционная
--- Процесс релиза.
--- Инструменты деплоя, сборки, хелзчекинга и т.д.
--- Контроль доступа.
- Защита данных
-- Восстановление
--- Восстановление после опасных операций (удаление).
-- Охрана данных и валидация операций
----в том числе от операторов.
- Контроль
-- Все совершают ошибки, нужно уметь детектировать их.
-- Метрики, SRE, OnCall.
-- Различные системы детектирование проблем, не связанные между собой, на каждом уровне систем (хост, кластер, ячейка, дата центр, внешние).
-- Тестирование
--- Disaster recovery testing.
- Автоматизация
-- Быстрое восстановление.
-- Быстрая реакция на события (нет времени реагировать вручную).
-- (introduce autoremedeation systems).
Одноклассники состоят из тысяч серверов, большая часть которых участвует в онлайн обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия, разнообразного и большого по объему. Таким образом, Одноклассники - это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе я расскажу об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также поговорим об авариях в распределенных системах и методах их предупреждения.
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
Инфраструктура от IBM Cloud: Как создать собственное частное облако на VMware...Dinar Garipov
IBM Cloud (IBM Bluemix, ранее – SoftLayer) предоставляет высокопроизводительную, гибкую и масштабируемую облачную инфраструктуру для бизнеса по значительно меньшей цене, чем большинство локальных решений
SETCON'18 - Vitali Fokin - Kubernetes 101Nadzeya Pus
Обзор возможностей Kubernetes, зачем он нужен, кому и когда, а также немного хороших практик по развертыванию и разработке Kubernetes-powered приложений.
MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)Ontico
Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него.
В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Чистая архитектура с VIPER / Сергей Крапивенский (Rambler&Co)Ontico
- Что такое "чистая" архитектура приложений. Чем грозит "грязная" архитектура, чем от нее отличается "чистая" архитектура, и какой от нее профит.
- История появления VIPER.
- Идея VIPER. Как изменяется структура приложения при применении этого подхода.
- Опыт использования VIPER в Rambler&Co. Что мы изменили и добавили.
- Работа с VIPER на примере user story из реального приложения.
- Выводы: чем помогает VIPER и когда его использовать не стоит.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Одноклассники состоят из тысяч серверов, большая часть которых участвует в онлайн обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия, разнообразного и большого по объему. Таким образом, Одноклассники - это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе я расскажу об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также поговорим об авариях в распределенных системах и методах их предупреждения.
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
Инфраструктура от IBM Cloud: Как создать собственное частное облако на VMware...Dinar Garipov
IBM Cloud (IBM Bluemix, ранее – SoftLayer) предоставляет высокопроизводительную, гибкую и масштабируемую облачную инфраструктуру для бизнеса по значительно меньшей цене, чем большинство локальных решений
SETCON'18 - Vitali Fokin - Kubernetes 101Nadzeya Pus
Обзор возможностей Kubernetes, зачем он нужен, кому и когда, а также немного хороших практик по развертыванию и разработке Kubernetes-powered приложений.
MySQL® и MongoDB® - когда что лучше использовать? / Петр Зайцев (Percona)Ontico
Сегодня много дискуссий о том, что лучше - MySQL или PostgreSQL? Однако перед тем, как выбирать именно реляционную базу данных для своего проекта, стоит понять, является ли реляционная база данных наилучшим решением для него.
В рамках этого доклада мы сравним наиболее популярную реляционную базу данных с открытым кодом с наиболее популярным хранилищем документов с открытым кодом. Мы определим, в каких случаях эффективнее всего работает MySQL, а в каких - MongoDB. Мы также рассмотрим ситуации, в которых ни одна из этих баз данных не будет лучшим решением и в которых целесообразно остановить свой выбор на других технологиях.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...Ontico
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Чистая архитектура с VIPER / Сергей Крапивенский (Rambler&Co)Ontico
- Что такое "чистая" архитектура приложений. Чем грозит "грязная" архитектура, чем от нее отличается "чистая" архитектура, и какой от нее профит.
- История появления VIPER.
- Идея VIPER. Как изменяется структура приложения при применении этого подхода.
- Опыт использования VIPER в Rambler&Co. Что мы изменили и добавили.
- Работа с VIPER на примере user story из реального приложения.
- Выводы: чем помогает VIPER и когда его использовать не стоит.
Путь от монолита на PHP к микросервисам на Scala / Денис Иванов (2GIS)Ontico
В своём проекте мы решали следующие задачи:
+ Скорость разработки задачи;
+ Стоимость поддержки задачи;
+ Возможность распараллеливать вычисления и задачи;
+ Возможность максимально просто масштабировать приложение;
+ CI/CD с минимальными усилиями.
Я расскажу о том, как мы решали эти задачи, на какие грабли мы наступали, что из этого всего получилось, и что делать дальше.
Что получили в итоге:
+ Мощь JVM под капотом Scala;
+ 15 минут от нажатия на кнопку "Merge request" до продакшена в 3 датацентра и 6 серверов с прохождением тестов (юнит + функциональные + интеграционные + нагрузочные);
+ 6 нод с приложениями вместо 18 (по 2 в каждом датацентре для отказоустойчивости) с запасом прочности в 60%;
+ Независимые пофичные релизы без даунтайма всех компонентов приложения;
+ Масштабирование только того функционала и в том количестве, которое необходимо данному сервису.
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Построение собственного JS SDK — зачем и как?buranLcme
Многие разработчики любят делать свои велосипеды, но не все задумываются зачем. Мы расскажем о том, зачем вам может понадобится собственный JavaScript SDK и полезно ли кататься на велосипедах.
Мы делали собственный JS SDK для того, чтобы дать возможность создания плагинов в рамках большой enterprise системы - <b>Parallels Automation</b> и <b>Plesk Panel</b>. Сам SDK является частью общего стандарта <b>APS</b>, который является шиной, объединяющей все наши продукты по автоматизации. Обе панели брендируются и мы должны были сохранить брендинг при уже существующей кодовой базе верстки и существующих правилах оформления. И главное - надо было дать возможность создания UI сторонним девелоперам, которые могут иметь абсолютно разный уровень - от пришедших бекэндеров до профессиональных js-разработчиков.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
Дмитрий Лазаренко-«Живая миграция и отказоустойчивость контейнеров в гибридно...Tanya Denisyuk
"Контейнеры могут динамически появляться и исчезать, являются легковесными, не резервируют все необходимые ресурсы при старте, потому их оркестрация дается не простой ценой. Каждый из виртуальных контейнеров в один момент времени может потребовать максимум доступных ему ресурсов и это может привести к тому, что закончатся все ресурсы на физическом сервере, на котором они размещаются. В докладе мы поговорим о механизме, который решает эту непростую задачу, и умеет проводить непрерывную балансировку нагрузки, перемещать контейнеры с одного физического сервера на другие для проведения технических работ без простоя приложений - умная живая миграция (Smart Live Migration).
Многие считают, что контейнеры не подходят для хранения важных данных, т.к. в любой момент они могут упасть и все данные пропадут навсегда. Мы расскажем как этого избежать с помощью технологии Software-defined-storage."
Docker Containers orchestrators: Kubernetes vs. SwarmDmitry Lazarenko
Обзор рынка оркестраторов Docker. Детальное технологическое сравнение Docker Swarm и Kubernetes. Обзор архитектуры и возможностей каждогого из них. Кто лучше справляется с построением масштабируемых микросервисных архитектур
The Dining Man: how does Afisha Restaurants change the behavioral patterns of choice and payments in cafes and restaurants. Based on the real experience of Project Manager
#MBLTdev: Core Data: особенности использования и синхронизация в iCloud (Aviasales)
1. Core Data: особенности
использования и синхронизация в
iCloud
Руслан Шевчук
iOS-разработчик, Aviasales
2. Road Map
• Задачи, которые решаются в приложении Aviasales с помощью
Core Data
• Дизайн модели и устройство стека в приложении Aviasales
• Особенности работы с большими объемами данных,
многопоточность, производительность и совместное
использование данных между контекстами
• Синхронизация Core Data с помощью iCloud: сопутствующие
проблемы
3. Особенности Core Data
• Объектный граф
• Faulting
• Версионность моделей баз данных
• Поддержка KVO
• Синхронизация пользовательских данных c помощью iCloud
4. Особенности Core Data
• Объектный граф
• Faulting
• Версионность моделей баз данных
• Поддержка KVO
• Синхронизация пользовательских данных c помощью iCloud
5. Особенности Core Data
• Объектный граф
• Faulting
• Версионность моделей баз данных
• Поддержка KVO
• Синхронизация пользовательских данных c помощью iCloud
6. Особенности Core Data
• Объектный граф
• Faulting
• Версионность моделей баз данных
• Поддержка KVO
• Синхронизация пользовательских данных c помощью iCloud
7. Особенности Core Data
• Объектный граф
• Faulting
• Версионность моделей баз данных
• Поддержка KVO
• Синхронизация пользовательских данных c помощью iCloud
8. Другие полезные функции Core Data
• Отслеживание изменений и поддержка Undo/Redo операций
• Автоматическая валидация свойств объекта
• Сложные запросы на получение данных из хранилища
• Сортировка и фильтрация
9. Особенности Core Data
• Объектный граф
• Faulting
• Версионность моделей баз данных
• Поддержка KVO
• Синхронизация пользовательских данных c помощью iCloud
11. Стек в
приложении
Aviasales
NSManagedObjectContext
NSManaged
Object
NSManaged
Object
NSManaged
Object
NSPersistantStore
Coordinator
NSPesistant
Store
SQLite
File
System
NSManagedObjectContext
NSManaged
Object
NSManaged
Object
NSManaged
Object
NSPersistantStore
Coordinator
NSPesistant
Store
In-Memory
NSManagedObjectContext
NSManaged
Object
NSManaged
Object
NSManaged
Object
NSPersistantStore
Coordinator
NSPesistant
Store
iCloud
12. Данные внутри
приложения
1. Временные данные
2. Данные, которые мы хотим хранить
3. Данные, которые мы хотим
синхронизировать между
устройствами
3 хранилища данных – одна модель
1 2 3
NSManagedObjectContext
NSManaged
Object
NSManaged
Object
NSManaged
Object
NSPersistantStore
Coordinator
NSPesistant
Store
SQLite
File
System
NSManagedObjectContext
NSManaged
Object
NSManaged
Object
NSManaged
Object
NSPersistantStore
Coordinator
NSPesistant
Store
In-Memory
NSManagedObjectContext
NSManaged
Object
NSManaged
Object
NSManaged
Object
NSPersistantStore
Coordinator
NSPesistant
Store
iCloud
15. Сonfinement Concurrency
NSManagedObjectContext -init
• Отдельные контексты в каждом используемом потоке
• Контекст (MOC) такого типа может использоваться только в
рамках потока или создавшей его очереди
• Устаревший тип контекста, тип по умолчанию для обратной
совместимости
16. Сonfinement Concurrency
NSManagedObjectContext -init
• Отдельные контексты в каждом используемом потоке
• Контекст (MOC) такого типа может использоваться только в
рамках потока или создавшей его очереди
• Устаревший тип контекста, тип по умолчанию для обратной
совместимости
17. Сonfinement Concurrency
NSManagedObjectContext -init
• Отдельные контексты в каждом используемом потоке
• Контекст (MOC) такого типа может использоваться только в
рамках потока или создавшей его очереди
• Устаревший тип контекста, тип по умолчанию для обратной
совместимости
18. Private Queue
NSManagedObjectContext -initWithConcurrencyType:
• MOC обладает своей личной очередью
• Может использоваться только в рамках этой очереди
• При использовании контекста из других потоков предыдущее
условие выполняется помещением задач в очередь блоками
-performBlock: и -performBlockAndWait:
• Сore Data API может безопасно использоваться внутри блоков
19. Private Queue
NSManagedObjectContext -initWithConcurrencyType:
• MOC обладает своей личной очередью
• Может использоваться только в рамках этой очереди
• При использовании контекста из других потоков предыдущее
условие выполняется помещением задач в очередь блоками
-performBlock: и -performBlockAndWait:
• Сore Data API может безопасно использоваться внутри блоков
20. Private Queue
NSManagedObjectContext -initWithConcurrencyType:
• MOC обладает своей личной очередью
• Может использоваться только в рамках этой очереди
• При использовании контекста из других потоков предыдущее
условие выполняется помещением задач в очередь блоками
-performBlock: и -performBlockAndWait:
• Сore Data API может безопасно использоваться внутри блоков
21. Private Queue
NSManagedObjectContext -initWithConcurrencyType:
• MOC обладает своей личной очередью
• Может использоваться только в рамках этой очереди
• При использовании контекста из других потоков предыдущее
условие выполняется помещением задач в очередь блоками
-performBlock: и -performBlockAndWait:
• Сore Data API может безопасно использоваться внутри блоков
22. Преимущества Private Queue над
Confinement Concurrency
• MOC отвечает за доставку блока в правильную очередь
• Возможность производить операции из любого потока с
помощью -performBlock: или -performBlockAndWait:
• Неиспользуемая очередь более эффективна, чем
дополнительный поток
23. Преимущества Private Queue над
Confinement Concurrency
• MOC отвечает за доставку блока в правильную очередь
• Возможность производить операции из любого потока с
помощью -performBlock: или -performBlockAndWait:
• Неиспользуемая очередь более эффективна, чем
дополнительный поток
24. Преимущества Private Queue над
Confinement Concurrency
• MOC отвечает за доставку блока в правильную очередь
• Возможность производить операции из любого потока с
помощью -performBlock: или -performBlockAndWait:
• Неиспользуемая очередь более эффективна, чем
дополнительный поток
25. Main Queue
NSManagedObjectContext -initWithConcurrencyType:
• Особености аналогичны NSPrivateQueueConcurrencyType
• Очередь всегда находится в главном потоке
• Обращение из других потоков помощью блока -performBlock:
26. Main Queue
NSManagedObjectContext -initWithConcurrencyType:
• Особености аналогичны NSPrivateQueueConcurrencyType
• Очередь всегда находится в главном потоке
• Обращение из других потоков помощью блока -performBlock:
27. Main Queue
NSManagedObjectContext -initWithConcurrencyType:
• Особености аналогичны NSPrivateQueueConcurrencyType
• Очередь всегда находится в главном потоке
• Обращение из других потоков c помощью блока -performBlock:
29. Использование Core Data с несколькими
потоками
NSManagedObjectID – универсальный потокобезопасный
идентификатор
• Временный
• Постоянный
30. Использование Core Data с несколькими
потоками
NSManagedObjectID – универсальный потокобезопасный
идентификатор
• Временный
• Постоянный
31. Временный NSManagedObjectID
• Временным идентификатором обладает NSManagedObject ранее
никогда не попадавший в NSPersistenStore
• Невозможно получить материализацию объекта в другом
контексте, используя временный идентификатор
32. Временный NSManagedObjectID
• Временным идентификатором обладает NSManagedObject ранее
никогда не попадавший в NSPersistenStore
• Невозможно получить материализацию объекта в другом
контексте, используя временный идентификатор
33. Постоянный NSManagedObjectID
• Постоянным идентификатор становится сразу после первого
сохранения объекта в хранилище
• Начиная с этого момента, вы можете рематериализовать объект в
другом контексте с помощью метода контекста
NSManagedObjectContext -objectWithID:
• Используйте NSManagedObjectID в случае необходимости передачи
объекта из одного контекста в другой
34. Постоянный NSManagedObjectID
• Постоянным идентификатор становится сразу после первого
сохранения объекта в хранилище
• Начиная с этого момента, вы можете рематериализовать объект в
другом контексте с помощью метода контекста
NSManagedObjectContext -objectWithID:
• Используйте NSManagedObjectID в случае необходимости передачи
объекта из одного контекста в другой
35. Постоянный NSManagedObjectID
• Постоянным идентификатор становится сразу после первого
сохранения объекта в хранилище
• Начиная с этого момента, вы можете рематериализовать объект в
другом контексте с помощью метода контекста
NSManagedObjectContext -objectWithID:
• Используйте NSManagedObjectID в случае необходимости передачи
объекта из одного контекста в другой
37. Вложенные контексты
• Совместное использование несохраненных
изменений между контекстами
MOC 2
Child
MOC 1
Parent
NSPersistant
Store
38. Вложенные контексты
• Родительский контекст является для дочернего хранилищем
данных
• Изменения, совершенные в дочернем контексте, при его
сохранении передаются его родителю
• Возможность использовать временные NSManagedObjectID для
передачи данных между вложенными контекстами
39. Вложенные контексты
• Родительский контекст является для дочернего хранилищем
данных
• Изменения, совершенные в дочернем контексте, при его
сохранении передаются его родителю
• Возможность использовать временные NSManagedObjectID для
передачи данных между вложенными контекстами
40. Вложенные контексты
• Родительский контекст является для дочернего хранилищем
данных
• Изменения, совершенные в дочернем контексте, при его
сохранении передаются его родителю
• Возможность использовать временные NSManagedObjectID для
передачи данных между вложенными контекстами
41. Особенности вложенных контекстов
• Могут использоваться для передачи несохраненных
данных между вложенными контекстами
• Контекст, сохраняя изменения, передает их на один уровень выше
• Метод NSManagedObjectContext -objectWithID: вернет объект в
том состоянии в котором сможет его обнаружить на одном из
самых ближайших уровней
• Родительский контекст должен иметь тип
NSPrivateQueueConcurrencyType или NSMainQueueConcurrencyType
42. Особенности вложенных контекстов
• Могут использоваться для передачи несохраненных
данных между вложенными контекстами
• Контекст, сохраняя изменения, передает их на один уровень выше
• Метод NSManagedObjectContext -objectWithID: вернет объект в
том состоянии в котором сможет его обнаружить на одном из
самых ближайших уровней
• Родительский контекст должен иметь тип
NSPrivateQueueConcurrencyType или NSMainQueueConcurrencyType
43. Особенности вложенных контекстов
• Могут использоваться для передачи несохраненных
данных между вложенными контекстами
• Контекст, сохраняя изменения, передает их на один уровень выше
• Метод NSManagedObjectContext -objectWithID: вернет объект в
том состоянии в котором сможет его обнаружить на одном из
самых ближайших уровней
• Родительский контекст должен иметь тип
NSPrivateQueueConcurrencyType или NSMainQueueConcurrencyType
44. Особенности вложенных контекстов
• Могут использоваться для передачи несохраненных
данных между вложенными контекстами
• Контекст, сохраняя изменения, передает их на один уровень выше
• Метод NSManagedObjectContext -objectWithID: вернет объект в
том состоянии в котором сможет его обнаружить на одном из
самых ближайших уровней
• Родительский контекст должен иметь тип
NSPrivateQueueConcurrencyType или NSMainQueueConcurrencyType
45. iCloud Core Data
• Позволяет решить задачу синхронизации пользовательских
данных
• Накладывает определенные ограничения на то, как вы будете
использовать Core Data.
46. iCloud Core Data
• Позволяет решить задачу синхронизации пользовательских
данных
• Накладывает определенные ограничения на то, как вы будете
использовать Core Data.
47. iCloud Core Data
• Позволяет решить задачу синхронизации пользовательских
данных
• Накладывает определенные ограничения на то, как вы будете
использовать Core Data
48. Задачи, которые решает iCloud в
приложении Aviasales
• Синхронизация хранилища данных
• Авторизация пользователя и смена аккаунтов
• Снимает необходимость в хранении пользовательских данных на
наших серверах и разработки API для транспортировки этих
данных
• Быстрый отклик системы (multi-master replication)
49. Задачи, которые решает iCloud в
приложении Aviasales
• Синхронизация хранилища данных
• Авторизация пользователя и смена аккаунтов
• Снимает необходимость в хранении пользовательских данных на
наших серверах и разработки API для транспортировки этих
данных
• Быстрый отклик системы (multi-master replication)
50. Задачи, которые решает iCloud в
приложении Aviasales
• Синхронизация хранилища данных
• Авторизация пользователя и смена аккаунтов
• Снимает необходимость в хранении пользовательских данных на
наших серверах и разработки API для транспортировки этих
данных
• Быстрый отклик системы (multi-master replication)
51. Задачи, которые решает iCloud в
приложении Aviasales
• Синхронизация хранилища данных
• Авторизация пользователя и смена аккаунтов
• Снимает необходимость в хранении пользовательских данных на
наших серверах и разработки API для транспортировки этих
данных
• Быстрый отклик системы (multi-master replication)
52. Multi-master replication
• Core Data разрешает конфликты, возникающие при
параллельных изменениях данных
• Увеличение доступности всей системы в целом, то есть
уменьшение времени отклика этой системы
53. Multi-master replication
• Core Data разрешает конфликты, возникающие при
параллельных изменениях данных
• Увеличение доступности всей системы в целом, то есть
уменьшение времени отклика этой системы
54. Создание хранилища данных в iCloud
контейнере
• Запросить разрешения на использование iCloud в entitlements
• Передать название вашего хранилища в словаре options по ключу
NSPersistentStoreUbiquitousContentNameKey
NSPersistentStoreCoordinator
-addPersistentStoreWithType:configuration:URL:options:error:
55. События iCloud
• NSPersistentStoreCoordinatorStoresWillChangeNotification
• NSPersistentStoreCoordinatorStoresDidChangeNotification
• NSPersistentStoreDidImportUbiquitousContentChangesNotification
56. NSPersistentStoreDidImportUbiquitousContent
ChangesNotification
• Core Data посылает тогда, когда в ubiquity container происходят
изменения извне
[[NSNotificationCenter defaultCenter]
addObserverForName:NSPersistentStoreDidImportUbiquitousContentChangesNotification
object:persistentStoreCoordinator
queue:queue
usingBlock:^(NSNotification *note) {
[self.managedObjectContext performBlock:^{
[self.managedObjectContext mergeChangesFromContextDidSaveNotification:note];
}];
}];
59. Edge Case №1 – Нарушение консистентности связей
объектов при использовании iCloud Core Data
Билет
Направление
Параметры
Агентство
Появление в хранилище объекта с полностью или частично
отсутствующими связанными объектами
поиска
Цена
60. Edge Case №1 – Нарушение консистентности связей
объектов при использовании iCloud Core Data
Билет
Направление
Параметры
Агентство
Атрибут проверки целостности объекта
поиска
Цена
61. Edge Case №2 – Модель
• Миграция на новую версию модели возможна с использованием
Lightweight Migration (добавление, удаление или переименовывание атрибутов,
записей или объектов)
• Возможность Lightweight Migration опереляется передаваемыми опциями при
создании хранилища данных значениями @YES
NSMigratePersistentStoresAutomaticallyOption и
NSInferMappingModelAutomaticallyOption
NSPersistentStoreCoordinator
-addPersistentStoreWithType:configuration:URL:options:error:
• Сложные миграции iCloud Core Data не поддерживаются
• Упорядоченные связи to-many (NSOrderedSet) не поддерживаются
62. Edge Case №2 – Модель
• Миграция на новую версию модели возможна с использованием
Lightweight Migration (добавление, удаление или переименовывание атрибутов,
записей или объектов)
• Возможность Lightweight Migration опереляется передаваемыми опциями при
создании хранилища данных значениями @YES
NSMigratePersistentStoresAutomaticallyOption и
NSInferMappingModelAutomaticallyOption
NSPersistentStoreCoordinator
-addPersistentStoreWithType:configuration:URL:options:error:
• Сложные миграции iCloud Core Data не поддерживаются
• Упорядоченные связи to-many (NSOrderedSet) не поддерживаются
63. Edge Case №2 – Модель
• Миграция на новую версию модели возможна с использованием
Lightweight Migration (добавление, удаление или переименовывание атрибутов,
записей или объектов)
• Возможность Lightweight Migration опереляется передаваемыми опциями при
создании хранилища данных значениями @YES
NSMigratePersistentStoresAutomaticallyOption и
NSInferMappingModelAutomaticallyOption
NSPersistentStoreCoordinator
-addPersistentStoreWithType:configuration:URL:options:error:
• Сложные миграции iCloud Core Data не поддерживаются
• Упорядоченные связи to-many (NSOrderedSet) не поддерживаются
64. Edge Case №2 – Модель
• Миграция на новую версию модели возможна с использованием
Lightweight Migration (добавление, удаление или переименовывание атрибутов,
записей или объектов)
• Возможность Lightweight Migration опереляется передаваемыми опциями при
создании хранилища данных значениями @YES
NSMigratePersistentStoresAutomaticallyOption и
NSInferMappingModelAutomaticallyOption
NSPersistentStoreCoordinator
-addPersistentStoreWithType:configuration:URL:options:error:
• Сложные миграции iCloud Core Data не поддерживаются
• Упорядоченные связи to-many (NSOrderedSet) не поддерживаются
65. Edge Case №3 – Дедупликация данных
• В приложении Aviasales для каждой функциональной единицы
используется специально созданный менеджер, например,
JRHistoryManager, JRFavouritesManager, JRPassengersManager и
т.д.
• Менеджер возвращает коллекции объектов JRSearchInfo,
JRTicket, JRPassenger и отвечает за процесс дедупликации
66. Edge Case №3 – Дедупликация данных
1. Выявление дублирующихся объектов в хранилище с помощью
специально созданных хешей
2. Выбор критерия определения дубликата
3. Удаление дубликата
67. Источники
Руслан Шевчук
iOS-разработчик, Aviasales
ruslan@jetradar.com
Core Data Documentation
Programming Guides, Examples, Tutorials
http://developer.apple.com/
Apple Developer Forums
http://devforums.apple.com
objc.io
http://www.objc.io
NSHipster
http://nshipster.com
MagicalRecord
https://github.com/magicalpanda/MagicalRecord